Subject: [BXXPwg] SOAP over BEEP

From: "Marshall T. Rose" <[email-masked]>
Date: Tue, 12 Jun 2001 19:13:00 -0700

Your comments are solicited.

TXT version at
http://www.ietf.org/internet-drafts/draft-etal-beep-soap-00.txt

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

/mtr

Subject: I-D ACTION:draft-etal-beep-soap-00.txt
From: [email-masked]
To: IETF-Announce: ;
Date: Tue, 12 Jun 2001 08:05:30 -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-00.txt
	Pages		: 12
	Date		: 11-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-00.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-00.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-00.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: Gabe Wachob <[email-masked]>
Date: Wed, 13 Jun 2001 17:18:41 -0700 (PDT)

One question this brings up w/r/t SOAP is that of URLs - is there such a
thing as a BEEP endpoint URL? The reason I ask is that WSDL (the web
services description language) tries to describe a SOAP endpoint with
(among other attributes) an HTTP URL. So, it seems that if SOAP/BEEP is
deployed, the WSDL folks are going to want to be able to specify a BEEP
URL similarly to the way they specify a HTTP URL:

from http://msdn.microsoft.com/xml/general/wsdl.asp (example 6):

 <service name="service1">
        <port name="port1" binding="tns:b1">
           <http:address location="http://example.com/"/>
        </port>
        <port name="port2" binding="tns:b2">
           <http:address location="http://example.com/"/>
        </port>
        <port name="port3" binding="tns:b3">
             <http:address location="http://example.com/"/>
        </port>
    </service>

 <binding name="b1" type="pt1">
        <http:binding verb="GET"/>
        <operation name="o1">
           <http:operation location="o1/A(part1)B(part2)/(part3)"/>
           <input>
               <http:urlReplacement/>
           </input>
           <output>
               <mime:content type="image/gif"/>
               <mime:content type="image/jpeg"/>
           </output>
        </operation>
    </binding>

Now, of course, this is WSDL and not SOAP or BEEP, so we aren't here to
solve the WSDL description of a BEEP endpoint -- but is now an
appropriate time to discuss URLs in the context of BEEP/TCP ? Or are URLs
not really appropriate?

	-Gabe

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

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

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 13 Jun 2001 19:23:00 -0700

hi. i don't think it makes sense to talk about a BEEP URL, because BEEP, by
itself, isn't a protocol like HTTP or FTP or SMTP is.

i suspect there is some general "issue" in the URL architecture that needs
to get resolved before we will find a satisfactory answer to the question.
for example, in the case of wsdl or soap or ipp or whatever, i can always
say

        http://example.com/

but how is anyone to know that the http server there is really a front-end
to wsdl or soap or ipp? my point is that there's something semantic going on
here that isn't visible in the URL, instead you somehow have to know from
context that if you see a URL inside a certain kind of message then there's
an expectation that a special kind of process is sitting at the http server.

i noted that the wcip draft says this about naming:

    wcip://" domain-name ":" port "/" channel-name "?proto=beep"

but you could just as easily have "?proto=http" tacked onto the end.

i'm not suggesting that this is the "right way" but it does bear some
thinking.

/mtr

----- Original Message -----
From: "Gabe Wachob" <[email-masked]>
To: "Marshall T. Rose" <[email-masked]>
Cc: <[email-masked]>; "Eamon O'Tuathail"
<[email-masked]>
Sent: Wednesday, June 13, 2001 17:18
Subject: Re: [BXXPwg] SOAP over BEEP

---

From: Gabe Wachob <[email-masked]>
Date: Wed, 13 Jun 2001 19:32:15 -0700 (PDT)

I think HTTP URLs have come to mean at least two things, notwithstanding
the specs or original intent:

1) A place where you can get a WWW resource

and

2) An endpoint which consists of a hostname/ip, a port, and a "relative
path" (and possibly a "query" part).

We need almost everything (and something more) in #2 for describing a
BEEP endpoint, so an HTTP URL looks (perhaps deceptively) close to
something useful for BEEP.

I think (and have always thought) that there should be a well-specified
(unambiguous) locator format of BEEP endpoint that can be used (for
example) for pointing a BEEP peer to another BEEP peer. Whether it would
include the profile which the describer intends the endpoint to be used
for is not clear to me.

And then there is the issue of how to describe endpoints across multiple
types of transport (with TCP, its pretty simple, but what about non
IP/port transports?)

	-Gabe

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 13 Jun 2001 20:31:07 -0700

> itself, isn't a protocol like HTTP or FTP or SMTP is.

Yes, though to be a little more accurate, BEEP isn't a service like HTTP
or FTP servers.  The URI scheme doesn't refer to the protocol.

> an expectation that a special kind of process is sitting at the http server.

That is already true.  The "http" URI defines a namespace with hierarchical
characteristics that is resolved by communicating with the naming authority
(server) using one of the HTTP family of protocols, but such resolution
only takes place when it is used within specific references as a hypertext
link or submit button.  Otherwise, it is just an identifier.

They could define a beep URL that had the property of discovering which
profile to be used as part of the connection, but that isn't very useful.
URI schemes are more like TCP reserved ports -- they correspond to the
type of service rather than the specific protocol to use (i.e., port 80
is reserved for WWW, not HTTP/1.0).

> i'm not suggesting that this is the "right way" but it does bear some

YUCK!  wcip needs to learn about hierarchy violations.

   wcip.beep://authority/path

would be better, but still misses the point.  The URI scheme should
answer the question of "what application interface should I expect?",
which is a a lot more than "what protocol should I use?".

Cheers,

Roy T. Fielding, Chief Scientist, eBuilt, Inc.
                 2652 McGaw Avenue
                 Irvine, CA 92614-5840  fax:+1.949.609.0001
                 ([email-masked])  <http://www.eBuilt.com>

                 Chairman, The Apache Software Foundation
                 ([email-masked])  <http://www.apache.org/>

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 13 Jun 2001 21:39:26 -0700

roy - i think i get what you're saying, but i'm still not entirely clear.

setting aside for the moment whether HTTP is a protocol or a service, let's

> which is a a lot more than "what protocol should I use?".

and setting aside that i think you mean "layering" and not "hiearchy", let
me ask the basic question: what should the uri look like for wcip over beep?
i suspect that a well-architected answer would provide guidance for the
dozen or so different domains in which this question is being asked...

thanks!

/mtr

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 14 Jun 2001 15:35:08 -0700

> and setting aside that i think you mean "layering" and not "hiearchy", let

Nope, I meant the URI has a hierarchical syntax that drops from left
to right, so, unless you consider "wcip over beep" and "wcip over somethng
else" to be under the same naming authority, then beep should be to the
left of the name.  Layering is protocol design.  URI are just names.

> dozen or so different domains in which this question is being asked...

wcip is a little odd in that I don't undertand the purpose of the path
within the URI.  If there is no chance of relative URI being used, then
the question of left-to-right hierarchy is not really an issue (aside
from aesthetics).

In general, if the service is available via multiple protocols and the
naming syntax for those protocols will differ, then use a protocol-specific
addition to the URI scheme (like the wcip.beep scheme above).  That is the
normal way of doing it because the authority syntax is often dependent on
the transport used (e.g., TCP ports and defaults).

OTOH, if the syntax for naming will be the same, but the naming authority
will differ based on the lower-layer protocol, then I would include beep
within the authority component.  However, I have yet to see a good example
of this in practice.

If the beep-ness of the resource isn't part of its name at all, then I would
use two separate identifiers -- a URI for the resource and some other
URI (possibly implied by context) to indicate the communication mechanism.
This is no different from how HTTP proxies are specified -- one URL for
the proxy within the client configuration/environment and another URI for
the resource being accessed through the proxy.

My suspicion, however, is that there is no wcip resource -- that, in fact,
the only thing they are using the URL for is selection of a channel.
In that case, they should not have created a wcip URL at all.  Instead,
they should have used existing URL schemes to identify the channel and
simply define a new one for beep channels (with care taken to only identify
aspects of beep that are not specific to one profile).

....Roy

---

From: "Marshall T. Rose" <[email-masked]>
Date: Thu, 14 Jun 2001 15:59:22 -0700

roy - thanks.

> within the authority component.  However, I have yet to see a good example

in most of the recent cases that i have seen, the only thing that differs is
how the data gets moved, e.g., going from soap/http to soap/beep, or
ice/http to ice/beep, etc. in both cases, you have a situation where the
path is going to be the same, and i have difficulty understanding whether
the "use beep" bit should be present in the scheme component or the
authority component. for example,

    http://example.com/

may very well be a valid thing for someone doing soap over http. so, what
should we be using for the soap over beep case? here are four possibilities,
i'm sure there are more...

    beep://example.com/

    soap.beep://example.com/

    soap://example.com/?proto=beep

    beep://example.com?profile=http://iana.org/beep/soap

ideally, i would prefer to avoid having to use a new scheme everytime
someone moves yet another service on top of beep.

thanks,

/mtr

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 14 Jun 2001 17:55:10 -0700

>     beep://example.com?profile=http://iana.org/beep/soap

Too many bits, and the ? really should be reserved for supplying information
to resources rather than general identification..

> someone moves yet another service on top of beep.

Hmmm, why?  Logically, they are distinct services.  Keep in mind that the
"http" URL is specific to HTTP over TCP, even though HTTP itself is not
dependent on TCP.  If we were to deploy a new HTTP-over-SCTP service,
we would need a new URL scheme because the authority syntax of hostname:port
is specific to TCP, not HTTP.

If I were to invent it from scratch, I would probably choose something like

    web://example.com:http.tcp.80/path
    web://example.com:http.udp.7149/path
    soap://example.com:beep.tcp.21212/path

with the first ":http.tcp.80" being the default for the web. Obviously,
that is getting pretty ugly.  For some reason I think this looks better

    http://example.com/path
    web.http.udp://example.com:7149/path
    soap.beep.tcp://example.com:21212/path

It also better fits the architecture of most URI handling software, which
typically consists of a table of (scheme name , handler routine) tuples.

Cheers,

....Roy

---

From: "Marshall T. Rose" <[email-masked]>
Date: Thu, 14 Jun 2001 23:44:58 -0700

> typically consists of a table of (scheme name , handler routine) tuples.

0. well, i agree that using "web:" instead of "http:" would certainly make
things a lot more clear, but that's water under the bridge.

1. let me understand your reaction to

> is specific to TCP, not HTTP.

i don't think that the http/tcp to http/sctp analogy is a good one. what i'm
trying to understand is whether it is a good thing to define two schemes for
soap.beep.tcp and ice.beep.tcp or to just have one scheme for beep over tcp.
for all three schemes, the authority part remains the same.

in guess i see your point that

> >     beep://example.com?profile=http://iana.org/beep/soap

is pretty week.

2. anyway, in comparing:

i guess i prefer the latter since when we move from "beep.tcp.21212" to
"beep.ipv6.21212" the thing to the left is going to be funky. what isn't
clear to me is whether the iana is going to be happy when i start
registering url schemes in groups of three, e.g.,

    ice:
    ice.beep:
    ice.beep.tcp:

/mtr

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 15 Jun 2001 19:50:25 -0700

> for all three schemes, the authority part remains the same.

The dns name within the authority part may be the same, but its interpretation
tends to be specific to the URI scheme.  The reason I used the tcp/sctp
analogy is because that is the slimmest margin of difference, and yet it
does require a different URI scheme because example.com:80 (tcp) and
example.com:80 (sctp) are two different naming authorities -- the
software listening to TCP port 80 is not capable of giving authoritative
answers for the resources named by SCTP port 80, for the same reason that
a web server at TCP port 8001 is not allowed to give authoritative answers
for another web server on TCP port 80.

> > >     beep://example.com?profile=http://iana.org/beep/soap

The biggest problem with it in practice is what happens when you do want
to name a resource within beep, and that resource has the ability to
accept data.  You can't have more than one ? in the URI syntax.

However, what people really want to do is name the resources made available
by the upper-layer protocol -- beep and its profile names are less significant
to the name even if they are a dependency.  That's why I wouldn't define a
"beep" URL scheme, unless there is some resource to be named within the
beep service itself [such as a management interface].

> registering url schemes in groups of three, e.g.,

I think that it is only necessary to register the default as ice
and additional ones only when they differ from the default.  IANA may not
be happy with it, but that is better than requiring every handler of "ice"
URLs to implement (or at least know about) every possible layering.
Applications tend to implement only one application-layer at a time.

I don't think that "beep.ipv6.21212" would ever be necessary because
the IP layer is defined by the hostname, and is therefore already represented
within the authority component.  Note that ipv6 literals can already be
included within URLs via the square-bracketed ipv6-literal syntax.

Likewise, if ice were to use some DNS attribute to select which session
layer protocol should be used, rather than encoding it within the URL,
then you wouldn't need ice.beep at all.  Someone might want it anyway,
though, just to be able to override the DNS response.  *shrug*

As a WWW software developer, I would prefer to implement it as a new scheme.
However, as a protocol architect, I think that if I were inventing it from
scratch and not worrying about the already deployed authority parsers, then
I would include this information in the authority component rather than the
scheme.  It is possible that we may end up being forced in that direction
when RFC 2396 is revised, regardless of the running code.

Please keep in mind, however, that the protocol stuff within a URL only
defines how the naming authority is contacted when it needs to be contacted,
and thus doesn't directly tell the client what to do -- a client chooses
what to do for a given URL according to its own configuration and the
context in which the URL was found.

....Roy