specs and implementations (Re: Problems with OpenID and TAG httpRange-14)
On Fri, 2008-03-21 at 09:38 -0700, Will Norris wrote: 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. I disagree here. We don't write specs just so people can appreciate the abstract beauty of the models we describe. We write specs so we can have working code solving problems. No specification should be considered complete without at least one reference implementation, and the complexity of implementation should be taken as feedback to the developing specification. The more complexity is required, the more expensive it is to implement and test the specification, which directly impacts adoption. And the more error-prone the implementations will be, hampering interoperability. I think this idea is fairly central to OpenID. As others have pointed out time and time again, there are other systems that have pretty much all the same properties as OpenID does, they may cover them in a more rigorous fashion, they may have been around for years or decades, but they don't have the appeal that OpenID does today. I believe that is because they were perceived as too inaccessible, or too expensive to implement or integrate. I'm not saying that Noah's proposed change is in any way impossible to implement, but as a member of a team which maintains three OpenID implementations, the cost is going to be a factor for me. Most (if not all) of the editors of the OpenID specification(s) to date have been directly involved in implementation, and I doubt I am alone in this. (And yes, I do recognize that I have, in the past, argued in favor of things that were a lot more complex than this. It's one factor among many.) - Kevin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Problems with OpenID and TAG httpRange-14
On Thu, Mar 20, 2008 at 12:42:45PM +1100, Manger, James H wrote: Perhaps I will add a note to the OpenID 2.0 errata page stating HTTP 303 See Other semantics are not currently supported so they should be avoided when hosting OpenIDs. Thank you for your enlightened response, a lot of that makes sense. It is my opinion however that you should consider 302, 303 and 307 redirects in the same boat for the purposes of making changes to the specification/errata. -- Noah Slater http://bytesexual.org/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Problems with OpenID and TAG httpRange-14
On 19-Mar-08, at 2:51 AM, Noah Slater wrote: On Tue, Mar 18, 2008 at 07:54:20PM -0700, Kevin Turner wrote: A request for an OpenID Identifier SHALL NOT issue a 303 response. This is even worse and also backwards incompatible. All the OpenIDs that currently use 303 redirects, including mine, will all break. By all standing definitions (both v1.x and v2.0), your http:// bytesexual.org/ URL is *NOT* an OpenID. You are the only one calling and expecting it to be, based on your interpretation and proposed changes. Well, from my perspective it seems like eventually most people on the list agreed that it was an issue as outlined by my use case. In any case, the simplest things are often discussed at great length, if for not other reason than the colour of the bikeshed, so this is a non sequitur. Note that there have been objections to your proposal, which have not been answered. This effectively accounts to a veto for the proposed changes getting accepted. On 19-Mar-08, at 7:54 AM, James Henstridge wrote: On 19/03/2008, Noah Slater [EMAIL PROTECTED] wrote: That seems to be an argument for making no changes. No, it's an argument to make the backwards incompatible change that effects people in the smallest possible negative way. Your suggestion replaces one non-compliant usage of HTTP with another, which is hardly a step forward. Per the above, the case of making no changes at all still stands. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Problems with OpenID and TAG httpRange-14
On Wed, 2008-03-19 at 23:54 +0900, James Henstridge wrote: The fact that some sites incorrectly resolved the redirect to /about/ is probably due to the non-standard response headers for http://bytesexual.org/ -- it contains a relative URI reference in the location header, while the spec requires an absolute URI. Do you have more information about which sites exhibit which behaviour? Or better yet, which libraries they are using? The current behaviour of all openidenabled.com libraries would be to either a) fail, due to the relative Location header (this may depend on what http client backend is used), or b) normalize that as http://bytesexual.org/about/ given Johnny's earlier comments, I expect that openid4java behaves the same way, and I'd expect the same from the -- well, I was going to say early Perl implementations, but really, I can't think of an implementation that I *wouldn't* expect that behaviour from. (Unless perhaps Noah or Sam Ruby have written their own implementations.) And my hunch is that the implementation which resolved it as bytesexual.org did so not because it was honoring 303 vs 302 semantics, but because it wasn't properly normalizing with redirects at all. (I'd happy to be shown wrong on that count.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Problems with OpenID and TAG httpRange-14
Hello again, Firstly, sorry for the double post, the OpenID.net homepage does not clearly indicate that specs@openid.net is a mailing list. However, it has come to my attention that the mailing list software has truncated my message http://openid.net/pipermail/general/2008-March/004217.html http://openid.net/pipermail/specs/2008-March/002219.html For the reference of people using mailman's web interface and incase the mailing list software truncated the emails as well I had originally cited the following references: From the OpenID specification [1]: Consumers MUST canonicalize the Identifier URL, following redirects, and note the final URL. The final, canonicalized URL is the End User's Identifier. From RFC2616 [2] (emphasis added in upper case): 10.3.4 303 See Other The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. THE NEW URI IS NOT A SUBSTITUTE REFERENCE FOR THE ORIGINALLY REQUESTED RESOURCE. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable. From the TAG's findings [3] (emphasis added in upper case): According to the HTTP specification, a response code of 303 indicates that the response to the request can be found under a different URI It provides the URI where we can look for that response. It's worth noting that although 303 has the role of redirecting user agents after script processing following POST requests, the specification does not limit it to that role. Importantly, the specification also states that The new URI is not a substitute reference for the originally requested resource. IN OTHER WORDS, RESPONSES CONTAINING THIS CODE DIRECT US TO RELATED MATERIAL. IF WE DEREFERENCE THE SUPPLIED URI AND RECEIVE A REPRESENTATION, IT IS CLEAR THAT THE REPRESENTATION RELATES TO THE URI WE WERE GIVEN IN THE 303 RESPONSE, AND NOT TO THE URI THAT LED TO THE 303 RESPONSE. IN PARTICULAR, WE'RE NOT BEING MISLEAD INTO THINKING THAT THE ORIGINAL URI ITSELF HAS REPRESENTATIONS. I am sorry if this information has reached you twice now. Thanks, -- Noah Slater http://bytesexual.org/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
