Talk:Draft 0.7
From Yadis
This page is now only of historical interest.
Contents |
Normative aspects only?
Currently, the document also contains a lot of non-normative stuff -- like the history. I'd like to suggest to move as much of this as possible out of the document, so we end up with a "small" specification that can be augmented by as much background as we'd like in other documents or on the wiki.
User:Jernst December 21, 2005
I agree. I thought we needed two documents: overview and technical spec. Now I see we need three: overview, technical spec and history-and-stuff. Joaquin
multiple URIs and Priority
6.2.1. URI Element: XRD allows for multiple URI elements in each Service element. This seems logically equivalent to providing multiple services with the same Type element. (See multiple URIs 2.)
6.2.2 Priority attribute: The priority attribute is optional, but I consider it a mistake to say the R.P. may ignore it when present. It seems like an important piece of functionality.
(See Priority 2.)
XRD also allows the priority attribute to appear on the URI element, useful for the case where more than one URI is present in a Service.
(See Priority 3.)
User:KevinTurner December 21, 2005
multiple URIs 2
6.2.1. URI Element: XRD allows for multiple URI elements in each Service element. This seems logically equivalent to providing multiple services with the same Type element.
Let me ask about two possible cases of multiple URIs:
a. single Type, two URIs b. two Types, two URIs
Q: a. single Type, two URIs: What would the two URIs mean?
A: e.g. two OpenID servers with differing priorities; a default and a fallback.
Q: b. two Types, two URIs:
A: First we should probably define "two types, one URI," but I think this means two hosts which provide the same set of two services. Like the previous case, one host may be preferred and the other a fallback.
Perhaps the discussion will work if answers are inserted above at A: and we then have a dialog in this page.
Joaquin December 21, 2005
Priority 2
6.2.2 Priority attribute: The priority attribute is optional, but I consider it a mistake to say the R.P. may ignore it when present. It seems like an important piece of functionality.
User:Joaquin December 21, 2005
It seems we have only two choices: Allow those who ignore priority to claim conformance to the spec, or specify exactly how those who claim conformance MUST use priority.
Does that seem correct?
One theme at both of the recent meetings in San Francisco (and with some support on the mailing list) was to keep it simple. Another theme was to make it clear to all that Yadis 2.0 may appear some day and, if it does, may specify more than Yadis 1.0 does. Priority is a valuable function: How do you feel about leaving it out for now?
Joaquin December 21, 2005
I want to avoid being in direct conflict with the XRD spec. If XRD says clients MUST treat Priority a different way, I hope that Yadis doesn't say they MAY be doing something differently. The question of whether you are compliant gets very hard to answer if we do that.
However, now that I go back and check, the XRI Resolution document we've been working from uses "SHOULD" rather than "MUST" when discussing the client's treatment of the priority attribute, so it would probably be OK for us to leave it optional for now.
I wish I could say that XRI Resolution already specified completely how to treat Priority so that there would be no extra effort in using it for Yadis, but there's some question on that at this point -- Some things that Drummond said on the phone at Meeting-2005-12-01 aren't really expressed in XRI-Resolution-wd-09. I'll ask for some clarification there.
User:KevinTurner December 21, 2005
Priority 3
XRD also allows the priority attribute to appear on the URI element, useful for the case where more than one URI is present in a Service.
Let's discuss that after we resolve the previous question. OK?
Joaquin December 21, 2005
Comments on Editorial Notes
Why not require that, if there is an X-Yadis-Location in the HTTP headers, that it also be in the HTML document. That will enable would-be weak Relying Parties to get the X-Yadis-Location.
Even if that was in the spec, in practice there would be cases where that is not true. Therefore there must be language describing what happens when they differ, and in order to comply with that a relying party must "see" both. Therefore any such requirement is pointless.
> Very good point. This calls my attention to something that might be a big problem. It seems an excellent idea to specify priority in case there are two X-YAIDS-Locations and they differ. But I see only two choices. I hope someone reading this will tell me about the third.
We require that, if present:
a. the real X-Yadis-Location, the one in the HTTP header take precedence
b. the fake X-Yadis-Location, the one in the HTTP-equiv header take precedence
If a, then everyone has to look in the HTTP headers. If b, then we have eliminated the HEAD optimization.
That means, to enable the HEAD optimization we have to require every relying party, even the home brewed, to be able to analyze HTTP headers.
Since some web servers will take the data in the HTTP-equiv and copy it to an HTTP header, while leaving the HTTP-equiv, we can't prohibit providing both.
I don't see the way out. Yet.
Joaquin 21Dec5
I don't really see a big deal in requiring relying parties to look at HTTP headers. In fact, I think it's easier to deal with HTTP headers than http-equiv (from a relying party point of view) since HTTP client libraries generally parse the HTTP header for you, while an HTML parser or some cunning regex is needed to analyse the document content. The http-equiv check is there to make things easier for the identity host, not for the relying party.
> Good discussion. Thanks, Mart. It seems to me that we do not want to require that the relying party check both the HTTP header and the HTTP-equiv. It follows, if we do not require that, that a specification of which takes priority in the case of conflict does not add much value. I feel we should let the the owner of the Yadis URL suffer the consequences if they use both HTTP header and HTTP-equiv and the two are inconsistent.
(Of course, somebody will invent a wonderful hack that produces some beneficial result by making use of inconsistency of HTTP header and HTTP-equiv. That will be fun.)
Joaquin 22Dec5
This 'HEAD optimization' seems a little dubious to me anyway. Nine times out of ten the relying party won't find an X-Yadis-Location header present because it's either not a Yadis URL or the document contains an http-equiv declaration; the relying party must then go back and make a GET request, repeating the connection and request overhead and making this not such an optimisation after all. Only after making these two requests can the relying party be satisfied and stop, so why not just make the GET request in the first place? The only time you lose is if there's an X-Yadis-Location header, which is probably the most unlikely possibility of all the cases, so why optimise for it? No harm in allowing it in the spec, of course. I'm just not sure why anyone would use it.
> It seems to me that the HEAD option will serve mainly organizations dealing with a large number of users for which they provide the setup. For example, when Microsoft adopts Yadis for MSN, they will handle the setup behind the scenes. If they choose to use indirection, they might benefit if they put the X-Yadis-Location in an HTTP header so that, when they want to sell time in an on-line game, they can reduce their throughput and processing requirements by using HEAD.
In any case, the HEAD option is there because it was asked for by folks at the December first San Francisco meeting, held to gain consensus on details of the protocol. The folks who asked for it need to consider your point.
Joaquin 22Dec5
Content Negotiation
It should be noted in the spec that if a server is relying on the content negotiation thing to serve a XRD response directly it must include a Vary: Accept header in the response to indicate to caches that differing values of the Accept header may return different responses. This header must be present even in the case where the "normal" HTML page is returned.
> Thanks. We will need other technical notes like this, too. I will place all such in Notes at appropriate places in the spec, rather than making them a normative part of the spec. Others more skilled will provide cookbooks and example working code.
Joaquin 21Dec5
