[BXXPwg] SOAP over BEEP
Roy T. Fielding
Fri, 15 Jun 2001 19:50:25 -0700
> 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
> > 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.
The dns name within the authority part may be the same, but its interpretation
tends to be specific to the URI scheme. The reason I used the tcp/sctp
analogy is because that is the slimmest margin of difference, and yet it
does require a different URI scheme because example.com:80 (tcp) and
example.com:80 (sctp) are two different naming authorities -- the
software listening to TCP port 80 is not capable of giving authoritative
answers for the resources named by SCTP port 80, for the same reason that
a web server at TCP port 8001 is not allowed to give authoritative answers
for another web server on TCP port 80.
> in guess i see your point that
> > > beep://example.com?profile=http://iana.org/beep/soap
> is pretty week.
The biggest problem with it in practice is what happens when you do want
to name a resource within beep, and that resource has the ability to
accept data. You can't have more than one ? in the URI syntax.
However, what people really want to do is name the resources made available
by the upper-layer protocol -- beep and its profile names are less significant
to the name even if they are a dependency. That's why I wouldn't define a
"beep" URL scheme, unless there is some resource to be named within the
beep service itself [such as a management interface].
> 2. anyway, in comparing:
> 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.,
I think that it is only necessary to register the default as ice
and additional ones only when they differ from the default. IANA may not
be happy with it, but that is better than requiring every handler of "ice"
URLs to implement (or at least know about) every possible layering.
Applications tend to implement only one application-layer at a time.
I don't think that "beep.ipv6.21212" would ever be necessary because
the IP layer is defined by the hostname, and is therefore already represented
within the authority component. Note that ipv6 literals can already be
included within URLs via the square-bracketed ipv6-literal syntax.
Likewise, if ice were to use some DNS attribute to select which session
layer protocol should be used, rather than encoding it within the URL,
then you wouldn't need ice.beep at all. Someone might want it anyway,
though, just to be able to override the DNS response. *shrug*
As a WWW software developer, I would prefer to implement it as a new scheme.
However, as a protocol architect, I think that if I were inventing it from
scratch and not worrying about the already deployed authority parsers, then
I would include this information in the authority component rather than the
scheme. It is possible that we may end up being forced in that direction
when RFC 2396 is revised, regardless of the running code.
Please keep in mind, however, that the protocol stuff within a URL only
defines how the naming authority is contacted when it needs to be contacted,
and thus doesn't directly tell the client what to do -- a client chooses
what to do for a given URL according to its own configuration and the
context in which the URL was found.