Subject: RE: Last Call: Using SOAP in BEEP to Proposed Standard

From: Michael Welzl <[email-masked]>
Date: Mon, 10 Sep 2001 15:42:56 +0200

...and I can't stand the acronyms ... SOAP in BEEP is just too
much for me  :)

Cheers,
Michael

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 2:43 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Last Call: Using SOAP in BEEP to Proposed Standard
> 
> 
> On Fri, 7 Sep 2001, The IESG wrote:
> 
> > The IESG has received a request to consider Using SOAP in BEEP
> > <draft-etal-beep-soap-04.txt> as a Proposed Standard.  This has been
> > reviewed in the IETF but is not the product of an IETF 
> Working Group.
> > 
> > The IESG plans to make a decision in the next few weeks, 
> and solicits
> > final comments on this action.  Please send any comments to the
> > [email-masked] or [email-masked] mailing lists by October 7, 2001.
> > 
> > Files can be obtained via
> > http://www.ietf.org/internet-drafts/draft-etal-beep-soap-04.txt
> 
> I could see this being informational or experimental - but proposed
> standard? I quote: 'SOAP is an evolving protocol.  New versions of the
> SOAP (such as the W3C's XMLP effort), and new features (such as
> compression), are likely to emerge.'
> 
> As reference (1) indicates, SOAP is documented in the W3C. Why is this
> work being done as an IETF draft and not in the W3C? BEEP is RFC3080,
> but SOAP in BEEP is a SOAP-specific problem, which afaik means it's a
> W3C problem.
> 
> More worryingly from a standards viewpoint:
> 
>    'The BEEP profile for SOAP is identified as
> 
       http://clipcode.org/beep/soap

   in the BEEP "profile" element during channel creation.'

What happens to the standard if that profile described on that url
(or an IANA equivalent - see IANA considerations) changes?

The entire 'initial registrations' (section 7) leaves me cold - and
its constant references to (1) indicate that it's for the W3C.

Use of caseSensitive serverName (another way of saying
Host)/encodingStyle etc. bugs me, given the move away from mixed case
in much W3C work.

section 4 - one-way messages: a NUL message *is* a response. Since
this is taking place over reliable TCP, it's not really a one-way
message.

Why have RPY *and* ANS? You could simplify soap.beep and just use zero
or more ANS responses with a terminating NUL for all cases. And then
you could use ERR correctly as defined in BEEP (RFC3080) without the
*non-standard* non-BEEP error-in-RPY hackery described in 4.2. Having
special-cased error-handling doesn't strike me as good design. And if
you're not going to use the proposed standard of BEEP as intended,
what's the point? Standardising this as is will actually detract from
the BEEP standard.

I'm tempted to say that this is someone else's problem entirely, and
that the IESG should wash its hands of anything to do with SOAP.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 10 Sep 2001 14:44:38 -0700

> Last, about Soap over TCP, well, that is probably not something we in
> Apps
> Area like. Beep solves an important problem we have, which is
> abstraction
> of the transport layer, so things end up being "nicer" to TCP.
> Remember all
> discussions a year or two ago about a generic application layer
> protocol?

Frankly, I don't see what the "abstraction of the transport layer" provides you. If you are saying that we should allow reuse of the TCP connection for multiple SOAP messages, that is fine. But BEEP is hardly the only way to achieve that.

> It's certainly better (from an architectural standpoint) than HTTP
> regarding "generic protocol for transport of application layer
> messages".
> HTTP is today extremely complicated, and just that should scare people
> away
> which doesn't work with traditional "web related things".

Well, HTTP has at least the benefit of being widely implemented and widely used. That is not the case for BEEP. I personally find BEEP quite atrocious. It introduces a "channel" artifact that is gratuitous complexity; it breaks at least one fundamental rule of networking, by allowing for multiplexing on top of TCP.

The designers of BEEP probably had some applications in mind; this is a free world, and they are welcome to try. But presenting BEEP as the favored solution to most application is very premature.

-- Christian Huitema

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 10 Sep 2001 18:41:03 -0400

As a reasonably neutral observer, I would conclude
that the IETF was an appropriate venue, and it is understandable
that this particular standard did not conveniently fall under
the purview of an existing working group (or merit the creation
of a separate working group).

(And yes, "reasonably neutral observer" in this case
can appropriately be interpreted as "someone who
knows little about the content and therefore comments
about the process".  OK, back to versioning and acl's,
where I should be spending my time :-).

Cheers,
Geoff

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Monday, September 10, 2001 4:58 PM
To: Christian Huitema; [email-masked]; Scott Brim
Cc: [email-masked]
Subject: RE: Last Call: Using SOAP in BEEP to Proposed Standard

As the Area Director which is taking care of this draft, I must comment on
this thread.

First of all, I agree completely with what is said by my co-ad Ned in
regards of "what organization do what".

Secondly, moving individual submissions onto Standards Track is perfectly
alright, and done quite often.

What we do though is normally to use a 4-week last call, and not a 2-week
last call. Further, I personally as AD always verify the document and see
that the document have been discussed in appropriate areas.

Now, let's look at the comments by Christian below (the rest of the issues
raised by others, such as the issue with naming convention by using URL's
are sorted out I think).

The draft itself specifies from my point of view how to run Soap over Beep.
This doesn't prohibit other specifications of how to run Soap over foo, or
Soap over bar. I.e. this is not _the_ way of moving Soap over the Internet.
It is about how to move Soap over Beep.

Because it _only_ talks about doing Soap over Beep, the important issue was
that this document have been reviewed in beep community. This I found was
ok as the document has been known on the beep mailing list.

About cooperation with W3C, all documents we in the IETF find is in a gray
area between IETF and W3C are discussed in the meetings that our respective
liaisons have. That is the path for move of information between the two
organizations.

After finding a few issues with the document, and having the document
updated once, I agreed issuing a last call.

All comments are input to the IESG decision which will happen after the
last call ends.

Last, about Soap over TCP, well, that is probably not something we in Apps
Area like. Beep solves an important problem we have, which is abstraction
of the transport layer, so things end up being "nicer" to TCP. Remember all
discussions a year or two ago about a generic application layer protocol?

Beep in the current incarnation might not be what we talked about _then_,
but it solves a need that we have today. And noone have come up with
anything better.

It's certainly better (from an architectural standpoint) than HTTP
regarding "generic protocol for transport of application layer messages".
HTTP is today extremely complicated, and just that should scare people away
which doesn't work with traditional "web related things".

Yes, I might exaggerate, but sometimes I find I have to just to get peoples
brains start moving a bit :-)

    paf

--On 01-09-10 10.34 -0700 Christian Huitema <[email-masked]>
wrote:

>> SOAP is going to see widespread use no matter what. The other
>> application
>> transport for SOAP is HTTP. Use of HTTP for things it isn't well
>> suited for is
>> something we want to discourage. So doing this correctly is of
>> considerable
>> concern to the application layer.
> 
> It is true that HTTP is the only transport defined in the SOAP
> specification, but SOAP can be mapped to a variety of transports,
> including direct mapping over TCP or UDP. Do we really believe that
> carrying SOAP over BEEP is better than carrying it over TCP? Did we even
> discuss that? Did we get some form of requirement from the WG defining
> the XML protocol in the W3C? How can we define a mapping to BEEP
> channels without even considering the potential requirements for
> multi-step forwarding of SOAP messages across various transports? What
> is the relation with SOAP extensions to handle such forwarding, that are
> currently debated in the W3C? 
> 
> I don't think it is a good idea for the IETF to issue a proposed
> standard on how to transport SOAP over the Internet without first having
> an organized discussion of what the transport should be, and without a
> well defined cooperation with the W3C -- unless indeed our intent is to
> maximize confusion. An individual draft such as draft-etal-beep-soap-04
> should not be published as an RFC, let alone a proposed standard,
> without first chartering a working group on the general issue of
> transporting SOAP.
> 
> -- Christian Huitema
>

---

From: "Eamon O'Tuathail" <[email-masked]>
Date: Mon, 10 Sep 2001 23:43:11 +0100

>> ... but SOAP can be mapped to a variety of transports,
>> including direct mapping over TCP or UDP. 

If your goal is to send a series of opaque pieces of data over a network
from peer A to peer B, you cannot simply place them directly on a TCP
socket and hope everything works. Something (we will politely argue
about 'what' in a second) has to provide authentication, transport
security, asynchrony, framing of messages etc. This "something" is
normally called an application protocol. You can give it a different
name (I am not too worried about what this collection of functionality
is called) but I assume you agree this is definitely needed. 

Marshall has a "must-read" paper on all this at:
http://www.ietf.org/internet-drafts/draft-mrose-beep-design-03.txt

In this context, by "opaque piece of data" I mean any data (e.g.
application programmatic XML messages) that gets through the application
protocol without having to be parsed or edited by the application
protocol itself. 

I think it will mislead some people when talking about opaque pieces of
data to say "direct mapping over TCP", given that the above range of
services must be provided - some people will think a 'direct' mapping is
magically faster, because a layer has been omitted, which is plain
wrong. 

But we are not talking about opaque pieces of data - we are talking
about SOAP envelopes - which do have SOAP extension fields - into which
any control information could be placed. The "application protocol"
services have not been omitted - they simply have be added into the SOAP
message. 

Now we reach our point of disagreement - which is whether it is better:

a) to use fat SOAP messages that extensively use these extension fields
for application protocol-like services, and that sit directly on top of
a TCP socket, or 

b) to use thin SOAP messages that carry the programmatic messages and
higher level services in the SOAP extension fields, over BEEP over TCP. 

>> Do we really believe that carrying SOAP over BEEP is better 
>> than carrying it over TCP? 

Do we really believe that carrying XHTML over HTTP is better 
than carrying it over TCP?

For each piece of "application protocol"-like information you are
planning to put inside the SOAP envelope, I could argue why not put it
inside the XHTML document (heck - they are both blobs of XML Infoset
items). At first this might seem a great idea, but what about those
users who need SVG, X3D, flash, PDFs, PNGs, etc. hmmm. 

Yes, SOAP over BEEP is obviously better. 

I agree that SOAP is more than just content (which is what you will
argue), but I think the extras should be used for higher level services
(see below), not to duplicate what is already provided. 

The whole concept behind BEEP is to define once all the common tasks
that an application protocol needs - session establishment, framing,
security, etc. I can't see the logic in defining all these things again
.. and again .. and again for each new thing we need to carry. SOAP is
just one of many things people wish to have carried. 

>Did we even discuss that? 
Yes. All the relevant BEEP and SOAP mailings lists were informed - 
* The BEEP WG mailing list:
http://lists.beepcore.org/pipermail/beepwg/2001-June/001118.html
* The W3C XMLP WG list:
http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0115.html
* The DevelopMentor SOAP list:
http://discuss.develop.com/archives/wa.exe?A2=ind0106&L=soap&F=&S=&P=868
4
* The SoapBuilders List:
http://groups.yahoo.com/group/soapbuilders/message/3867

Feedback was incorporated into the spec as appropriate.  

There was a LONG discussion of this at:
http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0013.html
(follow it all the way to the end!) which concluded with
http://lists.beepcore.org/pipermail/beepwg/2001-July/001210.html

>Did we get some form of requirement from the WG defining
the XML protocol in the W3C?
Yes. 
http://www.w3.org/TR/2001/WD-xmlp-am-20010709/
Also we had extensive discussions with many SOAP people about this. 

>How can we define a mapping to BEEP channels without even considering
the >potential requirements for multi-step forwarding of SOAP messages
across >various transports? What is the relation with SOAP extensions to
handle >such forwarding, that are currently debated in the W3C? 

Now we are seeing the obvious benefits of clean layering.

BEEP carries the SOAP envelope as an opaque block of data between peers
(possibly using the BEEP TUNNEL spec where needed, to get between >2
peers where each knows about BEEP). When we are talking about using
differing protocols together (where some peers understand one protocol
and others a different one), then additional information needs to be
carried - this is a higher level service and is ideally suited for those
SOAP extension fields. 
Whatever the W3C puts in those fields will be carried by BEEP - because
BEEP does not even look at the SOAP envelope. 

You should seriously consider using BEEP for your SOAP work.

Eamon O'Tuathail

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Sep 2001 16:51:18 -0700

At 02:44 PM 9/10/2001, Christian Huitema wrote:
>Frankly, I don't see what the "abstraction of the transport layer" 
>provides you.

Perhaps it is noteworthy that a number of folks, including ADs, who have 
long history working in the application layer, think that the benefits are 
significant.

In any event, the list of BEEP features is straightforward and well 
documented.  They were pursued and standardized through the usual IETF 
mechanism.  I was not the most ardent participant in the working group, but 
I do not remember your concerns being raised -- or, least, gaining any 
traction -- in the working group discussion.

And in any further event, BEEP is standards track and debating BEEP is not 
the current topic.

>  If you are saying that we should allow reuse of the TCP connection for 
> multiple SOAP messages, that is fine. But BEEP is hardly the only way to 
> achieve that.

Please point to other standards that achieve that functionality and have 
support for use.  (Working code would also be good to know about.)

>Well, HTTP has at least the benefit of being widely implemented and widely 
>used. That is not the case for BEEP.

Wow.  That IS significant.

Isn't it interesting how protocols that have existed for 10 years tend to 
have broader deployment than protocols that have existed for less than one?

Perhaps one should note that problems in using HTTP as a generic 
application layer protocol was one of the motivations for creating BEEP...

>  I personally find BEEP quite atrocious. It introduces a "channel" 
> artifact that is gratuitous complexity; it breaks at least one 
> fundamental rule of networking, by allowing for multiplexing on top of TCP.

Christian, perhaps you are forgetting that having multiple, related data 
streams use multiple, independent TCP connections is a problem, not a 
feature?  Hence there needs to be multiplexing on top of TCP.

And your knowledge about fundamental networking rules has demonstrated a 
significant  disparity from the knowledge of quite a few other folks.  Any 
literature references to this fundamental rule would be appreciated.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 10 Sep 2001 17:38:15 -0700

> feature?  Hence there needs to be multiplexing on top of TCP.

Either they are multiple streams or they are not. If they are not,
multiplexing them on the same transport connection is a bug, not a
feature.

> And your knowledge about fundamental networking rules has demonstrated
> a significant  disparity from the knowledge of quite a few other 
> folks. Any literature references to this fundamental rule would 
> be appreciated.

The effects of layered multiplexing were mostly experienced when trying
to run stuff TCP/IP on variation of protocols doing their own flow
control, with basically interference between several controllers. A
paper on the issue is for example:  

D. L. Tennenhouse, "Layered Multiplexing Considered Harmful," in
Protocols for High-Speed Networks, Rudin and Williamson (Ed.), North
Holland, Amsterdam, 1989.

A similar problem leads us to avoid IP layer fragmentation, because it
interferes with TCP layer reassembly and acknowledgement. Basically, you
want to have exactly one place at which you exercise transport level
functions such as fragmentation, flow control, etc. You want the unit of
transmission to be the unit of control.

-- Christian Huitema

---

From: "Eamon O'Tuathail" <[email-masked]>
Date: Tue, 11 Sep 2001 10:04:41 +0100

On Mon, 10 Sep 2001 16:13:43 -0700, Christian Huitema wrote:

>>Well, I am mostly concerned to see "SOAP over BEEP" defined
>> before we define the alternative "SOAP over TCP". 

Is that the real root of your objections? 

It is obvious that a small SOAP over BEEP spec will be written quicker
that a huge SOAP over TCP spec, since the latter has to effectively
duplicate most of what is in RFC 3080. That is the whole reason we take
a layering approach to these things and it is becoming clear it is
better. 

Eamon

---

From: "Eamon O'Tuathail" <[email-masked]>
Date: Tue, 11 Sep 2001 11:35:25 +0100

Larry,

First, thanks for moving this debate to a technical discussion on issues
relevant to soap over beep. 

SOAPAction
==========
SOAPAction is not supported in SOAP over BEEP on purpose. 

SOAPAction is an HTTP header field that is used for many things,
including, most worryingly, to get through firewalls. This is a BAD
idea, and the use of SOAPAction is strongly discouraged. The current
debate on the W3C list is how best to tell people not to use it. 

The use of SOAPAction has been extensively discussed:
http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0104.html

I particularly liked the comment from Valdis.Kletnieks:

"Consider that the user behind a firewall could, in conjunction with a
site
that supported it, just tack onto the end of the URL a
&callit=whateverSoap
and the web site could just label it with SOAPAction=whateverSoap
will get through the firewall.

So what is this actually fixing?  The guy *inside* the firewall
presumably knows what will be allowed to pass, and can tell the
guy outside what to call it.  This sounds like a scene from a
James Bond movie - if he knows that the roadblock up ahead is
looking for a Jaguar with Swiss plates, he hits a button and
he's now driving a Jaguar with French plates."

Concerning the other issues you raised:
=======================================
For those interested, the W3C SOAP issues list is at:
http://www.w3.org/2000/xp/Group/xmlp-issues.html

Issue 12 - "SOAP and HTTP status codes": We use SOAPFault envelopes
(which BEEP will not parse) for SOAP-related errors. It is up to the
SOAP implementation sitting above BEEP to decide what to do with it. 

Issue 67 - "convey error information": see comment for 12 above

Issue 69 - " http binding bias": Much of SOAP 1.1. was written with a
strong HTTP bias - essentially the SOAP over BEEP spec is an alternative
for the HTTP pieces. With respect to the intermediaries, we need to
distinguish between BEEP intermediaries (running the BEEP TUNNEL) who
know nothing about the contents of the SOAP envelope and simply forward
it on, and SOAP intermediaries (identified as SOAP actors), who do parse
the SOAP envelope and may take some local actions before forwarding the
same or an altered SOAP envelope onwards. BEEP intermediaries are
handled naturally as part of the BEEP infrastructure and there is
nothing specific to SOAP that we have to discuss. SOAP intermediaries
are a topic for SOAP processing engines which will understand the main
SOAP spec - and for the BEEP over SOAP spec we resolutely don't want to
get involved in that layer - that is for the W3C. 
 
Issue 95 - "SOAPAction" - see SOAPAction above

Issue 105 - I think the three main messaging patterns - one-way,
request-response and request/N-response - are covered in the SOAP over
BEEP spec. 

>>At the very least, you should be explicit about the
>>fact that SOAP is undergoing active review.

First line of section 1: Introduction states: "This memo specifies how 
**SOAP 1.1** envelopes are transmitted using a BEEP profile".

http://www.xmethods.net/ilab/ has a list of some SOAP 1.1.
implementations - there are plenty - which indicates its status as an
accepted spec in the community.

It is likely over the next number of years the W3C will produce updated
SOAP and SOAP-related specs every 18 months or so. SOAP 1.2 will be
coming out next year, but there are plenty of other topics that need to
be covered in future. What should we do? We have two options - wait
until all the SOAP work is completed, or define a SOAP over BEEP spec
for the current situation, with a clear eye to the future. 

We are not guaranteeing that the current soap over beep spec will work
for every future SOAP spec, but given that we are not interacting with
the SOAP envelope at all, and given that we have the "features" option
to cater for some future adjustment, it is sensible to go ahead and
define it now.

Eamon

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Sep 2001 10:50:07 -0700

At 09:19 AM 9/11/2001, Christian Huitema wrote:
>In particular, SOAP is evolving, and there are generic SOAP extensions
>being defined to deal with end to end security, end to end confirmations
>and the like,

You did not cite changes to basic SOAP packaging, yet that is the salient 
point in doing a convergence layer.

There is also some irony is trying to argue against evolution, such as this 
convergence work -- using the excuse that a component is evolving.

>where end-to-end is defined as "from the SOAP initiator to
>the final SOAP actor". It may be argued that these functions duplicate
>BEEP;

Oh?  Beep is a point-to-point protocol, Christian.  It has no 
relaying.  (Perhaps you are confusing Beep with Apex?)

>  in any case, the availability of such extensions within the XML
>protocol itself implies that mapping over TCP is, in fact, trivial; we
>need only a delimitation function,

Now I'm confused.  You previously said that multiplexing was so difficult 
that it violated basic networking principles and now you appear to be 
claiming that doing it in XML is trivial.

d/

----------