W3C home > Mailing lists > Public > xmlp-comments@w3.org > January 2004

New MTOM Issue: SOAP processing model and Representation Header

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 28 Jan 2004 13:42:55 -0500
To: xmlp-comments@w3.org
Message-ID: <OFB11B2DEC.A9372CA8-ON85256E29.00665462@lotus.com>





As requested on the group telcon a few minutes ago, this is a request to
open a new issue relating to representation headers.  This relates in part
to issue 442 [1] and to the proposed resolution at [2].

The proposed resolution must be augmented, IMO, to describe its use of the
SOAP processing model.   I believe this will result in our specfying some
rules for when a conforming implementation may use the representation
header to resolve a retrieval request for a resource.

Consider and example of an original sender, final destination and two
intermediaries:

S -> A -> B-> D

If a representation header is addressed to the final destinatino D (default
SOAP role), should a retreival request at A use it?  I would think not, as
that would be circumventing the usual mustUnderstand mechanisms of SOAP.

If I want to specifically cause two different representations, of the same
media type for the same resource, to be sent to A and B respectively, can I
safely use multiple representation headers that differ in their soap:roles
to do this?  I would think so.

In any case, I believe we must decide on and document the rules we want.
The current proposal [2] refers a bit to mustUnderstand, but doesn't really
cover the rules in detail.  I propose that we open a new issue to track
this question.  Thank you.

Noah

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x442
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2004Jan/0065.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Wednesday, 28 January 2004 13:43:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:08 UTC