Re: Issue 221 resolution text change

I think it's essentially fine.  One word minor suggested change, if you 
like it, otherwise stick with what you have.  This changes "the proc. 
insts." to "such proc. insts", more clearly indicating that it's the 
inbound ones that may survive.  Take your choice.  Many thanks.

"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 such processing
instruction information items unchanged in the relayed message."


------------------------------------------------------------------
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 12:51 PM

 
        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:        Re: Issue 221 resolution text change


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 Thursday, 5 September 2002 13:52:52 UTC