Subject: CAP: VCAR Proposal (#2)

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 05 Feb 2002 18:38:42 -0500

As promised, here's an updated version of my proposal on VCAR.

Highlight of changes:

- Re-ordered sections as in RFC 2445.

- CARID property is now mandatory.

- NAME property can now occur more than once, given some
  restrictions specified in the restriction tables.

- Added new component VRIGHT to group multiple access rights
  in a single VCAR component.

- Added new value type UPN-FILTER.

- Changed properties GRANT and DENY to be UPN-FILTERs.

- Changed syntax of the RESTRICTION property to be
  'cap-select' to allow restrictions on the type of
  components as well.

- Simplified some examples (using "SCOPE:SELECT * FROM VAGENDA"
  instead of multipled SCOPE instances for each type of
  component.

- I assumed that OWNER(), in addition to SELF(), was defined in
  CAP-QL.  I hereby officially propose that OWNER(), NONOWNER()
  and SELF() be added to the CAP-QL ABNF.

---------------------------------------------------------------------

x.x.1 Property Value Data Types

x.x.1.1 UPN Filter

   Value Name: UPN-FILTER

   Purpose: This value type is used to identify values that contain
   a user principal name filter.

   Formal Definition: The value type is defined by the following
   notation:

     upn-filter    = "OWNER" /
                     "NONOWNER" /
                     "*" /
                     ( "*" / *upn-char ) "@" ( "*" / 1*upn-char )

     upn-char      = <As defined for UPN>

   Description: The value is used to match user principal names (UPNs).

   Example: The following are examples of this value type:

    [ Editor's Note: Not sure this is the right place
                     for this information. ]

    OWNER       Matches the UPN equal to the OWNER
                property of the VAGENDA in which the
                encapsulating VCAR is stored.

    NONOWNER    Matches all UPNs different from the
                OWNER property of the VAGENDA in which
                the encapsulating VCAR is stored.

    *           Matches all UPNs.

    @           Matches the UPN of anonymous CUs
                belonging to the unnamed realm

    @*          Matches the UPN of anonymous CUs
                belonging to any named realm

    @realm      Matches the UPN of anonymous CUs
                belonging to the specified realm

    *@*         Matches the UPN of non-anonymous CUs
                belonging to any named realm

    *@realm     Matches the UPN of non-anonymous CUs
                belonging to the specified realm

    user@realm  Matches the UPN of the specified CU
                belonging to the specified realm

    user@*      Matches the UPN of the specified CU
                belonging to any named realm

x.x.2 Calendar Components

x.x.2.1 Calendar Access Right Component

   Component Name: "VCAR"

   Purpose: Provide a grouping of calendar access rights.

   Format Definition: A "VCAR" calendar component is defined by the
   following notation:

     carc    =  "BEGIN" ":" "VCAR" CRLF
                carprop 1*rightc
                "END" ":" "VCAR" CRLF

     carprop = 1*(

             ; 'carid' is REQUIRED,
             ; but MUST NOT occur more than once

             carid /

             ; the following are OPTIONAL,
             ; and MAY occur more than once

             name / x-prop / iana-prop
             )

   Description: A "VCAR" calendar component is a grouping of component
   properties, and "VRIGHT" calendar components, that represents access
   rights granted or denied to calendar users.

   The "CARID" property specifies the local identifier for the "VCAR"
   calendar component.  The "NAME" property specifies a localizable
   display name.

   Example: In the following example, the UPN "[email-masked]" is given
   read access to the "DTSTART" and "DTEND" VEVENT properties.  No other
   access is specified:

     BEGIN:VCAR
     CARID:abcd12345
     NAME:"View Start and End Times"
     BEGIN:VRIGHT
     GRANT:[email-masked]
     PERMISSION:READ
     SCOPE:SELECT DTSTART,DTEND FROM VEVENT
     END:VRIGHT
     END:VCAR

   In this example, all UPNs are given read access to "DTSTART" and
   "DTEND" properties of VEVENT components. "All CUs and UGs" are
	specified by the UPN value "*".  Note that this enumerated UPN
	value is not in quotes:

     BEGIN:VCAR
     CARID:abcd12345
     NAME:"View Start and End Times 2"
     BEGIN:VRIGHT
     GRANT:*
     PERMISSION:READ
     SCOPE:SELECT DTSTART,DTEND FROM VEVENT
     END:VRIGHT
     END:VCAR

   In this example, rights are specified for all UPNs to read VEVENT
	components classified as PUBLIC:

     BEGIN:VCAR
     CARID:abcd12345
     NAME:"View PUBLIC Start and End Times"
     BEGIN:VRIGHT
     GRANT:*
     PERMISSION:READ
     SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC'
     END:VRIGHT
     END:VCAR

   In this example, rights are specified for all UPNs to read or modify
   existing VEVENT components classified as PUBLIC:

     BEGIN:VCAR
     CARID:abcd12345
     NAME:"Read and Modify PUBLIC Calendar Entries"
     BEGIN:VRIGHT
     GRANT:*
     PERMISSION:READ
     PERMISSION:MODIFY
     SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC'
     END:VRIGHT
     END:VCAR

   In these examples, full calendar access rights are given to the
OWNER,
   and a hypothetical administrator is given access rights to specify
   calendar access rights.  If no other rights are specified, only these
   two UPNs can specify calendar access rights:

     BEGIN:VCAR
     CARID:abcd12345
     NAME:"Only OWNER or ADMIN Settable CARs"
     BEGIN:VRIGHT
     GRANT:OWNER
     PERMISSION:*
     SCOPE:SELECT * FROM VAGENDA
     END:VRIGHT
     BEGIN:VRIGHT
     GRANT:[email-masked]
     PERMISSION:*
     SCOPE:SELECT * FROM VCAR
     RESTRICTION:SELECT * FROM VCAR
     END:VRIGHT
     END:VCAR

   In this example, rights to write, read, modify or delete calendar
   access rights are denied to all UPNs.  This example would disable
   providing different access rights to the calendar store or calendar.
   This calendar access rights should not be specified, as they remove
   the ability to change calendar access; even for the owner or
   administrator:

     BEGIN:VCAR
     CARID:abcd12345
     NAME:"No CAR At All"
     BEGIN:VRIGHT
     DENY:*
     PERMISSION:*
     SCOPE:SELECT * FROM VCAR
     END:VRIGHT
     END:VCAR

x.x.2.2 VRIGHT Calendar Component

   Component Name: "VRIGHT"

   Purpose: Provide a grouping of component properties that describe an
   access right.

   Format Definition: A "VRIGHT" calendar component is defined by the
   following notation:

     rightc    =  "BEGIN" ":" "VRIGHT" CRLF
                  rightprop
                  "END" ":" "VRIGHT" CRLF

     rightprop = 2*(

               ; either 'grant' or 'deny' MUST
               ; occur at least once
               ; and MAY occur more than once

               grant / deny /

               ; 'permission' MUST occur at least once
               ; and MAY occur more than once

               permission /

               ; the following are optional,
               ; and MAY occur more than once

               scope / restriction / x-prop / iana-prop

               )

   Description: A "VRIGHT" calendar component is a grouping of calendar
   access right component properties.

   The "GRANT" property specifies the CU or UG to whom a calendar access
   right is granted.  The "DENY" property specifies the CU or UG to whom
   a calendar access right is denied.  The "PERMISSION" property
specifies
   the actual permission being set.  The "SCOPE" property identifies the
   calendar store properties, calendar properties, calendar components,
   component properties to which the access right applies.  The
   "RESTRICTION" property specifies restriction on the value that may
   take calendar store properties, calendar properties, calendar
components,
   and component properties after a WRITE or MODIFY operation.  Values
   MUST match all the instances of the RESTRICTION property to be valid.

x.x.3 Component Properties

   The following properties can appear within calendar components, as
   specified by each component property definition.

x.x.3.1 Descriptive Component Properties

   The following properties specify descriptive information about
   calendar components.

x.x.3.1.1 Name Component Property

   Property Name: NAME

   Purpose: This property provides a localizable display name for a
   calendar component.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VAGENDA" and
   "VCAR" calendar components.

   Description: This property is used in the "VAGENDA" and in the
   "VCAR" calendar components to specify a localizable display name.

   Format Definition: The property is defined by the following notation:

     name = "NAME" nameparam ":" text CRLF

     nameparam = *(
                    ; the following is optional,
                    ; but MUST NOT occur more than once

                    ( ";" languageparam ) /

                    ; the following is optional,
                    ; and MAY occur more than once

                    ( ";" xparam )
                  )

   Example: The following is an example of this property:

     NAME:"Restrict Guests From Creating ALARMs On Events"

x.x.3.2 Calendar Access Right Component Properties

x.x.3.2.1 Identifier Component Property

   Property Name: CARID

   Purpose: This property specifies the identifier for an access right
   calendar component.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property MUST be specified once in a "VCAR"
   calendar component.

   Description: This property is used in the "VCAR" calendar component
   to specify an identifier.

   Format Definition: The property is defined by the following notation:

     carid      = "CARID" caridparam ":" text CRLF

     caridparam = *( ";" xparam )

   Example: The following is an example of this property:

     CARID:abcd12345

x.x.3.3 Right Component Properties

x.x.3.3.1 Grant Component Property

   Property Name: GRANT

   Purpose: This property identifies the CU or UG being granted access
   in the VRIGHT component.

   Value Type: UPN-FILTER

   Property Parameters: Only non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VRIGHT" calendar
   components.

   Description: This property is used in the "VRIGHT" calendar component
   to specify the CU or UG being granted access.

   Format Definition: The property is defined by the following notation:

     grant     = "GRANT" grantparam ":" upn-filter CRLF

     grantparam  = *( ";" xparam )

   Example: The following are examples of this property:

     GRANT:*

     GRANT:[email-masked]

x.x.3.3.2 Deny Component Property

   Property Name: DENY

   Purpose: This property identifies the CU or UG being denied access
   in the VRIGHT component.

   Value Type: UPN-FILTER

   Property Parameters: Only non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VRIGHT" calendar
   components.

   Description: This property is used in the "VRIGHT" calendar component
   to define the CU or UG being denied access.

   Format Definition: The property is defined by the following notation:

     deny       = "DENY" denyparam ":" upn-filter CRLF

     denyparam  = *( ";" xparam )

   Example: The following are examples of this property:

     DENY:*

     DENY:[email-masked]
x.x.3.3.3 Permission Component Property

   Property Name: PERMISSION

   Purpose: This property defines a permission that is granted or
   denied in a VRIGHT component.

   Value Type: TEXT

   Property Parameters: Only non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VRIGHT" calendar
   components.

   Description: This property is used in the "VRIGHT" calendar component
   to define a permission that is granted or denied.

   Format Definition: The property is defined by the following notation:

     perm      = "PERMISSION" permparam ":" permvalue CRLF

     permparam = *( ";" xparam )

     permvalue = ( "READ" / "WRITE" / "DELETE" / "MODIFY" / all )

     all         = "*"

   Example: The following is an example of this property:

     PERMISSION:READ

x.x.3.3.4 Scope Component Property

   Property Name: SCOPE

   Purpose: This property identifies the objects in the CS to which
   the access rights applies.

   Value Type: capselect

   Property Parameters: Only non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VRIGHT" calendar
   components.

   Description: This property is used in the "VRIGHT" calendar component
   to define the set of objects subject to the access right being
defined.

   Format Definition: The property is defined by the following notation:

     scope      = "SCOPE" scopeparam ":" capselect CRLF

     scopeparam = *( ";" xparam )

   Example: The following is an example of this property:

     SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC'

x.x.3.3.5 Restriction Component Property

   Property Name: RESTRICTION

   Purpose: This property defines restrictions on the value that
   may take new or existent calendar components.

   Value Type: capselect

   Property Parameters: Only non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VRIGHT" calendar
   components, but only when the PERMISSION property is set to
   "WRITE", "MODIFY", or "*".

   Description: This property is used in the "VRIGHT" calendar component
   to define restrictions on the calendar components that can be written
   (i.e., by using the "create" or "move" commands) as well as on the
   values that may take existent calendar store properties, calendar
   properties, calendar components, and component properties (i.e.,
   by using the "modify" command).  Accepted values MUST match the
   specified RESTRICTION.

   Format Definition: The property is defined by the following notation:

     restrict      = "RESTRICTION" restrictparam ":" capselect CRLF

     restrictparam = *( ";" xparam )

   Example: The following are examples of this property:

     RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST'

     RESTRICTION:SELECT * FROM VEVENT WHERE ORGANIZER = SELF()

     RESTRICTION:SELECT * FROM VEVENT WHERE
CONTAINS(CATEGORIES,'BUSINESS')

------------------------------------------------------------------------

[Editor's Note: The purpose of predefined CARID needs to be specified. ]

Predefined calendar access CARIDs that MUST be implemented are:

CS MUST implement the following 

CARID:READBUSYTIMEINFO - grants all authenticated users the
right to read VFREEBUSY components.

   BEGIN:VCAR
   CARID:READBUSYTIMEINFO
   BEGIN:VRIGHT
   GRANT:*
   PERMISSION:READ
   SCOPE:SELECT * FROM VFREEBUSY
   END:VRIGHT
   END:VCAR

CARID:REQUESTONLY - grants to users other than the owner of
the calendar the right to write new events with the property
METHOD set to REQUEST.

   BEGIN:VCAR
   CARID:REQUESTONLY
   BEGIN:VRIGHT
   GRANT:NONOWNER
   PERMISSION:WRITE
   RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST'
   END:VRIGHT
   END:VCAR

CARID:UPDATEPARTSTATUS - grants all authenticated users the right
to modify the instances of the ATTENDEE property set to one of
their calendar adresses in the VEVENT and VTODO components for
which the ORGANIZER property is set to the address of the VAGENDA
in which the VEVENT or VTODO is stored, given that the submitted
value of the ATTENDEE property is one of their calendar adresses.

   BEGIN:VCAR
   CARID:UPDATEPARTSTATUS
   BEGIN:VRIGHT
   GRANT:*
   PERMISSION:MODIFY
   SCOPE:SELECT att FROM VEVENT
         USING_PROPERTIES ATTENDEE att
         WHERE att = SELF() AND ORGANIZER = OWNER()
   RESTRICTION:SELECT att FROM VEVENT
         USING_PROPERTIES ATTENDEE att
         WHERE att = SELF()
   END:VRIGHT
   BEGIN:VRIGHT
   GRANT:*
   PERMISSION:MODIFY
   SCOPE:SELECT att FROM VTODO
         USING_PROPERTIES ATTENDEE att
         WHERE att = SELF() AND ORGANIZER = OWNER()
   RESTRICTION:SELECT att FROM VTODO
         USING_PROPERTIES ATTENDEE att
         WHERE att = SELF()
   END:VRIGHT
   END:VCAR

CARID:DEFAULTOWNER - grants to the owner all permissions on
all the objects in the calendar.

   BEGIN:VCAR
   CARID:DEFAULTOWNER
   BEGIN:VRIGHT
   GRANT:OWNER
   PERMISSION:*
   SCOPE:SELECT * FROM VAGENDA
   END:VRIGHT
   END:VCAR

------------------------------------------------------------------------

   Restriction table for both "create" and "modify".

             Component/Property     Presence Comment
             -------------------    --------
-----------------------------

             . . VCAR               0+
             . . . CARID            1
             . . . NAME             0+       Note, there MUST NOT be
                                             more than one NAME with
                                             no LANGUAGE parameter,
                                             and there MUST NOT be
                                             more than one NAME with
                                             the same LANGUAGE value.
             . . . X-PROPERTY       0+
             . . . [IANA-PROP]      0+       any IANA registered
                                             property
             . . . VRIGHT           1+
             . . . . PERMISSION     1+
             . . . . DENY           0+       Note, there must be at
                                             least one GRANT or DENY
                                             within the VRIGHT.
             . . . . GRANT          0+       Note, there must be at
                                             least one GRANT or DENY
                                             within the VRIGHT.
             . . . . SCOPE          0+       Note, there must be at
least
                                             one SCOPE if PERMISSION is
set
                                             to "READ", "MODIFY",
"DELETE",
                                             or "*".
             . . . . RESTRICTION    0 or 0+  Note, allowed only if
                                             PERMISSION is set to
                                             "WRITE", "MODIFY", or "*".
             . . . . X-PROPERTY     0+
             . . . . [IANA-PROP]    0+       any IANA registered
                                             property

------------------------------------------------------------------------

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: Tue, 05 Feb 2002 18:34:02 -0700

Bernard Desruisseaux wrote:

Great - but I am sure you know I have suggestions :-)

>   and SELF() be added to the CAP-QL ABNF.

They are not in the text I checked in today - but I agree
that they are needed. Any objections?

Where OWNER() == any one of the UPN's listed in the
                 VAGENDA OWNER properties.

>                 encapsulating VCAR is stored.

...equal to any OWNER - correct?

(as opposed to 'the' OWNER).

>                 the encapsulating VCAR is stored.

Same here - ...different from any OWNER... ?

>                 belonging to the unnamed realm

You need to define 'unnamed realm'. I know it is the
the WG mailing list - I don't remember what it is and
it is not currently defined in CAP (or this proposal).

>                 belonging to any named realm

Same here - define a 'named realm'.

>                 belonging to the specified realm

In a previous email you said that the CS is not required
to do a reverse DNS lookup to find the 'belonging' to realm.
Do you mean the realm the UPN supplied as part of it authentication?
If not - what is it?

>    rights granted or denied to calendar users.

Add - "and the default is DENY".
Agree?  We have to have some default, and the security guys
in the past said the default should be to deny anything not
specifically granted.

>         components classified as PUBLIC:
nnn> 
>      SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC'

Questions / comments:

	You use quotes (") in the text value of the NAME
	property, that is optional - just like it is optional in
	any TEXT value property? Correct?

	They all have the SAME CARID in your examples.
	I think we need to add text that says that a CARID
        MUST BE unique within its scope.

>      SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC'

You define PERMISSION in x.x.3.3.3 below as a TEXT value type.
A TEXT value type can have multiple values, separated
by commas.

So this is also valid? If not, there needs to be
restrictions specified in the proposal.

	PERMISSION:READ,MODIFY

>    the ability to change calendar access; even for the owner or

Or it is the perfect data to add to a CAR-MIN CS that
only has decreed VCARs and does not wish to give READ access
to those VCARs.

     So I think the the "...should  not be specified..." sentence
     needs to be:

	This calendar access rights should not be specified unless
        all of the VCARs are decreed and the CS wishes to not
        allow any UPN to query for any of those decreed VCARs.

>	....

As CAP-QL, RESTRICTION, and SCOPE have the same value type, we
need to define a CAPSELECT value type. Much like 2445 defines
TEXT, BINARY, ... value types, then modify CAP-QL/QUERY and
VCAR/SCOPE to say that they have a value type of CAPSELECT.

And I think we need to add a note that the CAPSELECT value-type
is a valid "iana-token" value as defined
in 2445 "4.2.20 Value Data Types".

This is a complex and formatted data type. I think it
needs is own standalone 'IANA registration' section.

Agree?

And below you call the value for GRANT and DENY
a 'upn-filter' value type. I know what you mean, but
there is no such thing as a 'upn-filter' value type.
They need to be:

	(1) TEXT value type, with specific restrictions to
            its content.
or
	(2) We need to define UPN-FILTER as a valid VALUE type
            like I think we need to do with CAPSELECT.
            (which is what you call them below - value types).

I would opt for (1).

>      NAME:"Restrict Guests From Creating ALARMs On Events"

Again, the (")'s are optional - right?

> x.x.3.2.1 Identifier Component Property

I think the above section title needs renamed,
perhaps "VCAR Identifier".

It only identifies VCARs and not 'any' component - correct? 

>      carid      = "CARID" caridparam ":" text CRLF

And BOOLEAN parameter 'DECREED' ?

Or was that going to be a property?

Or were we going to force the CUA to figure it out after
reading the VCARs?

>    Purpose: This property identifies the CU or UG being granted access

Specifies the UPN subject to the upn-filters,
not the CU or UG - correct? The 'CU' is an entity that
may have multiple UPNs.

Same with UG, it is the CS's responsibility
to expand any UPN *if* it happens to be a UG, but we are only
restricting or granting based on UPN - correct?

> x.x.3.3.2 Deny Component Property

Same issues with DENY as GRANT above.

>    the access rights applies.

And as I said above, lets make 'capselect' and official value type.

> right to read VFREEBUSY components.

We are NOT defining them as MUST have 'this' content,
add:

>    SCOPE:SELECT * FROM VFREEBUSY

Add:

   In order to make this a decreed VCAR, an implementation would
   have to add something like the following to the above suggested VCAR.

     BEGIN:VRIGHT
     DENY:*
     PERMISSION:WRITE,MODIFY
     SCOPE:SELECT * FROM VCAR WHERE CARID = 'READBUSYTIMEINFO'
     END:VRIGHT

Add: (similar notes to the other predefined VCAR CARIDs,
      or one general statement that covers them all).

> value of the ATTENDEE property is one of their calendar adresses.

Technical wording issue:

	Where the value matched their authenticated UPN. The
        CS would not know their 'calendar addresses' (two places).

What about delete? (Not that I can't guess - but what about
the new reader?)

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 12:52:54 -0500

> Same here - ...different from any OWNER... ?

You are correct.  OWNER is currently 1+ in the draft.

Did this WG thought through the issues involved with
allowing multiple owners?

Since we invite calendars and not users, only one owner
can (need to) reply to an invitation?

Are there any issue with multiple instances of RELATED-TO?

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 12:46:33 -0500

>                  VAGENDA OWNER properties.

I realize that we can't use OWNER(), NONOWNER() and SELF()
as I did in my proposal.  For instance, the following
"cap-select" statement suffers from 2 type mismatches:

  SELECT att FROM VEVENT

That is,

  1- att = SELF()

     att is an ATTENDEE which is a calendar
     address (CAL-ADDRESS) and SELF() returns
     a user principal name (UPN).  Bug! :-)

  2- ORGANIZER = OWNER()

     where ORGANIZER is a calendar address
     (CAL-ADDRESS) and OWNER() returns a list
     of user principal names (UPN).  Bug! :-)

To iron out these bugs, I propose the following
additions to CAP-QL:

Function: CAL-OWNERS( CAL-ADDRESS )

    Returns a SET containing the UPNs of all the OWNERs
    of the specified calendar address.  UG UPN are
    expanded to CU UPN in the returned set.

Function: CURRENT-CAL-ADDRESS()

    Returns the calendar address of the queried
    source (i.e., VAGENDA or CALSTORE).  To get
    the OWNERs of the queried source we could do:
       CAL-OWNERS( CURRENT-CAL-ADDRESS() )

Operator: IN   (e.g., "elem IN set")

    Returns TRUE if "elem" is in "set", else it
    returns FALSE.

Thus, the "cap-select" statement could be written
as follows:

  SELECT att FROM VEVENT
  USING_PROPERTIES ATTENDEE att
  WHERE SELF() IN CAL-OWNERS(att) AND
        ORGANIZER = CURRENT-CAL-ADDRESS()

Comments?

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 13:01:19 -0500

> it is not currently defined in CAP (or this proposal).

I'll simply use "null" as in section 2.4.4 "CAP Session Identity".
The UPN-FILTER value type is based on the UPN value type which is
not yet formally defined with an ABNF.  I'll rely on the fact that
the definition of UPN will need to provide the definition of "null".

> Same here - define a 'named realm'.

I'll use "non-null" as in section 2.4.4.

> to do a reverse DNS lookup to find the 'belonging' to realm.

DNS provides information on Internet domains NOT realms.
DNS is of no use to find the realm to whom you belong.

> Do you mean the realm the UPN supplied as part of it authentication?

It is the UPN that identifies the authenticated user, that is,
after sufficient credentials were provided to an authentication
mechanism.  Whether the UPN itself is provided as part of the
credentials or not is irrelevant.  I could provide an X.500
distinguished name and a clear text password as my credentials
and still be identified as "[email-masked]" (my UPN) in
the CS.

> in the past said the default should be to deny anything not

That's already covered in section 2.4.2 "Access Rights - Summary".
My proposal does not intend to replace this text.  On the other
hand, we will need to make sure nothing is missing from this section
as well.

>         any TEXT value property? Correct?

Correct.  These values used to be specified in the CARID
property with double quote (") and I did not bothered
removing them.  I will remove them to avoid confusion.

>         MUST BE unique within its scope.

Yes.

How shall we express "scope" in:

The CARID itself MUST be a unique identifier within ???

> restrictions specified in the proposal.

The ABNF for PERMISSION does not allow this.
I don't think I need to change anything. Have
a look at the TRANSP property in RFC 2445.

What you are saying is true for CATEGORIES,
but not for PERMISSION and TRANSP.

>         allow any UPN to query for any of those decreed VCARs.

I will simply change "should not be specified" to
"should be specified with great care".

> VCAR/SCOPE to say that they have a value type of CAPSELECT.

That's right.

> needs is own standalone 'IANA registration' section.

How would that be different from the format that I've
used to define "Value Type", "Calendar Component" and
"Component Properties" in my proposal?

Isn't it implicit that all new "Value Type", "Calendar
Component" and "Component Properties" are indeed valid
iana-token?

Let me know if I haven't used the right format.

>             (which is what you call them below - value types).

I already did (2).  See very first section of the proposal.

> Again, the (")'s are optional - right?

Correct.

> perhaps "VCAR Identifier".

Okay.

> Or were we going to force the CUA to figure it out after

I'll add the DECREED property and I'll modify the
restriction tables as follow:

             . . . . DECREED        0        This property is outside
                                             the scope of the protocol.

Agree?

> not the CU or UG - correct? The 'CU' is an entity that

Correct.

> restricting or granting based on UPN - correct?

Correct.

> Same issues with DENY as GRANT above.

Yes.

> And as I said above, lets make 'capselect' and official value type.

I propose the name "CAL-QUERY" as the name of this
new value type.  I don't think value type should
bear the name of any protocol making use of them
(e.g., "CAP").  Agree?

>    A suggested content for the READBUSYTIMEINFO is:

I agree.

>       or one general statement that covers them all).

Decreed also mean "persistent and immutable" so this is
not sufficient.

Can you agree that in order to make a VCAR decreed you
ONLY have to specify DECREED:TRUE in the VCAR component?

> What about delete? (Not that I can't guess - but what about

An oversight from my part.  This information will need
to appear in many places in the draft.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 11:51:26 -0700

>     expanded to CU UPN in the returned set.

I assume returned in comma separated format like
any other multi-value property value?

Which would include quoting if needed and backslash escaping
if needed?

>        CAL-OWNERS( CURRENT-CAL-ADDRESS() )

Returns the CALID, not the RELCALID - correct?

>         ORGANIZER = CURRENT-CAL-ADDRESS()

Yes - and it is the same as the SQL 'IN' and seem to
do the same thing.

Also "NOT IN".

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 12:02:39 -0700

> allowing multiple owners?

Yes, it was changed to a multi-instances, single value in 05
or earlier. (this text from 06)

   OWNER           N    URI       A multi-instanced property
                                  indicating the calendar owner.
                                  Each entry returned will be a
                                  UPN. There must be at least one
                                  owner.

> can (need to) reply to an invitation?

Also [iTIP] 2.1.3 Acting on Behalf of other Calendar Users

  ...Second, a "sent-by" parameter may be specified in either the
   "Organizer" or "Attendee" properties. When specified, the "sent-by"
   parameter indicates that the responding CU acted on behalf of the
   specified "Attendee" or "Organizer".

So you can have your assistant be able to connect to your
calendar and REPLY for you - and they do not need to be an OWNER
of your calendar.

> Are there any issue with multiple instances of RELATED-TO?

According to Bruce, the RELATED-TO property needs to be multi
instance single value. I have no problem with that.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 14:41:50 -0500

> Which would include quoting if needed and backslash escaping

Do you mean?

  CAL-OWNERS(ATTENDEE) = [email-masked]', [email-masked]'

If so, that's fine with me.

> Returns the CALID, not the RELCALID - correct?

Yes.  We should even rename the function
to 'CURRENT-CALID()'.  Correct?

> Yes - and it is the same as the SQL 'IN' and seem to

Great!

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 13:06:15 -0700

I removed the UPN discussion from this reply. I'll need
to see the new text to understand. I don't yet.

> That's already covered in section 2.4.2 "Access Rights - Summary".

Yep - I missed that.

> The CARID itself MUST be a unique identifier within ???

How about?

   Any CALSTORE VCARS must be unique in the CALSTORE.
   Any VCARs in the CALSTORE override any in all contained
   VAGENDAs where the CARID are the same.

   Any VAGENDA VCARs must be unique in the VAGENDA.
   Any VAGENDA VCARs override any in all contained components
   where the CARID is the same in the VAGENDA.

   Any VCARs contained in any component must have unique CARIDs
   with respect to any other VCAR in that component.

This keeps the calendar owner from overriding any administrative
VCARs. And it keeps someone from depositing a REQUEST that
allows them to override the owners VCARs.

And it also allows the administrator or implementation
to allow the calendar OWNERs to define the VCARs for their calendars
by not defining them at the CALSTORE level.

> but not for PERMISSION and TRANSP.

The TANSP property is defined as single instance in 2445 grammar
and the 2446 restriction tables as there is only one state
the value can be for any given component.

The PERMISSION property is defined as multiple instance
in your proposal and each one is NOT declared in the
proposal as MUST BE be unique per component.

Which is why I was asking - it is not clear to me if it is allowed.
And if it is not allowed - why not as it can be one of several
combination of values? It is not fixed to one state per component.
So why is it single value multiple instance, and not single instance
multiple value? Or multiple instance, multiple value like CATEGORIES?

Is there are reason?

I agree.

> "Component Properties" in my proposal?

It allows them to be valid as the right hand side
of the 'VALUE=" parameter.

The 2445 registration procedure for new properties
specifies that they must be declared. I will 'declare'
CAL-QUERY value type (as you pointed out you did for UPN-FILTER).

I'll rip it out or modify the CAP-QL proposal and make it a stand
alone section that explicitly declares it to be a new
value type.

> Component" and "Component Properties" are indeed valid

We have to 'register' it somewhere so that it is explicitly
visible. We used it as if it is a value type, but we have
to declare that it is.

>                                              the scope of the protocol.

I don't follow. I don't think so.

You and others at Steltor have asked several times "how do
you know that it is DECREED". Are you now saying that
you don't want to define how to tell if it is decreed?

If you are saying "you do not care", then no, we need to be
able to define the VCAR it in the VCAR itself that it is
read-only. That must be by adding another VRIGHTs component,
or by a 'DECREED' property - that is defined.

> > not the CU or UG - correct? The 'CU' is an entity that

So, I assume this means your going to update the text? :-)

> ONLY have to specify DECREED:TRUE in the VCAR component?

Yes - you need to add a new property definition with
a boolean value DECREED.

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 13:36:50 -0700

Yes.

Yes.

> > Yes - and it is the same as the SQL 'IN' and seem to

After thinking about it, by mofifying the definition of 'CONTAINS'
to mean the left hand side is the value of the named property
or function:

   SELECT att FROM VEVENT
   USING_PROPERTIES ATTENDEE att
   WHERE CONTAINS(CAL-OWNERS(att), SELF())
    AND ORGANIZER = CURRENT-CAL-ADDRESS()

Correct? So do we need 'IN' ?

Or should we replace CONTAINS with 'IN' (this option
sounds better to me) ?

   SELECT att FROM VEVENT
   USING_PROPERTIES ATTENDEE att
   WHERE SELF() IN CAL-OWNERS(att)
    AND ORGANIZER = CURRENT-CAL-ADDRESS()

And 'IN' also works with:

   WHERE "value1" in CATEGORIES

If we write the text correcty.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 16:05:43 -0500

> Or should we replace CONTAINS with 'IN' (this option

I agree.  Let's replace CONTAINS with 'IN'.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 16:59:32 -0500

> by not defining them at the CALSTORE level.

As you said recently, we all need to keep each other from
inventing new things at this point in time. :-)

I would like to keep it simple and just say:

  The CARID MUST uniquely identify VCAR components within
  the components they are stored (i.e., VAGENDA or CALSTORE).

Correct?

> multiple value? Or multiple instance, multiple value like CATEGORIES?

It is clear that the current ABNF doesn't allow it.

The allow it the perm rule-part would need to
be written as follow:

     perm      = "PERMISSION" permparam ":" permvalue
                 *( "," permvalue ) CRLF

Do you have a problem with PERMISSION being single
value multiple instance?

> alone section that explicitly declares it to be a new

Good.

I'll change my proposal to obey to RFC 2445 as well.
I neglected to specify the following:

  To: [email-masked]
  Subject: Registration of text/calendar MIME property XXX

:-)   Here's the reason:

  > 2.4.2.2 Decreed VCARs
  >
  > ...
  >
  >   The CAP protocol does not define the semantics used to initially
  >   create a decreed VCAR.  This administrative task is outside the
scope
  >   of the CAP protocol.

Agree?

> So, I assume this means your going to update the text? :-)

Of course! :-)   

"Purpose: This property identifies the UPN(s) being granted access
 in the VRIGHT component."

UPN with "(s)" since "[email-masked]" will identify many UPNs.

> Yes - you need to add a new property definition with

I will.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 16:18:47 -0700

> Do you have a problem with PERMISSION being single

My only problem is - why restrict it. it seems the 
perfect example of why 2445 allows multi valued properties.

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 16:16:36 -0700

>   the components they are stored (i.e., VAGENDA or CALSTORE).

So who wins the access? If we don't specify it, one CS vendor
may implement it one way, and another CS vendor
the opposite way.

I did not think I was inventing anything, just defining
what I think is the only precedence order that will work.
Other implementation may disagree - then we do not
have interoperability.

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 16:21:15 -0700

Bernard Desruisseaux wrote:

>   >   scope of the CAP protocol.
> 
> Agree?

Did (in your original email) means that that would only
apply the above limitation to the <create> command? If so,
I misunderstood.

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 16:23:21 -0700

Yes.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 20:47:46 -0500

> Other implementation may disagree - then we do not

Recently, this WG has agreed to drop VCAR inheritance.
We should not introduce new rules at this time to specify
that VCARs in the CALSTORE can override VCARs in VAGENDAs
if they have the same CARID.  By doing so CUA would need
to worry about the CARIDs in use in the CALSTORE. It would
no longer be true that CARID only need to be unique within
VAGENDAs.

We just need to write a statement to say that all the VCARs
stored in a VAGENDA MUST have different CARID, and that all
the VCARs stored in the CALSTORE MUST have a different CARID.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 21:28:29 -0500

> apply the above limitation to the <create> command? If so,

Decreed VCARs are persistent and immutable.

That means you won't be able to <create>
<modify>, <delete> and <move> them with
the CAP protocol.  Right?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 19:46:34 -0700

> > may implement it one way, and another CS vendor

(What I had proposed was not VCAR inheritance, it was
 VCAR precedence which is not the same issue).

> the VCARs stored in the CALSTORE MUST have a different CARID.

I hope you mean that:

	2 or more VAGENDAs may have the same CARID as long
	as that CARID does not exist in the CALSTORE?

And I could live with that. It means that the precedence
between the CALSTORE and all VAGENDAs is that the first one
to use CARID - wins. The other gets an error. And that two or
more VAGENDAs may have the same CARID.

Agree?

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 19:58:40 -0700

> <modify>, <delete> and <move> them with

So what does the above apply to? I am lost as to what you will
add the DECREED property to - which restriction table - you
are saying all?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 22:23:08 -0500

>         as that CARID does not exist in the CALSTORE?

No.  The VCARs stored in the CALSTORE don't have
any impact on the VCARs stored VAGENDAs.

> more VAGENDAs may have the same CARID.

1- We don't need that.  The DEFAULT-VCARS will be copied in
   each VAGENDA at creation time, and if the administrator
   wants to override VCARs in VAGENDA he'll simply have to
   set the VCARs in the VAGENDAs to deny users the right to
   modify them.

2- By doing so, an administrator could screw up all my
   access rights if he creates a VCAR with the same CARID
   as mine by accident.  I'm sure nobody wants that.

Again, let's keep it simple.  We did away with VCAR
inheritance.  Let's not add back any more complexity.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 08 Feb 2002 09:15:37 -0500

> perfect example of why 2445 allows multi valued properties.

A property doesn't need to be both multiple instances
and multiple values.

Furthermore, with multiple instances, multiple values
properties you can specify the same thing in different
ways that may lead to different results in some
situations.

For instance, given the following CAL-QUERY values:

  1- SELECT perm FROM VCAR
       USING_PROPERTIES PERMISSION perm
       WHERE perm = 'READ'

  2- SELECT perm FROM VCAR
       USING_PROPERTIES PERMISSION perm
       WHERE 'READ' IN perm

What would be returned for:

  a) PERMISSION:READ,WRITE

     1- Nothing!
     2- PERMISSION:READ,WRITE

  b) PERMISSION:READ
     PERMISSION:WRITE

     1- PERMISSION:READ
     2- PERMISSION:READ

If you agree with my results, do you think it is desirable
that we get different results?

If you disagree with my results, why bother and not use
single value multiple instances?

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 08 Feb 2002 10:17:45 -0500

>                                   the scope of the protocol.

Actually, we only need to specify this in the restriction
table of the "create" command (section 6.2.4.1) since the
following is specified for the "modify" command:

  > The modifications MUST only be applied if the
  > resulting component respects the restriction
  > table of the "create" command.

Agreed?

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 08 Feb 2002 10:27:26 -0500

Just to make sure we are all on the same page.

We agreed to:

- Remove function CONTAINS() ;

- Add operator IN ;

- Add function CAL-OWNERS( CAL-ADDRESS )

- Add function CURRENT-CALID() ;

- Add function SELF() ;

That is, previously discussed functions OWNER()
and NONOWNER() will NOT be added to CAP-QL.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 08 Feb 2002 12:00:23 -0500

> calendar and REPLY for you - and they do not need to be an OWNER

Do you mean that we DON'T need multiple OWNER for
that reason?

Beside, given that you could set your VCARs to grant
others the rights to fully manage your VAGENDA do we
really need multiple OWNERs in VAGENDA? I would say no.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Feb 2002 12:03:05 -0700

> that we get different results?

For multi instance properties the following two are equivalent:

	PROPERRY:READ,CREATE
	
	PROPERTY:READ
	PROPERTY:CREATE

I am looking for it, but I am sure that we have declared
in some RFC or draft, that the above two are always equivalent.
If what I think is true, you are declaring that PERMISSION
is the exception to the rule. That will break parsers.
And any VQUERY implementation will already have to take
that into account for multiple other multi instance properties.

So, I'll add a note to CAP-QL that reminds implementors
that as multi-instance properts can also be provided as
multi-value, the CS QUERY implementation must take that
into account and check all instances and all values
when dealing with multiple-instance properties.

> single value multiple instances?

My point is that I believe they are supposed to be equivalent
(both ways).

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Feb 2002 12:06:47 -0700

Yes.

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Feb 2002 12:20:01 -0700

ers
> Do you mean that we DON'T need multiple OWNER for

No - I was respoding to the fact that the reply can come from
a non-OWNER.

> really need multiple OWNERs in VAGENDA? I would say no.

Decreed VCARs - grant OWNERs ...
How would you manage those?

It also simplifies VCARs 'SELECT .... WHERE OWNER() ...'
Otherwise you have to specificy tweak possibly multiple VCARs
some of which you may not have access to tweak.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 08 Feb 2002 15:37:42 -0500

Doug Royer wrote:
> is the exception to the rule.

There is no such rule.

> That will break parsers.

You MUST be joking!  Think about it for a second.

> that into account for multiple other multi instance properties.

It doesn't mean that every new property needs to be
multiple values, multiples instances.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Feb 2002 15:13:55 -0700

> You MUST be joking!  Think about it for a second.

No I am not. In the example you provided in this thread,
replace PERMISSION with RELATED-TO and perform a similar query
where you had (edited for RELATED-TO):

	  1- SELECT perm FROM VCAR
	       USING_PROPERTIES RELATED-TO rel
	       WHERE rel = 'relcal-1'

	  2- SELECT perm FROM VCAR
	       USING_PROPERTIES RELATED-TO rel
	       WHERE 'relcal-1' IN rel

	  a) RELATED-TO:relcal-1,relcal-2

	     1- Nothing!
	     2- RELATED-TO:relcal-1,relcal-2

	  b) RELATED-TO:relcal-1
	     RELATED-TO:relcal-2

	     1- PERMISSION:relcal-1
	     2- PERMISSION:relcal-1

It has to be true! The CUA must ask for what it wants.
If it uses query (1), it better understand why it may get
no data back (a-1).

And the same is true for RRULE. It is the CUA that did 
not query for what it wanted. It is not the fact that it
allows multiple values or instances. It is because
iCalendar allows multiple values and instances that that
must be true.

And each way of doing it is equivalent. Its the CUA
that must understand that.

---

From: Alan Davies <[email-masked]>
Date: Fri, 08 Feb 2002 17:30:14 -0500

>For multi instance properties the following two are equivalent:

If that's true, than we'd have to make a change to our CAP-QL
proposal; we wouldn't need the function that we created for
querying comma seperated values; they could just be queried
like multi-properties.

Of course, an exception to your multi-instance property 'rule'
would be the RRULE value, which uses the comma for it's own
purposes.

--Alan

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Feb 2002 16:41:47 -0700

> querying comma seperated values; they could just be queried

It was already part of the CAL-QL #3 proposal (see end of
this email for a summary)

> would be the RRULE value, which uses the comma for it's own

Any property that has a multiple values and where any
of the values contain a comma, must be quoted or escaped
as described in 2445. Otherwise the comma would be
a value separator.

	For the values (1), (2), and (3):

	PROP:1,2,3		One multi valued property

Equivalent to:

	PROP:"1", "2", "3"

And is equivalent to:

	PROP:1
	PROP:2
	PROP:3

And for values (part,one), (part,two), and (part,three):

	PROP:"part,one","part,two","part,three"

Is equivalent to:

	PROP:"part,one"
	PROP:"part,two"
	PROP:"part,three"

But is NOT equivalent to (because the comma means value separator):
	
	PROP:part,one
	PROP:part,two
	PROP:part,three

The RRULE is both multi-valued, and multi-instance.
As in both of these are valid in a VEVENT and are equivalent.

	RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
	RRULE:FREQ=YEARLY;BYDAY=-1SA;BYMONTH=10

Is equivalent to:

	 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=1,FREQ=YEARLY
	  ;BYDAY=-1SA;BYMONTH=10

The following was part of CAP-QL (#3) proposal as
note (7 - LIKE) and (8 - CONTAINS [now IN]):

             The CS must understand the objects being compared and
             understand how to determine how any multi valued property
             or parameter values are separated, quoted, and backslash
             escaped and perform the comparisons as if each value
existed
             by itself and not quoted or backslash escaped when
comparing
             using the CONTAINS() [or LIKE] element.

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Feb 2002 17:31:18 -0700

I agree.

> - Add operator IN ;

I agree. And also add NOT IN.

> - Add function CAL-OWNERS( CAL-ADDRESS )

I agree, And also add NOT CAL-OWNERS( CAL-ADDRESS )

> - Add function CURRENT-CALID() ;

I agree. Which returns the full CALID and not a RELCALID.

> - Add function SELF() ;

I agree. And allow NOT SELF().

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 11 Feb 2002 09:33:28 -0500

> The RRULE is both multi-valued, and multi-instance.

You are wrong.  RRULE is NOT multi-valued.

>          RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=1,FREQ=YEARLY

This is not legal per RFC 2445.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 11 Feb 2002 09:29:57 -0500

> where you had (edited for RELATED-TO):

1- What does RELATED-TO has to do with PERMISSION?
   It's not because some properties are multi-valued
   that they all need to be.

2- RELATED-TO is NOT a multi-valued property.

   From RFC 2445:

     related    = "RELATED-TO" [relparam] ":" text CRLF

   To be multi-valued its rule part would have
   need to be written as follow:

     related    = "RELATED-TO" [relparam] ":" text *("," text) CRLF

   But it was NOT.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 11 Feb 2002 10:13:18 -0500

> I agree. And also add NOT IN.

It's not really necessary since we must be able to write:

  NOT ( elem IN set )

If you really insist on adding this additional operator,
I would recommend naming it "NOT-IN" in one word.

> I agree, And also add NOT CAL-OWNERS( CAL-ADDRESS )

CAL-OWNERS() returns a set of UPNs, not a boolean value.
So it doesn't make sense to write "NOT" in front of this
function.

Yes.

> I agree. And allow NOT SELF().

SELF() returns a UPN value, not a boolean value.
So it doesn't make sense to write "NOT" in front
of this function.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Feb 2002 08:24:30 -0700

> You are wrong.  RRULE is NOT multi-valued.

I guess I was confused when I read in 2445:

  4.3.10 Recurrence Rule

   Description: If the property permits, multiple "recur" values are
   specified by a COMMA character (US-ASCII decimal 44) separated list
   of values. ...

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Feb 2002 09:05:46 -0700

> I would recommend naming it "NOT-IN" in one word.

No, that would be inconsistant with the other 'NOT' operators.
And:

	SELECT * FROM VEVENT WHERE 'abc' NOT IN proprety

reads better than

	SELECT * FROM VEVENT WHERE NOT 'abc' IN propert.

> So it doesn't make sense to write "NOT" in front of this

Your right - it would be: 'upn' NOT IN CAL-ONWERS( CAL-ADDRESS )

Ditto - SELF()

---

From: Alan Davies <[email-masked]>
Date: Mon, 11 Feb 2002 12:14:50 -0500

>         RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=1,FREQ=YEARLY

But RFC2445 has examples where RRULEs contain unescaped
commas within them, such as:

     RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

So I repeat my original statement about RRULE being a special case:

     "an exception to your multi-instance property 'rule' would
      be the RRULE value, which uses the comma for it's own purposes."

>this email for a summary)

[sections rearranged for clarity...]

>              using the CONTAINS() [or LIKE] element.

I was just pointing out that when CONTAINS() was originally proposed,
it was to allow multi-value properties to be queried like this:

SELECT * FROM VTODO WHERE CONTAINS( CATEGORIES, 'BUSINESS' ) = TRUE

But if your statement above is correct, and multi-instance is
equivalent to multi-value (for the purposes of the query), then
the more powerful and flexible multi-instance syntax could be
used instead:

SELECT * FROM VTODO
USING_PROPERTIES CATEGORIES cat1
WHERE cat1 = 'BUSINESS'

As an aside, I feel that for consistency this query should also
be considered equivalent with the others:

SELECT * FROM VTODO
WHERE CATEGORIES = 'BUSINESS'

i.e. a reference to a multi-instance/value property by name
refers to _any_ instance/value of that property within the component.

--Alan

---

From: Alan Davies <[email-masked]>
Date: Mon, 11 Feb 2002 12:18:44 -0500

>    specified by a COMMA character (US-ASCII decimal 44) separated list

I think 2445 was confused, as just a few lines below that it states:

    The BYSECOND rule part specifies a COMMA character (US-ASCII decimal
    44) separated list of seconds within a minute.

(and similar for other rule parts), and then gives examples that use
the COMMA in this way.

--Alan

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Feb 2002 14:01:44 -0700

>       be the RRULE value, which uses the comma for it's own purposes."

Well, it seems that the RECUR value type, breaks the rules
in iCalendar :-) The text that defines RRULE specifically says
that RRULE may be multi-value, then the examples break the rules.

I think we need to re-quote John Postel's famous statement,
something like,:

  Be liberal in what you accept, and conservative in what
  you generate.

So, I think I will put quotes around the any RECUR values
when I generate them, And I'll just have to figure it
out when I parse them.

> refers to _any_ instance/value of that property within the component.

Yes - I agree.
If not for RRULE, but in general for any MULTI-INSTANCE,
or MULTI-VALUE - properties that MAY exist, they MUST be
equivalent.

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Feb 2002 14:03:57 -0700

> (and similar for other rule parts), and then gives examples that use

Yes, but in multi-value 'values', you have to quote the
values in order to find the sets. I am willing to accept
that if there is exactly one, it may contain anything including
quotes.

We need to make sure we are more conservative in CAP and do
not make any mistakes :-)