[BXXPwg] new penultimate version available

Marshall T. Rose mrose+mtr.netnews@dbc.mtview.ca.us
Fri, 22 Jun 2001 12:49:05 -0700

dan - thanks for the note.

re: indicating tls in the "soap.beep" url scheme

i guess i can go for making a change of this type, although i'm not entirely
convinced. here's why:

do "http:foo" and "https:foo" refer to different resources? probably not.
the only difference here is an early-binding optimization saying that to get
at the resource you need privacy enhancement.

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.

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

what i'm saying here is that the privacy thing looks more like a policy
issue than a protocol issue. beep has a different way of signalling this
than the http approach. so, it's not really clear to me that the "soap.beep"
url scheme needs to externalize that policy.

i'd be interested in hearing roy's comments.

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