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