[BXXPwg] Updated strawman for BEEP protocol URIs

Dan Kohn dan@dankohn.com
Mon, 18 Jun 2001 21:10:39 -0700

The counterexample for Gabe is a beep listener that, for whatever
reason, supports profiles for two or more services on the same port.
Which is why I'd like to suggest the following (updated) proposal:

Any protocol built over beep is welcome to define it's own URL scheme.
This registration must include what profile is supported and the default
port number and transport layer.  Since URL schemes will map one-to-one
to BEEP profiles, the profile should not be separately specified in the
URL.  Thus, for a "web over beep" service, the following scheme would be
registered using RFC 2396 notation:

web_URL = "web:" "//" host [ ":" transport ] [ ":" port ] [ abs_path [
"?" query ]]

transport = "tcp" / "sctp" / "udp" / "tls"

And where lack of specified transport defaults to TCP (for this scheme
name, although not necessarily for others).  The listener and/or
initiator can still cause the transport to be negotiated (e.g., from tcp
to tls), but the transport in the URI specifies what to start with.

web is used instead of web.beep because web is not previously defined
over other session layers.  Similarly, imxp, syslog.raw, and
syslog.cooked are all good URL scheme names, where if soap is registered
as a scheme name using HTTP transport semantics, then SOAP over BEEP
should use "soap.beep".

A default beep URL scheme should not be registered, since invocation of
a beep URL would have no default semantics and no default application to

		- dan
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

-----Original Message-----
From: bxxpwg-admin@lists.invisibleworlds.com
[mailto:bxxpwg-admin@lists.invisibleworlds.com] On Behalf Of Gabe Wachob
Sent: Monday, June 18, 2001 17:07
To: Marshall T. Rose
Cc: bxxpwg@lists.invisibleworlds.com
Subject: Re: [BXXPwg] SOAP over BEEP

In the example I give, I am giving the endpoint to an application, or
another person to stick in their application. I presume the application
will know what to do... e.g. the profile to start.

Are there going to be applications which can run arbitrary BEEP
In which case, yes, you'd have to include the profile with the
I'm trying to figure out a real example of such...

I guess maybe there is increasingly a new class of applications where
"physical transport" is not specified and that somehow that physical
transport (or something even above it like BEEP) must be specified along
with the protocol's logical endpoint naming scheme (a la soap.beep
below). I just don't have a feel for how that will actually play out -
will SOAP clients be frequently using HTTP transport along side BEEP
transport, or will this be a toggle/preference/configuration issue that
not done on a per-interaction basis?


On Mon, 18 Jun 2001, Marshall T. Rose wrote:

> > Thus, no real need for URLs except something very basic like
> > beep:<hostname>:<port>
> >
> > Counterexamples?
> i think that it makes sense to define a URL scheme for a protocol that
> based on beep, e.g.,
>     soap.beep://example.com?resource=stockTicker
> what makes no sense to me is defining a URL scheme for beep, per se.
> in the example that you give, how is one to know what profile to
> /mtr

BXXPwg mailing list