[BXXPwg] new penultimate version available

Marshall T. Rose mrose+mtr.netnews@dbc.mtview.ca.us
Fri, 22 Jun 2001 15:40:32 -0700


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

hi. i guess i don't have a problem with something like

    soap.beeps:

there are two kinds of profiles in beep: tuning and data. tuning profiles
are the things you invoke serially to get the session the way you like it
and data profiles are the things you use to get real work done.

in terms of the semantics of https:, in beep there are two kinds of relaying
strategies.

first, you have the vc approach used by
http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-tunnel-01.txt
(which is what ben is talking about) lets the originator specify a source
route and get an octet-transparent path to the ultimate destination.

the second is the routing approach used by
http://www.ietf.org/internet-drafts/draft-ietf-apex-core-03.txt is an
generic application-layer relaying facility.

i don't think that either of these map cleanly to the http intermediary
model...

/mtr

ps: for those who thing "vc" stands for "venture capitalist" instead of
"virtual circuit", you probably got subscribed to this list by mistake.