W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2002

RE: Problem with resolution of Issue 221

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Sun, 25 Aug 2002 08:56:35 -0400
To: xml-dist-app@w3.org
Message-ID: <OF0D95AA95.B7629823-ON85256C20.0042DF56-85256C20.00470289@rchland.ibm.com>
So, possibly it is the verb 'send' that is at the core of the issue?

If we were to change the resolution text to read something like:
        SOAP senders MUST NOT introduce PIIIs into the SOAP messages they 
        SOAP receivers SHOULD generate a fault when receiving SOAP 
messages containing PIIIs.

I would also suggest adding back the original text:
        A SOAP receiver MUST ignore processing instruction information 
items in SOAP messages that it receives.
but I might suggest that it be tweaked to read:
        A SOAP receiver MUST ignore processing instruction information 
items in SOAP messages that it receives
        except for purposes of detection and subsequent generation of a 

This would absolve any intermediary from being required to strip out any 
before forwarding and would preserve what I believe to be the original 
intent of the WG
which was following the "be conservative in what you send and liberal in 
what you receive"

Thus,  a SOAP receiver (intermediary or ultimate recipient) would be 
conforming to the
spec if it simply ignored any PIIIs. It would also be conformant if it 
detected them and
generated a fault.


Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

xml-dist-app-request@w3.org wrote on 08/24/2002 06:31:16 PM:

> Well, I'm not so sure regarding the sender.  We don't really say 
> about the steps leading to the preparation of the envelope.  We just say 

> what is SHOULD/MUST/SHOULD NOT/MUST NOT contain.  I would rather not get 

> into a two step description along the lines of:  you might erroneously 
> in a PI but then you should check to see whether you did.  I think we 
> should just say:  senders MUST NOT send PIs,  Intermediaries  detect and 

> remove PIs.  Receivers SHOULD fault when receiving PIs.  Note, however, 
> that intermediaries MAY but need not detect (and fault) when a PI is 
> received in a message to be relayed;  this dispensation is provided 
> primarily to facilitate the implementation of high performance 
> intermediaries in which such checking may be impractical.  Such 
> intermediaries MAY relay PIs received in the inbound message (but MUST 
> introduce additional or altered PIs.)
> ------------------------------------------------------------------
> 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>
> 08/23/02 08:13 PM
>         To:     <noah_mendelsohn@us.ibm.com>, 
>         cc:     <xml-dist-app@w3.org>
>         Subject:        RE: Problem with resolution of Issue 221
> I agree with this but would also go further in stating that this seems
> to apply to any SOAP sender, regardless of whether it is the initial
> sender or an intermediary sender: for performance reasons, it would be
> really bad for a sender to first go through the message and check for
> PIs before sending.
> If we want to say anything for PIs then I think it should be SHOULD.
> FWIW, I would be happy not to say anything.
> Henrik
> >My strong feeling is that intermediaries should not be 
> >required to do PI 
> >checking in situations where performance makes such detection 
> >a problem. I 
> >agree with Gudge that requiring it for one purpose but not 
> >another misses 
> >the point.  So, if the resolution to 221 seems inconsistent 
> >when viewed 
> >from that perspective, then I think we need to get the WG to 
> >clarify.  My 
> >recollection was that our intention was that detection and 
> >rejection in a 
> >receiver was to be on a best effort basis, but I could be 
> >wrong.  Thanks.
Received on Sunday, 25 August 2002 08:57:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:21 UTC