hmm... seems I missed the entire thread over on openid-general. Accept my apologies if I simply repeated content from that discussion and for potentially adding more white noise. Now I'm going to go read that whole thread to see if the above apology is necessary. :)
-will On Mar 21, 2008, at 9:38 AM, Will Norris wrote: > 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 _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs