[BXXPwg] SOAP over BEEP

Dan Kohn dan@dankohn.com
Fri, 15 Jun 2001 19:23:19 -0700


Well first, an awful number of things currently more critical to the
Internet infrastructure than BEEP would break if TCP were to go away.

But, on reflection, I have a modified third point to my strawman:

+ Each URL scheme for a BEEP profile specifies the default transport
mapping.  Communication is begun on that transport but can then be
negotiated on to a different one.  Given TCP's obvious ubiquity, it
would seem a real mistake to require that a client invoking a BEEP URL
scheme support SCTP, TLS, WTLS, etc.  OTOH, there's no reason to a
priori prohibit it.

		- dan
--
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

-----Original Message-----
From: Gabe Wachob [mailto:gwachob@wachob.com] 
Sent: Friday, June 15, 2001 19:06
To: Dan Kohn
Cc: bxxpwg@invisible.net; Roy Fielding
Subject: RE: [BXXPwg] SOAP over BEEP


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

	-Gabe


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
>