- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Fri, 06 Sep 2002 17:28:47 +0200
- To: Marc Hadley <marc.hadley@sun.com>
- CC: Martin Gudgin <mgudgin@microsoft.com>, noah_mendelsohn@us.ibm.com, W3C Archive <www-archive@w3.org>
Yes, I guess there is a subtle difference. I still find it bizarre, though, that an intermediary must not insert a PI but may relay one. This seems a little inconsistent to me. Jean-Jacques. Marc Hadley wrote: > 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:28:40 UTC