OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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

Marty, the intent, even within 2119, is that there be a difference between MUST
and must.  It is this intent which is carried throughout the RFC body and we
make that same distinction.

While 2119 does not actually use the word *uppercase* it certainly implies this
(see paragraph 6 and 7) and the standards bodies have taken this explicit


-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, February 13, 2002 2:55 PM
To: Christopher Ferris
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Issue#10: 2.1.2 Message Package

Putting "may" in lower case does not solve anything.  RFC2119 does not
specify that the magic words be in upper case.



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

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.



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