Subject: RE: [BXXPwg] SOAP over BEEP

From: "Bob Wyman" <[email-masked]>
Date: Fri, 15 Jun 2001 15:33:59 -0400

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
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: Ward Harold <[email-masked]>
Date: Fri, 15 Jun 2001 15:22:37 -0500

> 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

---

From: "Dan Kohn" <[email-masked]>
Date: 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
support.
+ A default beep URL scheme should not be registered, since invocation
of a beep URL has no default semantics.

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bob Wyman
Sent: Friday, June 15, 2001 12:34
To: Bill Mills
Cc: [email-masked]
Subject: RE: [BXXPwg] SOAP over BEEP

		bob wyman

---

From: Gabe Wachob <[email-masked]>
Date: 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...

	-Gabe

---

From: "Dan Kohn" <[email-masked]>
Date: 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

-----Original Message-----
From: Gabe Wachob [mailto:[email-masked]] 
Sent: Friday, June 15, 2001 19:06
To: Dan Kohn
Cc: [email-masked]; 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).

	-Gabe

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 15 Jun 2001 19:41:25 -0700

>of a beep URL has no default semantics.

This sounds like a fairly reasonable proposal.

I note that LDAPext had a discussion about how to construct
URL for various LDAP mappings.  While URLs which explicitly
specify a mapping can be useful:
        ldap.tcp://example.net/
        ldap.udp://example.net/
        ldap.sctp://example.net/
        ldap.beep://example.net/
        ldap.beep.sctp://example.net/
        ldap.beep.tcp://example.net/

It is often advantageous just to say:
        ldap://example.net/

and let the client figure out the best way to locate the
service.  A client can use DNS SRV or other means (including
querying the service over the default mapping) to determine
which mappings are supported.

Kurt

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 15 Jun 2001 20:52:33 -0700

> not a good model going forward.

That is not sufficient.  The client must know whether or not the
connection must be secured before it makes the first resource request of
the server.  In order to know that, the information must be in the URI.
The mechanism used to establish the secure session might be present
in the protocol, as it is with HTTP/1.1 Upgrade, but the decision to make
that upgrade mandatory prior to sending any sensitive information is
something that the client must make using only the URI as a guide.

The IESG objected to multiple TCP ports per protocol, not multiple
scheme names.  There is no reason why a new "s" scheme cannot be defined
with the same default port as the normal scheme, just as there is no
reason why https services cannot be located on port 80.  The client,
however, still needs the distinct schemes in order to know how it
should contact the server.  https, in particular, not only requires
that contact with the naming authority be secure, it also requires that
all application hops along the way to the naming authority be secure,
and further that nothing on that chain be cachable by default.  https
therefore defines much more than simply HTTP over SSL.

....Roy

---

From: "Dan Kohn" <[email-masked]>
Date: Sat, 16 Jun 2001 09:14:35 -0700

Roy, I think you make great points that a) the URL scheme can signify
more than just secure or not (such as caching)) and that b) it's
essential that the client not reveal more information than necessary by
during the security negotiation.

However, my read of RFC 3080 is that it is possible for the BEEP peer to
provide a tuning profile that ONLY indicates upgrading to TLS (or
whatever, including intricate combinations of transport and SASL
profiles), and fails to return anything else.  See, for example, the
long example at the beginning of section 3.

In that case, no cleartext data communication is made.  Phrased
differently, the first resource request -- if it is a request for a
secure channel -- is always tuned in the clear, and so a single URL
scheme should suffice.

		- dan

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]] 
Sent: Friday, June 15, 2001 20:53
To: Dan Kohn
Cc: [email-masked]
Subject: Re: [BXXPwg] SOAP over BEEP

in the protocol, as it is with HTTP/1.1 Upgrade, but the decision to
make

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Jun 2001 23:09:44 -0700

> secure channel -- is always tuned in the clear, and so a single URL

Yes, if the protocol is designed such that the client must read a message
from the server prior to it sending any data across the connection, then the
security context can be established prior to the client sending data.
That is, assuming that the server knows what the security context should
be when it establishes the connection.

The problem with such a mechanism is that it doesn't work with intermediaries.
A client with a long-lived session connected to a peer acting like an http
proxy isn't likely to be negotiating a new channel context before making
each request.  Thus, such an architecture would require that all proxy
communication be restricted to the GCD of all possible security profiles,
unless the identifiers contain the security information regardless.

Fortunately, HTTP doesn't have that feature.  ;-)

....Roy

---

From: Darren New <[email-masked]>
Date: Thu, 28 Jun 2001 10:11:13 -0700

> the server.  In order to know that, the information must be in the URI.

Not really. If the server only advertises TLS in the greeting upon
connection, it's pretty obvious to the client that that must be
negotiated first.

> something that the client must make using only the URI as a guide.

No, the server can enforce it.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
       San Diego, CA, USA (PST).  Cryptokeys on demand.
     This is top-quality raw fish, the Rolls-Rice of Sushi!

---

From: James Aylett <[email-masked]>
Date: Thu, 28 Jun 2001 18:18:21 +0100

> connection, it's pretty obvious to the client that that must be

That's not the issue, is it? If there's a service which can either be
secured using TLS or not, and some application somewhere wishes to
explicitly link to the _secured_ version, then you need that in the
URI.
 
The counter argument to this is that in such a situation, the service
should really be secured _always_, but I don't think this holds
water. I'm sure there are ample situations where a sensible subset of
operations could be safely performed over an unsecured connection
(perhaps a search engine where a secured connection gives access to
more sensitive data?) for this to be a real issue.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                           www.zap.uk.eu.org
  [email-masked]                                    www.footlights.org

---

From: Darren New <[email-masked]>
Date: Thu, 28 Jun 2001 11:28:36 -0700

> explicitly link to the _secured_ version, then you need that in the

My apologies. I was away for the duration of the conversation, and my
mail reader sorted things in a funny way, and I wound up answering
before I read the entire thread. Nevermind.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 28 Jun 2001 14:44:29 -0700

> connection, it's pretty obvious to the client that that must be

The problem I was referring to is one where you have

                                     .------------> service peer
    client peer <=======> proxy peer -------------> service peer
                                     `------------> secure service peer

wherein the client has a semi-permanent beep session with the proxy,
which in turn accesses many different services.  Because the profile
is selected on a per-connection basis and negotiated up-front, the
proxy doesn't find out that the third service peer requires security until
after the client peer has sent a request in the clear to the proxy.  The
ways to avoid the problem are to require that beep proxy connections
always be secure (not really practical), or require that an indicator
of the secure connection requirement be supplied with the identifier,
so that the client peer can know in advance that it must create a
separate, secure connection to the proxy for that request.  That is
why the Web needed both http and https naming schemes.

Note that this problem depends on the nature of the application
architecture, but will certainly apply to soap over beep.

....Roy