Comments on Auth 2.0 - Pre-Draft 11

[Johannes Ernst]

So you believe that it is tight enough that if you and I implement  
the spec, and somebody types the exact same character string into  
both of our implementations, it will produce the exact same result,  
regardless what the character string was?

That's all I want to accomplish ...

On Dec 14, 2006, at 12:05, Josh Hoyt wrote:

> (I will be addressing the remaining issues that you brought up one  
> at a time)
>
> On 12/11/06, Johannes Ernst <jernst+openid.net at netmesh.us> wrote:
>> >> 7.2 Normalization
>> >>
>> >> I'm not sure that this -- all of which is OPTIONAL -- should be in
>> >> this document. I would suggest to either make it MANDATORY -- or
>> >> to take it out of this document and refer to a User Experience
>> >> document instead.
>> >>
>> >> The problem is that if the user can type in something incomplete
>> >> at site A, and then types in the same incomplete thing at site B,
>> >> it may work at A but differently at B, which is no good. So either
>> >> make these rules MANDATORY, or delegate them into the user
>> >> experience.
>> >
>> > Normalization is not optional at all - not sure why you understood
>> > it was. Maybe that section needs to be clarified, if you can point
>> > it to us.
>>
>> I am referring to par 1 sentence 2, where is says "needs to" instead
>> of "MUST ... according to the following algorithm".
>> Then to the entire paragraph 2, which says SHOULD.
>>
>> I'd like an algorithm that produces the same normalized identifier
>> from the same entered text string, regardless of site.
>
> I have changed that text from "needs to" to MUST, although I think
> that the sentence before that (The end user's input MUST be normalized
> into an Identifier) is pretty unambiguous.
>
> Paragraph two about normalizing XRIs I think was David's text, so I
> guess I'll wait for his response about that. I think he's on vacation.
>
> Other than the SHOULD for recognizing XRI global context symbols and
> adding the xri:// prefix, I think that the normalization section is
> pretty tight and will not lead to inconsistencies in implementation.
>
> Josh