Subject: [BXXPwg] SOAP over BEEP

From: "Eamon O'Tuathail" <[email-masked]>
Date: Fri, 15 Jun 2001 22:26:52 +0100

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

If we are only ever going to have two transport mappings, I would agree,
but what happens when (not if) we have twenty transport mappings (over the
next
ten years). RFC 3080 is careful to separate out the transport mapping from
the BEEP core, we really need to follow this good practice with the URI.

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 16 Jun 2001 10:36:59 EDT

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

Why not use something similar to the JDBC URLs in Java:

  beep:tcp
  beep:tcp:ssl
  beep:sctp