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 00:36:43 UTC