<?xml version="1.0" encoding="UTF-8"?>
<metanorma xmlns="https://www.metanorma.org/ns/standoc" type="semantic" version="2.8.5" schema-version="v2.1.5" flavor="cc">
<bibdata type="standard">
<title language="en" type="main">July 2004 CalConnect Interoperability Test Rules and Test Scenarios</title>
<docidentifier primary="true" type="CalConnect">CC/A 0401:2004</docidentifier><docnumber>0401</docnumber><date type="published"><on>2004-07-30</on></date><contributor><role type="author"/><organization>
<name>CalConnect</name>
</organization></contributor><contributor><role type="author"><description>committee</description></role><organization>
<name>CalConnect</name>
<subdivision type="Technical committee">
<name>IOPTEST</name>
</subdivision></organization></contributor><contributor><role type="publisher"/><organization>
<name>CalConnect</name>
</organization></contributor><edition>1</edition><version><revision-date>2004-07-30</revision-date></version><language>en</language><script>Latn</script><status><stage>published</stage></status><copyright><from>2004</from><owner><organization>
<name>CalConnect</name>
</organization></owner></copyright><ext><doctype abbreviation="A">administrative</doctype><flavor>cc</flavor></ext></bibdata><metanorma-extension><semantic-metadata><stage-published>true</stage-published></semantic-metadata>
<presentation-metadata><toc-heading-levels>2</toc-heading-levels><html-toc-heading-levels>2</html-toc-heading-levels><doc-toc-heading-levels>2</doc-toc-heading-levels><pdf-toc-heading-levels>2</pdf-toc-heading-levels></presentation-metadata></metanorma-extension>
<boilerplate><copyright-statement>

<clause id="_dbf4cf52-dae2-3cee-ac4f-60fbeb7e154e" obligation="normative"><p id="_f1e04aa6-f789-42c5-5d0f-de370d1570d6">© 2004 The Calendaring and Scheduling Consortium, Inc.</p>
</clause>
</copyright-statement>

<legal-statement>

<clause id="_30bb02f9-a03f-937c-b3bb-0058ec7c185d" obligation="normative"><p id="_4997ac1f-fe23-c399-660a-4ca594a6abda">All rights reserved. Unless otherwise specified, no part of this         publication may be reproduced or utilized otherwise in any form or by any         means, electronic or mechanical, including photocopying, or posting on the         internet or an intranet, without prior written permission. Permission can         be requested from the address below.</p>
</clause>
</legal-statement>

<feedback-statement>

<clause id="_525641bf-9235-cdcb-5b80-9232a01ea9cc" obligation="normative"><p id="_9c7e0878-01cd-c6a2-8060-5caf3135b547" anchor="boilerplate-name">The Calendaring and Scheduling Consortium, Inc.</p>

<p id="_851786db-d5f1-a086-bdb1-3bd48dc4f17c" anchor="boilerplate-address">4390 Chaffin Lane<br/> McKinleyville<br/> California 95519<br/> United States of America<br/> <br/> <link target="mailto:copyright@calconnect.org"/><br/> <link target="https://www.calconnect.org">www.calconnect.org</link></p>
</clause>
</feedback-statement>
</boilerplate><preface><foreword id="_cb69fd51-8b40-b8db-4939-b1641455967c" obligation="informative">
<title id="_41c9fad3-d4c1-eecc-4fad-f91704acc026">Foreword</title>
<p id="_b4cc3f8c-ebef-b96b-e718-f38fd3ccfb12">This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) Documents as located at</p>

<p id="_a373b6fd-c799-dd41-8ebd-c5dc10f851c6"><link target="http://www.calconnect.org/documents/disclaimerpublic.pdf"/>.</p>
</foreword><introduction id="_05f189c3-78cc-a2f0-86c6-b4af13350516" obligation="informative">
<title id="_2b2e98d1-114a-3da4-8556-01ae0a724280">Introduction</title>
<p id="_25c0c3e1-e577-810a-a505-40818ef66912">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.</p>

<quote id="_e305ad3a-9a40-79cf-f0a9-344472a2e116"><source type="inline" bibitemid="rfc2026" citeas="IETF RFC 2026"><localityStack><locality type="section"><referenceFrom>4.1.2</referenceFrom></locality></localityStack></source>
<author>IETF</author><p id="_1405b144-b215-d71a-fa1f-95214b853b51">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.</p>

<p id="_7f6b21bf-dcb0-7185-89c0-3b4bfd79481d">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.</p>

<p id="_bca7ca86-69c6-8518-4fa9-ae0f14a653b3">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)</p>

<p id="_b7a26656-1d64-e443-10bc-c7e9b3a90312">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.</p>
</quote>
</introduction></preface><sections>

<clause id="_fbecea70-ffe6-9f24-00e4-d21988fb4a34" obligation="normative">
<title id="_36f777f2-b087-9f78-036f-c0ac4319d6f2">Conditions and Their Meanings</title>
<clause id="_4e2832da-e217-7c80-10d7-d57abe350fb0" obligation="normative">
<title id="_9e6f7baf-ee36-35b5-4e1d-2f0f7e6021ea"><tt>MUST</tt></title>
<p id="_dfa8e1c9-cefc-3f19-71e7-bec64cc24a19">This word, or the terms “<tt>REQUIRED</tt>” or “<tt>SHALL</tt>”, mean that the definition is an absolute requirement of the specification.</p>
</clause>

<clause id="_e8d2bbf0-dfcb-2bdc-c60e-a90ebcd7009f" obligation="normative">
<title id="_9941eccd-83fd-52f7-bdc5-489e9c051431"><tt>MUST NOT</tt></title>
<p id="_15c9dd41-30de-b32a-2f14-c7fb86c1148d">This phrase, or the phrase “<tt>SHALL NOT</tt>”, mean that the definition is an absolute prohibition of the specification.</p>
</clause>

<clause id="_78dba810-1cee-1791-b346-a2b55ee21304" obligation="normative">
<title id="_f109fe79-81b2-74e4-44ac-03ccfa0117a8"><tt>SHOULD</tt></title>
<p id="_9d0ca843-016f-4576-c935-98e1a17a91bc">This word, or the adjective “<tt>RECOMMENDED</tt>”, 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.</p>
</clause>

<clause id="_85194e4a-c375-fc00-9465-5b1d2347f28c" obligation="normative">
<title id="_17794edd-a388-9faf-170e-81e558df4b8d"><tt>SHOULD NOT</tt></title>
<p id="_4feb5738-61a6-8f5c-fe96-a639a8744048">This phrase, or the phrase “<tt>NOT RECOMMENDED</tt>” 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.</p>
</clause>

<clause id="_ffe83c7c-566a-0ae0-3733-1ef409d55ffd" obligation="normative">
<title id="_09cf419f-b444-ba97-e45a-3f934328aa3f"><tt>MAY</tt></title>
<p id="_d179a08a-f4ce-8748-e2b7-aab149e3f718">This word, or the adjective “<tt>OPTIONAL</tt>”, 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  <tt>MUST</tt> 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  <tt>MUST</tt> be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)</p>
</clause>
</clause>

<clause id="_442a7812-4428-70c0-be93-bcfe6b3ccf4a" obligation="normative">
<title id="_181a87d5-5cc8-f989-6c14-8f1b54b422d1">Number of Conditions per RFC</title>
<table id="_2c1f3406-c10b-b31e-a174-18f91706f8df" unnumbered="true"><thead><tr id="_49ad357c-bfbc-ef4c-76b6-0cc7e55a6a48"><th id="_ffbd7836-1af1-212d-21f5-2dcc35fd65f7" valign="top" align="left">Conditions</th>
<th id="_fdeff7f4-db50-4fc0-e203-1f7570d97d4e" valign="top" align="left">iCalendar (<eref type="inline" bibitemid="rfc2445" citeas="IETF RFC 2445"/>)</th>
<th id="_3aab725d-7f1a-2713-7199-bca9170c1b23" valign="top" align="left">iMIP (<eref type="inline" bibitemid="rfc2446" citeas="IETF RFC 2446"/>)</th>
<th id="_6d314521-f12f-431c-c6de-1cf22b47517a" valign="top" align="left">iTIP (<eref type="inline" bibitemid="rfc2447" citeas="IETF RFC 2447"/>)</th>
</tr></thead>
<tbody><tr id="_faa1f1f6-8065-3060-c882-6be4e8fc33e5"><td id="_e863594f-fb94-1f7a-ca17-a27d9e488a60" valign="top" align="left"><tt>MUST</tt></td>
<td id="_48db1dc5-3a85-10a9-5b2d-bb6376721f06" valign="top" align="left">159</td>
<td id="_6e6f85b3-def8-4e6c-ea3a-e13d4f8bab38" valign="top" align="left">195</td>
<td id="_a67edc86-eb57-b000-a9c1-610de8e1c0f2" valign="top" align="left">16</td>
</tr><tr id="_1316d4b5-e5b9-7e09-ca85-9ef9317bbaa4"><td id="_d0a02c19-456d-a4e9-92a7-2f731e203cac" valign="top" align="left"><tt>REQUIRED</tt></td>
<td id="_449a7aaf-1735-c202-5fbd-1a3782c1216c" valign="top" align="left">17</td>
<td id="_5a0bcec6-d3b5-fb20-f33c-99c0fe361f99" valign="top" align="left">67</td>
<td id="_650f44b3-e92a-d9b7-5c78-a49b93bb8ff8" valign="top" align="left">2</td>
</tr><tr id="_4c97f1af-7470-bf44-516e-93082a5c6c97"><td id="_963e407e-ea3a-7c9d-e2ce-327d257fc7c0" valign="top" align="left"><tt>MUST NOT</tt></td>
<td id="_4c641440-4a04-3556-a5a2-067f1198deea" valign="top" align="left">55</td>
<td id="_ea7d6fb9-7dda-0eda-f5c3-8a242916c146" valign="top" align="left">60</td>
<td id="_303372bb-ff9d-e802-4775-db7bf86087cd" valign="top" align="left">0</td>
</tr><tr id="_a10de55c-2faf-20ef-963a-025da03aafab"><td id="_9088cd17-c7c9-e178-97b6-ec1b53de0b93" valign="top" align="left"><tt>SHALL</tt></td>
<td id="_12a5893d-47b5-3839-c5fa-189a8380fd47" valign="top" align="left">14</td>
<td id="_de13f157-677b-054c-81fa-1bb84e51d845" valign="top" align="left">0</td>
<td id="_ef199fe2-4e69-d578-5699-8a09487c9c1c" valign="top" align="left">0</td>
</tr><tr id="_a179ef15-3cf7-4d04-d13a-803db6852b40"><td id="_9359b20a-710f-62f3-ae23-dab4475cf15a" valign="top" align="left"><tt>SHALL NOT</tt></td>
<td id="_c6c94cfa-5ade-e550-d98d-110a3657478f" valign="top" align="left">1</td>
<td id="_9f10f994-acb8-c67e-f09b-3c77cfe41079" valign="top" align="left">0</td>
<td id="_a098bb5a-cd9e-20c9-21d8-f67ea4e75a27" valign="top" align="left">0</td>
</tr><tr id="_0272db89-30ca-d133-e897-e95620ac2d47"><td id="_add5e743-7af5-ed8d-06ae-7b02b543522d" valign="top" align="left"><tt>SHOULD</tt></td>
<td id="_a29eca31-ae70-e043-dd8a-a0ff92ce5e00" valign="top" align="left">39</td>
<td id="_f5911452-4087-a06e-90fc-65a011fbe223" valign="top" align="left">36</td>
<td id="_9e7da016-88b7-27bf-9b8d-fa3b5ade1f2c" valign="top" align="left">7</td>
</tr><tr id="_46ae5da6-0827-d79a-d6ca-a064a70ddc2d"><td id="_b81e8619-cb95-79ef-6e00-d0ed0e6d124b" valign="top" align="left"><tt>SHOULD NOT</tt></td>
<td id="_502cbf79-1eea-d6be-0eea-1feff9b98117" valign="top" align="left">6</td>
<td id="_142c96c8-3481-f3ec-80c0-2dae798881eb" valign="top" align="left">2</td>
<td id="_90e11651-eb29-bdeb-6932-dcf91b91bf35" valign="top" align="left">0</td>
</tr><tr id="_6b7eaba5-739b-3d8b-f06d-5e76d105eba1"><td id="_e35ed17b-070c-b634-1e69-5403197182c3" valign="top" align="left"><tt>MAY</tt></td>
<td id="_9c0e05ab-b29b-57b3-f29d-f2edb7cbcc6a" valign="top" align="left">79</td>
<td id="_4cd8213e-7402-d2c5-8e35-f6c9a9cad3a8" valign="top" align="left">217</td>
<td id="_db9e833a-4f13-9e6a-7396-87a0a9f5ff2c" valign="top" align="left">7</td>
</tr><tr id="_42b286f4-94d6-6adf-f15b-8ef3b890bcfc"><td id="_88ff5206-7563-8ca6-411d-62b63ca2176d" valign="top" align="left"><tt>MAY NOT</tt></td>
<td id="_7a91c961-5c8b-4958-de5c-05b698cd54cc" valign="top" align="left">2</td>
<td id="_2a4b1d8c-d932-0487-67dc-f86b26fd3956" valign="top" align="left">5</td>
<td id="_f0257f8b-d134-12a0-6138-d516645b22c9" valign="top" align="left">0</td>
</tr></tbody>
</table>
</clause>


</sections><bibliography><references id="_aa8ef5c1-07f0-98f9-40d4-f59fdd496961" normative="false" obligation="informative">
<title id="_2b4ed339-a7ed-1bbb-9576-55fcbc1ace3a">Bibliography</title><bibitem id="_ed7ff35d-6577-6ca4-0705-9b30ab34f40a" type="standard" schema-version="v1.5.6" anchor="rfc2445">
  <fetched>2026-05-06</fetched>
  
<title type="main">Internet Calendaring and Scheduling Core Object Specification (iCalendar)</title>

  <uri type="src">https://www.rfc-editor.org/info/rfc2445</uri>
  <docidentifier type="IETF" primary="true">RFC 2445</docidentifier>
  <docidentifier type="DOI">10.17487/RFC2445</docidentifier>
  <docnumber>RFC2445</docnumber>
  <date type="published">
    <on>1998-11</on>
  </date>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">F.</formatted-initials>          <surname language="en" script="Latn">Dawson</surname>          <completename language="en" script="Latn">F. Dawson</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">D.</formatted-initials>          <surname language="en" script="Latn">Stenerson</surname>          <completename language="en" script="Latn">D. Stenerson</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="publisher"/>
    <organization>
      
<name language="en">RFC Publisher</name>

    </organization>
  </contributor>
  <contributor>
    <role type="authorizer"/>
    <organization>
      
<name language="en">RFC Series</name>

    </organization>
  </contributor>
  <contributor>
    <role type="author">
      <description>committee</description>
    </role>
    <organization>
      
<name language="en">Internet Engineering Task Force</name>

      <subdivision type="workgroup">
        
<name>Calendaring and Scheduling</name>

        <identifier>calsch</identifier>
      </subdivision>
      <abbreviation language="en">IETF</abbreviation>
    </organization>
  </contributor>
  <language>en</language>
  <script>Latn</script>
  <abstract language="en" script="Latn">
    <p id="_c1986af7-5da9-6ec0-babf-47118fd017bf">This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [STANDARDS-TRACK]</p>

  </abstract>
  <status>
    <stage>PROPOSED STANDARD</stage>
  </status>
  <relation type="obsoletedBy">
    <bibitem>
      <formattedref>RFC5545</formattedref>
      <docidentifier type="IETF" primary="true">RFC5545</docidentifier>
    </bibitem>

  </relation>
  <series>
    
<title>RFC</title>

    <number>2445</number>
  </series>
  <series type="stream">
    
<title>IETF</title>

  </series>
  <keyword>
    <vocab>ICALENDAR</vocab>
  </keyword>
  <keyword>
    <vocab>interoperable</vocab>
  </keyword>
  <keyword>
    <vocab>mime</vocab>
  </keyword>
  <keyword>
    <vocab>multipurpose internet mail extensions</vocab>
  </keyword>
</bibitem><bibitem id="_f58a07b8-034d-6a4a-f8ab-36d90ae2c520" type="standard" schema-version="v1.5.6" anchor="rfc2446">
  <fetched>2026-05-06</fetched>
  
<title type="main">iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries</title>

  <uri type="src">https://www.rfc-editor.org/info/rfc2446</uri>
  <docidentifier type="IETF" primary="true">RFC 2446</docidentifier>
  <docidentifier type="DOI">10.17487/RFC2446</docidentifier>
  <docnumber>RFC2446</docnumber>
  <date type="published">
    <on>1998-11</on>
  </date>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">S.</formatted-initials>          <surname language="en" script="Latn">Silverberg</surname>          <completename language="en" script="Latn">S. Silverberg</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">S.</formatted-initials>          <surname language="en" script="Latn">Mansour</surname>          <completename language="en" script="Latn">S. Mansour</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">F.</formatted-initials>          <surname language="en" script="Latn">Dawson</surname>          <completename language="en" script="Latn">F. Dawson</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">R.</formatted-initials>          <surname language="en" script="Latn">Hopson</surname>          <completename language="en" script="Latn">R. Hopson</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="publisher"/>
    <organization>
      
<name language="en">RFC Publisher</name>

    </organization>
  </contributor>
  <contributor>
    <role type="authorizer"/>
    <organization>
      
<name language="en">RFC Series</name>

    </organization>
  </contributor>
  <contributor>
    <role type="author">
      <description>committee</description>
    </role>
    <organization>
      
<name language="en">Internet Engineering Task Force</name>

      <subdivision type="workgroup">
        
<name>Calendaring and Scheduling</name>

        <identifier>calsch</identifier>
      </subdivision>
      <abbreviation language="en">IETF</abbreviation>
    </organization>
  </contributor>
  <language>en</language>
  <script>Latn</script>
  <abstract language="en" script="Latn">
    <p id="_4ff6c973-80f3-8c67-6a02-d8c7a9f3147e">This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems.  It does so in a general way so as to allow multiple methods of communication between systems. [STANDARDS-TRACK]</p>

  </abstract>
  <status>
    <stage>PROPOSED STANDARD</stage>
  </status>
  <relation type="obsoletedBy">
    <bibitem>
      <formattedref>RFC5546</formattedref>
      <docidentifier type="IETF" primary="true">RFC5546</docidentifier>
    </bibitem>

  </relation>
  <series>
    
<title>RFC</title>

    <number>2446</number>
  </series>
  <series type="stream">
    
<title>IETF</title>

  </series>
  <keyword>
    <vocab>ITIP</vocab>
  </keyword>
  <keyword>
    <vocab>iCalendar Transport-Independent Interoperability Protocol</vocab>
  </keyword>
  <keyword>
    <vocab>internet</vocab>
  </keyword>
  <keyword>
    <vocab>systems</vocab>
  </keyword>
</bibitem><bibitem id="_fe908e48-a780-459a-3224-88b83b6ce870" type="standard" schema-version="v1.5.6" anchor="rfc2447">
  <fetched>2026-05-06</fetched>
  
<title type="main">iCalendar Message-Based Interoperability Protocol (iMIP)</title>

  <uri type="src">https://www.rfc-editor.org/info/rfc2447</uri>
  <docidentifier type="IETF" primary="true">RFC 2447</docidentifier>
  <docidentifier type="DOI">10.17487/RFC2447</docidentifier>
  <docnumber>RFC2447</docnumber>
  <date type="published">
    <on>1998-11</on>
  </date>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">F.</formatted-initials>          <surname language="en" script="Latn">Dawson</surname>          <completename language="en" script="Latn">F. Dawson</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">S.</formatted-initials>          <surname language="en" script="Latn">Mansour</surname>          <completename language="en" script="Latn">S. Mansour</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">S.</formatted-initials>          <surname language="en" script="Latn">Silverberg</surname>          <completename language="en" script="Latn">S. Silverberg</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="publisher"/>
    <organization>
      
<name language="en">RFC Publisher</name>

    </organization>
  </contributor>
  <contributor>
    <role type="authorizer"/>
    <organization>
      
<name language="en">RFC Series</name>

    </organization>
  </contributor>
  <contributor>
    <role type="author">
      <description>committee</description>
    </role>
    <organization>
      
<name language="en">Internet Engineering Task Force</name>

      <subdivision type="workgroup">
        
<name>Calendaring and Scheduling</name>

        <identifier>calsch</identifier>
      </subdivision>
      <abbreviation language="en">IETF</abbreviation>
    </organization>
  </contributor>
  <language>en</language>
  <script>Latn</script>
  <abstract language="en" script="Latn">
    <p id="_5be22720-5d40-7005-8ec1-52fb775bc53e">This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. [STANDARDS-TRACK]</p>

  </abstract>
  <status>
    <stage>PROPOSED STANDARD</stage>
  </status>
  <relation type="obsoletedBy">
    <bibitem>
      <formattedref>RFC6047</formattedref>
      <docidentifier type="IETF" primary="true">RFC6047</docidentifier>
    </bibitem>

  </relation>
  <series>
    
<title>RFC</title>

    <number>2447</number>
  </series>
  <series type="stream">
    
<title>IETF</title>

  </series>
  <keyword>
    <vocab>IMIP</vocab>
  </keyword>
  <keyword>
    <vocab>iCalendar Message-Based Interoperability Protocol</vocab>
  </keyword>
  <keyword>
    <vocab>internet</vocab>
  </keyword>
  <keyword>
    <vocab>electronic</vocab>
  </keyword>
  <keyword>
    <vocab>mail</vocab>
  </keyword>
  <keyword>
    <vocab>transport</vocab>
  </keyword>
</bibitem><bibitem id="_15fee673-4b72-a64a-540b-eb6d8998029f" type="standard" schema-version="v1.5.6" anchor="rfc2026">
  <fetched>2026-05-06</fetched>
  
<title type="main">The Internet Standards Process — Revision 3</title>

  <uri type="src">https://www.rfc-editor.org/info/rfc2026</uri>
  <docidentifier type="IETF" primary="true">RFC 2026</docidentifier>
  <docidentifier type="DOI">10.17487/RFC2026</docidentifier>
  <docnumber>RFC2026</docnumber>
  <date type="published">
    <on>1996-10</on>
  </date>
  <contributor>
    <role type="author"/>
    <person>
      
<name>                    <formatted-initials language="en" script="Latn">S.</formatted-initials>          <surname language="en" script="Latn">Bradner</surname>          <completename language="en" script="Latn">S. Bradner</completename>       </name>

    </person>
  </contributor>
  <contributor>
    <role type="publisher"/>
    <organization>
      
<name language="en">RFC Publisher</name>

    </organization>
  </contributor>
  <contributor>
    <role type="authorizer"/>
    <organization>
      
<name language="en">RFC Series</name>

    </organization>
  </contributor>
  <contributor>
    <role type="author">
      <description>committee</description>
    </role>
    <organization>
      
<name language="en">Internet Engineering Task Force</name>

      <subdivision type="workgroup">
        
<name>Poised 95</name>

        <identifier>poised95</identifier>
      </subdivision>
      <abbreviation language="en">IETF</abbreviation>
    </organization>
  </contributor>
  <language>en</language>
  <script>Latn</script>
  <abstract language="en" script="Latn">
    <p id="_4b2a406b-2cdd-e614-63f8-984c01a8e860">This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</p>

  </abstract>
  <status>
    <stage>BEST CURRENT PRACTICE</stage>
  </status>
  <series>
    
<title>BCP</title>

    <number>9</number>
  </series>
  <series>
    
<title>RFC</title>

    <number>2026</number>
  </series>
  <series type="stream">
    
<title>IETF</title>

  </series>
  <keyword>
    <vocab>Protocols</vocab>
  </keyword>
  <keyword>
    <vocab>copyrights</vocab>
  </keyword>
  <keyword>
    <vocab>intellectual</vocab>
  </keyword>
  <keyword>
    <vocab>property</vocab>
  </keyword>
</bibitem>




</references></bibliography>
</metanorma>
