"openid." name space of KeyValue Form

[Nat Sakimura]

(2010/02/08 10:50), Will Norris wrote:
> 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.

That's what I was thinking. But after Hideki's message, I started to 
doubt that a bit.
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. This led me to these question:

"Why are we putting openid.* in those request? / Why are we not putting 
openid.* to the response? "

If we do not send anything but openid parameters on the request, 
openid.* as a part of url is redundant.
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.

>
> You certainly don't need to add the prefix to KVF message to have 
> consistency within an OpenID library.  For example, in the Internet2 
> library that logic is entirely encapsulated within the message encoder 
> and decoder.  Compare URLFormCodec[0] to KeyValueFormCodec[1].  
> Everywhere else in the library, all message are treated exactly the 
> same, regardless of how they were encoded on the wire.
> [0]: 
> http://svn.middleware.georgetown.edu/view/java-openid/trunk/src/main/java/edu/internet2/middleware/openid/message/encoding/impl/URLFormCodec.java?view=markup 
>
> [1]: 
> http://svn.middleware.georgetown.edu/view/java-openid/trunk/src/main/java/edu/internet2/middleware/openid/message/encoding/impl/KeyValueFormCodec.java?view=markup 
>
No, we do not. I have never seen a library that puts openid.* in KVF. My 
curiosity after seeing Hideki's mail was not the current implementation 
issue but about the future consistency and a little bit of historical 
perspective.
>
>
> On Feb 7, 2010, at 4:22 AM, Paul E. Jones wrote:
>
>> For use in Key-Value Form, I didn't see it as necessary when I 
>> implemented
>> the spec.  It seemed logical not the be there.
>>
>> The only reason why one might want to use this is to include some 
>> kind of
>> non-standard information.  Is that something folks would want to 
>> encourage?
>> Anyway, changing the spec to have "openid." there now would break 
>> things, so
>> I would not recommend it unless there was a really good reason.
>>
>> Paul
>>
>>> -----Original Message-----
>>> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-
>>> bounces at lists.openid.net] On Behalf Of Nat Sakimura
>>> Sent: Monday, February 01, 2010 12:14 AM
>>> To: openid-specs at lists.openid.net
>>> Subject: Re: "openid." name space of KeyValue Form
>>>
>>> Hmmm
>>>
>>> That's a good question. The reason we put openid.* in the request and
>>> response is that there may be other applications sharing the same
>>> request/response. If so, it would be more consistent if we put openid.*
>>> prefix to the keys of the direct response as well...
>>>
>>> Is it just an oversight, or did it have a good reason for it?
>>>
>>> =nat
>>>
>>> (2010/02/01 13:49), nara hideki wrote:
>>>> Hello all,
>>>>
>>>> I'm thinking of the good reason why "openid." name space to keys of
>>>> Key-Value Form Encoding used for direct responses is dropped.
>>>> I think that we MAY use "openid." name space.
>>>>
>>>> I'm very happy if someone give me a good cue to understand the
>>> reason.
>>>>
>>>> Thanks in advance.
>>>> ----
>>>> hdknr
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>
>>>
>>> -- 
>>> Nat Sakimura (n-sakimura at nri.co.jp)
>>> Nomura Research Institute, Ltd.
>>> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs