draft-stracke-calsch-ical-reviewer-00

[John Stracke <francis@xxxxxxxx>]

Attached is an I-D I just wrote, proposing a fix to the Method
Reviewer process.  (Yes, this is basically what I promised to do
back in Oslo.) I've submitted this I-D already, but of course it
won't be published for a while.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Almost no one has ever wanted a 1/4" drill bit;|
|francis@xxxxxxxx|all they ever wanted was a 1/4" hole.          |
\================================================================/


Network Working Group                             J. Stracke, eCal Corp.
INTERNET DRAFT
<draft-stracke-calsch-ical-reviewer-00>
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 
   <http://www.ietf.org/ietf/1id-abstracts.txt>

   The list of Internet-Draft Shadow Directories can be accessed at 
   <http://www.ietf.org/shadow.html>

   Distribution of this document is unlimited. Please send comments to 
   francis@xxxxxxxx or to the impp@xxxxxxxxxxx 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@xxxxxxxx












Stracke                                                          [Page 2]