Subject: Re: Helping out with canonicalization of URIs

From: Sam Ruby <[email-masked]>
Date: Mon, 09 Aug 2004 14:45:50 -0400

Roy T. Fielding wrote:
> 
> On Monday, August 9, 2004, at 08:39  AM, Graham Klyne wrote:
> 
>> At 08:54 09/08/04 -0400, Sam Ruby wrote:
>>
>>>   http://:@example.com/
>>
>> I'd say that's different from http://example.com/, in that it contains 
>> empty username/password values, which the latter does not.  For 
>> example, following the exhortation not to expose passwords, my 
>> software would (by default) display this as:
>>   http://:[email-masked]/
>> whereas the other would be displayed unchanged.
>>
>> (I'm not claiming this is a *useful* distinction, but lacking any text 
>> that says a null username/password is the same as having no 
>> username/password, I'd say that it does exist.)
> 
> Yes, and it is a useful distinction because it defines how the user
> agent should respond to an initial authentication request, whereas
> without the colon the user agent is not supposed to try authenticating
> on its own.

A follow up question then, how about:

   http://@example.com/

> Right, the only thing it might make sense to add is a bullet explicitly
> restating what is already said about an empty port in 6.2.3.  However,
> this is not a conformance issue since all normalization is optional.

I would find it to be helpful if a simple statement that empty 
fragments, queries, passwords (or possibly userinfo) are to be preserved 
by canonicalization.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Mon, 09 Aug 2004 20:32:21 -0700

On Aug 9, 2004, at 11:26 AM, Roy T. Fielding wrote:

>>>   http://example.com:80/
>>
>> I think this is the same as http://example.com/ according to 
>> RFC2396bis, but that you have to climb someway up the equivalence 
>> ladder (protocol-specific equivalence) to recognize this.  It must be 
>> expected that many software packages would not recognize this 
>> equivalence.
>
> It is the same, but that is under scheme-specific normalization, not
> protocol.  It is the "http" that defines :80/none equivalence, not 
> HTTP.

Agreed; and it would be OK, for example, for Atom to require that you 
do this, and still be perfectly consistent with 2396bis; but that 
doesn't mean 2396bis requires it.

>>>   http://www.w3.org/2000/01/rdf-schema#
>>
>> I'd say this is distinct from http://www.w3.org/2000/01/rdf-schema -- 
>> an empty fragment is not the same as no fragment at all (note, when 
>> used as namespace URI in an RDF document, they certainly would not 
>> give rise to the same resource identifiers according to the RDF 
>> specifications -- see RDF syntax spec (10 Feb 2004), section 6.1.2, 
>> URI accessor)
>
> Yes.

Agreed, and here's another reason why: The semantics of the #fragid are 
defined in the context of the media type of the representation you get 
(if you ever get any), and it would be possible, although likely 
unwise, for some media type to attach semantics to an empty fragment 
identifier, i.e. example.com/foo# might be *really different* from 
example.com/foo.

  -Tim