Subject: [BXXPwg] new penultimate version available

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 22 Jun 2001 08:49:14 -0700

HTML version at http://beepcore.org/beepcore/beep-soap.jsp

this one has a typo, which is corrected in the next release.

whenever you see "?resource=stockQuote", ignore it.

new in this version:

    - soap packages
    - feature extensibility
    - new approach to profile initialization
    - a URL for soap over beep

/mtr

Subject: I-D ACTION:draft-etal-beep-soap-01.txt
From: [email-masked]
To: IETF-Announce: ;
Date: Fri, 22 Jun 2001 07:12:54 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Using SOAP in BEEP
	Author(s)	: E. O'Tuathail, M. Rose
	Filename	: draft-etal-beep-soap-01.txt
	Pages		: 20
	Date		: 21-Jun-01
	
SOAP is an XML-based messaging protocol used to implement a wide
variety of distributed messaging models.  It defines a message format
and describes a variety of message patterns, including, but not
limited to, RPC, asynchronous event notification, unacknowledged
messages, and forwarding via SOAP intermediaries.
A SOAP binding describes how SOAP messages are transmitted in the
network.  This memo specifies a SOAP binding to BEEP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-etal-beep-soap-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-etal-beep-soap-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-etal-beep-soap-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Dan Kohn" <[email-masked]>
Date: Fri, 22 Jun 2001 09:25:49 -0700

This looks great to me.  My only concern is whether you want to support
an optional transport token to support session initiation with TLS.
Yes, it can always be negotiated, but there may be initiators and
listeners that both support TLS but don't use it unless prompted (by the
URL) to do so.  This is analogous to the use of https vs. http URLs, but
without needing to explode the URL space with a different scheme for
every potential transport option.  Note that the use of [ ":" transport
] is also upward compatible as BEEP is defined over new transport
mappings.

Here again, was my last proposal:

Any protocol built over beep is welcome to define it's own URL scheme.
This registration must include what profile is supported and the default
port number and transport layer.  Since URL schemes will map one-to-one
to BEEP profiles, the profile should not be separately specified in the
URL.  Thus, for a "web over beep" service, the following scheme would be
registered using RFC 2396 notation:

web_URL = "web:" "//" host [ ":" transport ] [ ":" port ] [ abs_path [
"?" query ]]

transport = "tcp" / "sctp" / "udp" / "tls"

And where lack of specified transport defaults to TCP (for this scheme
name, although not necessarily for others).  The listener and/or
initiator can still cause the transport to be negotiated (e.g., from tcp
to tls), but the transport in the URI specifies what to start with.

web is used instead of web.beep because web is not previously defined
over other session layers.  Similarly, imxp, syslog.raw, and
syslog.cooked are all good URL scheme names, where if soap is registered
as a scheme name using HTTP transport semantics, then SOAP over BEEP
should use "soap.beep".

A default beep URL scheme should not be registered, since invocation of
a beep URL would have no default semantics and no default application to
call.

		- 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 Marshall T.
Rose
Sent: Friday, June 22, 2001 08:49
To: [email-masked]
Cc: Marshall Rose
Subject: [BXXPwg] new penultimate version available

new in this version:

    - soap packages
    - feature extensibility

/mtr

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

---

From: "Marshall T. Rose" <[email-masked]>
Date: 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...

/mtr

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 22 Jun 2001 13:57:25 -0700

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

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

> 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

---

From: Ben Feinstein <[email-masked]>
Date: Fri, 22 Jun 2001 15:31:26 -0700 (PDT)

> http-over-beep is a no-brainer.

For an example of BEEP peer chains and tunnelled security, see the TUNNEL
profile
(http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-tunnel-01.txt).  
In IDXP
(http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-02.txt) we
use the TUNNEL profile to provision a chain of peers, then tune with the
desired security profile (most likely TLS) before binding the endpoints to
the IDXP profile.

Cheers,

Ben Feinstein
[email-masked]

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 22 Jun 2001 15:40:32 -0700

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