Date: Mon, 27 Oct 1997 11:20:05 +0100 (MET) From: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <firstname.lastname@example.org> To: Keith Moore <email@example.com> cc: firstname.lastname@example.org, email@example.com, Subject: Re: The UR* scheme registry, Citing URL/URI specs In-Reply-To: <199710262118.QAA22615@spot.cs.utk.edu> Message-ID: <Pine.SUN.firstname.lastname@example.org> On Sun, 26 Oct 1997, Keith Moore wrote: > So the question is, does W3C: > > a) define the term "URIs" to be (essentially) "the set of > resource identifiers that we might want to use in HTML", or Probably it shouldn't, because of URCs and stuff. > b) assign some other name besides "URIs" to that set, or > > c) simply list the currently known kinds of resource identifiers > that have this property, without assigning a name to that set? > (note that if one set of resource identifiers is a subset > of another set, it doesn't hurt to list them both) Not having a name is rather impossible. That stuff turns up time and again in the spec. > Actually, the more we have this discussion, the more I'm inclined > to suggest that IETF and W3C ban (= "agree to not define") any new > kinds of resource identifiers, beyond URL and URN, whose names > begin with the letter U. Currently, the spec uses URL. That's somewhat close to b), but not exactly. Also, it's close to what non-technical people understand. And one has to say that the HTML spec is quite a bit more geared towards non-technical people than the average IETF standard. So what I would suggest is to use the term "URL", and to have a note that says: >>>>>>>> In the context of this specification, the term "URL" includes both URLs as formally defined in [RFC URL-Syntax] as well as other kinds of identifiers that are syntactically compatible and offer the same functionality (allow to obtain some resource). The only currently know kind of indentifiers that fits this description are URNs [RFC URN-Syntax]. <<<<<<<< Of course, the above text can be improved. But it is easy in that the HTML spec defines the ways it's using the words it's using, by reference to the relevant IETF documents. And it doesn't need a separate RFC, nor does it preclude a different use in different W3C specs, for examlpe because things have moved on by that time, or because the more formal language of such different specs would make other language more preferable. Regards, Martin.