Dan Kohn dan@dankohn.com
Fri, 15 Jun 2001 18:52:55 -0700

There is an imprecise and not fully defined mapping between
application-level protocols, profiles those applications use, MIME types
they carry, and transport layers they run over (including port number).
One important data point on the design of HTTP URLs is RFC 2817
<http://www.normos.org/ietf/rfc/rfc2817.txt>, which the IESG demanded so
that every new protocol issued did not need 2 port numbers, one for over
TCP and one for over TLS.

In that sense, the https URL specification
<http://www.normos.org/ietf/rfc/rfc2818.txt> was grandfathered in but is
not a good model going forward.

Unfortunately, the conclusions to draw from this story are not obvious.
The main question is, is there a default beep transport method
(presumably beep over tcp) from which all other options can be
negotiated (beep over sctp, beep over tls, etc.).  If yes, at least the
last layer of the ice.beep.tcp URL scheme name hierarchy is unnecessary,
at the potential cost of an extra RTT or two (although appending
";transport=tls" would alleviate this cost).

Another core question is whether there is an expectation of a generic
beep client that speaks lots of profiles.  It seems much more likely to
me that my mailer, my browser, my im client, etc. will all be extended
to use beep, perhaps in addition to other protocols.  This implies that
the beep URL scheme is not useful, since there is no obvious default
beep client to invoke.  An smtpbeep, webbeep, and imxp scheme would seem
to work better.

So, my strawman proposal is:

+ Any given beep profile is welcome to define it's own URL scheme
+ Such a scheme should define it's transfer semantics as based on beep
(e.g., ice, imxp), so there's no need for "beep" to appear in the URL
scheme name.
+ Use of alternate transport layers are negotiated upon invocation of
the URL.  This implies that all beep servers need to implement at least
a stub TCP implementation to negotiate over to SCTP, TLS, etc.  However,
it's hard to imagine a more prevalent lowest common denominator than TCP
+ A default beep URL scheme should not be registered, since invocation
of a beep URL has no default semantics.

		- 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 Bob Wyman
Sent: Friday, June 15, 2001 12:34
To: Bill Mills
Cc: bxxpwg@invisible.net
Subject: RE: [BXXPwg] SOAP over BEEP

Bill Mills wrote:
> Perhaps the scheme should encode the the transport mode 
> as well so that:
>	beep:			beep over tcp
>	beeps:		beep over ssl
>	beepsc:		beep over sctp

  Please don't do this. The transport protocols are correctly defined
distinctly from the application protocols and should be dealt with
distinctly. If they are bound together, then every introduction of a new
transport, tunnelling spec, etc. forces updates to a potentially large
number of specifications, implementations, etc. The mere fact that http
and https exist may be precedent, however, it doesn't establish the
binding of application and transport protocols as best practice. 

		bob wyman

BXXPwg mailing list