>> On 13-Jun-07, at 7:04 PM, =drummond.reed wrote:
>>
>> With the Yadis specification now included in section 4 of XRI
>> Resolution
>> Working Draft 11 (see
>> http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris
>> for a copy
>> of the text of this section -- thanks to David, Johnny, and Rowan for
>> feedback on the first draft)
>
>Johnny Bufu wrote:
>
>Drummond,
>
>A bit more feedback on the Yadis section, hope you don't mind.
Absolutely not. The goal has always been to make sure it specifies what
Yadis 1.0 specifies. Everyone else who cares about URL-discovery-of-XRDS,
please do review the proposed text of this section, posted on the XRI TC
wiki at:
http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris
> The overview section (4.1) still says:
>
>> A service hosting an XRDS document discoverable through an HTTP(S)
>> URI is only required to support one option
>
>Which is not equivalent with the Yadis spec, 6.2.4. Initiation:
>
>> This request MUST be either a GET or a HEAD request.
>
>Since the client has the option to do only GET (and the server is
>required to respond), the server doesn't have a choice to support
>only HEAD. GET is required , HEAD is optional (because of the
>required fallback on the client side).
Got it. It was David who sent me the suggestion to word it that way, as I
think he thought that the client could do either option.
David, if you agree with Johnny, then I will update the text of section 4.1
to say:
"The protocol has two options: using an HTTP HEAD request to obtain a header
with XRDS document location information (section 4.2), or using an HTTP GET
request with content negotiation (section 4.3). A service hosting an XRDS
document discoverable through an HTTP(S) URI MUST support the GET option,
and MAY support the HEAD option. A client agent seeking to discover an XRDS
document from an HTTP(S) URI MAY use either option, but MUST attempt the GET
option if the HEAD option fails."
Let me know if you have any feedback on this wording.
>> extending Canonical ID verification to cover
>> any combination of URLs and XRIs is quite straightforward.
>>
>> The formal proposal is now fully written up on the XRI TC wiki. The
>> first
>> link below is to the full page; the second takes you directly to
>> the example
>> section.
>>
>> http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification
>
>Looks ok to me. For the OpenID spec, it seems we have two options now:
>
>1) Use canonical IDs for URLs, and reference section 11 from the XRI
>spec for the verification part
> pros:
> addresses recycling issue
> brings in a (possibly) persistent identifier, addressing
issue B)
>here [1]
> cons:
> possible issue with defining the canonical ID (or an
alternate
>path) for HTML discovery
> need to adjust how the claimed id is handled with Yadis
discovery
> more complex than 2) (more canonical id verification paths)
>
>2) Adopt the fragment proposal and specify it inline [2]
> pros:
> addresses recycling issue
> simpler than 1)
> cons:
> does not address issue B here [1]
>
>
>Johnny
>
>
>[1] http://openid.net/pipermail/specs/2007-June/001847.html
>[2] http://openid.net/pipermail/specs/2007-May/001767.html
Agreed. Good analysis.
The XRI TC had a good discussion about this extended Canonical ID
verification model this morning, and we realized it actually adds some
additional functionality even to XRI-to-XRI relationships. We didn't have
time to complete the discussion, but we're going to proceed rapidly with the
goal of incorporating it into ED03 next week.
=Drummond
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
