Re: URI documents

>There are people among us who think (I think) that the rules of the
>second class are more a result of the history of the field than they
>are a good design that should be followed in the future; in particular,
>they want to make sure that nobody - BUT NOBODY - builds into their
>software assumptions that all URLs that happen to look like "type 2"
>can be treated like "type 2" URLs.

I am inclined to tell those people to go out and implement a system
that behaves as such, and then standardize it.  Forcing such opinions
onto systems that are definitely not implemented that way
is inappropriate for a Draft Standard.

>This separation is, I think, probably best served by having 2 different
>documents, one for URIs giving the "type 1" rules and one giving
>the "type 2" rules.

We can't do that.  A given protocol element MUST be defined according
to one and only one set of rules.  The "type 1" and "type 2" rules
that you mention are conflicting -- no system can implement both,
since they determine what parts of the protocol element represent
the URI and what parts represent a fragment.  A system of interrelated
protocol standards (like the Web) depends on a consistent syntax and
semantics for its identifiers, since they get moved from in-document
reference in one media type to a field in another protocol to a display
in a browser and onward to a napkin in a bar and somebody else's
document in perhaps an entirely different media type.

That means that either all systems implement "type 2" rules, or
"type 1" identifiers are not allowed in "type 2" systems except
when they do obey "type 2" rules.  Either way, what we need is a
specification of the "type 2" rules, since those are the rules that
need to be referenced by HTTP, HTML, and XML (and all of the other
URI-enabled protocols in current practice).

....Roy

Received on Wednesday, 7 January 1998 12:46:10 UTC