- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Fri, 06 Sep 2002 10:23:36 +0200
- To: Marc Hadley <marc.hadley@sun.com>
- CC: noah_mendelsohn@us.ibm.com, Martin Gudgin <mgudgin@microsoft.com>, W3C Archive <www-archive@w3.org>
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 04:23:57 UTC