Subject: [EDITORS NOTE: John Stracke to review...

From: Doug Royer <[email-masked]>
Date: Thu, 15 Nov 2001 18:14:24 -0700

In 12.2 ... 

 [EDITORS NOTE: John Stracke to review any updates]

John, this is an old one - have you reviewed this?

-Doug

---

From: "John Stracke" <[email-masked]>
Date: Fri, 16 Nov 2001 09:50:29 -0500

(Patrik, I'm CC:ing you because this is a process problem, and I'd like 
your input.)

>John, this is an old one - have you reviewed this?

Let's see, is this the Method Reviewer thing...yes.  Yeah, this still has 
the same problem that the iCalendar Method Reviewer process has: the only 
appeal available is if the MR rejects a proposal.  If the MR accepts a 
proposal, nobody can object.

I first brought this up in Oslo; at the time, people seemed to agree that 
it was something to fix.  The main problem is that the MR can add whatever 
extensions to iCalendar they please.  Now, we can expect that most people 
won't abuse this power most of the time; but, at a minimum, having the 
power could put them in a painful position when their employer wants them 
to abuse it.

And adding bad extensions isn't the only way this power could be abused. 
Suppose I propose Extension X, which does such-and-so.  The MR doesn't 
like it, so they propose Extension Y, which does the same thing, 
differently.  They accept Y, and then reject X.  I could try to appeal the 
decision to reject X, but it'd be hard to make the case that both X and Y 
should be standardized.

In addition, only the original proposer can appeal a decision to reject. 
Suppose the original proposer no longer has time to work on the idea; a 
third party who wants the proposal to go through has to resubmit it 
themselves, and wait for it to be rejected.  Not an insurmountable 
problem, but it's an extra barrier.

I think I see two meta-problems here.  This process was based on the MIME 
type registration process.  The first meta-problem is that the process was 
changed; the MIME process permits all decisions to be appealed.  The 
second meta-problem is that the needs of iCalendar, or CAP, are 
fundamentally different from the needs of MIME types.  A new MIME type can 
be registered without having to worry about its interaction with other 
MIME types; they're orthogonal.  But a new iCalendar/CAP property, or a 
change to an existing property (the same process applies), cannot be 
considered in isolation; it's necessary to consider its interactions with 
other properties.  This becomes a harder problem, a problem for the full 
WG, not an appointed reviewer.  For this reason, I believe that the Method 
Reviewer process should be abandoned altogether.  Extensions and 
modifications to the spec can be done via the normal RFC process, just as 
with other standards.

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|If you're omniscient, how do you know?                 |
\=======================================================/