Hmmm Actually it would be interoperability, and I think it does meet that test. What do you think?
Those who need this feature can only use it if it is supported on the technology (product) being used at both ends of the conversation. And this doesn’t mean that the other 'user' has chosen to turn it on. It has to be built into the product so that users can turn it on. So it means that whole classes of people cannot use the technique among themselves if the products don't support it. So it would appear that this meets the definition of SHOULD, yes? - it SHOULD be supported - and product developers should understand the full implications of not implementing and carefully weigh them before choosing to not include this feature. Gregg ----------------------- Gregg Vanderheiden Ph.D. Director Trace R&D Center Professor Industrial & Systems Engineering and Biomedical Engineering University of Wisconsin-Madison On Mar 2, 2011, at 6:21 AM, Dave Cridland wrote: > On Wed Mar 2 12:00:42 2011, Gregg Vanderheiden wrote: >> Should vs Optional >> Should was used because, although they can be safely omitted (the technology >> would still work in message mode), they are important to certain classes of >> users. So we should include these features in mainstream applications - >> both so that people who need them can use mainstream apps and so that they >> can call everyone else who is using the mainstream apps. > > Just to pick up on this: > > http://tools.ietf.org/html/rfc2119 says (extracts): > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > 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. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > 6. Guidance in the use of these Imperatives > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > > I can see you're describing marketplace benefits, but I don't see an > interoperability issue, so I suggest you need to find alternative language to > describe the intent, here. > > Dave. > -- > Dave Cridland - mailto:[email protected] - xmpp:[email protected] > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
