That new wording for the Yadis bit looks good to me!
From: =drummond.reed [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 14, 2007 4:49 PM
To: 'Johnny Bufu'
Cc: firstname.lastname@example.org; Recordon, David
Subject: RE: Writeup of XRDS Canonical ID verification for URLs and XRIs
On 13-Jun-07, at 7:04 PM, =drummond.reed wrote:
With the Yadis specification now included in section 4 of XRI
Working Draft 11 (see
for a copy
of the text of this section -- thanks to David, Johnny, and Rowan for
feedback on the first draft)
Johnny Bufu wrote:
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
please do review the proposed text of this section, posted on the XRI TC
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
think he thought that the client could do either option.
David, if you agree with Johnny, then I will update the text of section
The protocol has two options: using an HTTP HEAD request to obtain a
with XRDS document location information (section 4.2), or using an HTTP
request with content negotiation (section 4.3). A service hosting an
document discoverable through an HTTP(S) URI MUST support the GET
and MAY support the HEAD option. A client agent seeking to discover an
document from an HTTP(S) URI MAY use either option, but MUST attempt the
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
link below is to the full page; the second takes you directly to
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
addresses recycling issue
brings in a (possibly) persistent identifier, addressing
possible issue with defining the canonical ID (or an
path) for HTML discovery
need to adjust how the claimed id is handled with Yadis
more complex than 2) (more canonical id verification
2) Adopt the fragment proposal and specify it inline 
addresses recycling issue
simpler than 1)
does not address issue B here 
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
time to complete the discussion, but we're going to proceed rapidly with
goal of incorporating it into ED03 next week.
specs mailing list