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

From: Lloyd Wood <[email-masked]>
Date: Mon, 10 Sep 2001 13:42:37 +0100 (BST)

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: Scott Brim <[email-masked]>
Date: Mon, 10 Sep 2001 09:27:28 -0400

> but SOAP in BEEP is a SOAP-specific problem, which afaik means it's a

Good point.  Let's take a parallel with how the IETF divides work with
groups working on lower layers.  When we formed the sub-IP area the
philosophy was that the IETF would take on sub-IP issues iff ...

 - The work depends on IP expertise, which is here,
 - That it is critical to the development of the IP infrastructure, and
 - That it directly or indirectly affects operations or routing at the
   IP layer.

Reflect that upwards.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Sep 2001 08:02:23 -0700

>but SOAP in BEEP is a SOAP-specific problem, which afaik means it's a

Ethernet is not an IETF specification, yet the IETF has an IP-over-Ethernet 
standard.

The simple fact is that "convergence" layer protocols, that allow one 
protocol to work on top of another, are separate specification efforts from 
either of the protocols being converged.  It is not automatically better to 
have the "top" or the "bottom" layer originating standards group do the 
convergence protocol.

My own view is that the IETF has very strong skills at doing protocols and 
the W3C is strong at doing formats (content).  That suggests doing the 
convergence protocol in the IETF.

In any event, the specification has been written.  Are there any TECHNICAL 
problems with it?

d/

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

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 10 Sep 2001 16:22:13 +0100 (BST)

> Ethernet is not an IETF specification, yet the IETF has an IP-over-Ethernet 

... because the IETF did IP and has the interest in IP.

In SOAP over BEEP, W3C did SOAP and has the interest in SOAP, so that
would make SOAP-over-BEEP the W3C's problem.

In general, I think that foo-over-blah is the foo group's problem.

> have the "top" or the "bottom" layer originating standards group do the 

Meeting the needs of the top layer is imo best understood by the
top-layer group, which works within the framework already established
by the bottom-layer group. That way you may well end up with something
sucky, but at least it should be adequate to the needs of the top
layer.

> convergence protocol in the IETF.

I would say that everything is a protocol, to be parsed and processed.

L.

---

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

>In general, I think that foo-over-blah is the foo group's problem.

Thank you for that bit of philosophy.  It is reasonable.  However it is not 
mandatory, as exemplified by the competing philosophy that I have already 
provided.

]
>top-layer group

Again, a reasonable starting perspective, but not one that guarantees the 
best outcome in all cases.

>I would say that everything is a protocol, to be parsed and processed.

Computer Science discussions sometimes combine the exchange rules and the 
format and sometimes treat them separately.  hence the term protocol 
sometimes means exchange rules and content and sometimes means only 
exchange rules.  For example, SMTP is a protocol, and RFC822 is a 
format.  They are handled separately.  (Well, technically, RFC822 has a bit 
of user-to-user protocol in it, for such things as Reply, but mostly it is 
about formats.)

In any event, please refer to the IETF/W3C agreement to split HTML and HTTP 
standardization efforts.

> > In any event, the specification has been written.  Are there any TECHNICAL

And now I see that you did not respond to the only important question...

d/

----------

---

From: [email-masked]
Date: Mon, 10 Sep 2001 08:54:15 -0700 (PDT)

>  - The work depends on IP expertise, which is here,

A good application protocol is far less dependent on the format and structure
of the data being carried than it is on the proper design of the application
protocol itself. So, while it is true that data format and structure is the
W3C's domain and not the IETF's, the IETF is where the expertise to do
application protocol design lies.

We have plenty of examples of poor application protocol design, and we also
have plenty of examples of poor data bindings to application protocols, so we
know this isn't trivial stuff anyone can just slap together.

>  - That it is critical to the development of the IP infrastructure, and

A way to do the things SOAP does is critically needed at the application layer.
And while I personally do not like the approach SOAP uses, it does represent a
solution, and moreover it seems to be the solution peopel are pursuing.

>  - That it directly or indirectly affects operations or routing at the

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.

				Ned

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 10 Sep 2001 17:41:39 +0100 (BST)

On Mon, 10 Sep 2001, Dave Crocker wrote:

> of user-to-user protocol in it,

exactly. There's no such thing as a format.

This goes right to Wittgenstein's private language argument, if you
ask me. There's no such thing as a private language; there's no such
thing as a format.

If it's public, it's a protocol; the exchange rules and the format are
interdependent and interwoven to an amazing degree, and if you weren't
exchanging it as information you wouldn't be needing a format for it
in the first place.

That makes everything a protocol, if you ask me.

(btw, does the 'Object' in 'SOAP' have any relation to the 'objects'
 discussed in the http rfcs, and any relation to 'object' as
 understood by computer scientists?)

> for such things as Reply, but mostly it is 
> about formats.)
> 

where?

> And now I see that you did not respond to the only important question...

I thought it was ad-hominem.

please see my other responses in this thread. My understanding is that
last calls are not limited only to technical problems - besides, one
man's technical problem is often another man's trifling concern.

L.

of course, I think descartes' mind/body dualism is bunk too.

> Thank you for that bit of philosophy.

---

From: [email-masked]
Date: Mon, 10 Sep 2001 10:02:27 -0700 (PDT)

> In general, I think that foo-over-blah is the foo group's problem.

In general this cannot be right, since it would make all problems the
responsibility of whoever is responsible for a given application and eliminate
the IETF entirely. Example: HTTP began as HTML over TCP, so it is the W3C's
problemn. Repeat with TCP, IP, whatever.

Problems need to be solved by the people with the competence and interest to do
so. And in this case the W3C has said they have neither.

> sucky, but at least it should be adequate to the needs of the top

That's exactly the logic that has led to bad protocol designs so many
times in the past.

				Ned

---

From: John Stracke <[email-masked]>
Date: Mon, 10 Sep 2001 13:16:54 -0400

>sucky, but at least it should be adequate to the needs of the top
Not necessarily.  The top-layer people may not have expertise on how to 
use the bottom-layer protocol.  For example, HTTP performed badly until 
it was overhauled by people who knew TCP.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Organ transplants are best left to the       |
[email-masked]|professionals.                               |
\==============================================================/

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 10 Sep 2001 18:23:10 +0100 (BST)

On Mon, 10 Sep 2001 [email-masked] wrote:

> the IETF entirely.

...which is reasonable.

Consider the alternative, where foo-over-blah is the blah group's
problem, and the guys thinking about the physical layer get hamstrung
with responsibility for absolutely everything.

> Example: HTTP began as HTML over TCP, so it is the W3C's

odd. they've got all the SOAP people, after all.

> That's exactly the logic that has led to bad protocol designs so many

There are bad protocol designs and there are good protocol designs.
Many are produced using similar methodologies; it's hardly the only
defining factor.

care to give specific examples?

L.

---

From: [email-masked]
Date: Mon, 10 Sep 2001 10:28:51 -0700 (PDT)

> Many are produced using similar methodologies; it's hardly the only

Actually, in many cases it *is* the defining factor. Frameworks are fine as far
as they go but they just don't provide enough guidance to get things right in
many cases. And the assumption that they do often leads to trouble.

> care to give specific examples?

There are so many it is difficult to know where to begin. Here are two that
continue to plague us to this day.

The poor use of TCP by HTTP almost certainly could have been addressed had HTTP
been designed with more input from transport layer folks.

The design of MIME failed to take certain security issues into account and as a
result makes end to end security more of a pain than it should be. And I know
for a fact this was a direct result of security and application working
group scheduling conflicts -- I was there.

				Ned