Re: Issue 221 resolution text change

[Adding Henrik back.]

Ok, makes sense.

Re. your new last sentence, I like the spirit, but wouldn't an 
implication be that intermediairies can no longer remove headers 
targeted to them, when they contain PIs? Isn't this in 
contradiction with the processing model?

Jean-Jacques.

noah_mendelsohn@us.ibm.com wrote:
> 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 Monday, 9 September 2002 05:05:27 UTC