[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Issue#10: 2.1.2 Message Package
correct which is why I raised the issue:) Martin W Sachs wrote: > Putting "may" in lower case does not solve anything. RFC2119 does not > specify that the magic words be in upper case. > > Regards, > Marty > > ************************************************************************************* > > Martin W. Sachs > IBM T. J. Watson Research Center > P. O. B. 704 > Yorktown Hts, NY 10598 > 914-784-7287; IBM tie line 863-7287 > Notes address: Martin W Sachs/Watson/IBM > Internet address: mwsachs @ us.ibm.com > ************************************************************************************* > > > > Christopher Ferris <chris.ferris@sun.com> on 02/13/2002 02:56:34 PM > > To: ebxml-msg@lists.oasis-open.org > cc: > Subject: [ebxml-msg] Issue#10: 2.1.2 Message Package > > > > David's comments in the updated issues list he > distributed disagreed with the proposed editorial > change. > > My rationale for changing "may" to "can" in this context is > to remove any possible confusion w/r/t interpretation > of our intent here. RFC2119 reserves the word MAY for > reflecting optionality. In the context here, it is not > expressing optionality but choice or preference. > > I will grant that we've used lower case "may" in this > context, but this will (IMO) lead only to confusion. > We've been around the block on this issue of RFC2119 > usage a number of times. I think it critical that we > leave no room for doubt especially as not all readers > of the specification will have english as their first > language and may not catch subtleties. > > Line 510 currently reads: > "Implementations MUST support non-multipart messages, which > may occur when there is no ebXML payload. An ebXML message may > be sent either as a plain SOAP message or as a [SOAPATTACH] > multipart message with one body part." > > Our intent here is to require that either form be supported > by a receiving node, but that a sending node MAY choose which > packaging mechanism to use. What this amounts to is that > there are really two perspectives at play here, sending > and receiving ebMS nodes. The sending MSH node actually > *does* have an OPTION, from an implementation perspective, > as it can choose to package the message either way, where as > the receiving MSH MUST be prepared to process either form. > > I would actually suggest that this issue be addressed > not solely by changing the "may" to a "can" by by being > explicit as to what we mean here. I would therefore > propose that we replace the paragraph at line 510 in > David's draft with the following text: > > An ebMS MSH implementation MAY package a message containing > no application payload, as in the case of an Acknowledgment > message carrying no application payload, either as a > multipart/related message as described in [SOAPATTACH] containing a > single body part, or as described in [SOAP] using the text/xml > MIME content-type. An ebMS MSH implementation MUST be capable of > processing received messages that arrive in either form. > > Cheers, > > Chris > > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC