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

The URI syntax document 

[email protected] wrote:
> 
> 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.

I think we should defer to the URI syntax/semantics document
as soon as that's actually finished. (Those on the [email protected]
or [email protected] list will know about the latest flap.)

It is true that either a scheme uses the 'generic syntax' or it
doesn't, and it should say, and the 'generic syntax' is

      <scheme>://<site><path>?<query>

where

      site          = server | authority

However, the generic syntax doesn't allow "//<site>" to be elided.

> 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.

The syntax document is actually clear on this point.


> (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.)

No, it isn't 'conceivable', without changing URLs, and there is
unlikely to be consensus to change URLs for this dubious feature.
It's important that the relative+base => newURL algorithm be
independent of the scheme.

>  > 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.

The definition of the scheme SHOULD define at least one way to
use the scheme. Not the only way. Not the unique way. Not MUST --
maybe there's some really good reason. But SHOULD.

It doesn't have to be documented in just one RFC, either, if
there's a good reason to put something in a separate document, fine.
But there's no good reason not to require a definition.


>  > 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.

This doesn't seem like a good idea. The case analysis is illuminating,
even if you believe the cases collapse. You either have a network
protocol or you don't. If you don't, then you should say so. If you
do, you should say how you can use the network protocol.


>  > 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.

"telnet:" is neither a function or 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.

This is bogus. Of course there's a data object, and it's what you get
when you do GET. There is no data object when you invoke a "telnet" URL.

> I do not believe it is even useful to distintinguish between resources
> and services.  

It's pretty clear that you want to explain where a new URL scheme stands,
even if there's no clear distinction. 

>             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'm all for asking people to identify things that are useful, but I'm
not sure if it's (a) possible, or actually, *HOW* it would be useful.
For many schemes, the answer is "it depends on the URL". Now what?

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

The Internet is illusory too, but we manage to deal with the illusion.
I'm not sure "Location is illusory" is helpful, Dan.


>  > 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).

These are guidelines. We're asking people to provide documentation.
That there are some cases where it is hard for the documentation to
be precise is NOT a good reason not to ask for it.

Larry
-- 
http://www.parc.xerox.com/masinter