Subject: Method Reviewer

From: John Stracke <[email-masked]>
Date: Tue, 24 Aug 1999 14:35:16 -0400

In Oslo, I brought up my concern with the Method Reviewer
specified in the CAP draft: it seemed like too much authority for
a single person.  Frank countered that it was the same process
defined for iCalendar, and someone I didn't see said that it was
the same as for MIME types; Pat asked me to look at it more
carefully and decide whether I was still concerned, and I
agreed.  Here's what I think:

The process specified in the CAP draft seems fine, because the
MR's decisions are subject to appeal; but there's a hole: the
language says, "The Method Reviewer's decision to reject an
entity can be appealed...".  There are no provisions for
appealing a decision to *accept* an entity.  This means that, if
the MR works for Company X, then Company X can (probably) get
pretty much anything they want passed, with no chance of appeal.
It may be that there's a general IETF-wide rule that says that
any decision is appealable; but I don't know of it, and other
people who read the document may not, either, so they might not
try to appeal.  I would like to see "decision to reject an
entity" changed to "decision".

RFC-2445 (iCalendar) has identical language; I would like to see
an editorial update making the same change.  (Perhaps it could be
folded into ietf-draft-calsch-ical21-00.txt.)

I would also like the two documents to clarify whether the two
MRs are intended to be the same person.  (Of course, even if
they're different roles, they could be the same person from time
to time; the question is whether the ADs can appoint separate
people when appropriate.)

RFCs-2446 and -2447 do not have (or need) an extensibility
process, so there's no problem there.

MIME (specifically, RFC-2048, "MIME Registration Procedures")
does specify an access type reviewer, but permits all the
reviewer's decisions to be appealed (see section 3.2.2).
Furthermore, there is no reviewer for content types or transfer
encodings (both of which have registration processes defined in
the same document), which raises the question: why are access
types different? And are iCalendar entities like content types or
access types? If they're like content types, maybe we shouldn't
have a Method Reviewer at all.

I think the reason access types (mechanisms for fetching an
external body--analogous to URL schemes) are different is that
they can have a much greater interoperability impact than
content-types.  For example, if I want to send a message as
text/enriched, well, it's still text, and the human at the other
end can probably read it even if they don't have software that
understands text/enriched (that's the definition of text/*).
Alternatively, if I'm sending application/postscript, it can be
reasonable to send text/plain as well (the percentage increase in
size won't be too much).  But, if I'm sending a reference to an
external body, then I don't want to have to give several
alternative representations, since that would mean running
several different servers.  Thus, registering a new access type
can make it harder to get interoperability, so it's not a step to
be taken lightly.

Mind you, the above paragraph is just me gazing at my navel; I
wasn't around for the discussions that led to the MIME
registration process.  But, if I'm right, then I think that
iCalendar methods are more like access types than content types,
since creating a new method has a severe interop impact.  On the
other hand, I'm not sure about iCalendar properties or
parameters; I suspect that they're more like content types, since
it's easy to provide alternative representations (both a new
property and an old one, for example).  It may be that it would
be most appropriate to limit the Method Reviewer to reviewing
methods.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: Doug Royer <[email-masked]>
Date: Fri, 27 Aug 1999 14:26:09 -0700 (PDT)

> Date: Tue, 24 Aug 1999 14:35:16 -0400
> From: John Stracke <[email-masked]>
> 

I agree. It does seem one sided.

Anyone have a reason not to change it as John has proposed?

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked]
Date: Tue, 31 Aug 1999 22:05:50 GMT

>Anyone have a reason not to change it as John has proposed?

Wait a sec. John is complaining that a CHANGE REQUEST was approved; which 
means that it was submitted by someone, discussed on the list, found to 
have consensus and then the REVIEWER proposed acceptance to the AREA 
DIRECTORS.
Where is the problem here? If there was a problem with the proposal, then 
it would have been aired in the review period. If there is real objections 
during the review, then the objections will have to be addressed prior to 
consensus being reached. Right? So, where is the problem here?
Do we want forward progress to be held hostage by a single objection that 
gets perpetuated by a series of escallation appeals?
The existing process appears to have due-process and has been proofed 
through experience with the MIME registration process. What more do we 
want?
-- Frank