Talk:Yadis Protocol Draft 0.8
From Yadis
This page is now only of historical interest.
[Thanks for all the work, folks. Please note the dates on my comments. -- Joaquin 25Dec5]
>> In version 0.8, I've acted on all the comments on this page, except any after which I have added a note that I have put that item off for tonight. -- Joaquin 29Dec5
>> I've now acted on all but one:
Talk:Yadis Protocol#6.2.4 Response needn't be HTML Talk 2
I'll let 6.2.4 stand until the technical review starts. I expect I will require a major rewrite to make this section significantly better; in any case, it will require leaving the document for a while, so I can see it better. -- Joaquin 31Dec5
Responding to Content Negotiation
This section should probably include a requirement for any server doing the "magic" based on the "Accept" header field to include an appropriate "Vary" header field in the response indicating this. I forgot this in my original proposal. -- Martin Atkins
> Yes. This will be in the spec (as a Note, not as normative text). Joaquin 25Dec5
>> This was added in v.0.7. -- Joaquin
All this "Identity Consumer" business
I don't really like the term "Identity Consumer", since it implies that all uses of Yadis will be to do with identity. This is not the case; I'm hoping to apply Yadis to describe capabilities that are more related to websites than people, and the word "identity" doesn't really fit here. (unless you're comfortable with the idea of a website having an identity of its own, of course.)
Why don't we just call it the "Yadis Consumer", or just "Consumer" in places where that's unweildy? That says what it is with no extra implications that might inadvertantly limit the reader's understanding of the scope of Yadis.
> It is now 'Relying Party'. How do you feel about that? http://mylid.net/joaquin 22Dec5
>> There were no objections to 'Relying Party,' so that it is. --Joaquin
Server location for Yadis ID with schemes other than "http"
Section 6.2 has "A Yadis ID MUST be a URI or XRI resolvable to a URL usable with the HTTP protocol." It is not clear what "usable with the HTTP protocol" means.
>> I have rewritten. I hope this will make the intent clearer.
From the Architectural Assumptions, it appears that the Yadis ID is any URL, the subset of URI. [RFC 3986] section 1.1.2 defines the term "Uniform Resource Locator" (URL) as
the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location").
and there are several examples of URLs that do not use the HTTP scheme, such as
ftp://ftp-people.example.com/~joe
https://secured.example.com/~paranoid
ldap://[2001:db8::7]/uid=ipv6er
Presumably these can be included as the Request-URI (as absoluteURI form) in the Request-Line in HTTP,
GET ftp://ftp-people.example/com/~joe HTTP/1.1 Accept: application/xrds+xml, text/html
So how does the Relying Party determine the HTTP server to send these Yadis IDs to?
--MarkWahl 14:26, 23 December 2005 (PST)
> An URI starting with ftp:// wants to express that the FTP- and not the HTTP-protocol should be used for obtaining the resource. Any concept of maybe "tunneling" FTP or any other protocol through HTTP is too complex as well as forcing Yadis relying parties to accept anything. I'd say we can agree on that a Yadis URL has to start with "http" or "https" or be something convertable (like an XRI, as far as I've understood) and fail on anything else. --Http://mylid.net/lukasros 14:04, 26 December 2005 (PST)
To keep things simple, Yadis identity URLs will *only* allow HTTP or HTTPS as a scheme.
--Josh Hoyt 08:35, 29 December 2005 (PST)
>> v.0.8 continues to allow only HTTP and HTTPS. This in now expresed in terms of the scheme name in the Yadis URL. --Joaquin
Server location reference suggested text
To follow on the previous comment, here is some suggested text:
Obtaining the address of the HTTP server or servers to query for a Descriptor document can be performed using the The Uniform Resource Identifiers Resolution Application of the Dynamic Delegation Discovery System (DDDS) to locate the services associated with the Yadis ID URI. This algorithm uses NAPTR and SRV records in the DNS. The Relying Party can then select those services which are of the http service.
--MarkWahl 16:18, 23 December 2005 (PST)
I would argue we do not need to tell how URLs are resolved -- point to appropriate W3C/IETF/whatever standards is sufficient.
--User:http://mylid.net/jernst 14:19, 30 December 2005 (PST)
>> I've made no change. The infrastructure for resolving URLs is ubiquitous, even if I can't spell that. I may add a very short not with a link, if someone will provide a link into the right document. If that is felt to be a good idea. --Joaquin
Only content negotiation and no X-Yadis-location
Is it so, and if yes, clear enough that a Yadis URL has to return X-Yadis-Location if no Accept-header is sent? Maybe relying parties don't send this header and therefore will assume that a certain URL (as it only returns an (X)HTML-document) is no Yadis URL? --Http://mylid.net/lukasros 14:08, 26 December 2005 (PST)
> Thanks. Answer: Yes and maybe not.
I'll look for the place to make it perfectly clear that every HTTP/HTTPS request to a Yadis URL must return an X-Yadis-Location in either the HTTP response-headers or the HTML
, unless the request results in the return of the Yadis Resource Descriptor its very self.In fact, to keep it even simpler, I will make it clear that, while the HTTP response-headers are an optional goodie, the HTML
equiv is mandatory.Any objections?
=Joaquin 26Dec5
Yes. I don't like requiring the HTML equiv because it violates our "provider-driven deployment" scenario.
Johannes Ernst 14:22 30 December 2005 PST
> Maybe change section "6.2.4 Response" to something like this:
... 4. A document of MIME type, application/xrds+xml. If the request did not include an "Accept: application/xrds+xml" header, the response MUST be of type 1 or 2. Note: This is necessary because Yadis relying parties may not support content negotiation and look for the X-Yadis-Location only.
I wouldn't suggest making the HTML head meta-equiv a MUST. --Http://mylid.net/lukasros 03:43, 27 December 2005 (PST)
I'd also like the HTML head to not be a MUST. It removes the advantage of the HTTP header and requires a HTML document. If simplicity is the overriding goal, we'd want to drop HTTP headers from the spec entirely. But the consensus was to include them. --keturn 14:31, 27 December 2005 (PST)
-1 on requiring HTML
--Josh Hoyt 08:37, 29 December 2005 (PST)
Agree with Lukas and Josh. Johannes Ernst 14:22 30 December 2005 PST
>> This is in v.0.72 and subsequent drafts: HTML equiv OPTIONAL. --=Joaquin
6.2.3
"This request MAY be either an HTTP GET or an HTTP HEAD request." should read "This request MUST be either an HTTP GET or an HTTP HEAD request."
On the use of the Accept header: "The relying party may use content negotation in the request by adding an Accept header preferring the mime type application/xrds+xml. (Reference the HTTP spec on content negotiation, RFC 2616, section 12.)"
--keturn 13:36, 27 December 2005 (PST)
>> I've corrected this in v.0.8 --=Joaquin
6.2.4 Response needn't be HTML Talk 1
The response does not need to be a HTML document if the HTTP response headers are set, contrary to option 2 in this list. Perhaps options 2 and 3 don't need to be seperate, as if the response headers are present, it does not matter if a document follows.
--keturn 13:44, 27 December 2005 (PST)
Doesn't this depend on whether we require the equiv in the
? If we do require that, then the response does need to be an HTML doc. Right? Joaquin 28Dec56.2.4 Response needn't be HTML Talk 2
About the recently added Note ("if the request is a GET and does not include an "Accept: application/xrds+xml" header, the response MUST be of type 1 or 2."): Why can't it be a document with content-type application/xrds+xml?
--keturn 14:44, 27 December 2005 (PST)
Excellent question! It seems it certainly could, if my Yadis ID was http://www.joaquin.net/yadis.xml . The only restriction, it seems to me, is that stated elsewhere, that the response must conform to the HTTP protocol. =Joaquin 28Dec5
I agree with keturn.
Johannes Ernst 14:26 30 December 2005 PST
>> I feel this requires a major re-write. I will give up on this for this year. See note at top of this page.. There is agreement that the document returned need not be an HTML document. There is also agreement that HTTP-equiv need not be used, if the Location is in an HTTP header. There must be a better way to specify that. But I will see better after being away from the document for a bit. --http://myLID.net/joaquin
Other cases
What happens if the X-Yadis-Location header is present and the content-type is application/xrds+xml? (Follow the X-Yadis-Location header.)
What if when retreiving the URI specified by the X-Yadis-Location header you encounter a redirect? (Follow all redirects?)
What if the X-Yadis-Location header is present along with a Location redirection header or other non-200 HTTP response? (Answer is probably "the server is broken, don't do that.")
--keturn 14:58, 27 December 2005 (PST)
+1 on keturn's suggestions
--Josh Hoyt 08:40, 29 December 2005 (PST)
I think:
- Follow all redirects
- If both application/xrds+xml and X-Yadis-Location, any disambiguation rule is fine with me -- keturn's idea is fine
- Rather than "server is broken", I'd say we simply do not discuss this. There are some funny cases where this might make sense, but we don't understand them yet, so let's let people play without feeling constrained by a standard whose authors don't understand yet why people may want to do things like that ;-)
--Johannes Ernst 14:30, 30 December 2005 PST
6.2.6
The wording describing the HTML element is a bit confused. Perhaps "If the response includes an X-Yadis-Location response header or an HTML element whose http-equiv attribute is X-Yadis-Location [...]"
--keturn 15:09, 27 December 2005 (PST)
Will fix. http://mylid.net/joaquin 28Dec5
>> I've used this language in v.0.8. --[[User:Joaquin|Joaquin]
6.2.1, the Yadis ID and XRI
"A Yadis ID MUST be a URL (or a URI or XRI resolvable to a URL)."
I agree that we want to interoperate with XRI at some stage, but this suggests that a compliant Yadis tool MUST have an XRI resolver available. Is that the intent?
--keturn 14:41, 2 January 2006 (PST)
>> Not the intent. The intent is 1) to place a restriction on both the form (XRI (or URI (or URL))) of a Yadis ID and 2) wind up with something that can be used in the protocol, which require a URL. Looks like we have two alternatives: a note here or require a URL. The latter will not be friendly to our XRI and i-name collaborators. =Joaquin
