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

From: "Eamon O'Tuathail" <[email-masked]>
Date: Mon, 10 Sep 2001 15:55:01 +0100

Dear Lloyd,

The full "evolving" comment from the 'soap over beep' spec states:

"feature negotiation: 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.  For example, if a
new version of SOAP is specified, a corresponding feature for the
BEEP profile for SOAP should be defined that allows negotiated use
of the new version."

The idea is that BEEP should be able to carry a variety of SOAP 
payloads - including the current version 1.1, the version under
development 1.2, and whatever the future might bring. We don't want to
limit it to the current version only. We don't want to wait a couple of
years until everything is complete and gone through a couple of updates
before defining the 'soap over beep' spec. So the sensible route we took
was to define what we can now, and add the feature negotiation mechanism
so that additional features may be easily added without breaking
existing implementations of the soap over beep spec, which might not
support that feature. 

W.r.t. the question of who should be working on SOAP over BEEP - note
that there are many pieces of functionality evolving into a natural
stack - some are W3C - such as SOAP, (and I imagine soon) WSDL and UDDI,
and some are IETF - BEEP (RFC 3080), BEEP transport mapping to TCP (RFC
3081), TCP, etc. [when using BEEP for transfer]. 

At some point the IETF pieces have to interface with the W3C pieces.
There is naturally scope for discussion about who does what at such
interface points. (e.g. One could ask why was the XML *Protocol* work
not done in the IETF). As much of 'SOAP over BEEP' discusses usage of
BEEP and it effectively carries the SOAP envelope as an opaque piece of
data, it is fair to say it is just below the bottom of the W3C stack and
at the top of the IETF stack, so it should be an IETF spec in this
scenario. 

>>More worryingly from a standards viewpoint:
>>
>> 'The BEEP profile for SOAP is identified as
>>   http://clipcode.org/beep/soap

This URL is transient for work in progress. Note that "Appendix B. IANA
Considerations" states:
   If the IESG approves this memo for publication, then the IANA
   registers the profile specified in Section 7.1, and selects an IANA-
   specific URI, e.g.,
       http://iana.org/beep/soap
What is in the spec is normative, not what might be located at one of
these URLs. 

>> 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.
All BEEP MSG messages require a response - RPY, ANS/NUL or ERR. The NUL
that is returned from a one-way *SOAP* message tells the peer that sent
the SOAP message that the BEEP implementation at the remote peer has
received the message - it says nothing about how it is further
processed. 

>>Why have RPY *and* ANS? 
RFC 3080 supports both, so we should too. 

>> ... without the *non-standard* non-BEEP error-in-RPY hackery ...

The spec is designed so that it carries an envelope of SOAP data without
having to know what is inside it. 

Eamon O'Tuathail
http://www.clipcode.com

---

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

> existing implementations of the soap over beep spec, which might not

That's very W3C fast-track approach. It strikes me it's not the IETF
standard cycle, which has been known to take... well, rather longer.

I can't see feature negotiation working well in implementations; it's
nice in theory, but often problematic in practice. The feature
negotiation described in your draft seems clean and simple, but see
further comments on this at end. I'm not convinced it's needed.

> stack - 

natural? beg to differ.

> some are W3C - such as SOAP, (and I imagine soon) WSDL and UDDI,
> not done in the IETF). 

One _could_ ask why the xml protocol work was done at all. (and isn't
xml a format?)

> As much of 'SOAP over BEEP' discusses usage of
> Considerations"

...which is why I cited IANA in the following lines:
$ What happens to the standard if that profile described on that url
$ (or an IANA equivalent - see IANA considerations) changes?

I have trouble viewing any url/uri as a normative reference, and would
much prefer to see the original content embedded in the nascent rfc,
so that the starting point is a fixed target.

> RFC 3080 supports both, so we should too. 

Well, RFC 3080 supports ERR. You do not, overloading RPY in this case,
and by your reasoning above you should.

> having to know what is inside it. 

Then you don't need to support both RPY and ANS to distinguish between
types of SOAP message patterns, do you? That's not opaque.

And if you *really* want to be opaque, why would you need any feature
negotation in BEEP? You could leave that up to the SOAP versioning in
the Envelope element...

I am concerned by the phrase 'tuned for privacy' and use of 'beeps'
(presumably as analogous to 'https') to suggest an equivalent level of
security, when all that is required is the start of a user
authentication profile.

Is that really strong enough from a security perspective, or simply
desirable from the marketing viewpoint that the phrase 'tuned for
privacy' suggests? (I'm by no means a security expert.)

thanks,

L.

being tuned for privacy isn't much use if you're not in the right key.

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

---

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

>nice in theory, but often problematic in practice. The feature

Then you should discuss such concerns about SOAP in a SOAP protocol 
development forum.  This thread does not concern general SOAP issues.

One more time:

         Are there any technical problems with
         the specification that is under review?

d/

ps.  the time for challenging the venue for this work was when it was 
initiated, not now.

----------
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 18:17:51 +0100 (BST)

> development forum.  This thread does not concern general SOAP issues.

Then there is another reason why SOAP over BEEP is W3C work, as I've
been claiming and you've been denying.

If you've read Eamon's draft, you will know that the feature
negotiation that takes place in this draft is done in the context of a
BEEP exchange during profile initialisation; in my previous message I
go on to suggest that that BEEP exchange of supported features may not
be necessary, and could be left entirely up to SOAP in the interests
of a far simpler, more opaque transport.

(defining feature negotiation separately for everything carrying SOAP
 strikes me as a rathole.)

>          the specification that is under review?

I believe so. Which is why I took the trouble to write.

> ps.  the time for challenging the venue for this work was when it was 

It's an _individual draft_.
http://www.ietf.org/internet-drafts/draft-etal-beep-soap-04.txt

We don't have First Calls, charters or bofs to discuss whether
individual drafts should or should not be written. Challenging
individual drafts when the work for them is initiated strikes me as 
both impossible and absurd.

L.

---

From: "Marshall T. Rose" <[email-masked]>
Date: Mon, 10 Sep 2001 15:55:17 -0700

lloyd - in looking at your technical concerns:

1. i am at a loss to understand the problem you perceive with respect to
mapping soap message patterns onto beep. in each of the three cases, it
looks to me that the "obvious" choice was taken. what leads you to suspect
otherwise?

2. with respect to feature negotation, i agree that the mechanism used in
the specification is about as simple as clean as you can get. as to whether
it's needed or not, that's a great question.

the delta between soap 1.0 and soap 1.1 is reasonable. what remains unknown
is what soap x.y will look like. this is why we have a feature negotiation
mechanism. to the extent that future versions of soap are compatible with
the exist versions, then it isn't needed. if a future version is
incompatible, then a feature can be defined to signal this.

> negotation in BEEP? You could leave that up to the SOAP versioning in

and i agree, as long as versioning remains transparent, feature negotiation
isn't needed... i would be happy to see that it never gets used. think of it
as a very cheap insurance policy.

> privacy' suggests? (I'm by no means a security expert.)

specifically, "tuning" is a term of art in beep, so anyone who knows beep
knows what "tuned for privacy" means. what problem, per se, are you worried
about?

/mtr

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 10 Sep 2001 20:33:01 -0700

Reference [1] in draft-etal-beep-soap-04.txt is written

   [1]   World Wide Web Consortium, "Simple Object Access Protocol
         (SOAP) 1.1", May 2000, <http://www.w3.org/TR/2000/NOTE-SOAP-
         20000508>.

However, http://www.w3.org/TR/2000/NOTE-SOAP-20000508 is not
a W3C publication; it is a submission by its authors, and has
not much more standing in the W3C than an Internet Draft has
in the IETF. At a minimum, the attribution of the reference should
be fixed. The authors are Box, Ehnebuske, Kakivaya et al.

However, the status of the document cited should also
be made clear. The document says:

  This document is a NOTE made available by the W3C for discussion only.
  Publication of this Note by W3C indicates no endorsement by W3C or the 
  W3C Team, or any W3C Members. W3C has had no editorial control over the
  preparation of this Note. This document is a work in progress and may be
  updated, replaced, or rendered obsolete by other documents at any time.

Part of the discussion in the XML protocol group in W3C is about
the various characteristics of SOAP binding. I thought during the
discussion of the "SOAPAction" header in the HTTP binding that perhaps
a binding of SOAP to a 'transfer' protocol might require other information.
Should there be something in "SOAP over BEEP" corresponding to the
SOAPAction header? The status of SOAPAction in the XML protocol group
has not been resolved definitively, although there's a discussion of
it in the same NOTE about SOAP.

Is reference [1] normative? Should a standards track document
(even a Proposed Standard) make normative reference to a W3C NOTE?
And how could you specify "SOAP over BEEP" without making normative
reference to SOAP?

I don't question the venue of IETF specifying the binding of SOAP
over transfer protocols, but I wonder about the timing.

Perhaps the IETF document could specify how to BEEP as a transfer
protocol for *any* SOAP-like protocol, but it's hard to imagine
it being specific enough to warrant "Proposed Standard".

To make progress, the IESG could publish "Using SOAP in BEEP" as
Experimental, and move it to standards track once there's an
appropriate reference for SOAP.

Larry
-- 
http://larry.masinter.net

---

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

>          (SOAP) 1.1", May 2000, <http://www.w3.org/TR/2000/NOTE-SOAP-

ok. it's easy enough to fix this.

> appropriate reference for SOAP.

the document in question is 16 months old and forms the basis for many
implementations, products, services, and so on.

i think that those implementors would be somewhat confused by your view that
"it's hard to imagine it being specific enough".

in theory, i might agree with you; however, the practice is far different
from the theoretical perspective you suggest...

/mtr

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 10 Sep 2001 23:27:32 -0700

> the document in question is 16 months old and forms
> the basis for many implementations, products, services, and so on.

Indeed the document is 16 months old. In the intervening
16 months, there have been the basis for updates
(see http://www.w3.org/TR/2001/WD-soap12-20010709/)
and a very active mailing list
(http://lists.w3.org/Archives/Public/xml-dist-app/)
and a large number of issues
 (http://www.w3.org/2000/xp/Group/xmlp-issues.html).

I think that it would be good to review how some of those
issues might affect SOAP in BEEP (e.g., issues 12, 67,
69, 95 and 105) to insure that the BEEP binding wouldn't
change depending on the resolution of those and related
issues. (I'm especially concerned about how the counterparts
of the use of HTTP 500 errors and the SOAPAction header
would map -- or not map -- to a BEEP binding.)

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

Larry

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 11 Sep 2001 12:01:48 +0200

> further comments on this at end. I'm not convinced it's needed.

just about every single protocol I've watched has gone through a some 
standard stages:

1 - "The problem space is simple. We will define everything we need."
2 - "We can handle the needed new features by reissuing the protocol."
3 - "As long as we provide a registry for new features, we will be OK."
4 - "As long as we do vendor spaces for new features, we will be OK."
5 - "As long as we have mandatory/optional extension flags, we're OK."
6 - "How did we end up with such a complex protocol? Let's kill it!"

Feature negotiation is required at all stages beyond number 2, and 
sometimes even at stage 2; it depends on the new features.
Numbers 4 and 5 sometimes trade places, and number 6 can occur at any time.

That's life.

(Real, named examples: HTTP, Receipt notifications, X.400, X.500, PGP/MIME, 
LDAP, BGP, DHCP, SRVLOC, URLs.....counterexamples would be harder to 
find....)

                  Harald

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Sep 2001 09:48:42 -0700

> appropriate reference for SOAP.

Speaking for myself only, I agree; I find the timing of this curious,
at the very least. The authors of SOAP submitted 1.1 to the W3C
specifically to work towards what is now SOAP 1.2, which is rapidly
(at least on the time scale of these things) approaching completion.

Putting a binding based on 1.1 on the IETF Standards track while 1.2
is being finalized seems like poor coordination at best.

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

---

From: "Eliot Lear" <[email-masked]>
Date: Wed, 12 Sep 2001 02:21:54 -0700

As someone who is still coming up to speed on SOAP (would a SOAP server
be called a dispenser?) I would appreciate the authors and AD responding
to Mark.  Marshall, can you comment on this point?  Thus far this is the
only objection that raised my eyebrows.

Mark, my condolences to Akamai on your loss of Danny.  He was a really
cool guy.

Eliot

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 12 Sep 2001 16:35:00 -0700

> only objection that raised my eyebrows.

ok.

> > (at least on the time scale of these things) approaching completion.

there's nothing curious about the timing.

the original draft came out a little over three months ago. there was a fair
amount of discussion on both the beep and xmlp working group mailing lists.
the draft was revised a few times based on that.

after a quiet period of a couple of weeks, i asked the ADs to have it
published. unfortunately, that was right before the london ietf, which
introduced a lot of delay. then there was more management coordination.

then the last call came out.

> > is being finalized seems like poor coordination at best.

i guess it depends on what you mean by the term "finalized".

the I-D in question works with 1.1 and 1.2 and, as explained previously,
contains an extensibility mechanism to deal with 1.x and perhaps even 2.y...

/mtr

---

From: "Eliot Lear" <[email-masked]>
Date: Thu, 13 Sep 2001 00:46:40 -0700

if it works with 1.1 and 1.2, what's the problem then?

eliot

ps: it wasn't a motivation thing that concerned me, but more just to
know it works with 1.2.

---

From: Mark Baker <[email-masked]>
Date: Thu, 13 Sep 2001 09:14:01 -0400 (EDT)

> ps: it wasn't a motivation thing that concerned me, but more just to

1.2 is still in working draft state[1], and some major issues are still
being worked out.

 [1] http://www.w3.org/TR/soap12/

MB

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 14 Sep 2001 13:26:11 +0100 (BST)

Re:  http://www.ietf.org/internet-drafts/draft-etal-beep-soap-04.txt

> looks to me that the "obvious" choice was taken. what leads you to suspect

Special-casing the single-response case struck me as less than obvious
(especially given Eamon's comment that 'The spec is designed so that
it carries an envelope of SOAP data without having to know what is
inside it'). And then there's ERR use.

> incompatible, then a feature can be defined to signal this.

Should compatibility between versions of soap be encouraged by leaving
out such mechanisms? 

Bear in mind that beep is not the only thing bound to soap, so that
having one other popular soap carrier/binding that *doesn't* bother
with doing soap version negotiation to deal with soap's future
oddities imposes the limit of compatibility on future versions of soap
here.

I don't think beep should be worrying about soap's version problems;
encouraging soap developers to actually think about compatibility and
legacy and deal with their own messes in the existing envelope
mechanism is imo a good (if perhaps overdue?) idea, and if at least
one other binding does that, beep's soap version negotiation is then
unneeded.

> isn't needed... i would be happy to see that it never gets used. 

Removing versioning ensures that it never gets used, and that we're
happy.

> think of it as a very cheap insurance policy.

...that encourages you to burn down your house to collect the reward.

> knows what "tuned for privacy" means. 

'tuned for privacy' is not defined in RFC3080 or 3081. It's not
defined or even discussed in the full raw beep list archive at:
http://lists.beepcore.org/pipermail/beepwg.mbox/beepwg.mbox

How will beep implementors know what this term means?

Transport security, privacy, and user authentication are somewhat
different things, I'd have thought. Is it reasonable to equate them
all in 'tuned for privacy'?

Specific text comment on the definition in section 5.2 of the draft:

'tuned for transport security' strikes me as a more reasonable term,
and would require that either:

a. a transport security profile is successfully started; or,
b. a user authentication profile that *requires the use of* transport
   security is successfully started.

so that transport security is *mandated*.

Privacy is a very different beast.

cheers,

L.