- From: Al Gilman <asgilman@access.digex.net>
- Date: Fri, 24 Oct 1997 14:04:38 -0400 (EDT)
- To: connolly@w3.org (Dan Connolly)
- Cc: timbl@w3.org, fielding@ics.uci.edu, masinter@parc.xerox.com, Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, uri@bunyip.com, lassila@w3.org, swick@w3.org, tbray@textuality.com, jeanpa@microsoft.com, cmsmcq@uic.edu, dsr@w3.org, lehors@w3.org, ij@w3.org
There are two pieces of this question. One is a question of nomenclature: how many names, and what name(s) should we use to refer to things of the UR* class? The second is a matter of software architecture: what IETF documents should the W3C documents for HTML etc. cite, and how? This message talks to the architecture question. The HTML specification has trouble deciding which RFC(s) to cite to define acceptable URLs. The right answer is that the HTML spec should not be trying to define acceptable URLs. This is a deal between the browser and the marketplace which is somewhat disciplined through the registry efforts of the IETF, but does not pass under the thumb of the HTML specification. The _HTML_ requirements on URLs are that they are expressed in the appropriate SGML type so that they can be embedded in text where an attribute value is needed. What strings (schemes) browsers should be capable of handling is not the place of HTML to define. That is the architecture bug at the moment. HTML talks as though it defines URLs by reference to RFCs. HTML per se shouldn't be pretending to regulate URLs at all. The IETF process should be cited as a source for more information. This is an informative, not normative clause, i.e. the more information available from the IETF is outside the scope of the HTML language rules. -- Al Gilman
Received on Friday, 24 October 1997 14:06:04 UTC