fyi: should URIs convey protocol/service layering?

This is a couple'o (key) messages from a thread over on the 
bxxpwg@invisible.net list that may be of interest to folks here.

The discussion is nominally about whether the URI identifying a service that 
may be available via muliple protocols should convey/reflect this and how it 
might do so.

The bxxpwg@invisible.net is here..

  http://lists.invisible.net/pipermail/bxxpwg/

..and the message that instigated the thread is here..

  http://lists.invisible.net/pipermail/bxxpwg/2001-June/000513.html

JeffH

------- Forwarded Message 1

From: "Marshall T. Rose" <mrose+mtr.netnews@dbc.mtview.ca.us>
To: "Roy T. Fielding" <fielding@ebuilt.com>
Cc: "Gabe Wachob" <gwachob@wachob.com>, <bxxpwg@invisible.net>,
        "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>
Subject: Re: [BXXPwg] SOAP over BEEP
Date: Thu, 14 Jun 2001 15:59:22 -0700

roy - thanks.

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

in most of the recent cases that i have seen, the only thing that differs is
how the data gets moved, e.g., going from soap/http to soap/beep, or
ice/http to ice/beep, etc. in both cases, you have a situation where the
path is going to be the same, and i have difficulty understanding whether
the "use beep" bit should be present in the scheme component or the
authority component. for example,

    http://example.com/

may very well be a valid thing for someone doing soap over http. so, what
should we be using for the soap over beep case? here are four possibilities,
i'm sure there are more...

    beep://example.com/

    soap.beep://example.com/

    soap://example.com/?proto=beep

    beep://example.com?profile=http://iana.org/beep/soap

ideally, i would prefer to avoid having to use a new scheme everytime
someone moves yet another service on top of beep.

thanks,

/mtr

------- Forwarded Message 2

From: "Marshall T. Rose" <mrose+mtr.netnews@dbc.mtview.ca.us>
To: "Roy T. Fielding" <fielding@ebuilt.com>
Cc: "Gabe Wachob" <gwachob@wachob.com>, <bxxpwg@invisible.net>,
        "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>,
        "Marshall Rose" <mrose@dbc.mtview.ca.us>
Subject: Re: [BXXPwg] SOAP over BEEP
Date: Thu, 14 Jun 2001 23:44:58 -0700

> If I were to invent it from scratch, I would probably choose something
like
>
>     web://example.com:http.tcp.80/path
>     web://example.com:http.udp.7149/path
>     soap://example.com:beep.tcp.21212/path
>
> with the first ":http.tcp.80" being the default for the web. Obviously,
> that is getting pretty ugly.  For some reason I think this looks better
>
>     http://example.com/path
>     web.http.udp://example.com:7149/path
>     soap.beep.tcp://example.com:21212/path
>
> It also better fits the architecture of most URI handling software, which
> typically consists of a table of (scheme name , handler routine) tuples.

0. well, i agree that using "web:" instead of "http:" would certainly make
things a lot more clear, but that's water under the bridge.


1. let me understand your reaction to

> > ideally, i would prefer to avoid having to use a new scheme everytime
> > someone moves yet another service on top of beep.
>
> Hmmm, why?  Logically, they are distinct services.  Keep in mind that the
> "http" URL is specific to HTTP over TCP, even though HTTP itself is not
> dependent on TCP.  If we were to deploy a new HTTP-over-SCTP service,
> we would need a new URL scheme because the authority syntax of
hostname:port
> is specific to TCP, not HTTP.

i don't think that the http/tcp to http/sctp analogy is a good one. what i'm
trying to understand is whether it is a good thing to define two schemes for
soap.beep.tcp and ice.beep.tcp or to just have one scheme for beep over tcp.
for all three schemes, the authority part remains the same.

in guess i see your point that

> >     beep://example.com?profile=http://iana.org/beep/soap

is pretty week.


2. anyway, in comparing:

    soap://example.com:beep.tcp.21212/path
    soap.beep.tcp://example.com:21212/path

i guess i prefer the latter since when we move from "beep.tcp.21212" to
"beep.ipv6.21212" the thing to the left is going to be funky. what isn't
clear to me is whether the iana is going to be happy when i start
registering url schemes in groups of three, e.g.,

    ice:
    ice.beep:
    ice.beep.tcp:

/mtr





------- End of Forwarded Message

Received on Friday, 15 June 2001 11:53:43 UTC