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>
>