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: Mon, 26 Aug 2002 08:01:06 -0400
To: "Noah Mendelsohn" <noah_mendelsohn@us.ibm.com>
Cc: xml-dist-app@w3.org, xml-dist-app-request@w3.org
Message-ID: <OF69927EF9.D8868EFE-ON85256C21.004186A2-85256C21.0041EE0D@rchland.ibm.com>
I could live with this wording. I think' XXXX fault' would be 'Sender 
fault'.

Cheers,

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/25/2002 12:10:57 PM:

> 
> I think this is in the right general direction, but I think the word 
> "ignore" in the original is problematic and should not be reintroduced. 
> For example, we are allowing (discouraging) an intermediary to relay 
PIs. 
> Has that intermediary "ingored" those PIs?  I suggest we not get into 
> that, but rather spell out:
> 
> 
> 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. 
> 
> I think that's closer to how we want to deal with this.  Thanks.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> "Christopher B Ferris" <chrisfer@us.ibm.com>
> Sent by: xml-dist-app-request@w3.org
> 08/25/02 08:56 AM
> 
> 
>         To:     xml-dist-app@w3.org
>         cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        RE: Problem with resolution of Issue 221
> 
> 
> 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 
> send. 
>         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 
> fault. 
> 
> This would absolve any intermediary from being required to strip out any 

> PIs 
> 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" 
> principle. 
> 
> 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. 
> 
> Cheers, 
> 
> 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 
> anything 
> > 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 

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

> NOT 
> > 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>, 
> <Mike.Champion@SoftwareAG-USA.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 Monday, 26 August 2002 08:01:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:11 GMT