Foreword
This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) Documents as located at
Introduction
The purpose of this testing is to move the iCalendar, iMIP and iTIP proposed standards to the next level, Draft Standard. The following text describes what must occur.
A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the “Draft Standard” level. For the purposes of this section, “interoperable” means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful.
The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed.
The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. This documentation should be submitted to the Area Director with the protocol action request. (see Section 6)
A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation. A Draft Standard may still require additional or more widespread field experience, since it is possible for implementations based on Draft Standard specifications to demonstrate unforeseen behavior when subjected to large-scale use in production environments. A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of Draft Standards into a disruption sensitive environment.
— IETF, IETF RFC 2026, Section 4.1.2
July 2004 CalConnect Interoperability Test Rules and Test Scenarios
1. Conditions and Their Meanings
1.1. MUST
This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.
1.2. MUST NOT
This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification.
1.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.
1.4. SHOULD NOT
This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
1.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.)
2. Number of Conditions per RFC
Conditions | iCalendar (IETF RFC 2445) | iMIP (IETF RFC 2446) | iTIP (IETF RFC 2447) |
---|---|---|---|
MUST | 159 | 195 | 16 |
REQUIRED | 17 | 67 | 2 |
MUST NOT | 55 | 60 | 0 |
SHALL | 14 | 0 | 0 |
SHALL NOT | 1 | 0 | 0 |
SHOULD | 39 | 36 | 7 |
SHOULD NOT | 6 | 2 | 0 |
MAY | 79 | 217 | 7 |
MAY NOT | 2 | 5 | 0 |
Bibliography
[1] IETF RFC 2445, F. DAWSON and D. STENERSON. Internet Calendaring and Scheduling Core Object Specification (iCalendar). 1998. RFC Publisher. https://www.rfc-editor.org/info/rfc2445.
[2] IETF RFC 2446, S. SILVERBERG, S. MANSOUR, F. DAWSON and R. HOPSON. iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries. 1998. RFC Publisher. https://www.rfc-editor.org/info/rfc2446.
[3] IETF RFC 2447, F. DAWSON, S. MANSOUR and S. SILVERBERG. iCalendar Message-Based Interoperability Protocol (iMIP). 1998. RFC Publisher. https://www.rfc-editor.org/info/rfc2447.
[4] IETF RFC 2026, S. BRADNER. The Internet Standards Process — Revision 3. 1996. RFC Publisher. https://www.rfc-editor.org/info/rfc2026.