W3C home > Mailing lists > Public > uri@w3.org > August 2004

Re: Helping out with canonicalization of URIs

From: Clive D.W. Feather <clive@demon.net>
Date: Mon, 9 Aug 2004 22:03:50 +0100
To: Graham Klyne <GK@ninebynine.org>
Cc: Sam Ruby <rubys@intertwingly.net>, uri@w3.org, Atom WG <atom-syntax@imc.org>
Message-ID: <20040809210350.GC59184@finch-staff-1.thus.net>

Graham Klyne said:
> >  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://:********@example.com/
> 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.)

Actually it is useful, because it means "you need a username/password"

>>  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)

I don't like this result. To my mind, the # separates "what goes to the
host" from "what to look for within the resulting resource". I don't see a
useful distinction between "don't look" and "look for nothing".

HTTP doesn't distinguish them that I can see. Can you explain the RDF bit
in words of one syllable?

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
Received on Monday, 9 August 2004 21:04:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:08 UTC