Subject: CAP Draft 6 comments

From: [email-masked] (Steve Mansour)
Date: Tue, 11 Dec 2001 13:49:11 -0800

Hey All,

Thanks to a delayed flight, I managed to get through the entire draft.
Here are some things I noted (I'm not listing all the typos):

  1. Section 2.1.  We can use BEEP as a handle for "transport
     protocol",  However, there was no explicit mention of an
     "application protocol". I believe that is what CAP has become now
     that we use BEEP.  I think it's important to state it.
  2. Section 2.2 - We refer to many new components before ever listing
     them and before we provide even a one-liner describing what they
     are. I think a table that lists each of the components CAP deals
     with and a quick one-line description would be really useful.
  3. Is there a VSCHEDULE anymore? We still refer to it in 2.2.
  4. Section 2.4.4 we mention trusted server relationships. We should
     mention explicitly that this is out of the scope of [CAP]
  5. Section 2.6 - we mention "printable 7 bit ASCII characters".  Is
     this sufficiently explicit? Should we list the character value
     range?
  6. Section 3.3 in the example, the MSG number changes from 4 to 2,
     shouldn't they match?
  7. Section 4.1.2 Use 'DTSTART <= ...'  -- the two strings look
     identical. I think it's a typo... or is it?
  8. What was intended for 4.1.3 Querying Experimental Properties ?
  9. Section 4.1.6 versus 4.1.8 -- the value for METHOD.  In some
     places, we refer to the METHOD value for "booked" events as NULL,
     and in other places we refer to it as CREATED.  I happen to prefer
     being explicit and keeping it at CREATED, but whatever we choose we
     must be consistent.
 10. Section 4.1.6 -- I thought we decided that we need a METHOD state
     for a CANCELled event or a DELETEd event. This is important for
     several reasons. One was mentioned in the draft, another is that
     it's important for synchronization applications to determine which
     events have been deleted. If we use the METHOD property to mark
     cancelled / deleted events, then the query needs to be fixed.
 11. Section 6.1.3 needs an example
 12. We need to close on the iCalendar version we're going to require
     for CAP.  In the current draft we specify that we require VERSION
     2.0 and VERSION 2.1.  Let's pick one :-)
 13. Section 6.2.4.1.  (and most of the other commands that follow it)
     -- need more error return values to be listed. All commands are
     showing 2.0, 6.1, 6.3. But there are many other errors that can
     occur; security violations, etc. We need to list them.
 14. Section 6.2.4.2.  Regarding the editors note -  my recommendation
     is that the way to delete a VALARM is to modify or delete the
     component that contains it.  The delete command should apply to the
     VTIMEZONES that exist at the calstore level.  I don't think
     components like VEVENTS can contain VTIMEZONE components, I think
     they only reference VTIMEZONE components that exist at the calstore
     level.
 15. Section 6.2.4.3.  Are there sequencing (ordering) issues? are
     removes always processed before updates? does it matter?
 16. Section 6.2.4.3.  The returned REQUEST-STATUS has a single 2.0
     return value, yet many error conditions can occur. Some of the
     requested edits / removes may be successful while others are not
     (perhaps due to access control).  When multiple errors occur, is
     there a separate REQUEST-STATUS for each update/remove that failed?
 17. Section 6.2.4.4. "CS MUST ensure that VCARs are still valid after
     the move" seems pretty nebulous to me. I think the issue is the
     following: given that VCARs are hierarchic, moving a calendar from
     one location in the hierarchy to another could possibly change the
     access control considerably and yield unexpected and unwanted
     results.  I think what we want to do is make sure that the access
     control is at least as restrictive (and possibly more restrictive)
     than it was prior to the move.  Note that with hierarchic VCARs the
     way they are defined now, it may not be possible to provide exactly
     the same access to a calendar as prior to the move -- something
     further up the new hierarchy may be more restrictive.  Also, there
     are ownership issues. Is there something we want to say about the
     ownership of the new parent calendar(s) given the owners of the
     previous parent calendars?  (this problem is pointed out in the
     editors note).
 18. Section 6.2.4.4, in the example query for moving "Nellis" to
     "area-51" there can only 0 or 1 calendars will match the query. Do
     we want to put in a statement that discusses what would happen if
     the query resulted in multiple calids (I'm not sure what it
     means).  Or do we want to state that the query can only produce 0
     or 1 result, and if more than 1 calids result from the query it
     would be an error ?
 19. Section 6.2.4.5, just past the last example we show this query:
     QUERY: SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com'   CALSTORE
     is being used as a special keyword here. We should probably list
     this somewhere or find another way to do the query.
 20. Section 6.3.3.1   was the Organizer intentionally left out of the
     ATTENDEE list?  Seems like the organizer should be in the attendee
     list.
 21. Section 6.3.3.4   the second part of the example is wrong.  C
     cannot send a DECLINECOUNTER.  DECLINECOUNTER is sent by the
     Organizer to the Attendee who countered.  C is not the Organizer.
     We'll fix it.

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Dec 2001 01:43:19 -0700

>      mention explicitly that this is out of the scope of [CAP]

Yes 

>      this sufficiently explicit? Should we list the character value

Yes, I can print lots of printable form feeds :-)

>      identical. I think it's a typo... or is it?

Yes - The formating/grouping is also incorrect:

Is:
     Use 'VEVENT,VTODO', not 'VEVENT, VTODO'
     Use 'DTSTART <= 20000605T131313Z', not
         'DTSTART <= 20000605T131313Z'.
     Use ' AND ' and ' OR ', not 'AND' and not 'OR'.

Should Be:

     Use 'VEVENT,VTODO', not 'VEVENT, VTODO'

     Use 'DTSTART <= 20000605T131313Z',
     not: 'DTSTART<=  20000605T131313Z'.

     Use ' AND ' and ' OR ', not 'AND' and not 'OR'.

>      and in other places we refer to it as CREATED.  I happen to
>      prefer being explicit and keeping it at CREATED, but whatever we
>      choose we must be consistent.

I agree - lets keep it 'CREATE' (same as METHOD:CREATE) not CREATEd.

>      it's important for synchronization applications to determine
>      which events have been deleted. If we use the METHOD property to
>      mark cancelled / deleted events, then the query needs to be
>      fixed.

Yes - I think the discussion took place as the changes were made.
I think that a hard working person edited too much :-)
Without the ability to tag objects as CANCELed and DELETEd, things
will bust - for synchronization.

>      2.0 and VERSION 2.1.  Let's pick one :-)

(A) We are NOT upgrading the format. Why would we update the
    iCalendar Version.
(B) Lets not wait for iCal-V-next.

>      component that contains it.  The delete command should apply to
>      the VTIMEZONES that exist at the calstore level.  I don't think
>      they only reference VTIMEZONE components that exist at the
>      calstore level.

In Chicago timefraime, I thought we agreed that the MODIFY
only has to list what makes something unique. So if you list
the *entire* alarm in the 'is' section, and not in the 'change to'
section - it gets deleted.

And  I would like to extend that idea for binary inline
attachments to say:

	When deleting inline binary attachments with METHOD:MOVE:
	
	Only sufficient octets to uniquely identify the attachment
	MAY BE sent. It is not necessary to send the entire contents
	of the inline attachment.

And add:

	When using the MODIFY command, the property values for
	inline attachments can only be updated, deleted, or
	added. You can not modify part if a inline binary attachment.

>      removes always processed before updates? does it matter?

I don't see how it can matter.

>      following: given that VCARs are hierarchic, moving a calendar
>      from one location in the hierarchy to another could possibly
>      change the access control considerably and yield unexpected and
>      unwanted results.  I think what we want to do is make sure that
>      the access control is at least as restrictive (and possibly more
>      restrictive) than it was prior to the move.  Note that with
>      hierarchic VCARs the way they are defined now, it may not be
>      possible to provide exactly the same access to a calendar as
>      prior to the move -- something further up the new hierarchy may
>      be more restrictive.  Also, there are ownership issues. Is there
>      something we want to say about the ownership of the new parent
>      calendar(s) given the owners of the previous parent calendars?
>      (this problem is pointed out in the editors note).

Last point first. - if you have the VCAR for it :-), you should
be able to move it.

I agree with the VCAR issues you point out. It's hard to say
what is more restrictive, adding access you did not want,
or no longer having  access denied.

The only way to do this would be to allow only moves to top
level calendars - where they can control all of their own VCARs.
And as that would be a kludge, should we drop the ability
to move calendars?

>      this somewhere or find another way to do the query.

In addition (reminder) we need to add back the VCAR and other
text back into CAP - and add CALSTORE and VSCHEDULE to the VCAR
and VQUERY ABNF - (if not already there).

>      ATTENDEE list?  Seems like the organizer should be in the
>      attendee list.

The ORGANIZER does not have to be in the ATTENDEE list.
I'll organize it - you do the work :-)

---

From: [email-masked] (Steve Mansour)
Date: Wed, 12 Dec 2001 08:48:21 -0800

> >      mention explicitly that this is out of the scope of [CAP]

OK. This is done.

> Yes, I can print lots of printable form feeds :-)

Right. Pat has the action item of giving us the exact character set.
Alright!

>      not: 'DTSTART<=  20000605T131313Z'.

got it.  Fixed.

> I agree - lets keep it 'CREATE' (same as METHOD:CREATE) not CREATEd.

We all came to that conclusion.  One suggestion was that we use "BOOKED"
instead of "CREATED".

> will bust - for synchronization.

OK. It we'll make it better.

> (B) Lets not wait for iCal-V-next.

Version 2.0 it is!

>         added. You can not modify part if a inline binary attachment.

George, Bruce, others... what do you think of this?

> Last point first. - if you have the VCAR for it :-), you should

agreed, question is which vcar gives you access to move a calendar into it?

> And as that would be a kludge, should we drop the ability

hmm... I think it's pretty severe to drop it.  Do people have an issue with
calenders possibly becoming more restrictive after a move?

> I'll organize it - you do the work :-)

Right.  But later in the example an Attendee sends another Attendee a
DECLINECOUNTER, which cannot happen. I've fixed up the example -- but I did
add the Organizer as an Attendee (I think this will be the most common
case).  Have a look at it and see what you think.

-Steve

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Dec 2001 14:46:02 -0700

> We all came to that conclusion.  One suggestion was that we use "BOOKED"

I could go for that, that would bring up another question.
Can I queue 'CREATE' and store it (like iTIP methods)? Or must
CREATE always be acted on and never stored?

> calenders possibly becoming more restrictive after a move?

I would towards dropping it until CAP-v-next. As pointed out in
another email, VCARs are complex, this just multiplies the states
changes to consider.

By dropping it, it does not mean you can not do it, it means
the WG has not thought out all of the VCAR issues.
Lets work out VCAR interoperability first, before we try
to make it more complicated. You can always - copy to new, delete old
until we have MOVE worked out.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 12 Dec 2001 17:45:36 -0500

> Right. Pat has the action item of giving us the exact character set.

Pat, we should comply with RFC 2396 (URI Generic Syntax)
(see section 2, URI Characters and Escape Sequences), and
follow RFC 2718 (Guidelines for new URL Schemes) as well.

> We all came to that conclusion.  One suggestion was that we use "BOOKED"

So the VSCHEDULE would now be:
METHOD != 'BOOKED' AND METHOD != 'DELETED' ?

> > (B) Lets not wait for iCal-V-next.

Doesn't the addition of new components (e.g., VAGENDA, VQUERY,
and VCAR) as well as new properties in existent components
(e.g., UID in VALARM) call for a new iCalendar version?

What's the safest?  Use VERSION:2.1 to warn presumably 2.0
compliant applications that they may not handle the object
properly, or use VERSION:2.0 and let them choke on it?

> >         When deleting inline binary attachments with METHOD:MOVE:

I assume you meant "the modify command".

> >         of the inline attachment.

Would it matter if the encoding used to specify the "sufficient
octets" is different from the encoding that was used to create
the attachement in the first place?  Will the server have to
decode the attachments to see if they match?

> agreed, question is which vcar gives you access to move a calendar into it?

See my last post.

> calenders possibly becoming more restrictive after a move?

I agree with John.  The server should not try to be smart
with my VCAR.

> > and VQUERY ABNF - (if not already there).

Doug, how do you intend to add VSCHEDULE into the VQUERY ABNF?

Salut!
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, 12 Dec 2001 16:51:56 -0700

> METHOD != 'BOOKED' AND METHOD != 'DELETED' ?

Or is it 'DELETE' ?

> (e.g., UID in VALARM) call for a new iCalendar version?

No, 2445 says that the objects are any IANA component
property, parameter, value type (my words). As long
as we don't change the format - it is 2.0.

> properly, or use VERSION:2.0 and let them choke on it?

If they choke, they were already busted as 2.0 is the 
format, not the version of iCalendar.

The problem is that in the future there could be X different
additions to iCalendar, only Y of which you need in your implementation.
If we bump the rev each time, that's X time Y versions. And for
no reason. They should be doing it right already.

> I assume you meant "the modify command".

Yes - thanks!

> decode the attachments to see if they match?

We should add something like:

		... of the resulting data after any decoding...

> > agreed, question is which vcar gives you access to move a calendar into it?

I am beginning to think that MOVE of calendars should not be 
in CAP at this time. Else, add VAGENDA to the valid VCAR objects
and treat it like the rest of the objects.

> > hmm... I think it's pretty severe to drop it.  Do people have an
> > issue with calenders possibly becoming more restrictive after a move?
> 

One persons smart is another persons dumb. The CS can never know
why you set the VCAR - only the CU can know that. It would be a
BIG mess. Let the CUA - COPY to new, delete old - the issues
say with the CU/CUA and not in the CS. Lets get CAP out the door
and figure out how to move a calendar without copy/delete
by the CUA later.

> Doug, how do you intend to add VSCHEDULE into the VQUERY ABNF?

As any other named object (+ any other IANA container, property,
parameter, parameter value, or value).

My Unix box main disk died - All of my data is backed up.
(It was 12 years old!) I have much of the IETF work on that box.
I'll send specific changes in the next few days.

---

From: [email-masked] (Steve Mansour)
Date: Wed, 12 Dec 2001 18:51:21 -0800

> CREATE always be acted on and never stored?

yea, this is weird, we use the "create" command to store METHOD:BOOKED  ???

maybe we should just stick with "CREATED"

-Steve

---

From: Patrice Lapierre <[email-masked]>
Date: Thu, 13 Dec 2001 08:13:15 -0500

Steve Mansour wrote:
>   6. Section 3.3 in the example, the MSG number changes from 4 to 2, shouldn't
>      they match?

  No this was on purpose, they are distinct messages originating from
different peers. The msgno 4 is for the client request and the 
associated reply from the server. The msgno 2 is for the the 
"timeout" request from the server and the associated reply 
from the client.

  A comment should probably be added to the example to make 
this clearer.

--
Patrice.

---

From: [email-masked] (Steve Mansour)
Date: Thu, 13 Dec 2001 11:21:38 -0800

Right. I talked with George about this at the meeting. I'm clear on it now.  Yes, we
should add some comments to clarify.
-Steve