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

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

Yes it does.  See the last paragraph in 4.3.1 (or the BNF).

[...]

>>  > 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 think Dan's effective point is that "data resources" and "data object"
are the wrong terms to use here.  The definition of resource in the
syntax document is much better.  What you are trying to talk about
here is what happens when you access a resource, what are the various
ways (like HTTP methods) you can access the resource, etc.  How the
resource is implemented should not be relevant (i.e., describe it as
different types of interface).

....Roy