...and I can't stand the acronyms ... SOAP in BEEP is just too
much for me :)
Cheers,
Michael
-----Original Message-----
From: Lloyd Wood [mailto:l(_dot_)wood(_at_)eim(_dot_)surrey(_dot_)ac(_dot_)uk]
Sent: Monday, September 10, 2001 2:43 PM
To: iesg(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org
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
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org 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.
<L(_dot_)Wood(_at_)surrey(_dot_)ac(_dot_)uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>