W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2004

Re: Issue 455 closed: Representation header and SOAP processing model

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 23 Mar 2004 10:38:59 -0500
To: Jacek Kopecky <jacek.kopecky@systinet.com>
Cc: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>, XMLP Dist App <xml-dist-app@w3.org>
Message-ID: <OFFA67B3E8.300562A3-ON85256E60.0056010E@lotus.com>

Jacek Kopeckwy writes;

> I would note that in absence of other features saying
> otherwise, SOAP Processing Model mandates that the
> header is removed by forwarding intermediaries. Your
> text seems to imply the nodes may freely choose
> otherwise, without reference to active intermediaries
> which is what those nodes would become.

This is a good discussion, but I think I disagree with the analysis above. 
 Section 2.7.1 includes what I think is the crucial text [1]:

"A SOAP header block is said to be reinserted if the
processing of that header block determines that the
header block is to be reinserted in the forwarded
message.

This clearly says that the processing rules for a header block can 
determine whether to reinsert, even in the case of a forwarding 
intermediary (I think it's clearly implied that we're talking about 
forwarding intermediaries here.)  We are writing the specification for the 
processing of this header, so we have permission and indeed SHOULD in my 
opinion indicate the rules for reinsertion as a result of such processing. 
 My note was intended to offer two options for such a Representation 
Header processing  specification.  I really don't think that suppying such 
rules makes the node an active intermediary;  on the contrary, I think 
we're doing what the SOAP Rec tells you to do when specifying the 
processing of a header at a forwarding intermediary.  Make sense?

Thanks.

Noah

[1] http://www.w3.org/TR/soap12-part1/#relayable

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Tuesday, 23 March 2004 10:40:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:16 GMT