RE: Issue 221 resolution text change

Noah,

Sorry for not being clear, I was commenting on the latest proposal that
you made yesterday, which was not part of your comments on my proposal.
In doing so, I made the following observations:

1) Even though I wasn't at the f2f and while I understand what the
proposal is trying to address, it seems to me to have moved so far away
from the outcome of the f2f that I don't believe it is appropriate to
use the notion that it is in the spirit of the f2f resolution. Even
though this may indeed be the case, this is no more obvious than for
other proposals.

2) The proposal started with a performance consideration regarding
intermediaries but has turned into imposing different requirements on
SOAP receivers acting as intermediaries vs. receivers acting as ultimate
destinations. Similarly, it has introduced a corresponding difference on
the sending side. While I don't want to be disrespectful in any way of
the effort that have gone into this, I believe, this is a significant
change and is going in the wrong direction.

Rather than throwing more fine-tunings on the table, however, it may be
beneficial to take a step back and review what it actually is we want to
do. I don't think there is any disagreement in saying that PIs have no
role in SOAP processing. Therefore we want to make it very clear that
PIs are NOT desired in SOAP messages. However, the WG has also
acknowledged that there are cases where it is both impractical or would
cause significant overhead to actively enforce this policy on both the
sending and the receiving side.

Clearly we all want simple and unambiguous rules for describing this
trade-off. My only point is that I think the SOAP processing model works
as-is and we should leverage it without introducing special cases and
exceptions. I am fine with Gudge's proposal that we simply say that they
are ignored and have also stated that I can live with the proposal that
was agreed upon at the last WG telcon. Other than that I am open to
suggestions.

Does this sound reasonable?

Henrik

>-----Original Message-----
>From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
>Sent: Monday, September 09, 2002 21:35
>To: Henrik Frystyk Nielsen
>Cc: Marc Hadley; Martin Gudgin; Jean-Jacques Moreau; W3C Archive
>Subject: RE: Issue 221 resolution text change
>
>
>I'm a little confused as to which proposals you think I have 
>put on the 
>table.   The one I have proposed that I believe is in the 
>spirit of the 
>f2f resolution is:
>
><yetAnotherProposal>
>SOAP messages MUST not contain XML Processing instructions.  
>Accordingly, 
>initial SOAP senders MUST NOT include processing instructions 
>in a SOAP 
>message, and SOAP intermediaries MUST NOT insert into a SOAP 
>message new 
>headers containing processing instructions.
>
>An ultimate SOAP recevier that receives a message containing 
>one or more 
>Processing Instructions MUST fault with a SENDER fault.   A SOAP 
>intermediary receiving a message containing one or more Processing 
>Instructions SHOULD fault with a sender fault, but  in 
>situations where 
>performance considerations make such fault detection 
>impractical at the 
>intermediary,  the intermediary MAY instead retain the 
>received Processing 
>
>Instructions in the relayed message.  If the intermediary 
>chooses not to 
>fault, it MUST retain all the Processing Instructions in the relayed 
>message (the intention being that a downstream intermediary or 
>ultimate 
>receiver will eventually detect the error and fault). 
></yetAnotherProposal>
>
>The others in my more recent notes were my attempts to help 
>you tune your 
>counter proposal, and to point out areas where it still needs 
>work.  I was 
>doing that because you still seem interested in that option.  I still 
>recommend the above, which does not distinguish header and 
>body from other 
>content.  Actually, I would fine tune the above as:
>
><yetAnotherProposal>
>SOAP messages MUST not contain XML Processing instructions.  
>Accordingly, 
>initial SOAP senders MUST NOT include processing instructions 
>in a SOAP 
>message, and SOAP intermediaries MUST NOT insert into a SOAP 
>message new 
>headers containing processing instructions.
>
>An ultimate SOAP recevier that receives a message containing 
>one or more 
>Processing Instructions MUST fault with a SENDER fault.   A SOAP 
>intermediary receiving a message containing one or more Processing 
>Instructions SHOULD fault with a sender fault, but  in 
>situations where 
>performance considerations make such fault detection 
>impractical at the 
>intermediary,  the intermediary MAY instead retain the 
>received Processing 
>
>Instructions in the relayed message If the intermediary chooses not to 
>fault, it MUST retain all the Processing Instructions in the relayed 
>message, except within headers that are removed and not 
>reinserted; such Processing Instructions MUST be removed along 
>with the header.
>NOTE: retained processing instructions are likely to result in 
>a fault by a downstream intermediary or by the ultimate 
>receiver. </yetAnotherProposal>
>
>------------------------------------------------------------------
>Noah Mendelsohn                              Voice: 1-617-693-4036
>IBM Corporation                                Fax: 1-617-693-8676
>One Rogers Street
>Cambridge, MA 02142
>------------------------------------------------------------------
>
>
>
>

Received on Tuesday, 10 September 2002 11:28:17 UTC