Comments on draft-ietf-urlreg-guide-01.txt

Larry Masinter writes:
 >                   Guidelines for new URL Schemes
 > 2.1.1 Use of initial "//" for top level
 > 
 >    Many proposed new URL schemes seem to use "://" as a kind of
 >    indicator that what follows is a URL. However, the use of "//"
 >    indicates a "top level" for schemes that support relative
 >    URLs, and is not necessary (and just confusing) for schemes
 >    that have no relative forms. URL schemes without relative
 >    forms (such as mailto, cid, mid) do not use an initial "//".

I believe this meaning of "//" is incorrect.
Whether a scheme has relative forms is irrelevant.  Consider the "path"
scheme which allowed relative forms but had no separate higher-level
that needs a "//" to distinguish it.  

A more correct meaning of "//" is as Tim B.L. described about a year ago
(and years earlier, I am sure): it distinguishes a higher-level name
space with its own notational constraints from a lower level one.  For
"http" URLs, the "//" signals that what follows is a domain name, up
until the first "/" after which is the path that is typically mapped to
a file system path.  Many people assume that "//" means that what
follows is a domain name, but that is not necessarily the case across
all URL schemes, though it probably is currently.

(Furthermore, it is conceivable to have a relative URL that is relative
to part of the higher-level name space of a base URL, although we don't
have a way to express that with current relative URI notation.  For
example, a base URL with domain "www.a.b.c.com" might allow a relative
URI that starts "//support/..." which would be translated to the FQDN
"support.a.b.c.com".  There isn't much need for this kind of relative
URI for http (currently), but it is conceivable for other multi-level
schemes.)

 > 2.2.2 URL schemes associated with network protocols
 > 
 >    Most new URL schemes are associated with network resources that
 >    have one or several network protocols that can access them. The
 >    'ftp', 'news', and 'http' schemes are of this nature.  For such
 >    schemes, the specification should completely describe how URLs are
 >    translated into protocol actions in sufficient detail to make the
 >    access of the network resource unambiguous.  If an implementation
 >    of of the URL scheme requires some configuration, the configuration
         ##
 >    elements must be clearly identified. (For example, the 'news'
 >    scheme, if implemented using NTTP, requires configuration of the
 >    NTTP server.)

The key word is "associated".  I interpret it rather loosely while
others think of it as a strong binding.  Nevertheless, while the
specifier of a scheme may hope that the scheme is strongly bound
to a particular protocol, implementors of the scheme may find other
mechanisms that are partially or completely outside of that protocol.
Conversely, a scheme that is not supposed to be bound to a particular
protocol may end up being strongly bound because there is only one
protocol that is ever implemented and used.

So I would change this paragraph to not require any such specification
of the protocol and configuration elements.  Such details could be
(or perhaps should be) moved to separate documents.

 > 2.2.4 Definition of non-protocol URL schemes
 >    
 >    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. This is the case, for
 >    example, with the "cid" and "mid" URL schemes. For these URL
 >    schemes, the specification should describe the notation of the
 >    scheme and a complete mapping of the locator from its source.

This should be combined with the above paragraph (modified) about
schemes that are supposedly associated with protocols.

 > 2.2.5 Definition of URL schemes not associated with data resources
 > 
 >    Most URL schemes locate Internet resources that correspond
 >    to data objects that can be retrieved or modified. This is the
 >    case with "ftp" and "http", for example. However, some URL schemes
 >    do not; for example, the "mailto" URL scheme corresponds to an
 >    Internet mail address.
 >    
 >    If a new URL scheme does not locate resources that are data
 >    objects, the properties of names in the new space must be clearly
 >    defined.

There is an ambiguity concerning schemes associated with resources vs
services.  To some degree, the distinction is similar to that of
functions vs procedures.  A function returns a result identified by the
function name and its parameters, whereas a procedure is affected by
hidden state and typically has some side effect.  But a function that
returns a "null" result and has some side effect is then the same as a
procedure.

"http" URLs are certainly affected by hidden state such that each
resolution may produce a different result, and increasingly, they cause
side effects when resolved.  Any claim that http URLs universally
correspond to data objects quickly falls apart in the face of reality.

I do not believe it is even useful to distintinguish between resources
and services.  To get to a resource, after all, one must go through
several services.  What is meant, perhaps, is that the semantics of the
scheme should specify whether resolution of a URL (via some particular
protocol) may be affected by side effects and causes side effects, and
whether or not the resolution results in an object.  That would indeed
be useful.

I would replace the suggestion of "locating resources" with "resolving
URLs".  Location is illusory.

 > 2.2.6 Definition of operations
 > 
 >    In some contexts (for example, HTML forms) it is possible to
 >    specify any one of a list of operations to be performed on a
 >    specifc URL. (Outside forms, it is generally assumed to be
 >    something you GET.)
 > 
 >    The URL scheme definition should describe all well-defined
 >    operations on the URL identifier, and what they are supposed to
 >    do.

The distinction between the abstract semantics of a scheme and the
particular semantics of a resolution protocol blurs when we get to the
definition of operations.  Any precise enough definition of the
operations constrains the protocol to the point that either you have one
particular protocol or there is still some degree of abstraction that
may be implemented by several protocols and it truely does not matter
which is used (as long as all parties involved speak the protocol).

--
Daniel LaLiberte

[email protected] => [email protected]
Was: NCSA.  Now: GTE Labs, Waltham MA

[email protected]