Subject: RE: SOAP/XML Protocol and filtering, etc.

From: "Henrik Frystyk Nielsen" <[email-masked]>
Date: Mon, 7 May 2001 14:50:37 -0700

The meaning of SOAPAction is not to say that "this is a stockquote
service" but to say that "I am sending you a SOAP message of a type that
is part of a stock quote service".

The difference is that one is a destination which is carried in HTTP by
the request-URI but the other is a hint about what is in the message.
This is why SOAPAction is a separate parameter.

Henrik

>> On Sun, May 06, 2001 at 03:12:08PM -0400, Keith Moore wrote:
>> > and client APIs.  It also keeps HTTP servers from having to know 
>> > specifically whether a particular URI corresponds with a SOAP 
>> > request (in which case it might have to look at the SOAPAction 
>> > header in order to know how to handle it) or not (in which case the

>> > SOAPAction header should be ignored).
>> 
>> Yep; seems to me that Content-Type ss more appropriate for dispatch, 
>> if doing it in a header is desireable.
>
>ugh.  only if you must.  the URL is *far* better for this purpose.

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 May 2001 20:16:41 -0400

> is part of a stock quote service".

okay, fine.  but why bother exposing this in the request header at all?

Keith

---

From: "Dick Brooks" <[email-masked]>
Date: Mon, 7 May 2001 20:13:14 -0500

Keith,

SOAP messages can take many forms. SOAPAction provides the information
needed by a generic message broker to dispatch a message to the appropriate
handler, without requiring the message broker to have intimate knowledge of
each SOAP message structure. The SOAPAction can serve as a "key" into a
table of message processors. IMO, SOAPAction is conceptually similar to the
MIME Content-type.

If a generic message broker couldn't determine the message type from a
request header it require intimate knowledge of each message structure in
order to perform dispatch functions. It's more efficient and easier to write
a
message broker that operates off the MIME/HTTP headers for dispatching
purposes.

Dick Brooks (ebXML liaison)
http://www.8760.com/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Keith Moore
Sent: Monday, May 07, 2001 7:17 PM
To: Henrik Frystyk Nielsen
Cc: [email-masked]; Mark Nottingham; [email-masked];
[email-masked]
Subject: Re: SOAP/XML Protocol and filtering, etc.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 May 2001 01:24:09 -0400

> table of message processors. IMO, SOAPAction is conceptually similar to the

HTTP servers do not dispatch on content-type.

either you're dispatching on the URI or you're breaking compatibility with
HTTP.  

Keith

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 8 May 2001 07:30:12 -0500

>HTTP servers do not dispatch on content-type.

I agree, dispatching on Content-type does not occur within the HTTP server,
it's the function of a message broker to dispatch based on Content-type.

>either you're dispatching on the URI or you're breaking compatibility with

I agree, the HTTP server will dispatch processing to the request-uri of a
HTTP POST,
in SOAP's case.

However, if the request-URI is a program that performs message broker
functions then
dispatching, by the message broker, is performed based on Content-type or
some
other information within the HTTP entity headers (e.g. SOAPAction) or
session information
(e.g. cookies, username).

If the SOAPAction is removed and there is nothing else in the HTTP headers
to tell the message broker
how to dispatch then the message broker will have to interrogate the
incoming messages to decide how to dispatch the information. The message
broker would require
intimate knowledge of each incoming message, including the ability to
decrypt, if necessary.

The message broker design pattern needs "something" outside the message
payload (e.g. HTTP or MIME headers) to facilitate dispatch functions. The
alternative
requires message brokers to have intimate knowledge of each message payload.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 08, 2001 12:24 AM
To: Dick Brooks
Cc: Keith Moore; Henrik Frystyk Nielsen; Mark Nottingham; [email-masked];
[email-masked]

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 May 2001 08:49:33 -0400

> alternative requires message brokers to have intimate knowledge of each 
> message payload.

far better for the SOAP-specific message broker to have intimate knowledge
of the SOAP-specific payload, than to have the SOAP-specific message broker
to have intimate knowledge of the HTTP-specific request header.

also, far better for the SOAP-specific dispatching tags to be part
of the SOAP-specific payload which is supposed to be independent of the
protocol being used as a substrate for SOAP, than to have to supply this
dispatching tag in a different way for every substrate protocol.

Keith

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 8 May 2001 08:31:19 -0500

>to have intimate knowledge of the HTTP-specific request header.

I never said a message broker was SOAP specific. There are message brokers
running on HTTP servers that can dispatch processing for EDIINT AS2, GISB
EDM, AIAG E-5,
ebXML, SOAP and other types.

Dick

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 May 2001 09:25:39 -0400

> I never said a message broker was SOAP specific. 

a message broker that looks at a SOAPAction header isn't SOAP specific?

> There are message brokers running on HTTP servers that can dispatch 
> processing for EDIINT AS2, GISB EDM, AIAG E-5, ebXML, SOAP and other types.

what you are saying is that there are people out there who do not understand
the value of clean separation of function between layers.  how is that a 
justification for a standards-setting organization to propagate that 
misunderstanding?

Keith

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 8 May 2001 08:56:20 -0500

>a message broker that looks at a SOAPAction header isn't SOAP specific?

SOAPAction is a HTTP header - message brokers are HTTP/MIME aware, including
the
ability to deal with HTTP/MIME extension headers, such as SOAPAction. A
message broker is not required to understand the structure and semantics of
a SOAP document.

>justification for a standards-setting organization to propagate that

Or perhaps there are people who don't understand message broker concepts.

How is what I've described all that different from inetd? Consider:

|ftp|telnet|finger|    |ebXML|GISB|AIAGE5|AS2|
|      inetd      |    |   message broker    |
|       TCP       |    |       HTTP          |
   ........                 ...........

What's unclean about this approach, it enables centralized administration,
single security domains, workflow management, a single "choke point" for
security purposes. The "handlers" are in fact separate and distinct layers
from the message broker.

Dick

---

From: "Dave Winer" <[email-masked]>
Date: Tue, 8 May 2001 07:33:26 -0700

Does the HTTP spec allow applications to add headers?

If so, what the heck is the argument about?

BTW, I thought SOAPAction was dorky when I first heard the idea. But it's
there.

There's deployment based on SOAPAction.

Dave

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Dick Brooks" <[email-masked]>
Cc: <[email-masked]>; "Henrik Frystyk Nielsen" <[email-masked]>;
"Mark Nottingham" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 08, 2001 6:25 AM
Subject: Re: SOAP/XML Protocol and filtering, etc.

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 08 May 2001 11:11:11 -0400

It seems to me that the argument for using the SOAPAction header is 
based on two conflicting points:

- that the action needs to be identified outside the HTTP body so 
that it can be used by a message broker to dispatch the body without 
understanding it.

and

- that the message broker cannot use the URI because it is not a 
part of the HTTP server

Either the message broker is part of the server, can use a header 
value (including the URI) and the body is opaque, or it isn't and 
should use the body but not the headers.

It seems to me that together, these argue for an additional layer of 
encapsulation - send a message broker body (whatever that is) in the 
HTTP message (with the URI of the message broker and a content type 
that identifies it as a message broker message), and then within 
that body encapsulate a SOAP message, with whatever metadata the 
message broker needs to dispatch it.

If an additional encapsulation sounds harder to deal with in a 
firewall, then you begin to understand what firewalls are for.  The 
objective, IMHO, should not be to design protocols so that we can 
poke them through firewalls - that is a bad way to use firewalls. 
We should instead design things so that it is easy for services to 
be offered outside firewalls when that is appropriate (yes, this is 
hard, but it is the real problem and the hacks to avoid solving it 
only make it worse).

We should not permit upper-layer protocols to poke information 
arbitrarily far down into the stack in order to label the payload as 
'ok to pass through security' unless we have also defined ways for 
that label to be appropriately secured. If we can have SOAP reaching 
past the 'message broker' to HTTP with its label, why not have it 
reach past HTTP to add a TCP option? When put that way it seems 
silly - the HTTP option really isn't any better.

As for the specific question that began this thread (whether the 
SOAPAction header is useful or not), I can offer an implementation 
perspective.  We've implemented the 0.9 version of SOAP as a part of 
our UPnP implementation.  SOAP/0.9 is carried in HTTP and does 
include the SOAPAction header.  It also includes the same 
information (the action identifier) in the XML body of the message. 
  We found the potential conflict between these to be a major pain 
to deal with, especially since the namespace was represented 
differently in the header and body (which meant that the comparison 
had to be namespace-aware, it couldn't just be the equivalent of 
strcmp).
-- 
Scott Lawrence      Architect            [email-masked]
Virata       Embedded Web Technology    http://www.emweb.com/

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 08 May 2001 11:18:39 -0400

> |      inetd      |    |   message broker    |

Inetd uses only the port number - the address provided by the TCP 
and UDP layers below it - to make its decision.

What is not clear (to me at least) is why the URI isn't enough to 
make the decision - that is the address of the resource above the 
HTTP layer.  I don't see why administering and managing SOAPAction 
headers and Content-Types and whatever else is easier than 
adminstering URIs.

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 May 2001 11:23:51 -0400

> SOAPAction is a HTTP header - message brokers are HTTP/MIME aware, 
> including the ability to deal with HTTP/MIME extension headers, such 
> as SOAPAction. 

HTTP and MIME are not the same thing.  They do not have the same set
of extension headers, nor the same extension mechanisms, even if some
of the protocol elements have the same names between the two.
(this has caused a fair amount of confusion when MIME header names
were borrowed for HTTP but used with slightly different semantics)

They share a common set of media types, and not much more than that.

> A message broker is not required to understand the 
> structure and semantics of a SOAP document.

I get that.  But you're requiring it to understand HTTP headers, which
is worse.

> How is what I've described all that different from inetd? Consider:

inetd dispatches on destination port number. destination port number
is *defined* as a dispatching mechanism for TCP and UDP.

what you're describing is like adding an IP option to provide an additional
means of dispatching incoming IP messages, when port numbers already exist
for this purpose.  in the HTTP world, URIs already exist for the purpose
of dispatching incoming HTTP requests.  to change this is to break HTTP.

> security purposes. The "handlers" are in fact separate and distinct layers

it breaks compatibility with HTTP, it forces SOAP implementations to depend
on non-portable features of HTTP client libraries and proxies, it is not 
portable across SOAP substrates, it is not reliable as a filtering mechanism
(meaning it's inherently insecure), and it doesn't work with encryption.

what's more, you haven't provided a single justification for making this
external to the SOAP protocol.  if the SOAP protocol can't provide some
easily accessible tagging to facilitate dispatching within the SOAP world,
perhaps this is because some basic idea behind SOAP is inhernetly flawed -
such as that it's a good idea to use XML for everything, or that it's a good
idea to layer new protocols on top of HTTP.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 May 2001 11:25:16 -0400

> Does the HTTP spec allow applications to add headers?

HTTP *is* an application.  it's not intended to be used as a substrate
for other applications.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 8 May 2001 16:27:38 +0100 (BST)

On Tue, 8 May 2001, Dick Brooks wrote:

> How is what I've described all that different from inetd?

ftp, telnet and finger services run on different ports with different
numbers, are clearly separate services with no interdependencies, and
don't require ever-more-complex parser implementations to work
correctly.

Separate, compartmentalised functionality has its advantages.

L.

IP is the waist in the hourglass.
no, HTTP is the waist in the hourglass.
no, CCAMP is the waist in the hourglass.
and time is still running out.

> Consider:

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 May 2001 08:40:19 -0700

> idea to layer new protocols on top of HTTP.

Ah, diplomacy at its finest. ;)

I didn't intend for the issues to be debated cross-group on the main
IETF list; a better forum would be the [email-masked] list,
which is archived and explained at
  http://www.w3.org/2000/xp/Group/

Cheers,

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