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

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

>> Frankly, I don't see what the "abstraction of the transport 
>> layer" provides you.

It means you don't have to define the same things again and again. 

SOAP is important, but there are many others types of messaging - 
http://www.ietf.org/internet-drafts/draft-ietf-apex-core-05.txt
http://www.ietf.org/internet-drafts/draft-new-webi-wcip-beep-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-beep-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sacred-protocol-beep-pdm-
00.txt
http://www.ietf.org/internet-drafts/draft-ietf-syslog-reliable-12.txt

Are we expected to duplicate and define slightly different variations of
the 50 pages of the BEEP spec inside each of these? And repeat roughly
every 6-8 weeks when the IETF and others start work on a new type of
messaging (e.g. http://www.ietf.org/html.charters/provreg-charter.html).

Rather than concentrating solely on SOAP, we have to consider the wider
picture, and come up with an appropriate solution - in this scenario I
think using BEEP is very sensible. Other people have differing views -
that is fine. Diversity is good!

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

On the issue of whether BEEP itself is a good idea or not based on these
questions, see:
http://lists.beepcore.org/pipermail/beepwg/2001-July/001210.html

On the issue of "gratuitous complexity":
I can tell you in practical terms it is roughly 50 lines of C# code. 

For those people who - after carefully examining the alternatives for
richer messaging (e.g.
http://www.clipcode.com/peer/http_async_notif.htm) - think BEEP is a
good thing, and now wish to use it to carry SOAP messages - is there
anything technically wrong with, or do you have any suggestions for
improvements to, the SOAP over BEEP spec as proposed?

Eamon

---

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

>It means you don't have to define the same things again and again.

We should not be pursuing a debate about the utility of BEEP.  That 
question was settled already.

Folks who do not understand the issues are, as you very considerately note, 
able to peruse quite a bit of educational material on the topic.  However 
the topic is irrelevant to this Last Call.

At 05:38 PM 9/10/2001, Christian Huitema wrote:
> > 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.
>
>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.

oh.  you want to ignore the problems that multiple, related tcp connections 
cause?  I thought the seriousness of that problem was established 8 or so 
years ago.

again, you are attempting to make basic attacks on beep, but beep is 
already standards track.

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

Interesting.  CSNet (the predecessor to NSFNet) ran TCP over X.25 just 
fine.  (There are lots of other examples, but that one rather stands out.)

However, yes, layers of flow control are an issue.

And BEEP deals with them, very explicitly and very carefully.

Do you have evidence that the beep specification does not work?  If so, 
please do bring that information to the beep working group.  They will be 
delighted to receive the feedback.

Again, however, that is not an issue for this Last Call.  That is why I 
have changed the Subject line, so no one will mistake this exchange as 
being relevant to the Last Call.

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

I love the title.

It suggests that TCP over IP over Ethernet is harmful, since each one does 
multiplexing.

>A similar problem leads us to avoid IP layer fragmentation
>, because it
>interferes with TCP layer reassembly and acknowledgement

The only problem with IP layer fragmentation is efficiency and holding 
receiving host buffers for a long time.  That efficiency hit is 
substantial, but the functionality works fine.

d/

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