that ess in 'https'
Peter Davis
peter.davis at neustar.biz
Tue Jun 27 17:27:06 UTC 2006
On 6/27/2006 12:03 AM, "Jonathan Daugherty" <cygnus at janrain.com> wrote:
>> I thought we were trying to decide whether we should adopt the
>> convention that pairs of URLs like the following two URLs, when used
>> as identity URLs, are equivalent: identify the same persona.
>>
>> http://joaquin.net
>> https://joaquin.net
>
> I've said this before: whether these identity URLs are equivalent is a
> decision
> best left up to the parties serving and / or controlling both URLs. If you
> want one URL to be equivalent to the other -- at least in OpenID land -- you
> set up a redirect.
>
Might I suggest that this decision is best left to RFC 3986, which lays out
clearly normalization rules for URIs. Doing otherwise, I think, will lead
to madness and mayhem. If implementations presently do not support this,
than it's a problem with the implementation, I think, and should be fixed
there, not grafted into a specification.
Additional processing gleaned from RFC 3986 also help with things like case
normalization :
...
For example, the URI <HTTP://www.EXAMPLE.com/> is
equivalent to <http://www.example.com/>
...
And also:
...
For example, an application using this [ Syntax-Based Normalization]
approach could reasonably consider the following two URIs equivalent:
example://a/b/c/%7Bfoo%7D
eXAMPLE://a/./b/../b/%63/%7bfoo%7d
Web user agents, such as browsers, typically apply this type of URI
normalization when determining whether a cached response is
available.
...
And FWIW, http://joaquin.net and https://joaquin.net are not equivalent.
My 2cents
=peterd ( http://xri.net/=peterd )
More information about the yadis
mailing list