Hi Tatsuki, <br><br><div class="gmail_quote">On Fri, Aug 7, 2009 at 1:42 AM, Tatsuki Sakushima <span dir="ltr"><<a href="mailto:tatsuki@nri.com">tatsuki@nri.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Nat,<br>
<br>
I read the document. Here is my comments:<br>
<br>
-This contract data may be out of scope but could be in the spec<br>
since this spec defines "Contract Exchange".</blockquote><div><br>I can assure you that it is NOT out of scope. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
-Contract data could be big, therefore it should not be transmitted<br>
in a indirect communication channel. It should be always in a direct<br>
communication. The key to reference the data should be transmitted<br>
either direct or indirect communication. The key MUST be small enough<br>
for mobile phones to exchange in a protocol.</blockquote><div><br>Agreed. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
-Contract data can be written in many forms(XML preferred?). It should be extensible<br>
(flexible) and detachable from a protocol.</blockquote><div><br>Agreed. We can think of XML, XDI, JSON, etc., but from the point of view of the library reuse, XML seems to be a logical choice. Also, XML has added benefit of having defined long-term signature validation methodologies established. Of course, this does not preclude other formats either. I am just saying that XML as the default and leaving the separate profile to define other format would be logical approach. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
(Replacing it has no effect on protocol part.)</blockquote><div><br>Indeed. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
-The format of parameters in protocol is still "key-value" pairs.<br>
The reference key for contract data is one of parameters in a protocol.</blockquote><div><br>Agreed. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
-Authentication in 4 legs model and Notification is tricky. The flow should be clearly defined. </blockquote><div><br>The use case is valid and useful as well as real. <br>Only concern in including it in the spec is that it may get a bit complicated for the readers. <br>
>From a spec modularity point of view, we should write the 4 legs model first and make the 3 legs one as a special case, though. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
-I am still not sure how AX can carry site(server) attributes seemed to<br>
be required in this spec. This could be a issue. However, reusing existing<br>
specs/protocols is a good thing.</blockquote><div><br>Right. AX 2.0 WG not starting after over 8 months are a sad fact. <br>We have been waiting for Microsoft to give Dick the permission to join in, but apparently he has not got it yet. It is probably the time that we should start. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I hope this would help. Should we start discussion about the spec based on this document? Please let us know how you like to proceed.</blockquote><div><br>Yes. We should discuss and build consensus around it. <br>Then, we should implement to see if it really works. <br>
Let's write spec after that. That's going to be more concrete. <br><br>Would that be OK? <br><br>Assuming that's ok, what we have to decide on are: <br>* Spell out the message flow more concretely. <br>* List the parameters that we need to send and receive in each flow<br>
* Name the parameters<br>* Make XML schema<br><br><br>=nat<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Tatsuki <br>
Tatsuki Sakushima<br>
NRI Pacific - Nomura Research Institute America, Inc.<div><div></div><div class="h5"><br>
<br>
<br>
(7/30/09 4:53 AM), Nat Sakimura wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
Hi All:<br>
<br>
To explain the concept of CX better, and by doing so, making my understanding clearer, I wrote a discussion note to set a level ground on the discussion.<br>
<br>
Please have a look.<br>
<br>
Hopefully, it is pretty clear.<br>
<br>
Caveat: It is the dump of my thinking as of today, and no proof reading has been done.<br>
<br>
Cheers,<br>
<br>
=nat<br>
<br>
<br></div></div>
------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
Specs-cx mailing list<br>
<a href="mailto:Specs-cx@openid.net" target="_blank">Specs-cx@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs-cx" target="_blank">http://openid.net/mailman/listinfo/specs-cx</a><br>
</blockquote>
_______________________________________________<br>
Specs-cx mailing list<br>
<a href="mailto:Specs-cx@lists.openid.net" target="_blank">Specs-cx@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-cx" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-cx</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>