[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Issue 15: Use of the word OPTIONAL
David, If you can quote words in RFC2119 that prescribe (normative) that the keywords be in all caps, I might change my view. Merely observing that most people use the keywords in all caps when they mean them in the RFC2119 sense doesn't cut it. If you want to be sure that developers interpret the keywords as intended, you should expend the effort to avoid those words where the RFC2119 sense is not intended. The CPPA team has already cleaned up its document in this regard. 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/17/2002 01:14:51 PM To: ebXML Msg <ebxml-msg@lists.oasis-open.org> cc: Subject: RE: [ebxml-msg] Issue 15: Use of the word OPTIONAL Here are some more responses from the IETF concerning the RFC2119 key words. It seems some of these words were actually identified in earlier RFCs, particularly 1122 & 1123. RFC1123 also includes the "Robustness Principle" which I have cited before. "Be liberal in what you accept, and conservative in what you send" This says to me that we should ignore errors where we can and continue processing which is one of the things I have been arguing for, without much success. If we want true interoperability, we need to follow this principle. Regards, David. -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Friday, February 15, 2002 9:57 AM To: Martin W Sachs Cc: ebXML Subject: RE: [ebxml-msg] Issue 15: Use of the word OPTIONAL Marty, your characterization of the RFC2119 words gives me great pause. If you were correct, then we must erase these words from our vocabulary -- which certainly was not the intent of the RFC. I must strongly disagree concerning those words used in non-upper case (*must* as opposed to *MUST*). Standard usage in RFCs has been strictly with ALL CAPS. This has also been true throughout the development process of TRP/ebXML-MS and in all our discussions. However, just be sure, I went to the IETF and asked. The answers so far have been in favor of only ALL CAPS (see attached) invoking the definitions in 2119. They do acknowledge the confusion as you have cited. One interesting example was the word May -- the name of a month. Should this also be an RFC2119 key word? I'm sorry Marty, but the 2119 definitions only apply to ALL CAPS, unless we define otherwise in our specification. We have been VERY careful with these words and we have only used them (the ALL CAPS versions) when we really mean the 2119 definitions -- including our use of OPTIONAL. Regards, David. Note: If more responses come in from the IETF, I will be happy to forward them. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, February 12, 2002 4:59 PM To: David Fischer Cc: Doug Bunting; ebXML Subject: RE: [ebxml-msg] Issue 15: Use of the word OPTIONAL Conformance to RFC2119 means that the word OPTIONAL (or optional) means that an implementer does not have to provide that which is stated as optional. We don't want to confuse anyone into thinking that non-required elements or attributes do not have to be provided by implementers. Don't assume that implementers will catch on. The words in a specification have to be precise. 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/12/2002 05:36:53 PM To: Doug Bunting <dougb62@yahoo.com>, ebXML <ebxml-msg@lists.oasis-open.org> cc: Subject: RE: [ebxml-msg] Issue 15: Use of the word OPTIONAL I'm still not sure why it is not either definition and why this is not allowed? Section 1.1.1 says "An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality." Our spec simply defines *reduced functionality* as an Error of NotSupported. I'm not sure why this change is needed? We need to limit out discussions to essential changes. Regards, David -----Original Message----- From: Doug Bunting [mailto:dougb62@yahoo.com] Sent: Tuesday, February 12, 2002 4:09 PM To: ebXML Subject: [ebxml-msg] Issue 15: Use of the word OPTIONAL David has disagreed with Chris' statement that OPTIONAL is misused (according to 2119) in a number of contexts. The basic issue here is a conflict between something that may or may not appear in an instance of an ebXML message and something that must or may be implemented by a compliant ebMS system. In the specified uses of the word OPTIONAL, the first is meant but our document conventions (section 1.1.1) restricts us to using OPTIONAL only when the second is intended. I would strongly recommend making the change Chris suggested. thanx, doug ---------------------------------------------------------------- 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> Content-transfer-encoding: 7BIT Date: Sat, 16 Feb 2002 10:28:42 -0600 From: "Robert Elz" <kre@munnari.OZ.AU> Subject: Re: RFC2119 Keywords In-reply-to: <3C6D4AD1.1050802@isi.edu> Sender: <owner-ietf@ietf.org> To: "Joe Touch" <touch@ISI.EDU> Cc: "Bob Braden" <braden@ISI.EDU>, <sbrim@CISCO.COM>, <moore@cs.utk.edu>, <ietf@ietf.org> Message-id: <3098.1013876922@brandenburg.cs.mu.OZ.AU> X-UIDL: 6a6af0b71ef0b9758220c9e65d216659 MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=Windows-1252 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Loop: ietf@ietf.org References: <3C6D4AD1.1050802@isi.edu> <200202151709.RAA26668@gra.isi.edu> X-Authentication-warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Date: Fri, 15 Feb 2002 09:52:17 -0800 From: Joe Touch <touch@ISI.EDU> Message-ID: <3C6D4AD1.1050802@isi.edu> | Actually, MUST was first introduced in RFC1023 two years earlier :-) That's true, it appears there, but there it really is just a strange typographical convention (or shouting, for emphasis). It certainly isn't defined to mean anything special. In 1122/3 it was. (Further, 1122/1123 defined the terms in a very specific way, which was highly useful - quite the contrary of what most specifications using the things these days do). kre Content-transfer-encoding: 7BIT Date: Fri, 15 Feb 2002 11:52:17 -0600 From: "Joe Touch" <touch@ISI.EDU> Subject: Re: RFC2119 Keywords Sender: <owner-ietf@ietf.org> To: "Bob Braden" <braden@ISI.EDU> Cc: <sbrim@CISCO.COM>, <moore@cs.utk.edu>, <ietf@ietf.org> Message-id: <3C6D4AD1.1050802@isi.edu> X-UIDL: 1982a197e4d3b65bdd5d898b824ae7d3 MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=Windows-1252 Importance: Normal X-Accept-Language: en-us X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Loop: ietf@ietf.org References: <200202151709.RAA26668@gra.isi.edu> X-Authentication-warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Bob Braden wrote: > *> I don't believe the intent of 2119 was to change the meanings of > *> "should", "must", etc., in RFCs, but rather to define new terms > *> "SHOULD", "MUST", etc., with specific new meanings. > *> > *> Keith > *> > > Keith's statement was certainly correct when we first introduced the > capitalized words in the Host Requirements RFCs (1122,1123). Actually, MUST was first introduced in RFC1023 two years earlier :-) The list is as follows: 1023 MUST 1085 MAY 1122 SHOULD Joe Content-transfer-encoding: 7BIT Date: Fri, 15 Feb 2002 11:10:07 -0600 From: "Paul Hoffman / IMC" <phoffman@imc.org> Subject: Re: RFC2119 Keywords In-reply-to: <20020215081540.B1644@SBRIM-W2K> Sender: <owner-ietf@ietf.org> X-Sender: phoffman@mail.imc.org To: "Scott Brim" <sbrim@CISCO.COM>, "Ietf@Ietf. Org" <ietf@ietf.org> Message-id: <p05101425b892efc47ab8@[165.227.249.20]> X-UIDL: 5d6cb8ba76a0bf9c716e6b803b30242a MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=Windows-1252 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Loop: ietf@ietf.org References: <NFBBIIHJMLEPPLNMNKLGEEMNDDAA.david@drummondgroup.com> <Pine.GSO.4.40.0202151250570.18854-100000@brisingi.ifi.uio.no> <20020215081540.B1644@SBRIM-W2K> X-Authentication-warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f At 8:15 AM -0500 2/15/02, Scott Brim wrote: >In normative text, I don't see how "must" could occur anywhere except >where it was supposed to mean "MUST". It occurs when describing how something happened, not what needs to happen. Example from a current Internet Draft that is having the capitalization fixed: ...not less than 3, but 4 is less than 5, so 4 must be the last digit. -> ...not less than 3, but 4 is less than 5, so 4 has to be the last digit. There were a few places where the "must" turned into a "MUST" as a way of specifying how an implementation of the protocol had to work. --Paul Hoffman, Director --Internet Mail Consortium Content-transfer-encoding: 7BIT Date: Fri, 15 Feb 2002 11:09:29 -0600 From: "Bob Braden" <braden@ISI.EDU> Subject: Re: RFC2119 Keywords Sender: <owner-ietf@ietf.org> To: <sbrim@CISCO.COM>, <moore@cs.utk.edu> Cc: <ietf@ietf.org> Message-id: <200202151709.RAA26668@gra.isi.edu> X-UIDL: d4a7fe4625ce65425d5c49823d5bd6da MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Loop: ietf@ietf.org X-Sun-Charset: US-ASCII X-Authentication-warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f *> I don't believe the intent of 2119 was to change the meanings of *> "should", "must", etc., in RFCs, but rather to define new terms *> "SHOULD", "MUST", etc., with specific new meanings. *> *> Keith *> Keith's statement was certainly correct when we first introduced the capitalized words in the Host Requirements RFCs (1122,1123). Bob Brden
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC