[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
David, The phrase "These words are often capitalized" in RFC2119 abstract is not a normative statement. It does not say "the words in question SHALL be capitalized if they have the meanings defined in RFC2119". I see nothing in the paragraphs numbered 6 and 7 that bears on this question. Even the use of all caps in RFC2119 does not prevent a vendor from interpreting the lower case forms of these words as having the RFC2119 meanings. If you want to be certain that implementers do the right thing, use the RFC2119 words as defined there and only as defined there. Note that the issue is only with MAY and OPTIONAL. All of the other RFC2119 words may safely be used as ordinary words without confusing vendors about implementation reuqirements. For example, "The Foo element shall always be used" means the same thing whether it is interpreted as guidance to a user or guidance to an implementer. 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 ************************************************************************************* David Fischer <david@drummondgroup.com> on 02/13/2002 04:44:44 PM To: Martin W Sachs/Watson/IBM@IBMUS, Christopher Ferris <chris.ferris@sun.com> cc: ebxml-msg@lists.oasis-open.org 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 meaning. David. -----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. 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> ---------------------------------------------------------------- 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