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

		- 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
profiles?
In which case, yes, you'd have to include the profile with the
endpoint...
I'm trying to figure out a real example of such...

I guess maybe there is increasingly a new class of applications where
the
"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
naming
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
is
not done on a per-interaction basis?

	-Gabe


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
is
> 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
start?
>
> /mtr
>
>


_______________________________________________
BXXPwg mailing list
BXXPwg@lists.invisible.net
http://lists.invisible.net/mailman/listinfo/bxxpwg