Bill Mills wmills@invisibleworlds.com
Fri, 15 Jun 2001 13:39:30 -0700

Well, I had intended it to be comparable to http and https, which is 
distict from any encryption layer withing the BEEP framework.

The vector that I thought needed to be dealt with is the underlying 
transport mapping.  Let's leave it at TCP and SCTP and ignore SSL for 
now then.  The question stands.

-----Original Message-----
From: Ward Harold [mailto:wharold@tivoli.com]
Sent: Friday, June 15, 2001 1:23 PM
To: Bob Wyman
Cc: Bill Mills; bxxpwg@invisible.net
Subject: Re: [BXXPwg] SOAP over BEEP

Bob Wyman wrote:

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

Not to mention the fact that ssl is only one of a number of security layers
that a beep profile might use. Yes, please don't do this.

... WkH