[BXXPwg] Updated strawman for BEEP protocol URIs

Gabe Wachob gwachob@wachob.com
Mon, 18 Jun 2001 22:25:12 -0700 (PDT)


OK, now that I buy your counterexample (a useful excercise IMHO)..

I guess my only concern is the negotiation of transport - see my note
below.

On Mon, 18 Jun 2001, Dan Kohn wrote:

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

Little nit - "port" may not have meaning in some transports.. i.e. a
serial connection or bluetooth serial profile (if one were to go there,
its been suggested not to).

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

Outside of TCP->TLS, this negotiation isn't part of BEEP, is it? If I
understand this proposal (you are not the first to make it), a listener
can make an initial TCP connection, and then somehow negotiate that it
wants to use a different transport (say sctp) and so the two magically
make this new connection. OK, its not magic - probably a relatively simple
profile for transport negotiatoin.

Is that what you are suggesting?

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

Right, we all agree thats clear now. BEEP endpoints don't need URLs,
application endpoints do.

	-Gabe