Re: [URN] Potential inconsistency between URL and URN syntaxes...

On Wed, 18 Dec 1996, Leslie Daigle wrote:

> It looks like the following questions are on the table:
> 
> 	. should URN and URL syntaxes be consistent?

I guess we have to ask "to what extent should they be consistent".
Definitely, allowing something such as ">" in URNs, while they
are used to delimit URLs, would be a very bad idea. On the other
hand, the fact that the octets represented (with %HH in the canonical
form) in URNs are interpreted as UTF-8 should not at the moment
force URLs to suddenly convert to UTF-8 (quite difficult), but
should not on the other hand scare URLs away from making the
necessary preparations to get better i18n facilities and try
to move in the direction of UTF-8. (more on that later).

> 	. if yes, which should now change:
> 
> 		. URLs cannot, because of legacy support, although
> 	 	  there is the issue of "I18N"
> 
> 		. URNs "can", except that the existing syntax was
> 		  built for specific reasons to address issues that
> 		  have concerned URNs more than URLs (e.g., bringing
> 		  in other namespaces and addressing multiple language
> 		  issues).
> 
> 
> Is it "desirable" that URN syntax be compliant with URL syntax, or "required"?
> What _breaks_ if it is not?

We don't want a HTML parser or something similar to need separate code
for parsing URLs and URNs. It should be able to deal with URNs as one
URL scheme, syntactically. It looks like that is possible, but I have
to admit that I am no regex expert.


> [Ryan quotes from the URL draft:]
> > > 
> > >    Although this specification restricts its discussion to URLs, the
> > >    syntax defined is that of URI in general.  Any requirements placed on
> > >    the URL syntax also apply to the URI syntax.  This uniform syntax for
> > >    all resource identifiers allows a URN to be used in any data field
> > >    that might otherwise hold a URL.
> 
> This draft is for the _URL_ syntax, and this is the only paragraph that
> lays claim to all of URI syntaxes.
But it lays claims for all of the URL document, or at least a large part
of it.

Regards,	Martin.

Received on Thursday, 19 December 1996 09:56:36 UTC