Problems with OpenID and TAG httpRange-14
Will Norris
will at willnorris.com
Fri Mar 21 19:09:27 UTC 2008
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 at openid.net
> http://openid.net/mailman/listinfo/specs
More information about the specs
mailing list