Network Working Group J. Stracke, eCal Corp. INTERNET DRAFT Expires September, 2000 March 30, 2000 Fixing the iCalendar Registration Process 1 Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at Distribution of this document is unlimited. Please send comments to francis@ecal.com or to the impp@iastate.edu discussion list. 2 Abstract This document discusses a problem with the [ICALENDAR] registration process, which gives the Method Reviewer too much power, and proposes a fix. 3 Introduction This document discusses a problem with the [ICALENDAR] registration process, which gives the Method Reviewer too much power, and proposes a fix. Section 7.2 of [ICALENDAR] defines a process for defining new iCalendar properties. This process seems to be modeled on the [MIME] registration procedures, but with some subtle changes: a decision from the Method Reviewer to accept a proposal cannot be appealed. Decisions to reject can be appealed, but only by the original proposer. In the first place, the IETF simply does not grant any single person the power to extend a standard unilaterally. Consider what happens if an unscrupulous MR gets appointed: they can propose, and accept, a slew of extensions to further their employer's agenda. In the second place, the unilateral power to accept can be used to make the review of rejections meaningless. If the MR sees a proposal Stracke [Page 1] INTERNET-DRAFT iCalendar Registration Fix March 30, 2000 which they want to reject, they can propose, and accept, a different proposal which conflicts with the rejected proposal (e.g., by using the same type names). The appeal of the rejection would then be more or less foredoomed. In the third place, it may be a bad idea to state that only the original proposer can appeal the MR's decisions. For example, suppose the MR rejects a proposal, and the original proposer cannot afford the time for a formal appeal; it may well be desirable to permit a third party to make the appeal (as is possible in [MIME]). Finally, it is not made explicit that the MR can be removed; the Applications Area Director(s) appoint the MR, but an argument could be made that they do not have the power to remove the MR. Granted, it would be a pretty weak argument; but better to avoid the problem in the first place. 4 Proposed fix The proposed fix is to modify the registration process so that all decisions of the Method Reviewer can be appealed to the IESG, by any party, and so that the Area Director(s) can remove the Method Reviewer at any time. 5 References [MIME-FORMAT] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures." RFC-2048. Innosoft, MCI, ISI. November, 1996. [ICALENDAR] F. Dawson, D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC-2445. Lotus, Microsoft. November, 1998. 6 Author's Address J. Stracke eCal Corp. 234 N. Columbus Blvd., 2nd Floor Philadelphia, PA 94043 francis@ecal.com Stracke [Page 2]