Subject: Editors notes in CAP

From: Doug Royer <[email-masked]>
Date: Tue, 29 Jan 2002 18:54:29 -0700

We need to clean up the editors notes in CAP -COMMENTS?
I have included my comments.

>  [Editors Note:  TODO - get the lower port number ]

WHY? Lets get this out of the CAP text and into the TODO list.

>   [EDITORS NOTE: Issues:
>
>  - Can one use DELETE to remove all VALARMs and VTIMEZONEs that
>    match a certain search criteria and that belong to all
>    components, event though VALARMs and VTIMEZONEs never exist as
>    independent components?

Yes - with the old DELETE command 
- checking to see if it still can be done.

> Or should one use MODIFY? If they can
>    be deleted, do we return the REQUEST-STATUS of their deletion
>   in a VEVENT or separately?

???

>   [EDITORS NOTE: Issue: does write access to a VAGENDA give you the
>   right to move a calendar into it?

No - about MOVE permission.

>   [EDITORS NOTE: need to make a pass through the iTIP restriction
>   tables to make sure that there are no problems with using them as
>   they exist]

TODO.

>   [EDITORS NOTE: Do we want to use the same set of codes?]

Error codes  - YES when they are the same error.
And we need to make sure that we do NOT use the same
error codes for already defined iTIP errors if they
have different meanings.

> 6.XXX [EDITORS NOTE: More are in this memo - add here TODO]

Yes - we need to do this. I have volunteered as soon as
we get the next version of the draft ready to ship, I'll
update this section will all of the error codes that are
in the doc, and compare / sync them with iCal, iTIP and iMIP
where they overlap.

>   [EDITORS NOTE: These extensions/changes to iCalendar need to be
>   reformatted to conform to the IANA registration process defined in
>   section 7 of [iCAL].]

Anyone volunteer?

>   [Editor's Note: see if the above still make sense after
>   reviewing the VCARs in ICAL-updates.html doc]

(default VCARS) still needed - delete the note.

>  [EDITORS NOTE: hopefully, calid is defined somewhere...]

I am confused, this comment is in the definition for CALID?
Remove it?

>   [EDITORS NOTE: John Stracke to review any updates]

I talked to him about this. He has not done this.
Lets make it usable. The problem (as I recall) was
that there was no appeal process once the method
reviewer accepted a proposal. I think we want to
be able to appeal all method reviewer decisions.

---

From: George Babics <[email-masked]>
Date: Wed, 30 Jan 2002 13:39:33 -0500

Doug Royer wrote:

[snip]
 
> >   reformatted to conform to the IANA registration process defined in

  I can take of of this.
   
  If anyone sees an extension to iCalendar that is not
defined in section 11 "Properties" and is not already
in the To Do list please let us know.

  Section 4 defines the syntax for queries. Should
these definitions go into section 11? Do we really
need section 4? Or should we rename it to "Searching"
since all it deals with is searching?

  Once we have a consensus on VCARs, the definition of
the components, parameters, and properties used in VCARs
can also go into section 11.

George

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 30 Jan 2002 17:54:54 -0500

> - checking to see if it still can be done.

How would you write the VQUERY even with the old METHOD:DELETE?

> >   in a VEVENT or separately?

Deleting VALARMs could easily be done by remplacing them with nothing.

> No - about MOVE permission.

I disagree.  Again, see my post on why we can't have a MOVE PERMISSION:

http://www.imc.org/ietf-calendar/mail-archive/msg03230.html

You have not replied to this post.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Jan 2002 16:33:14 -0700

> How would you write the VQUERY even with the old METHOD:DELETE?

The DATA for a delete command could be a VQUERY BEGIN/END block.
That would delete everything that the QUERY:SELECT ... selected.

> I disagree.  Again, see my post on why we can't have a MOVE PERMISSION:

No , that explains that you don't want a MOVE permission.

Proposed text for MOVE permission:

	The MOVE permission means you have WRITE permission
	on the TARGET calendar and DELETE permission
	on the OLD-TARGET calendar. And the permissions do
	not need to be reciprocal.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 30 Jan 2002 18:03:00 -0600

Doug,

So would a MOVE permission have to EXPLICITLY state the OLD_TARGET and
TARGET as part of the permission???

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.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Wednesday, January 30, 2002 5:33 PM
To: [email-masked]
Subject: Re: Editors notes in CAP

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 30 Jan 2002 19:10:28 -0500

> That would delete everything that the QUERY:SELECT ... selected.

So could I use the following VQUERY with the "delete" command
to specify that I want to delete all the ATTENDEEs from a VEVENT?

   BEGIN:VQUERY
   QUERY:SELECT ATTENDEE FROM VEVENT WHERE UID = '123'
   END:VQUERY

I'd prefer if we would use the "modify" command for that.

>         not need to be reciprocal.

1- Would you need the MOVE permission granted
   in both the TARGET and OLD-TARGET?  If so,
   see my post to find why this is bad. If not,
   how can this work?

2- Since MOVE is defined in terms of other
   PERMISSSIONS we clearly don't need it.

3- Wouldn't you need the right to READ in the
   OLD-TARGET as well?

Regards,
Bernard