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

From: "Christian Huitema" <[email-masked]>
Date: Mon, 10 Sep 2001 16:13:43 -0700

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

Well, I am mostly concerned to see "SOAP over BEEP" defined before we
define the alternative "SOAP over TCP". I mean, if we are transporting
opaque blobs of data between two points, TCP looks like a no-brainer...

-- Christian Huitema

---

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

> opaque blobs of data between two points, TCP looks like a no-brainer...

christian - i'm interested only in the technical issues. i'll leave the
non-technical issues to others. as much as i'd enjoy have a concrete v.
abstract discussion, it's not time-effective.

so, while i do not wish to discourage your postings in any fashion, i would
be most appreciative if your reply to me would enumerate any technical
issues you see in the "soap over beep" specification. obviously, you should
feel free to send other messages/replies that more fully discuss issues
which are either non-technical or not specific to the "soap over beep"
specification.

thanks,

/mtr

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2001 10:45:48 -0500

> opaque blobs of data between two points, TCP looks like a no-brainer...

There are other "SOAP over foo" proposals in the wings too. I do agree that
the general question needs looking at. Maybe it's OK to have lots of
SOAP mappings, or maybe it isn't. Although mtr may disagree, imho this does
need to be considered before deciding to publish a Proposed Standard.

   Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Sep 2001 10:44:06 -0700

(appreciating the distraction from today's shock...)

>need to be considered before deciding to publish a Proposed Standard.

Does it?

Your suggestion reflects a model that the IETF acts as a gatekeeper to 
ensure only the right "number" of specifications.

However the actual history of IETF successes has permitted as many such 
mappings as folks feel inclined to make -- as long as they satisfy the 
usual IETF requirements for technical adequacy and community support.

With the possible exception of IP, itself, all efforts by the IETF to 
pretend that we can do such technology planning, like constraining 
competing choices down to a single winner, have failed.

All of them.

d/

ps.  And of particular concern is that you are raising no specific 
technical concerns, thereby leaving the matter as one that is purely abstract.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2001 16:08:47 -0500

> ensure only the right "number" of specifications.

I believe we have some responsibility to limit the number of
options. You may recall some roadkill called OSI, one of whose major
problems was too many options, notably at the transport level.

SOAP over HTTP
SOAP over HTTPR
SOAP over BEEP
SOAP over APEX
SOAP over TCP
SOAP over SCTP

...
> technical concerns, thereby leaving the matter as one that is purely abstract.

Putting the Web Services world in a situation where it needs a discovery protocol
to find out how to layer SOAP is not at all an abstract issue. Or do you think
the WSDL for each Web Service is going to define the available layerings? What
is a poor vendor to do other than support all of them, and what is the technical
justification for that? imho this is an absolutely valid last call issue.
(If this had been a WG work item, it would have been discussed as a WG charter
issue.)

  Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Sep 2001 15:04:55 -0700

Brian,

At 02:08 PM 9/11/2001, Brian E Carpenter wrote:
>options.

We have a responsibility to evaluate each technical proposal on its merits.

You are raising the spectre of a possible scenario that currently has no 
basis.  There is only one proposal on the table.  Everything else is 
conjecture.

The IETF does best when it focuses on the real, immediate world, rather 
than on an infinite array of hypotheticals.

If you insist on playing the OSI card, please note that the real sin of the 
OSI effort was to try to pay attention to every possible future 
requirement, rather than paying attention to immediate ones.  It advisable 
that we not replicate that error by way of impeding focused technical work.

>to find out how to layer SOAP is not at all an abstract issue.

How is that a problem for the current specification?  (That's a rhetorical 
question, since the answer is:  it isn't.)

So, we continue to have all the criticisms of this proposal focus on 
everything except the technical details of this proposal.  How constructive.

d/

----------

---

From: Mark Baker <[email-masked]>
Date: Tue, 11 Sep 2001 20:54:23 -0400 (EDT)

> (If this had been a WG work item, it would have been discussed as a WG charter

I don't have an opinion on the larger issue here, but I did want to
point out that the "Web Services world" is far from clear about what
it wants to achieve, let alone *how*.  There exists major architectural
disconnects between existing Web architecture, and the architecture
commonly associated to "Web Services".

IMO, it's premature to use that as an example.

MB

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Sep 2001 10:30:43 -0500

Mark,

I can't claim deep expertise but the people I work with who are building the
UDDI/WSDL/SOAP world have a very clear idea of what Web Services means. I agree
that the phrase is also used in a hand waving way too, but there is a kernel
of very precise technical solutions that is essentially unknown in the IETF.

I'm not using it as an example - it *is* the deployment arena for SOAP.

   Brian

---

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

> UDDI/WSDL/SOAP world have a very clear idea of what Web Services means.

Heh, well I don't doubt that some people have a very clear idea of what
Web Services means. 8-) The problem is that it isn't shared by everybody
else.

To get some idea of what I'm talking about here, check;

http://conveyor.com/RESTwiki
http://conveyor.com/RESTwiki/moin.cgi/HowToConvertRpcToRest

MB