Hmmm. OK. Got it. <div><br></div><div>So, it probably is the topic that we might want to revisit when we introduce new response type like JSON in v.next, if we ever do, I suppose. There may be some cases that we might want to respond to the request at once. (Do not know if there would be.) </div>
<div><br></div><div>Thanks. </div><div><br></div><div>=nat<br><br><div class="gmail_quote">On Mon, Feb 8, 2010 at 3:03 PM, Will Norris <span dir="ltr"><<a href="mailto:will@willnorris.com">will@willnorris.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
On Feb 7, 2010, at 8:45 PM, Nat Sakimura wrote:<br>
<br>
> (2010/02/08 10:50), Will Norris wrote:<br>
>> I've never thought of the "openid." prefix as part of the parameter name, even in URL form encoded messages... it's simply a namespace prefix to ensure URL parameters don't collide. It's completely unnecessary in KVF encoded messages, and would add nothing but extra size to the payload.<br>
><br>
> That's what I was thinking. But after Hideki's message, I started to doubt that a bit.<br>
> Currently, we only use Direct Response in a very limited way: (1) association response and (2) direct verification. In both case, we actually only send openid.* parameters in the request, so we do not need any name space qualifier in the response.<br>
<br>
</div>Not necessarily. What about when the OpenID server's URL is "<a href="http://example.com/?service=openid" target="_blank">http://example.com/?service=openid</a>" ? This was actually the case for the WordPress OpenID plugin for a long time, and is still true for certain deployments, I believe. You can't make any assumptions about what the base URL will be, or what additional parameters may be present, hence why the "openid." is certainly necessary in those cases.<br>
<div class="im"><br>
<br>
> If we do not send anything but openid parameters on the request, openid.* as a part of url is redundant.<br>
> If there is value in having openid.* in the request, then that is to send parameters in other name-spaces, in which case, the response may include other parameters as well, and we need name-space qualifier.<br>
<br>
</div>allowing non-OpenID parameters in a direct response has never been a design goal, nor do I believe that it should be. KVF encoding is a new format defined by the OpenID spec, so it is perfectly acceptable to state that it is only for OpenID related parameters. This is not the case for URL parameters.<br>
<div><div></div><div class="h5">_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</div></div></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><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>