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

RE: Issue 221 resolution text change

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 9 Sep 2002 14:23:02 -0400
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Cc: "Marc Hadley" <marc.hadley@sun.com>, "Martin Gudgin" <mgudgin@microsoft.com>, "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "W3C Archive" <www-archive@w3.org>
Message-ID: <OFB8D8CDAC.8AC1B06E-ON85256C2F.0062BD32@lotus.com>

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 14:24:39 GMT

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