RE: Issue 221 resolution text change

Noah,

Thanks for your reply, I appreciate your comments. FWIF, as I said on
last week's telcon, I can live with the resolution [1] although I am not
happy about the inconsistencies and fuzziness that it brings: 

"Except in the special case of intermediaries (see below), envelopes
transmitted by SOAP senders MUST NOT contain PIs. Receivers (including
intermediaries)  receiving an envelope with a PI SHOULD fault with a
XXXX fault.  However, in the case where performance considerations make
it impractical for an intermediary to detect PIs in a message to be
relayed, such intermediaries MAY leave the PIs unchanged in the relayed
message."

However, the text discussed today seems to have come quite some ways
from this proposal as it has introduced a distinction between SOAP
header blocks and SOAP body not discussed in the text above and in doing
so removed part of the proposal that addresses PIs not included in SOAP
header blocks or the SOAP body.

Note that this may still be completely within the realm defined by the
expectations of the WG but from an editorial POW I think it at least
warrants WG discussion, especially as the text above seems to be already
departed significantly from the issue resolution generated at the f2f
[2]:

"SOAP sender MUST NOT send a message containing Processing Instructions
Information Items(PIIIs). SOAP receivers (including intermediaries)
receiving a message with a PIII SHOULD generate an error. Whenever
possible, receivers should detect PIIIs and fault. The above rule says
SHOULD (as opposed to MUST) only to allow for implementations in which
performance considerations outweigh the desirability of detecting 
erroneous messages."

That said, I actually don't think there is much difference between the
proposal that I put forward and your recent proposal. Interestingly
enough they seem to have moved significantly closer over the last few
iterations.

You correctly point out that my proposal is not clear as to whether a
SOAP receiver MAY/SHOULD/MUST fail if it sees a PI as part of a SOAP
header block or the body. However, reading the text "Receivers
(including intermediaries)  receiving an envelope with a PI SHOULD fault
with a XXXX fault.", it doesn't seem to provide any more guidance for
SOAP receivers other than for SOAP receivers acting as intermediaries.

As long as we are clear on *where* we allow this slack I am actually ok
with not saying anything. The reason is that at least a plausible
understanding of the SOAP 1.2 spec is that a SOAP processor has nothing
in particular to say about data within the header blocks and body if not
targeted at that receiver other than the contents is significant to the
party processing that data. Properly processing the contents of header
blocks and the body have always been somewhat supplemental to the basic
SOAP processing model.

In other words, I think we have started down the path of your
alternative 2 feeling that it is a slippery slope while it in fact may
be completely grounded in section 2.6.

Thank you,

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Aug/0034.html

>-----Original Message-----
>From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
>Sent: Monday, September 09, 2002 11:23
>To: Henrik Frystyk Nielsen
>Cc: Marc Hadley; Martin Gudgin; Jean-Jacques Moreau; W3C Archive
>Subject: RE: Issue 221 resolution text change
>
>
>The only problem I have with your proposed resolution is that it was 
>explicitly considered and rejected by the f2f, and I'm not 
>sure we have 
>the new information needed to reopen.  I've always stated that I'm 
>semi-neutral on whether we take the route you suggest, or the 
>f2f route, 
>so I don't much care in principle.  Speaking as an editor, I 
>think we have 
>to come as close as we can to finding a coherent formulation 
>of what the 
>f2f requested.  If that embodies any significant functional tuning, we 
>should at least mention it on distApp so someone can complain, 
>and if we 
>thing the f2f resolution is too broken we should indeed request 
>reconsideration by the WG.  My earlier notes proposing 
>formulations were 
>in the spirit of:  how can I write something that says what 
>the f2f asked 
>us to say, but fills in a few of the details that seemed to be 
>causing a 
>bit of discomfort. 
>
>So, are you suggesting that you are sufficiently unhappy with the f2f 
>resolution that we should bring it back to the WG?  Speaking 
>just as an 
>editor, I don't really see the need, as I think some of the 
>formulations 
>offered within the last few days are essentially embodiments 
>of the f2f 
>decision, and I think they do work.  Whether I think they're 
>ideal is a 
>separate question (as I say, I think they're OK, but not necessarily 
>better than the alternative...I'm actually not that happy with 
>either one, 
>and lean just slightly toward the f2f rules.
>
>Also, if we do go with your suggestion, I propose the 
>following change of 
>the word "that" to "which":
>
><original>
>"Unless explicitly stated otherwise, a SOAP message MUST NOT 
>contain PIs and a SOAP receiver MUST generate an env:Sender 
>fault if it receives a SOAP message containing PIs. The only 
>exception to this rule is for SOAP header blocks and SOAP Body 
>that SHOULD NOT contain PIs. PIs included in a SOAP header 
>block or the SOAP body are considered significant and MUST be 
>forwarded by intermediaries relaying that message." 
></original> <slightRevision> "Unless explicitly stated 
>otherwise, a SOAP message MUST NOT contain PIs and a SOAP 
>receiver MUST generate an env:Sender fault if it receives a 
>SOAP message containing PIs. The only exception to this rule 
>is for SOAP header blocks and SOAP Body,  which SHOULD NOT 
>contain PIs. PIs included 
>in
>a SOAP header block or the SOAP body are considered 
>significant and MUST be forwarded by intermediaries relaying 
>that message." </slightRevision>
>
>If we say "The headers that should not contain pi's" that 
>implies:  some 
>should, some shouldn't, and I'm talking about the ones THAT should not.
>
>If we say "The headers, which SHOULD contain pi's,...",   That 
>says:  "I'm 
>talking about headers, and they should not contain PIs.  I think even 
>clearer might be:
>
><lessslightRevision>
>"Except as described here, a SOAP message MUST NOT contain PIs 
>and a SOAP receiver MUST generate an env:Sender fault if it 
>receives a SOAP message containing PIs;  the only exception to 
>this rule is for SOAP header blocks and the SOAP Body: 
>header blocks and the SOAP body SHOULD NOT contain PIs among 
>their descendants.
>If such header or body PIs are present, however, they are considered 
>significant and MUST
>be forwarded by intermediaries relaying that message." 
></lessslightRevision>
>
>Actually, now that I read all of these, they require yet more tuning I 
>think:  they don't say whether you MAY, SHOULD or MUST NOT 
>fault if you 
>receive a header or body entry with a PI.  We say they SHOULD NOT be 
>there.  That tends to mean I can fault on them if I like.  
>Then we say the 
>intermediary MUST forward. 
>
>I would have thought that to get to where you want to go, 
>Henrik, we would 
>need one of the following choices: 
>
>(alternative 1): a SOAP node, including an intermediary, 
>SHOULD fault when 
>it receives a message with a PI in a header or body, but if an 
>intermediary chooses not to and therefore relays the message, it MUST 
>treat as significant and forward the PIs. 
>
>(alternative 2):  a SOAP node processing (in the sense of 
>chapter 2.6) a 
>header entry targeted to it (or body at ultimate receiver) MAY 
>fault with 
>a sender fault if that entry contains a PI that is not 
>appropriate given 
>the specficiation for the header or body in question;  nodes MUST NOT 
>fault based on the presence of PIs in header or body entries 
>not processed 
>by that node.  An intermediary relaying such unprocessed 
>header or body 
>entries MUST treat as significant and forward the PIs.
>
>(note also:  this needs to be recast in terms of information items, I 
>think.) 
>
>Anyway, I'm still not convinced we've got a good reason to reopen the 
>decision of the f2f, but if you want to it's OK with me.  I do 
>think that 
>some more detail work is needed to get your proposal right, 
>and I hope the 
>above at least helps lay out the alternatives.  Thanks.
>
>------------------------------------------------------------------
>Noah Mendelsohn                              Voice: 1-617-693-4036
>IBM Corporation                                Fax: 1-617-693-8676
>One Rogers Street
>Cambridge, MA 02142
>------------------------------------------------------------------
>
>
>
>
>
>
>
>"Henrik Frystyk Nielsen" <henrikn@microsoft.com>
>09/09/2002 12:52 PM
>
> 
>        To:     <noah_mendelsohn@us.ibm.com>, "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>
>        Subject:        RE: Issue 221 resolution text change
>
>
>
>Jean-Jacques, thanks for adding me back in!
>
>In a previous mail in a related thread on xml-dist-app it was 
>pointed out that the f2f resolution was clear and unambiguous 
>but the dialog below seems to indicate that this is not the 
>case. Either we say that the f2f resolution was broken or we 
>don't. If it is broken we owe it to the WG to say so and move 
>the discussion to xml-dist-app. 
>
>That said, making conformance requirements but then add 
>opt-outs because of hardware or microcode implementation 
>optimizations seems bizarre and hard to defend. Writing a 
>specification is about getting unambiguous reactions 
>regardless of the implementation. Personally I am not fond of 
>PIs but bending processing rules seems even less appealing.
>
>In addition, I don't believe the argument that performance 
>optimizations are any different for SOAP receivers acting as 
>ultimate destinations than they are for receivers acting as 
>intermediaries.
>
>Having a situation where one conformant SOAP receiver 
>generates a SOAP fault and another conformant SOAP receiver 
>doesn't will damage interoperability and erode people's trust 
>in our specification. 
>
>In general, we use MUST and MUST NOT requirements to enforce 
>behavior that is essential in order to produce an 
>interoperable system. The opt-out seems to indicate that we in 
>fact do not have such a case, otherwise we would be forced to 
>say that messages MUST NOT contain PIs and receivers MUST 
>fail. I don't believe it is sufficient to say that the message 
>will fail eventually as each SOAP node must be able to process 
>a message independently of other SOAP nodes.
>
>I think the fundamental problem is that we have different 
>expectations about PIs in places where they may interact with 
>the SOAP processing like before the envelope, between header 
>blocks, etc. as compared to within SOAP header blocks and 
>within the SOAP body. The discussion below only mentions the 
>issue within the SOAP Body or within SOAP header blocks but 
>one could argue that this in fact doesn't address the issue 
>that was initially brought up:
>
>                 3rd paragraph: We are not clear about whether 
>intermediaries
>                 MUST, SHOULD, MAY, SHOULD NOT or MUST NOT 
>forward PIs -
>                 only that a message SHOULD NOT contain them.
>
>Forwarding is defined in terms of SOAP body and SOAP header 
>blocks as this is what a SOAP intermediary may relay. I would 
>suggest that therefore state something like this: 
>
>"Unless explicitly stated otherwise, a SOAP message MUST NOT 
>contain PIs and a SOAP receiver MUST generate an env:Sender 
>fault if it receives a SOAP message containing PIs. The only 
>exception to this rule is for SOAP header blocks and SOAP Body 
>that SHOULD NOT contain PIs. PIs included in a SOAP header 
>block or the SOAP body are considered significant and MUST be 
>forwarded by intermediaries relaying that message."
>
>I believe this covers the cases where an intermediary relays a 
>message containing PIs in the relayed SOAP body or SOAP header 
>blocks while providing unambiguous SOAP processing semantics 
>for when to generate a fault.
>
>Henrik Frystyk Nielsen
>mailto:henrikn@microsoft.com
>
>>-----Original Message-----
>>From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
>>Sent: Monday, September 09, 2002 07:49
>>To: Jean-Jacques Moreau
>>Cc: frystyk; Marc Hadley; Martin Gudgin; W3C Archive
>>Subject: Re: Issue 221 resolution text change
>>
>>
>>Jean Jacques Moreau writes;
>>
>>>> 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?
>>
>>Thanks, looks like we're closing in on a resolution.
>>
>>I don't think there's a problem with the processing model. We
>>clearly say 
>>you SHOULD fault if you receive a PI.  The reason for the 
>lattitude is 
>>essentially that you're relaying a header of no concern to 
>you and not 
>>looking at it closely.  I agree we need to be careful with the 
>>case where 
>>it was addressed to you, and we have to document the rules for 
>>that very 
>>clearly.  Actually, I think the ambiguity is only in the case 
>>where you 
>>chose to "reinsert" a header, as it's in the case of relayed 
>>content that 
>>we've given lattitude.  I think that in all other cases, 
>>including just 
>>removing  a header, we've said "SHOULD fault", end of story. 
>>In the case 
>>of a re-inserted header,  what about (at or near the sentence on 
>>re-inserting indistinguishable headers) "intermediaries SHOULD NOT 
>>reinsert headers that contained processing instructions but SHOULD 
>>instead, as described above(below), fault with a sender fault."
>>
>>In other words, you MUST not insert new headers with PIs, you
>>SHOULD NOT 
>>reinsert headers that were received with PIs, (and as we've 
>>more or less 
>>agreed) you SHOULD fault if you receive a message with a PI. 
>>How's that?
>>
>>------------------------------------------------------------------
>>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 17:07:09 UTC