Roy T. Fielding fielding@ebuilt.com
Thu, 14 Jun 2001 15:35:08 -0700

On Wed, Jun 13, 2001 at 09:39:26PM -0700, Marshall T. Rose wrote:
> roy - i think i get what you're saying, but i'm still not entirely clear.
> setting aside for the moment whether HTTP is a protocol or a service, let's
> skip to this part:
> >
> > YUCK!  wcip needs to learn about hierarchy violations.
> >
> >    wcip.beep://authority/path
> >
> > would be better, but still misses the point.  The URI scheme should
> > answer the question of "what application interface should I expect?",
> > which is a a lot more than "what protocol should I use?".
> and setting aside that i think you mean "layering" and not "hiearchy", let

Nope, I meant the URI has a hierarchical syntax that drops from left
to right, so, unless you consider "wcip over beep" and "wcip over somethng
else" to be under the same naming authority, then beep should be to the
left of the name.  Layering is protocol design.  URI are just names.

> me ask the basic question: what should the uri look like for wcip over beep?
> i suspect that a well-architected answer would provide guidance for the
> dozen or so different domains in which this question is being asked...

wcip is a little odd in that I don't undertand the purpose of the path
within the URI.  If there is no chance of relative URI being used, then
the question of left-to-right hierarchy is not really an issue (aside
from aesthetics).

In general, if the service is available via multiple protocols and the
naming syntax for those protocols will differ, then use a protocol-specific
addition to the URI scheme (like the wcip.beep scheme above).  That is the
normal way of doing it because the authority syntax is often dependent on
the transport used (e.g., TCP ports and defaults).

OTOH, if the syntax for naming will be the same, but the naming authority
will differ based on the lower-layer protocol, then I would include beep
within the authority component.  However, I have yet to see a good example
of this in practice.

If the beep-ness of the resource isn't part of its name at all, then I would
use two separate identifiers -- a URI for the resource and some other
URI (possibly implied by context) to indicate the communication mechanism.
This is no different from how HTTP proxies are specified -- one URL for
the proxy within the client configuration/environment and another URI for
the resource being accessed through the proxy.

My suspicion, however, is that there is no wcip resource -- that, in fact,
the only thing they are using the URL for is selection of a channel.
In that case, they should not have created a wcip URL at all.  Instead,
they should have used existing URL schemes to identify the channel and
simply define a new one for beep channels (with care taken to only identify
aspects of beep that are not specific to one profile).