RE: Issue 221 resolution text change

I understand the concern with the sub-optimal wording.  What I think we're 
trying to say is:

* You really, really MUST NOT ever insert a PI into new content in a SOAP 
message (I.e. content from the initial sender, or newly inserted headers 
at an intermediaries.  Thus, if you ever receive a PI, the message is in 
error --- somebody upstream has a bug.

* For reasons of efficiency, we do not absolutely require that an 
intermediary detect and avoid propagating all such errors. 

* Presumably, a correctly written ulitmate reciever MUST eventually detect 
such errors, and an intermediary actually processing a header MUST detect 
such errors.  The only lattitude is in relaying content that's not 
actively re-inserted.

Make sense?  I'm open to any wording that conveys the above, and I agree 
that the proposals that Marc and I have offered could probably be 
improved.  Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Martin Gudgin" <mgudgin@microsoft.com>
09/06/2002 04:37 AM

 
        To:     "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "Marc Hadley" 
<marc.hadley@sun.com>
        cc:     <noah_mendelsohn@us.ibm.com>, "W3C Archive" <www-archive@w3.org>
        Subject:        RE: Issue 221 resolution text change


JJM,

This is exactly the point I was making when I initially questioned the
resolution. But I decided that seen as the 'obvious' fix was not on the
table, I could ( just about ) live with Noah's formulation.

I still think its busted really.

Gudge

> -----Original Message-----
> From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr] 
> Sent: 06 September 2002 09:24
> To: Marc Hadley
> Cc: noah_mendelsohn@us.ibm.com; Martin Gudgin; W3C Archive
> Subject: Re: Issue 221 resolution text change
> 
> 
> I'm sorry to spoil the agreement, but I find the paragraph 
> really, really bizarre. First, we say MUST NOT, which to me 
> implies never, never send a PI. But then we add: well, take it 
> easy, we're not really serious, you can use PIs if you really 
> want to. Am I getting something wrong? Is a MUST NOT really not 
> that strong? Have we not created an untestable assertion (MUST 
> NOT/MAY)?
> 
> Also, I think one of the initial use cases was that of an initial 
> sender forwarding XML data, which could contain PIs, and over 
> which the sender had no control. Are we not considering this use 
> case any longer? Did I miss something?
> 
> I'm easy about PIs; but I tend to find it difficult for the spec 
> to remain undecided.
> 
> Jean-Jacques.
> 
> Marc Hadley wrote:
> > OK, how about the following:
> > 
> > "SOAP messages sent by initial SOAP senders MUST NOT contain 
> > processing instruction information items. SOAP 
> intermediaries MUST NOT 
> > insert processing instruction information items in SOAP 
> messages they 
> > relay. SOAP receivers receiving a SOAP message containing a 
> processing 
> > instruction information item SHOULD generate a SOAP fault with the 
> > Value of Code set to "env:Sender". However, in the case where 
> > performance considerations make it impractical for an 
> intermediary to 
> > detect processing instruction information items in a message to be 
> > relayed, such intermediaries MAY leave the processing instruction 
> > information items unchanged in the relayed message."
> > 
> > Does that nail it ?
> > 
> > Marc.
> > 
> >>
> > On Thursday, Sep 5, 2002, at 12:39 US/Eastern,
> > noah_mendelsohn@us.ibm.com wrote:
> > 
> >> I think this is generally good, but I'm uncomfortable with 
> the change 
> >> to initial SOAP sender.  An intermediary can wind up 
> sending PI's in 
> >> at least two ways, potentially:
> >>
> >> * In relayed content, for which we've agreed to allow wiggle room
> >> * In newly inserted headers, for which we allow no such lattitude.
> >>
> >> I therefore think that we need to go back to something like:
> >>
> >> Except in the special case of content relayed by 
> intermediaries (see 
> >> below), SOAP messages sent by SOAP senders MUST NOT contain 
> >> processing instruction information items.
> >>
> >> ...or some such.  If one wanted to be even more explicit, 
> at the risk 
> >> of being verbose, one could also go with:
> >>
> >> "However, in the case where performance considerations make it
> >> impractical
> >> for an
> >> intermediary to detect processing instruction information 
> items in a
> >> message to be relayed, such intermediaries MAY leave the processing
> >> instruction information items unchanged in the relayed 
> message.   SOAP 
> >> intemediaries
> >> MUST NOT include PIs in headers inserted by the intermediary."
> >>
> >> So, I really want to make it clear that there's no wiggle room for 
> >> allowing PI's in new content by any sender, otherwise the 
> whole change
> >> we've just made is a waste of time.   Otherwise, I like 
> what you've done,
> >> and would be happy with any reasonable variation that 
> deals with the 
> >> remaining concern.  Many thanks.
> >>
> >> ------------------------------------------------------------------
> >> Noah Mendelsohn                              Voice: 1-617-693-4036
> >> IBM Corporation                                Fax: 1-617-693-8676
> >> One Rogers Street
> >> Cambridge, MA 02142
> >> ------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Marc Hadley <marc.hadley@sun.com>
> >> 09/05/2002 10:02 AM
> >>
> >>
> >>         To:     noah_mendelsohn@us.ibm.com
> >>         cc:     Martin Gudgin <mgudgin@microsoft.com>, 
> Jean-Jacques 
> >> Moreau
> >> <moreau@crf.canon.fr>, W3C Archive <www-archive@w3.org>
> >>         Subject:        Issue 221 resolution text change
> >>
> >>
> >> Noah,
> >>
> >> I have incorporated the resolution to issue 221. In doing 
> so I have 
> >> modified your proposed text as follows:
> >>
> >> Original:
> >> "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."
> >>
> >> New:
> >> "SOAP messages sent by initial SOAP senders MUST NOT contain 
> >> processing instruction information items. SOAP receivers 
> receiving a 
> >> SOAP message containing a processing instruction information item 
> >> SHOULD generate a SOAP fault with the Value of Code set to 
> >> "env:Sender". However, in the case where performance 
> considerations 
> >> make it impractical for an intermediary to detect processing 
> >> instruction information items in a message to be relayed, such 
> >> intermediaries MAY leave the processing instruction 
> information items 
> >> unchanged in the relayed message."
> >>
> >> The main changes were associated with use of terminology 
> from section
> >> 1.4:
> >>
> >> (i) envelope->message to make sure people don't think they 
> can prefix 
> >> the envelope with a PIII since that is not 'in' the envelope
> >>
> >> (ii) use of 'initial SOAP sender' instead of 'SOAP sender but not 
> >> intermediaries'
> >>
> >> (iii) expansion of PI to processing instruction information item.
> >>
> >> (iv) reference to sender fault made consistent with the 
> rest of the 
> >> spec.
> >>
> >> I hope you agree that the changes do not affect the semantics or 
> >> general spirit of the issue resolution. Please let me know if you 
> >> disapprove.
> >>
> >> Regards,
> >> Marc.
> >>
> >> --
> >> Marc Hadley <marc.hadley@sun.com>
> >> XML Technology Center, Sun Microsystems.
> >>
> >>
> >>
> >>
> >>
> > --
> > Marc Hadley <marc.hadley@sun.com>
> > XML Technology Center, Sun Microsystems.
> > 
> 
>

Received on Friday, 6 September 2002 13:33:06 UTC