Problems with OpenID and TAG httpRange-14

[Will Norris]

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