Sorry to jump in here a little late, but I feel there are a couple of important points that haven't been mentioned...
On Mar 18, 2008, at 7:54 PM, Kevin Turner wrote: > > The code path you are are requiring the implementations to change > (OpenID discovery and normalization) is, with the combination of > different identifier types, protocol versions, and discovery schemes, > already one of the most tangled chunks of code involved. I > acknowledge > that your proposed change, in isolation, seems simple enough, but that > code *really* doesn't need another branching condition in it. You seem to have the tail wagging the dog here, and I'm a bit surprised no-one has called you on it yet. Regardless of what specific spec addition we're talking about, I don't think the technical difficulty to implement it should ever be a determining factor in weighing the merit of the proposal. If a particular library chooses not a support a specific portion of the spec based on technical programming factors, that is one thing. But using that as a factor in deciding whether or not to accept that proposal is approaching very dangerous waters. Now, regarding the specific proposal in question, I'm actually a bit discouraged by the arguments being made. I see OpenID discovery (Yadis) and web browsers as two different applications, both of which happen to make use of HTTP has their transport layer. At the most basic level, the "application" of a web browser is the retrieval of a document and displaying it to a user. In addition to HTTP, this application could use as its transport layer FTP, Gopher, or probably a number of other protocols I'm not thinking of. Yadis is a discovery service used to enable OpenID authentication (among other uses), but with no requirement to ever display the data to the end user. When determining how one should interpret a technical spec or implement a particular feature, it is perfectly acceptable and encouraged to consider other similar implementations. These other implementations should be used as supplementary guidance, particularly when the specification isn't clear. However, RFC2616 is pretty clear in how 303 responses should be handled, namely that "the new URI is not a substitute reference for the originally requested resource". For the purpose of obtaining a "representation" of the resource the redirect needs to be resolved, but only for that purpose... the spec is clear that these are still entirely distinct resources. Based solely from the perspective of "implementing the HTTP spec as written" I am in complete agreement with Noah... his argument is entirely valid and supported by the spec. If the OpenID spec chooses not to implement that part of HTTP, that is a completely valid route to take, but it ought to be explicit. I'm not sure that I've actually heard a really compelling argument against implement 303 responses as Noah has described, but I'm not sure that one isn't still out there, yet to be mentioned. Does this have any ramifications on the OpenID trust model regarding identifiers? I don't think it does, just trying to think through everything. -will _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
