W3C home > Mailing lists > Public > www-archive@w3.org > September 2002

Re: Issue 221 resolution text change

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 6 Sep 2002 12:29:58 -0400
To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
Cc: Marc Hadley <marc.hadley@sun.com>, Martin Gudgin <mgudgin@microsoft.com>, W3C Archive <www-archive@w3.org>
Message-ID: <OFF6B9852B.07ABA610-ON85256C2C.0058BADA@lotus.com>

Jean-Jacques Moreau writes:

>> I still find it bizarre, though, that 
>> an intermediary must not insert a PI but 
>> may relay one. This seems a little 
>> inconsistent to me.

Why?  I think the notion is that adding content is something that you do 
very explicitly, so doing it wrong is just an error and is never excused. 
The reason for allowing wiggle room at all is the thinking that relaying 
someone else's content is something that you sometimes want to do in a 
sort of black-box highly optimized manner.  Think of a hardware or 
microcode implementation that makes sure the role attributes don't match 
the intermediary, then just cut-through streams the header until the 
end-tag is matched.  (Perhaps an over-simple example, but I think the 
spirit is right.)  There's no reason in the world that such an 
intermediary should be granted license to _insert_ erroneous content.

So, I think the approach taken at the F2F is at least plausible, if not 
necessarily ideal. 

<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 last sentence is an innovation, but I think it makes sense.  Does the 
above help?

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------
Received on Friday, 6 September 2002 12:31:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:22 GMT