[BXXPwg] Updated strawman for BEEP protocol URIs
Mon, 18 Jun 2001 22:40:50 -0700
Yep, that's what I'm suggesting.
TCP to SCTP seems like it could become common in addition to TCP to TLS.
My original strawman suggested not to bother with a transport token in
the URL, since you can always negotiate it later. But, one can imagine
circumstances (say IMXP) where the listener supports both secure and
insecure modes, but the webpage embedding the IMXP URL wants the
initiator to start off secure. Without the tls token in the URL,
there's no way to be sure that the initiator will bother to upgrade.
This is analogous to the situation with http vs. https today.
Although one could do different URL schemes for each transport, there's
no obvious benefit to doing so, and it's a pain in terms of requiring
multiple registrations. Also, URL schemes for all BEEP profiles are
upward compatible with new transport mappings (e.g., BEEP over DNS)
simply by having the transport mapping RFC specify an additional
Finally, the fact that port may not be meaningful in certain transports
is already handled by the fact that it's optional.
Dan Kohn <mailto:firstname.lastname@example.org>
From: Gabe Wachob [mailto:email@example.com]
Sent: Monday, June 18, 2001 22:25
To: Dan Kohn
Cc: firstname.lastname@example.org; Roy Fielding
Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs
OK, now that I buy your counterexample (a useful excercise IMHO)..
I guess my only concern is the negotiation of transport - see my note
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
> port number and transport layer. Since URL schemes will map
> to BEEP profiles, the profile should not be separately specified in
> URL. Thus, for a "web over beep" service, the following scheme would
> 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
> 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
profile for transport negotiatoin.
Is that what you are suggesting?
> A default beep URL scheme should not be registered, since invocation
> a beep URL would have no default semantics and no default application
Right, we all agree thats clear now. BEEP endpoints don't need URLs,
application endpoints do.