Subject: [Fwd: I did a checkin of CAP]

From: Doug Royer <[email-masked]>
Date: Mon, 17 Jun 2002 12:43:02 -0600

An INTERIM version of CAP is available at:

	http://INET-Consulting.com/CAP-16-JUN-2002.txt

Please note that we hope to push the next official version of CAP
before the 24th cutoff date. (just because we want to get it out.)

Please send ME email for typo's (mailto:[email-masked]).

Please send what you think are changes that need to be
made to CAP - to this list (mailto:[email-masked]).

It was my intent to consolidate the list information. I suspect
as usual there will be issues - please we are open - just
send the objective facts of any issues.

I took text from -05, -06, and -07, and I am still comparing
for missing or extra text.

THIS IS STILL work in progress.

I have a list of 20 or so things left. Look for "TODO" where I
spotted these in the draft. 

	Double check to see that all properties and components
        have a definition section. (some missing).

	Add definitions for STATE(), OWNER(), NONOWNER(), CAL-QL
        and other CAP-QL text missing.

        Text to describe how to store and fetch pre-defined or
        stored VQUERYs.

        Double check all work.
       
I went through and changed all descriptions to use common
phrases and terminology. 

I organized and alphabetized the properties and components.
They were by section, however I think the sections leading
up to the property descriptions give the summary. 

In a few places I combined 2 or 3 sections into one section.
(VCARs for example)

There is more text to be added, mostly properties and CAP-QL
statements that were not defined, but used.

-Doug

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Jun 2002 13:40:42 -0400

In section 6.1.3 UPN-FILTER Value you are proposing to modify
the values "OWNER" and "NONOWNER" to "OWNER()" and "NONOWNER()"
respectively.

This proposition has already been discussed on the mailing list
in January 2002 and did not reach consensus.  See:

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

The syntax of UPN-FILTER has nothing to do with the CAP-QL
language.  There are no rational to have UPN-FILTER "look like"
CAP-QL.  There are no "OWNER()" and "NONOWNER()" functions in
CAP-QL anymore.  With the functions "SELF()", and "CAL-OWNERS()",
CAP-QL doesn't need "OWNER()" and "NONOWNER()".

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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Jun 2002 13:43:19 -0400

In section 6.1.1 CAL-QUERY Value Type you are proposing to add
the function STATE() to the col-value rule part.

As I mentionned on the mailing list in May 2002, this function is
ambiguous.  It is not clear to which component(s) it applies.
For instance, if the STATE() function applies to VEVENT in the
following query:

   SELECT * FROM VEVENT WHERE STATE() = 'BOOKED'

does it applies to VAGENDA in the following query?

   SELECT * FROM VAGENDA WHERE STATE() = 'BOOKED'

As I pointed out on the mailing list:

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

The state of a component should be sent on the wire to the CUA,
such that the CUA can easily find out the state of components
returned for an arbitrary search.  Otherwise, the CUA will be
forced to perform multiple search commands (i.e., one for each
state) when a single search could do.

My understanding is that the STATE() function attempts to solve
the issue about querying on the METHOD property, unfortunately,
it makes querying on this property an exception, and doesn't solve
the issue about querying on the X-PROP in iTIP objects.

For those interested I posted a proposal on the mailing list that
doesn't make query for iTIP objects a special case.  See:
http://www.imc.org/ietf-calendar/mail-archive/msg04640.html, and
http://www.imc.org/ietf-calendar/mail-archive/msg05008.html.

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Jun 2002 13:51:57 -0400

In section 7.1 VAGENDA Component you are proposing that:

>  To fetch all of the properties from the targeted VAGENDA.  This does
>  not feach any components:
>
>      SELECT * FROM VAGENDA
>
>  To fetch all of the properties from the targeted VAGENDA and all of
>  the contaied components, use the special '*.*' value:
>
>      SELECT *.* FROM VAGENDA

If this WG agrees to change the CAP-QL has you are proposing this
information should appear in the CAP-QL section and not in the
VAGENDA component registration.

Can you clarify what is the intent here?   Does your proposition
imply that

      SELECT * FROM VEVENT

will no longer return VALARM components contained in VEVENT
components as well?   Or are you making this an exception
exclusively for VAGENDA components?

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Jun 2002 13:53:33 -0400

In section 8.4 GENERATE-UID Command you are proposing that
the GENERATE-UID command returns an iCalendar object such as:

> BEGIN:VCALENDAR
> VERSION:2.0
> CMD;ID=unique-per-cua-124:REPLY
> UID:[email-masked]
> UID:[email-masked]
> UID:[email-masked]
> UID:[email-masked]
> UID:[email-masked]
> END:VCALENDAR

Futhermore, in section 8.5 GET-CAPABILITY Command you are proposing
that the GET-CAPABILITY command returns an iCalendar object such as:

> BEGIN:VCALENDAR
> VERSION:2.0
> CMD;ID=unique-per-cua-125:REPLY
> CAP-VERSION:1.0
> PRODID:The CS prodid
> QUERY-LEVEL:CAP-QL
> CAR-LEVEL:CAR-FULL-1
> DATE-MAX:99991231T235959Z
> DATE-MIN:00000101T000000Z
> MAX-COMPONENT-SIZE:0
> COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR,
>  VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT
> ITIP-VERSION:2447
> RECUR-ACCEPTED:TRUE
> RECUR-EXPAND:TRUE
> RECUR-LIMIT:0
> CS-STORES-EXPANDED:FALSE
> X-INET-PRIVATE-COMMANDS:1.0
> END:VCALENDAR

Clearly, these iCalendar objects violates RFC 2445.
Since, per RFC 2445 (section 4.6), iCalendar object
MUST include at least one calendar component.

As it is a requirement for CAP to obey RFC 2445. I
don't see any other solution than to return results
in new components such as:

  BEGIN:VUIDLIST
  UID:uid1
  UID:uid2
  UID:uid3
  END:VUIDLIST

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Jun 2002 14:04:19 -0400

In section 8.9 REPLY Command you are proposing to add a new
command REPLY to return the results of commands.

In my opinion, it doesn't makes sense to reply to a command
by a command!  REPLY being a command, should one reply to
this command as well?

It is clear to me that the identifier of a command should be
specified in a separate attribute (e.g., CMDID) and not as a
parameter of the CMD property, such that it is possible to
return a calendar component that contains a command identifier
(CMDID) and no command (CMD) (i.e., when returning the result
of a command).

I did send a full proposal on the mailing list that follows
the model that was specified in draft-05.  I haven't heard
any objections so far on the mailing list.

See examples:
  http://www.imc.org/ietf-calendar/mail-archive/msg04640.html
See specification:
  http://www.imc.org/ietf-calendar/mail-archive/msg05008.html

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Jun 2002 14:07:57 -0400

In section 4.2.4 Decreed VCARs you are proposing to add the
following statement:

> To the CUA any "VCAR" component with the "DECREED"
> property set to "TRUE" can not be changed by the currently
> authenticated UPN, and depending on the implementation and other
> VCARs; might not be able to be changed by any UPN using CAP.
         ^^^^^^^^^

That must be MUST NOT.

Decreed VCARs are "persistent and immutable" by definition, so
it doesn't make sense to allow someone to change a decreed VCAR
by using CAP.  Otherwise, a CUA will no longer be able to assume
that a decreed VCAR will remain the same for its entire session.

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Jun 2002 14:06:00 -0400

following statement:

> [...]
> A reply from the CS
> may dynamically create VCARs that are decreed depending on the
> implementation.
> [...]

This proposition has already been discussed on the mailing list
in February 2002 and did not reach consensus.

I still believe that it would not be a good idea to allow the
CS to add DECREED:TRUE on the fly in returned VCAR components.

For those interested check the following thread in the mailing
list archive:

http://www.imc.org/ietf-calendar/mail-archive/thrd2.html#03185

and the message in which I expressed my view on the subject:

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

Cheers,
Bernard

---

From: [email-masked]
Date: Thu, 20 Jun 2002 16:32:58 -0400

> > UID:[email-masked]
[Snip]
> > CMD;ID=unique-per-cua-125:REPLY
[Snip]
> in new components such as:

Nice idea.  Id suggest that you make a generic component to use, perhaps 
something like a VREPLY or a VRESPONSE (Editors pick as to the actual 
name). 

I suggest it so that we dont get a proliferation of new subcomponents 
whose sole purpose in the standard is to make sure we dont violate the RFC 
2445 tenant about containment.  That is, a VUIDLIST and a VCAPABILITY and 
a VGEEWHIZ and a VCAPV4FILLER and a... 

Since there is data to return in reponse to the command, make a generic 
container we can reuse for that purpose and let it be defined such that it 
can have anything in it (properties only, properties and other containers, 
etc) and then use the new container wherever needed.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 20 Jun 2002 15:05:56 -0600

> Nice idea.  Id suggest that you make a generic component to use,
> perhaps something like a VREPLY or a VRESPONSE (Editors pick as to the
> actual name).

Great idea, if there are no objections, I'l wrapp all replies
with a VREPLY (just because it is shorter than VERSPONSE :-).

Keep those cards and letters coming.

-Doug

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Jun 2002 16:25:38 -0400

In section 1.3 Definitions you are proposing the following definition:

> Booked -  An entry in the calendar store has one of three conceptual
>    states.  It is "UNPROCESSED", "BOOKED" or marked as "DELETED".
>    How the implementation stores the state of any object is not a
>    protocol issues and is not discussed.  An object can be said to be
>    booked, unprocessed, or marked for delete.

As I said before on the mailing list, we shouldn't be mixing the
state of a component (i.e., "unprocessed"/"booked") with the fact
that it has been marked for removal.  These are 2 different things.

It should be possible to differentiate a VEVENT marked for removal
from an iTIP object, containing a VEVENT, that has been marked for
removal.

The fact that a component has been marked for removal would be
better handled by a property which could easily be maintained
by CMD:MODIFY, and queried with CMD:SEARCH, just like any other
property.  What I'm saying here is the exact same thing as was
done in draft-05, where calendars could be marked for removal
by mean of the TOMBSTONE property.

Furthermore, I maintain that given a proper calendar store object
model we don't need a special CAP-QL function (such as STATE())
to differentiate "unprocessed" components (iTIP) from "booked"
components.

With the proposal I sent to the mailing list, finding all
"unprocessed" components is as easy as:

    SELECT * FROM VITIP

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Jun 2002 19:02:09 -0400

> perhaps something like a VREPLY or a VRESPONSE (Editors pick as to the

Good by me.  Such a component would provide a grouping of
component properties that describe the reply to a command.

Now, if you think about it, the CMDID, TARGET and perhaps
the REQUEST-STATUS properties should also go into this VREPLY
(or VRESPONSE) component.  This way, whenever the CUA specifies
more than one TARGET in a command it could receive an iCalendar
object with multiple VREPLY components, that is, one for each
TARGET.

For instance, the reply to an arbitrary search command for some
VEVENT components in multiple calendars could then look like
the following:

  BEGIN:VCALENDAR
  VERSION:2.0
  PRODID:-//XYZZY/CalendarServer//EN
  BEGIN:VREPLY
  CMDID:abcd1235
  REQUEST-STATUS:2.0
  TARGET:cap://cal.host.com/mary-relcalid     <-- Mary's target
  BEGIN:VEVENT
  [...]
  END:VEVENT
  END:VREPLY
  BEGIN:VREPLY
  CMDID:abcd1235
  REQUEST-STATUS:2.0
  TARGET:cap://cal.host.com/bob-relcalid    <-- Bob's target
  BEGIN:VEVENT
  [...]
  END:VEVENT
  END:VREPLY
  END:VCALENDAR

Cheers,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Jun 2002 19:11:40 -0600

>    SELECT * FROM VEVENT WHERE STATE() = 'BOOKED'

The same as when it was:

     SELECT * FROM VEVENT WHERE  METHOD = ' ...

>    SELECT * FROM VAGENDA WHERE STATE() = 'BOOKED'

The same as when it was:

     SELECT * FROM VAGENDA WHERE METHOD = '...

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Jun 2002 19:14:26 -0600

Bernard Desruisseaux wrote:
> components as well?

No

>   Or are you making this an exception
   (and VCALSTORE I assume?)

It says VAGENDA and VCALSTORE in the text, correct?

---

From: "Darryl Champagne" <[email-masked]>
Date: Sat, 22 Jun 2002 22:14:40 -0400

Hi,
I may be a relatively quiet lurker, and witnessing an ongoing dispute, but
could I ask for slightly more expansive responses?  I realize there is a
tendency to get annoyed, and answer with short, minimalistic responses, but
they are not especially informative for other people trying to better their
understanding of CAP.

Thanks,
dgc
Darryl G. Champagne               Openwave Systems Inc.
Mobile Development                One Burlington Woods Drive
Email: [email-masked]  Burlington, MA 01803 USA
(W) +1.781.313.1306               (M) +1.781.820.2283
-------------------------------------------------------------
Privacy and Confidentiality Notice:
The information contained in this electronic mail message
is intended for the named recipient(s) only. It may contain
privileged and confidential information.  If you are not an
intended recipient, you must not copy, forward, distribute,
or take any action in reliance on it. If you have received
this electronic mail message in error, please notify the
sender immediately.
-------------------------------------------------------------

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Friday, June 21, 2002 9:12 PM
To: [email-masked]
Subject: Re: STATE() is ambiguous and makes querying for METHOD an
exception

The same as when it was:

The same as when it was:

---

From: Doug Royer <[email-masked]>
Date: Sun, 23 Jun 2002 13:43:55 -0600

> they are not especially informative for other people trying to better their

Thanks for your reply. However the response is in total, there
was no change to the scope of the query response.