[OpenID] [Fwd: Re: guid openid delegate]

[Johnny Bufu]

On 13-Sep-07, at 2:50 PM, Jack wrote:

> Johnny Bufu wrote:
>>
>> On 13-Sep-07, at 1:21 PM, Jack wrote:
>>> What is surprising that a suppliedId such as
>>> http://user.example.com/ is not to be subjected to discovery,
>>
>> How did you arrive at this conclusion?
>
> For myself, I arrived at the opposite conclusion, through intuition.
> Then, in this message: <517F9E6B-45F3-4987-8B54-4E9FE35AAFFE at sxip.com>
> you said:
>
>> "For URLs, the claimed identifier is not the result of the (las part
>>  of) discovery; it is determined only by the normalization (i.e. the
>>  URI-normalized form of the user-supplied id after following all
>> redirects)."
>>
>>> whereas user.example.com/ must be discovered, in addition to being
>>> normalized (and both URLs must be subjected to normalisation, yeah?
>>> Just because you're a proper URL doesn't mean you're normalised).
>
> user.example.com/ is not a URL (at least, it doesn't have the form  
> of a
> URL unless you pre-suppose a hierarchical protocol such as HTTP), and
> therefore it must be subjected both to normalisation and discovery.
>
> Is that incorrect?

No. But you haven't explained how you came to the conclusion at the  
beginning of the quote above:

>> On 13-Sep-07, at 1:21 PM, Jack wrote:
>>> What is surprising that a suppliedId such as
>>> http://user.example.com/ is not to be subjected to discovery,


>>> So absent a clear description of the rationale behind the various
>>> decisions that have been made, one would assume that a suppliedId
>>> that is an incomplete URL, once completed, should then be treated
>>> in the same way as a suppliedID that is a complete URL.
>>
>> What exactly are you referring to with complete / incomplete URL, and
>>  the act of completing a URL?
>
> I'm referring to one of the requirements for normalisation; taken from
> OpenID Auth 2.0 Draft 12, 7.2: "if it does not include a "http" or
> "https" scheme, the Identifier MUST be prefixed with the string  
> "http://".


> I guess the string "jack" is a complete URL; but in http terms, it's
> referred to as a relative URL; and as a bare string, it's  
> impossible to
> tell whether it's supposed to be a URL or not.

If "jack" is a User-supplied Identifier, per 7.2.  Normalization /  
bullet 3, it is intended to be a HTTP URL.

> So by "complete URL", perhaps I meant "recognisable as a URL".

I find the term "complete" in regards to URLs confusing. The spec  
doesn't define or use it. Without a clear understanding of what you  
mean, it's difficult (for me at least) to follow your reasonings when  
you use the term.

> If you feel I'm bugging you, perhaps it might be better if you left it
> to someone else (or nobody) to answer my questions. If nobody answers,
> that's OK - I'm nobody.
>
> I have little doubt that the reason I have questions is simply  
> because I
> don't understand. I'm certainly not trying to attack anything, just to
> clarify. I'm an outsider, trying to implement the specs as they  
> develop.
> I would have thought that the spec-writers would find it useful to  
> know
> what problems people like me have been having interpreting their
> documentation.

I was more or less in the same position one year ago :) I'm trying to  
help by pointing to the exact portions of the spec that do answer  
(some of) your clarification
questions.


Johnny