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

Larry Masinter writes:
 > 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.

I'm fine with the generic syntax that disallows elision of "//<site>"
leaving just "<scheme>:<path>?<query>".  I was not talking about that at
all, in case you thought I was.

The problem I have is that calling it a "<site>" in the first place
causes confusion in the mind of the reader since what follows the "//"
might not be a site in the sense of a location specifed by a domain name
or any other naming scheme.  It is more generally an identifier in a
higher-level naming scheme, one step higher than the path component,
that provides a context for interpretation of the remainder of the URL.
I'd replace "<site>" with something like "<context>".

Maybe you are saying that a URL of the form

  path:<path>?<query>

is not using the generic syntax because there is no "//<site>" part.  If
so, I believe that is bad and unnecessary.  I would say that "//<site>"
is *not* a required part of the generic syntax, but it is specifically
required by a few schemes.  And I would change "<site>" to something
else anyway.

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

I'm not sure which point "this" is, or which way it is clarified.

I'm still confused since you defend that "//" is only useful for schemes
that support relative forms, which is clearly wrong since all you need
is a base URI to provide a context, not one with a <site> in it or any
higher-level naming part at all.

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

 > No, it isn't 'conceivable', without changing URLs, 

That's why I said "although we don't have a way to express that with
current relative URI notation".

 > ... and there is unlikely to be consensus to change URLs for this
 > dubious feature.

I wouldn't be so quick to label this dubious.  The web is still young.
What about 500 years from now when URNs are supposed to still be
meaningful?

I'm not suggesting we change the syntax of URLs for this now.  I'm
merely noting a potential area for future work.

 > It's important that the relative+base => newURL
 > algorithm be independent of the scheme.

I agree.  I wouldn't want to disturb that.  I only suggested that the
algorithm could be generalized to deal with relative URIs that are
relative to higher level parts of the base, higher than just the
hierarchical path component.

 > >  > 2.2.5 Definition of URL schemes not associated with data resources

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

Yes, the issue is more complex than function vs procedure.  It involves
connections vs connectionless transactions, synchronous vs asychronous, etc.
(That's why I said "To some degree".)

So what do you mean by a "service"?  Anything that is not "clearly" a
resource?  If that is what you mean, then you better at least be clear
about what you mean by a "resource".

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

Of course nothing!  First of all, I recall language in the HTTP spec
saying that a resource is what is hidden behind the server side of the
request, not "what you get".  You only actually get an entity, according
to that scheme of things.  But if you never really "get" a resource, but
only interact with it via services, what is it really?

On the other hand, it is not difficult to imagine mapping a telnet URL
to a connection-oriented interaction with a remote resource called the
shell environment.

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

That strikes me as rather ironic - I don't think it is clear at all.  I
think a major part of the problem is that we don't have clear
definitions of resources and services in terms of simpler notions, and
if we did, it would probably be those simpler notions that we use to
distinguish types of schemes.  And that is why I suggested the
following:

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

Fine, say that it depends on the URL.  Maybe even say how it depends, if
that is definable, which it probably should be if agents are supposed
to make sense of the scheme.

Clearly it is useful to know whether resolution of a URL causes side
effects or is affected by side effects, and whether there is any result
returned - caches could use that to determine whether they should cache
the result of a resolution.

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

Ah, if you agree that location *is* illusory, we are getting somewhere.
Many people can't seem to see the forest for the trees.  

The illusion of "locating resources" has given rise to a deeper illusion 
of "location independence" because people seem to have forgotten what
goes on when they lookup a resource by resolving its identifer.

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

In this case, I was not suggesting that we not ask for documentation of
the operations that may be applied.  In fact, I believe we SHOULD
require that documentation.  Above, I was arguing that the blur between
abstract semantics and concrete protocol is where the illusion of
protocol-independence breaks down.

--
Daniel LaLiberte
 [email protected]  (was: [email protected])
 [email protected]