Response to Guidelines for new URI Schemes

This is a response to "Guidelines for new URL Schemes,
draft-ietf-urlreg-guide-05.txt, by Masinter, Alvestrand, Zigmond, Petke

Summary:  Good overall, but I have two general recommendations,
described in more detail below. 

  1. Change "locator" to "identifier" throughout.
  2. Separate identification from protocol throughout.

Section "Syntactic compatibility"

Regarding the sentence starting "If a URI scheme that has embedded links
in content accessed by that scheme does not share syntax with a
different scheme," do we agree that "accessed by that scheme" is
shorthand for "accessed by a protocol associated with that scheme"?  I
have more comments on protocol relationships below.

Regarding the general caution that "new schemes must have demonstrable
utility and operability", it is fine to consider what might happen if a
new scheme is deployed.  But there is another concern that would appear
to make this caution is almost irrelevant since very few if any new
schemes will likely be deployed for use by global identifiers.  The main
reason is the catch 22 that providers are very unlikely to use a new
scheme in documents if few clients support it, and producers of client
software are unlikely to support a new scheme unless there are providers
that use them to make the extra code worth while.

On the other hand, this extreme difficulty of deployment would make it
all the more important that any new scheme that does get deployed follow
the compatibility guidelines.  And furthermore, use of relative URIs
will actually make deployment of new schemes easier since the same
document could potentially be accessed by both old and new schemes.  So
it is probably worth explicitly pointing this out in the guidelines.


Section "Motivations for syntactic compatibility".

It is good to point out the motivations by stating what would go wrong
with incompatibility, but there probably some positive ways to state the
same thing, and some additional positive motivations, such as easing
deployment, greater predictability and hence readability, and leveraging 
the power of relative URIs.  

It appears most of the text of this section comes almost directly from
Jim Gettys' mail of February 1998.  Perhaps he should be a co-author.


Because the fragment syntax for http URLs is a property of the media
type of the returned object, the fragment syntax should probably be
avoided entirely unless it can be used in a media independent way.  This
is a stronger way of saying what the draft says regarding the fragment
syntax.

The paragraph about the '/' syntax is rather confusing.  The example
helps, but even it could be more explicit.  Also, "see section 2.1.1" is 
in section 2.1.1.

Regarding the paragraph on naming authority syntax, it suggests
that relative URIs starting with '//' are meaningful, but it doesn't
quite say that.

Regarding improper use of '//', the text "is not simply an artistic
indicator that what follows is a URL", "a URL" should be "the rest of a
URL".  And in "what follows is the top hierarchical element for a naming
authority", the "naming authority" is not necessarily correct,
regardless what RFC 2396 says.  Any other higher level use of this
element is possible that has nothing to do with being a naming
authority.


Section "Compatibility with fragment syntax": "Fragments indicate a location
within a particular document" the "location" is too specific since there
may be no such clearly defined point in a space.  Rather it should just
be "local label", leaving the interpretation up to the handler of the
media type.


Section "Is the scheme well defined?": in the phrase 'the
"resource" that a URL "locates"', replace "locates" with "identifies".
In fact, the draft should be "Guidelines for new URI schemes", and most
uses of "locator" should be replaced with "identifier", and "locate" with
"identify", etc.  (This will also make the guidelines for the non-protocol
URLs less problematic.)  Maybe split this document into two documents,
one for "Guidelines for new identifier schemes" and another for
"Guidelines for mapping identifier schemes to protocols".


Section "Definition of non-protocol URL schemes" seems to have
some problems that relate to the whole model of identifiers and resources.

  In some cases, URL schemes do not have particular network protocols
  associated with them, because their use is limited to contexts where
  the access method is understood.

The "access method" could be interpreted as a protocol, unless
"protocol" can be clearly defined as some "over-the-wire" mechanism.
(Wires are increasingly irrelevant as distributed object mechanisms gain
force.)  But whether the access method is "understood" by the
application seems irrelevant because whatever is done with a URL,
protocol or not, must be understood by the application otherwise it is
meaningless.

The "complete mapping of the locator from its source" doesn't make any
sense to me.  

I think what is missing here is that these identifiers are used just for
labeling a piece of data in a context and for referencing those labelled
pieces of data in the same context.  The access method is in fact just
"use the piece of data with this label".  The very same identifier might
also be useable via a protocol to access an object remotely, if it makes
sense to do so.

So what this section should be talking about seems to be the use of an
identifier merely for labelling, local access, and comparison,
regardless of whether the scheme is associated with any protocols.

Also related to this "non-protocol" issue is how to deal with
identifiers that are associated with non-internet resources such that
there can be no internet protocol associated with it, at least not
in the near future.  For example, ISBN numbers for physical books, and
street/city/country addresses for people.  Phone numbers are a case
where we might soon have internet protocols that use them.

Backing up to the section "URL schemes associated with network
protocols", I like the weakness of term "associated" since it doesnt
suggest the tight binding that people often assume.  But I would weaken
it more explicitly.  The ability to change a protocol for the same
identifier scheme is important to ensure the evolution of network
applications while maintaining continued use of the same identifiers.
In fact, I believe scheme writers should be *encouraged* to specify the
syntax and abstract semantics of a scheme *without* having to specify
any concrete semantics of a particular network protocol.  The mapping
from a scheme to a particular network protocol could be done in a
separate document.

The abstract semantics of a scheme could be given in the form of
relatively fuzzy, intended effects or more formal declarations that
constrain the cause-effect relationships without specifying how to
achieve those results.


The section "Definition of URL schemes not associated with data
resources" is at least titled ambiguously, and it has possibly several
other problems.  That title suggests a distinction between "resources
that correspond to data objects that may be retrieved or modified" and
resources that one can only interact with via a protocol or service.
But most protocol interactions are of that form, and whether you
retrieve or modify an object is an independent question.

What this section seems to really be about is a distinction between
protocols that mostly request data (e.g. ftp and http) and protocols
that mostly send data (e.g. mailto).  But notice that all these
protocols involve one or more synchronous connections across a network
where the client sends some data to a server and receives some response,
perhaps repeatedly during one connection.    So the distinction at this
level is not clear.

Finally, it says 'the "mailto" URL scheme corresponds to an Internet
mail address'.  But what one does with an internet mail address is not
self-evident.  The "mailto" scheme associates the particular action of
composing and sending an email message to that address, and that would
seem to be the limit of its scope, not so much because of the name of
the scheme, but because of established use.  But other actions relative
to an internet address might be possible that *are* related to data
resources, such as accessing a local collection of messages previously
sent to or received from that address, or sending a request for data.

Also consider that one mailto action might cause a second mail
transaction that is a response to the first, or it might cause a cascade
or chain of messages to other recipients, and these transactions might
all be regarding some data resource on the server.

Back to the issue of associating particular protocols with identifiers,
this section seems to assume that some identifiers are associated with
particular *kinds* of protocols relative to the identifiers.  But it
turns out that what kinds of protocols those are is not so clear, and
there probably should not be any particular protocol binding in the
first place.

I hope I have at least shown the muddle of concepts that come to mind
when reading this section, though I admit I haven't made it much
clearer.  One thing seems clear: separate identifiers from protocols.


The section "Definition of operations" is really about the operations of 
particular protocols associated with identifiers, and so it has similar
problems as described above.  The problem is more obvious when the same
identifier can be used in different ways, with different "methods" of
the same protocol.  

Another important issue not discussed or referenced in this document is
registration of identifier schemes and associated protocols.  I realize
this is covered in a separate document, but it should be mentioned here
as well.


===========
The remainder of my comments are typographical or stylistic.

Section "Demonstrated utility"
"needless" => "needlessly"

Too many "things".  I'm not sure what kinds of things are meant in
"kinds of things that are useful".


Section "Proxy into HTTP/HTML"

HTML seems to be unrelated to this proxying function.  Requiring use of
HTML for representing non-HTML objects would seem to change the functionality
of the protocol.

"the new URL object" => "the new URL scheme"

Under "Are the operations mappable ... to HTTP operations?" add the
question "If so, why use a new scheme?"




-- 
Daniel LaLiberte
[email protected]