[BXXPwg] new penultimate version available

Roy T. Fielding fielding@ebuilt.com
Fri, 22 Jun 2001 13:57:25 -0700


On Fri, Jun 22, 2001 at 12:49:05PM -0700, Marshall T. Rose wrote:
> in the beep world, it seems to me that if the resource administrator wants
> that kind of policy, then when the listener sends its greeting, it
> identifies only the TLS profile. after you tune with that, the listener
> tells you what profiles it's now willing to let you use.

Right, but it should be noted somewhere that this only applies to
per-connection TLS, whereas things like https indicate the entire
application route must be TLS (or equivalent) secure.  The difference
is encountered when you have a chain of peers acting in the same way as
an HTTP proxy chain -- if the client must wait for the origin to tell
it the type of profile, then how does the first peer tell the second
peer to contact the third peer to get the profile and send it back to
the first peer before the first peer makes a non-secure request on the
second peer?

I'm not saying that a separate URL scheme is the right way to handle
this in BEEP (I'm not even sure if peer chains are a reasonable application
of BEEP), but people who are coming from HTTP-land need to understand
the difference between hop-by-hop security and tunnelled security.
Something to think about, in any case, before somebody thinks that
http-over-beep is a no-brainer.

> similarly, if the initiator wants that kind of policy, the first thing you
> do is tune for TLS and then bind the desired profile.

Yes, easy to do if the initiater is always configured for TLS or if there
is some other application state to tell it to do so.  Traditionally, the
Web has put that in the URI in order to support plain-text references.
Otherwise, I think it would have been an HTML element or attribute.

> re: the proposal for a "web:" url scheme
> 
> the problem i have is that i reject the notion of putting transport
> information on the RHS of the ":" in a URI.
> 
> different transport mappings may imply different kinds of domains,
> addressing, etc. all of these things go in the RHS side.
> 
> the LHS side tells you how to interpret the RHS side, so i think the
> transport mapping should go there.
> 
> presumably roy has a more elegant way of stating this...

Hmmm, elegant.... no, but a more geeky way to look at it is that the
URI scheme is the key used to dynamically load all of the mechanisms needed
to parse and resolve the RHS.  If we place a bunch of conditional elements
within the RHS, then we either have to do N dynamic loads (very expensive)
or we have to load every possible option for the scheme (very expensive),
and in any case makes it extremely hard for application developers to
implement only those transports that they care to implement.  Consider,
for example, what that meant before export controls were lowered.

In any case, regarding the proposal, there is no way that another ":" will
be allowed within the authority component -- see the URI syntax for
why that would be ambiguous.  We did discuss the addition of a transport
indicator to the port component (e.g., "example.com:tls.20202"), but I
still prefer "s" schemes (or soap.beep.tls) over that.  Or would that
be soap.tls.beep?  *shrug*  That is, assuming peer chains are needed,
since profiles are fine for neighbor exchanges.

....Roy