Re: Issue 221 resolution text change

I agree that its busted, I wasn't championing a particular approach 
just trying to make sure the paragraph captured the (admittedly 
awkward) resolution of the WG in a crisp nailed down manner.

FWIW, I don't think the new text says "you can use PIs if you want to". 
It says message content originators MUST NOT use PIs but intermediaries 
don't have to check for them if they can't be bothered. There's a 
difference I think.

Marc.

On Friday, Sep 6, 2002, at 04:37 US/Eastern, Martin Gudgin wrote:

> 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.
>>>
>>
>>
>
>
--
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.

Received on Friday, 6 September 2002 11:22:26 UTC