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

RE: Issue 221 resolution text change

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Mon, 9 Sep 2002 09:52:09 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D08C50185@red-msg-07.redmond.corp.microsoft.com>
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>

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
	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

Henrik Frystyk Nielsen

>-----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 
>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 12:52:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:53 UTC