Gabe Wachob gwachob@wachob.com
Fri, 15 Jun 2001 19:05:58 -0700 (PDT)

Hi Dan-

Your suggestion is interesting, but I don't think its a workable solution
as presented.

I think requiring TCP transport for all BEEP peers is a problem because
there are some beep peers which are explicitly only going to able to
support connection over one particular transport mechanism (say, something
stupid like BEEP/WTLS in the wireless space - not saying its practical
today, but maybe someday). In some cases, TCP connectivity just may not
exist. Take also BEEP over something like the serial bluetooth profile...
the IP profile simply may not exist on that personal area network (or
whatever the bluetooth people call it).

I'm not sure if you are actually suggesting that TCP be a required
transport for all BEEP peers, but it sounds like it...


On Fri, 15 Jun 2001, Dan Kohn wrote:

> 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
> support.
> + 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
> BXXPwg@lists.invisible.net
> http://lists.invisible.net/mailman/listinfo/bxxpwg
> _______________________________________________
> BXXPwg mailing list
> BXXPwg@lists.invisible.net
> http://lists.invisible.net/mailman/listinfo/bxxpwg