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