Subject: RE: Editors notes in CAP

From: Doug Royer <[email-masked]>
Date: Wed, 30 Jan 2002 17:52:40 -0700

> Doug,

By TARGET I meant what we used to call parent, but as we
did away with hiericaial calendars - 'parent' has no valid
meaning any more.

> i.e. if a store had 10 calendars and I wanted to give MOVE permission from
> all 10 to all 10 - I have to specify 81 separate MOVE permissions? (i.e.
> from each calendar to each of the other 9 calendars ) This seems rather
> cumbersome and ugly.

No - It means that if you don't have DELETE on the old
     location, and WRITE on the new location PLUS the MOVE
     permission (that I was defining) - you can't move.

---

From: "John Stracke" <[email-masked]>
Date: Thu, 31 Jan 2002 17:17:32 -0500

>I think we want to
>be able to appeal all method reviewer decisions.

Actually, I would prefer to strike the MR process from CAP and iCalendar 
altogether.  As I wrote back in August 
(<http://www.imc.org/ietf-calendar/mail-archive/msg02034.html>), it simply 
does not make sense.  To quote:

>CAP seems to have picked up the "item registration" meme from iCalendar, 
>which got it from MIME. In MIME, it makes sense (all Content-types, for 
>example, are independent); in iCalendar, it's risky (different 
>properties can interact); in CAP, it's an out-and-out mistake. CAP is a 
>protocol, not a data format; it cannot be defined piecemeal. For that 
>reason, protocols need to be updated by the normal RFC process. If 
>someone wants to define, say, a new method for CAP, they need to write 
>an I-D and get it approved as a standards-track RFC, updating the CAP 
>RFC. (This does not mean that they have to reissue an updated CAP RFC; 
>they can have a smaller RFC that just defines the new method.)
>
>This is the normal mechanism for extending protocols. We should not be 
>coming up with our own mechanism just for CAP.

/=============================================================\
|John Stracke                   |Principal Engineer           |
[email-masked]  |Incentive Systems, Inc.      |
|http://www.incentivesystems.com|My opinions are my own.      |
|=============================================================|
|Rope is rope, and string is string, and never the twine shall|
|meet.                                                        |
\=============================================================/