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

From: "Christian Huitema" <[email-masked]>
Date: Mon, 10 Sep 2001 10:34:27 -0700

> 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: [email-masked]
Date: Mon, 10 Sep 2001 11:36:28 -0700 (PDT)

> carrying SOAP over BEEP is better than carrying it over TCP?

Yes we do, because BEEP offers a number of services straight TCP lacks:
Multiplexing, various sorts of security services, and so on.

> Did we even discuss that?

Yes we did.

> Did we get some form of requirement from the WG defining
> the XML protocol in the W3C?

Requirement no, but having just spoken with W3C people about this I can say
that they were interested in having a such a binding done and happy to have it
done in the IETF.

> How can we define a mapping to BEEP
> multi-step forwarding of SOAP messages across various transports?

It is axiomatic that a "potential requirement" cannot be addressed.
All I can tell you is that this wasn't a concern raised by the W3C.

> What

Any such extension would do well to consider the issues that arise from a wide
variety of transports.

> maximize confusion.

This is already taking place.

> An individual draft such as draft-etal-beep-soap-04

I disagree, and think that the general issue of transporting BEEP, which
necessarily will encompass transports other than TCP/IP, is definitely
outside the scope of the IETF. This one piece is here because we're the
ones who know how to do it. 

				Ned

---

From: Allison Mankin <[email-masked]>
Date: Mon, 10 Sep 2001 16:33:17 -0400

> the XML protocol in the W3C? 

...

> well defined cooperation with the W3C.

Careful consideration of the tranport mapping decisions is
really important, agreed.  Why not use this Last Call discussion
to bring out the issues of SOAP directly over TCP rather over
BEEP (but not over UDP, please - SOAP should not do its own
reliability)?  A good reason for use of BEEP is to have
transaction multiplexing.

To your point about WC3, there has* been some coordination in
the form of teleconferences among IESG/IAB folk and WC3 counterparts. 
The draft wasn't last called until after this group discussed the
coordination aspects of last calling it.

Allison

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 10 Sep 2001 22:58:28 +0200

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Sep 2001 13:58:30 -0700

>ones who know how to do it.

Indeed.

The IETF has a long history of permitting documents to be made 
standards-track, without first having a working group.

It is also worth noting that, so far, all we have been hearing are 
questions about the protocol, rather than criticisms that it was done badly.

d/

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

---

From: "Marshall T. Rose" <[email-masked]>
Date: Mon, 10 Sep 2001 16:05:53 -0700

christian - i'd like to understand any technical concerns you might have on
the the "soap over beep" specification.

in reading your note, i think i found one, specifically how the "soap over
beep" specification will interact with the not-yet-existent soap routing
specification.

if that's the case, then i'd have to say that it will work no worse than the
"soap over http" mapping:

1. if all the routing information is carried in the envelope, then neither
mapping will have a problem.

2. if the routing information is entirely out-of-band, it is a non-issue for
both mappings.

3. if the routing thing requires some incompatible change, then we'll use
feature negotiation to deal with it (which should make lloyd wood happy).

(this third choice is something not in the "soap over http" mapping, so
hopefully whoever does the soap routing specification will be sensitive to
that.)

if there are other technical issues, let me know. i think that the
specification got scrubbed pretty well over the last three months, but i'm
certainly happy to hear otherwise.

/mtr

---

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

At 01:33 PM 9/10/2001, Allison Mankin wrote:
>Why not use this Last Call discussion
>BEEP

Allison,

The most simple and direct answer to your question is that the 
specification that has been put forward is for using BEEP, not TCP.

Would it make sense to discuss IP over PPP when a specification for IP over 
ATM were being put forward?

In addition, having a philosophical discussion about comparative approaches 
is particularly dangerous when there is a detailed specification for one 
approach and nothing but theory for another approach.

What remains really interesting is that all these messages have been posted 
about the last call, without a single criticism of that actual contents of 
the specification.

>(but not over UDP, please - SOAP should not do its own

BEEP's multiplexing feature is, perhaps, the only aspect of it that is 
"interesting" but it is far from the only reason for using the protocol.

Folks need to remember that BEEP serves to regularize a collection of 
services that applications constantly and wastefully re-invent for 
themselves, such as data packaging and security negotiation.

d/

----------

---

From: Allison Mankin <[email-masked]>
Date: Mon, 10 Sep 2001 21:37:25 -0400

Dave,

> specification that has been put forward is for using BEEP, not TCP. 

You mistake my intent in the question - I think this discussion
is serving to increase community awareness of the valuable 
functions of BEEP, the whole range of them, of which I mentioned
only one, multiplexing.  There was a lot of review of BEEP by IESG
as it went to Proposed Standard, and I share Ned's view that it is
a very useful protocol/application structure.  So my comment was
not intended to support a naked TCP mapping of SOAP.

TCP (or SCTP) fulfils critical reliability and congestion control 
functions under BEEP, hence my statement against a UDP mapping.

> ATM were being put forward? 

Purely with respect to the architecture discussion, yes -
there should be commonalities and consistency of the big
picture.  But any more about IP over foo would be digressive.

Allison

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Sep 2001 19:21:50 -0700

At 06:37 PM 9/10/2001, Allison Mankin wrote:
>only one, multiplexing.

Ahh.  Thanks for the clarification.

I guess the problem with using a Last Call as a teaching event is that 
postings on the Last Call thread might be mistaken for negative sentiment 
about the specification, rather than as demonstrations of interest in 
learning more about the technology.

It is further confused by the fact that the pedagogy, in this case, is for 
a related technology, rather than the specification currently under discussion.

Note that the postings have, in fact, been in the form of challenges, 
albeit absent any technical criticism of the specification at hand.  Hence 
my concern about serving ancillary agendas, such as pedagogy.

>picture.

I agree. That's why we chose to make the beep multiplexing mechanism 
identical to the tcp mechanism...

d/

----------