Message-Id: <330CD0C6.2C5586B@w3.org> Date: Thu, 20 Feb 1997 16:31:34 -0600 From: Dan Connolly <firstname.lastname@example.org> To: Daniel LaLiberte <email@example.com> Cc: firstname.lastname@example.org, email@example.com Subject: Re: URI-protocol mapping (was Re: How to add new "protocols" ?) Daniel LaLiberte wrote: > > Then we're just talking semantics. Are we? If so, then I'm content with differences of opinion, i.e. just different perspectives. Half-full, half-empty and all that. Or is this relavent to any of the specs in revision? > > The use of symbolic indirection in both languages and > > communication has a long and distinguished history which is > > directly applicable here. > > Indirection is necessary to get the mobility that names allow, but > indirection is possible also for URLs. A URL is symbolic too. > > I don't disagree with the value of layers of abstraction, but in the > realm of internet resource identifiers, I have seen no need > to distinguish URNs and URLs since they can both serve the same > symbolic function. I agree. Now: my question is: are both Daniel and Joe's perspectives consisten with the UR* specs (extant and in development), or is one of them inconsistent? For example, I notice that Ron Daniel's proposes some mechanisms for URN resolution. Funny enough: they work just fine on strings like: http://www.foo.com/software/latest-beta.exe Personally, I caved in a while ago: the community refers to these things as URLs (as in "hurl me an url, dude!"), so I call them URLs almost all the time. I don't feel that having two or three terms (URI, URN) which differ only in their connotations, rather than in the technical mechanisms and uses, is useful at all. I'd like the specs to be consistent. If it's easier to get all the specs to say URI, then that's fine with me too. See: http://www.w3.org/pub/WWW/Architecture/Terms#URL  ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-naptr-01.txt p.s. I know, I need to start using the official mailing lists. For actual comments on the drafts, I'll be sure to do that.