Subject: VCARs - any other specific proposals?

From: Doug Royer <[email-masked]>
Date: Tue, 22 Jan 2002 17:42:23 -0700

VCARs - any other specific 2445 object complient proposals?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 23 Jan 2002 10:01:00 -0500

> VCARs - any other specific 2445 object complient proposals?

I am going to send, by Monday, a proposal that will
address the issues that were recently brought to the
attention of the list.

Regards,
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: Mon, 28 Jan 2002 10:30:50 -0500

As promised, here's my proposal that addresses the issues
that were recently brought to the attention of the list.

Highlight of changes:

- Changed the GRANT and DENY properties to only specify the
  CUs and UGs to which the specified access right applies.

- Added new property PERMISSION to specify the permissions
  being granted or denied.

- Added new property SCOPE to specify the objects in the
  CS to which the access right applies by using CAP-QL as
  the selection mechanism.

- Added new property RESTRICTION to specify restrictions
  on the submitted values.

- Added new property NAME to specify a localizable display
  name for VCAR components.  This was already proposed and
  agreed on the list.

- Multiple instances of the properties GRANT, DENY, PERMISSION,
  SCOPE, and RESTRICTION may be present in VCAR components.

- A VCAR component, as defined in this proposal, can only
  define a single access right.  If there is a need to group
  multiple access rights in a single VCAR (e.g., to share
  the same CARID and/or NAME properties) we could always
  group the properties GRANT, DENY, PERMISSION, SCOPE, and
  RESTRICTION in a component (e.g., VRIGHT).

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

11.3 VCAR Calendar Component

   Component Name: "VCAR"

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

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

     carc    =  "BEGIN" ":" "VCAR" CRLF
                carprop
                "END" ":" "VCAR" CRLF

     carprop = 1*(
                 ; the following are optional,
                 ; but MUST NOT occur more than once

                 carid / name /

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

                 permission /

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

                 grant / deny / scope / restriction / x-prop
                )

   Description: A "VCAR" calendar component is a grouping of calendar
   access rights component properties.

   The "CARID" property specifies the local identifier for the "VCAR"
   calendar component.  The "NAME" property specifies a localizable
   display name.  The "GRANT" property specifies the UPN to whom a
   calendar access right is granted.  The "DENY" property specifies
   the UPN 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
   restrictions on the submitted values.

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

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

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

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

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

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

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

     BEGIN:VCAR
     NAME:"Read and Modify PUBLIC Calendar Entries"
     GRANT:*
     PERMISSION:READ
     PERMISSION:MODIFY
     SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC'
     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
     NAME:"Owner full calendar access rights"
     GRANT:OWNER
     PERMISSION:*
     SCOPE:SELECT * FROM VEVENT
     SCOPE:SELECT * FROM VTODO
     SCOPE:SELECT * FROM VJOURNAL
     SCOPE:SELECT * FROM VTIMEZONE
     SCOPE:SELECT * FROM VALARM
     SCOPE:SELECT * FROM VFREEBUSY
     SCOPE:SELECT * FROM VAGENDA
     SCOPE:SELECT * FROM VQUERY
     SCOPE:SELECT * FROM VCAR
     END:VCAR

     BEGIN:VCAR
     NAME:"ADMIN Settable CARs"
     GRANT:[email-masked]
     PERMISSION:*
     SCOPE:SELECT * FROM VCAR
     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 the
   ability to change calendar access; even for the owner or
   administrator:

     BEGIN:VCAR
     NAME:"No CAR At All"
     DENY:*
     SCOPE:SELECT * FROM VCAR
     END:VCAR

11.4 VCAR Grant Component Property

   Property Name: GRANT

   Purpose: This property identifies the CU or UG being granted access
   in the VCAR object.

   Value Type: TEXT

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

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

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

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

     grant     = "GRANT" upnparam ":" upnvalue CRLF

     upnparam  = *( ";" xparam )

     upnvalue  = ( "OWNER" / "NONOWNER" / text / all )

     all       = "*"

   Example: The following are examples of this property:

     GRANT:*

     GRANT:[email-masked]

11.5 VCAR Deny Component Property

   Property Name: DENY

   Purpose: This property identifies the CU or UG being denied access
   in the VCAR object.

   Value Type: TEXT

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

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

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

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

     deny      = "DENY" upnparam ":" upnvalue CRLF

   Example: The following are examples of this property:

     DENY:*

     DENY:[email-masked]

11.6 VCAR Identifier Component Property

   Property Name: CARID

   Purpose: This property specifies the identifier for a "VCAR" calendar
   component.

   Value Type: TEXT

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

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

   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" textparam ":" text CRLF

   Example: The following is an example of this property:

     CARID:REQUESTONLY

11.6 VCAR Name Component Property

   Property Name: NAME

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

   Value Type: TEXT

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

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

   Description: This property is used in the "VCAR" calendar component
   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"

11.7 VCAR Permission Component Property

   Property Name: PERMISSION

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

   Value Type: TEXT

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

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

   Description: This property is used in the "VCAR" 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

11.8 VCAR Scope Component Property

   Property Name: SCOPE

   Purpose: This property identifies the objects 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 "VCAR" calendar
   components.

   Description: This property is used in the "VCAR" 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'

11.9 VCAR Restrictions Component Property

   Property Name: RESTRICTION

   Purpose: This property defines restrictions on the submitted
   values for objects.

   Value Type: TEXT

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

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

   Description: This property is used in the "VCAR" calendar component
   to define restrictions on the submitted values.

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

     restrict      = "RESTRICTION" restrictparam ":" restrictvalue CRLF

     restrictparam = *( ";" xparam )

     restrictvalue = [ cap-uselist "WHERE" SP ] cap-expr

   Example: The following are examples of this property:

     RESTRICTION:METHOD = 'REQUEST'

     RESTRICTION:ORGANIZER = SELF()

     RESTRICTION:CONTAINS(CATEGORIES,'BUSINESS')

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

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

Predefined calendar access CARIDs that MUST be implemented (CAR-MIN)
are:

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

   BEGIN:VCAR
   CARID:READBUSYTIMEINFO
   GRANT:*
   PERMISSION:READ
   SCOPE:SELECT * FROM VFREEBUSY
   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
   GRANT:NONOWNER
   PERMISSION:WRITE
   RESTRICTION:METHOD = 'REQUEST'
   END:VCAR

CARID:UPDATEPARTSTATUS - grants all authenticated users the
right to modify the PARTSTAT parameter of ATTENDEE property
set to themselves.

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

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

   BEGIN:VCAR
   CARID:DEFAULTOWNER
   GRANT:OWNER
   PERMISSION:*
   SCOPE:SELECT * FROM VEVENT
   SCOPE:SELECT * FROM VTODO
   SCOPE:SELECT * FROM VJOURNAL
   SCOPE:SELECT * FROM VTIMEZONE
   SCOPE:SELECT * FROM VALARM
   SCOPE:SELECT * FROM VFREEBUSY
   SCOPE:SELECT * FROM VAGENDA
   SCOPE:SELECT * FROM VQUERY
   SCOPE:SELECT * FROM VCAR
   END:VCAR

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

   Restriction table

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

             . . VCAR               0+
             . . . CARID            0 or 1
             . . . NAME             0 or 1
             . . . PERMISSION       1+
             . . . DENY             0+       Note, there must be at
                                             least one GRANT or DENY
                                             within the VCAR.
             . . . GRANT            0+       Note, there must be at
                                             least one GRANT or DENY
                                             within the VCAR.
             . . . SCOPE            0+       Note, there must be at 
                                             least one SCOPE if
                                             PERMISSION:READ or
                                             PERMISSION:DELETE is
                                             specified
             . . . RESTRICTION      0 or 0+  Note, allowed only if
                                             PERMISSION:WRITE and/or
                                             PERMISSION:MODIFY are/is
                                             present.
             . . . X-PROPERTY       0+
             . . . [IANA-PROP]      0+       any IANA registered
                                             property

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

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 28 Jan 2002 09:54:30 -0700

I don't understand the RESTRICTION property.

>    Purpose: This property defines restrictions on the submitted

As in "restrict them - and they must match" ?
Or    "restrict them - and they must NOT match" ?

>    Example: The following are examples of this property:

So the restriction is that these must match ?
Or is the restruction is that they must not match?

>      RESTRICTION:CONTAINS(CATEGORIES,'BUSINESS')

In this example, it seems to be saying that METHOD MUST equal REQUEST.

   BEGIN:VCAR
   CARID:REQUESTONLY
   GRANT:NONOWNER
   PERMISSION:WRITE

Below the RESTRICTION property seems to duplicate the SCOPE, the
results of the SELECT would only return SELF, so what does the
RESTRICTION property do here?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 28 Jan 2002 12:27:08 -0500

> Or    "restrict them - and they must NOT match" ?

As in "restrict them - and they must match".

> Or is the restruction is that they must not match?

That these must match.

>    RESTRICTION:METHOD = 'REQUEST'

Non-owner are only granted the right to write objects
that have the property METHOD set to REQUEST.

> >   RESTRICTION:ATTENDEE = SELF()

Here, the SCOPE property specifies that you are allowed
to modify the ATTENDEE property that matches SELF.  While
the RESTRICTION property simply ensure that you are not
going to change the value of the ATTENDEE property to
some other value than SELF, that is, you'll be allowed
to change the value of the parameter of the property but
not its value.

If the CAP-QL change previously proposed by Alan, and
mentionned by Patrice today, is adopted, we could also
improve the definition of our SCOPE property as follows :

  SCOPE:SELECT att FROM VEVENT
        USING_PROPERTIES ATTENDEE att
        WHERE att = SELF()

Regards,
Bernard

---

From: "Shannon J. Clark" <[email-masked]>
Date: Mon, 28 Jan 2002 11:38:50 -0600

Bernard,

Thanks. Just a minor suggestion to make sorting and locating documents
easier - we should all probably be in the habit of including in our subject
line (and probably in the body text as well) the specific document to which
we are suggesting making changes - this way it will be easier for editors
and interested parties to locate all the letters dealing with CAP. In fact
if we were to somewhere make note of the version of the document we were
either editing (or quoting from) this would also help everyone keep track of
the conversations.

Again thanks for all of your efforts - when I get some free time in the next
few weeks I plan on reviewing the current draft of CAP to see how I would go
about implementing it.

thanks,

Shannon

---

From: Doug Royer <[email-masked]>
Date: Mon, 28 Jan 2002 11:04:44 -0700

(1) I noticed Bernard called SELF a function 'SELF()' and not 'SELF'.
    Are you proposing a change, or is this a typo?

    I like the idea, but lets do it to all of the non-literal values
    if we do it for any:

	OWNER()
	NONOWNER()
	SELF()
	Anything else?

(1.1) For clarification, do we want to rename SELF() to
      AUTHENTICATED(), CURRENT-UPN(), or sometning?

(2) And perhaps the anonymous - (and without much thought).
    After trying to specify some non-local-domain
    restrictions this weekend, the existing ANONYMOUS value is
    difficult to restrict local and non-local UPNs (anonymous or not)

    From the UPN section, a CU can login as anonymous and it says
    what their UPN is.

	@domain		Anonymous from named domain only.
	@		Anonymous from any domain.

    And VCAR allows:

        *		Any UPN - does that include anonymous?

    And how do you specify in a VCAR that you will only allow
    UPN's *connecting from* a specific domain? As in:

	I want UPN [email-masked]' to have FULL access if
        "connecting from inside of" ROYER.COM, but read only
        access (or no-access) when 'connecting from' outside the
	named domain.

    A UPN name is an authentication 'ID' but it makes no assertion
    about where it is coming *from* at the time it is connecting.

    This is NOT a proposal for the login ID's in the UPN section.
    This is a proposal for how to specify the UPN restrictions IN A
    VCAR. Below I'll use 'Cdomain' to mean the domain they are
    connecting from (that that has nothing to do with their
    UPN-domain or UPN-realm):

    Where DELETE means remove it from the VCAR section.
    And ADD means add it to the VCAR section.

				Meaning
             --		----
    DELETE   *		Any UPN - anonymous or not
			connecting from any domain.

    DELETE   @		anonymous connecting from any
			domain.

    DELETE   @domain	anonymous@domain connecting
			from any domain.

    ADD     ANY()	Any known non-anonymous UPN
                        connecting from any domain.

			GRANT:ANY()
			DENY:ANY()

    ADD     ANY(@Cdomain)	Any known non-anonymous UPN
                        BUT ONLY IF connecting from
                        the named domain.

			GRANT:ANY(@local-sub-net)
			DENY:ANY(@hacked-me.com)

    ADD     ANONYMOUS()   Any anonymous UPN that is
                        connecting from any domain.

			GRANT:ANONYMOUS()
			DENY:ANONYMOUS()

    ADD     ANONYMOUS(@Cdomain)    Any anonymous UPN that is
                                connecting from the NAMED domain.

			Allow anonymous from my-domain.com,
			but not from bogus.my-domain.com.

			GRANT:ANONYMOUS(@royer.com)
			DENY:ANONYOMUS(@bogus.royer.com)
			GRANT:ANONYMOUS(@trusted-domain.com)

			So, if I authenticate with:

				@royer.com

			But I am connecting from 'bogus.royer.com,
			I will have less access based on the contents
			of the entire VCAR.

    ADD     UPN(named, @Cdomain)   Known UPN, But only of connecting
                        from domain. As in:

			Allow UPN [email-masked], but only if
                        connecting from the named domains.

			GRANT:UPN([email-masked], royer.com)
			GRANT:UPN([email-masked], inet-consulting.com)
			DENY:UPN([email-masked], tried-to-hack-me.com)
 
    no-change <named-upn>	As before, allow named UPN:

			GRANT:[email-masked]
			DENY:NOT [email-masked]

   ADD      NOT         And allow 'NOT' to be placed in front of 
                        any of them.

(3) Our VCARs did not allow us to specify an action of LOGIN:

    So do we want to allow something like this to be specified
    in a VCAR? (note new 'LOGIN' pseudo table who's contents
    is simply a list of UPN's): (And Bernard forgive me and
    correct me if I have not got all of the proposals syntax
    correct):

	     BEGIN:VCAR
	     NAME:"Named UPS that can log in to this system"
	     GRANT:ANY(@local-domain.com)
	     GRANT:ANONYMOUS()
	     PERMISSION:*
	     SCOPE:SELECT * LOGIN WHERE UPN=SELF();
	     END:VCAR

---

From: Doug Royer <[email-masked]>
Date: Mon, 28 Jan 2002 15:33:06 -0700

> to change the value of the parameter of the property but

So you are saying that RESTRICTION only applied to WRITE?

> improve the definition of our SCOPE property as follows :

Why is this improved? It looks the same to me except
it require more code. I see no advantage at all.

---

From: Doug Royer <[email-masked]>
Date: Mon, 28 Jan 2002 17:03:23 -0700

"Shannon J. Clark" wrote:
> we are suggesting making changes 

What other document contains VCARs?

---

From: "Shannon J. Clark" <[email-masked]>
Date: Mon, 28 Jan 2002 18:39:47 -0600

Well there was a proposal back a while ago to consider making it a separate
document, and there was some discussion back and forth about whether the new
structure (VCAR) meant that changes needed to be made to 2445 - this was
resolved by agreeing not to make changes to the core iCalendar standard but
rather to have the changes documented in CAP as extensions that CAP
requires - but my overall point is that some clarity and search capabilities
are lost when we don't document which document our discussions are covering.

i.e. if you were a developer implementing CAP in an ideal world you should
be able to get to all of the threads that cover CAP related items with a
search for CAP (or iCalendar/2445 or iMIP etc)

overall the level of posts in the past few weeks is quite impressive -
thanks to everyone who are rapidly documenting and ironing out the unclear
areas.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Monday, January 28, 2002 6:03 PM
To: [email-masked]
Subject: Re: VCARs - any other specific proposals?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 29 Jan 2002 09:28:55 -0500

[ I've replied to your 3 points in separate messages. ]

>     I like the idea, but lets do it to all of the non-literal values

OWNER and NONOWNER are not in the same name space as SELF
(or SELF()).  OWNER and NONOWNER are valid values for the
GRANT and DENY properties, while SELF (or SELF()) will need
to be added to the CAP-QL ABNF.

>       AUTHENTICATED(), CURRENT-UPN(), or sometning?

SELF() is used in comparisons with the properties ATTENDEE
and ORGANIZER which hold "calendar addresses" and not UPNs.
So it may not be a good idea to use the equality operator
after all (type mismatch).  We should probably come up with
a better way to express the following:

   The value of ATTENDEE is the address of a calendar
   owned by the currently authenticated calendar user.

What about a OWNED_BY() function?

   SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att
          WHERE OWNED_BY( att, SELF() )

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 29 Jan 2002 10:27:33 -0500

>         *               Any UPN - does that include anonymous?

From the previous proposal:

   If the value is the keyword is *, then the rule applies
   to all authenticated calendar users (i.e., all UPNs).

Since anonymous users are authenticated (anonymously),
then I would say that '*' includes anonymous users.

This information is missing from my proposal.

>     no-change <named-upn>       As before, allow named UPN:

Couldn't we simply allow the '*' character before and
after the '@' character?

  GRANT:*                 Grant anybody (including anonymous)
  GRANT:@                 Grant anonymous only
  GRANT:*@*               Grant named from any realm only
  GRANT:@example.com      Grant anonymous from example.com only
  GRANT:[email-masked]     Grant named from example.com
  GRANT:doug@*            Grant doug from any realm
  GRANT:[email-masked]  Grant [email-masked]

>    ADD      NOT         And allow 'NOT' to be placed in front of

Do we really need a NOT operator?

I can grant everybody but you this way:

  GRANT:*
  DENY:[email-masked]

and I can grant you but nobody else this way
(DENY:* is implicit):

  GRANT:[email-masked]

Perhaps I'm missing something.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 29 Jan 2002 10:31:23 -0500

>              SCOPE:SELECT * LOGIN WHERE UPN=SELF();

The SCOPE property is used to define a set of calendar objects.
I don't think it would be acceptable to overload the SCOPE
property to affect the meaning of the GRANT and DENY properties.

I don't think this administrative task is within the scope of
the CAP protocol.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 29 Jan 2002 10:07:14 -0700

> to be added to the CAP-QL ABNF.

OWNER NONOWNER and SELF have been in defined and used in the
past. So you have invented something new? Or is it a typo?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 29 Jan 2002 12:15:22 -0500

> So you are saying that RESTRICTION only applied to WRITE?

RESTRICTION only applies to permissions WRITE and MODIFY.

> >         USING_PROPERTIES ATTENDEE att

Assuming PERMISSION:READ,

would grant you the right to read ALL instances
of the ATTENDEE property of a VEVENT for which
one ATTENDEE is set to SELF, while

would only grant you the right to read the instances
of the ATTENDEE property of a VEVENT that are set
to SELF.

Regards,
Bernard

---

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

>   GRANT:[email-masked]  Grant [email-masked]

No, not the same issue.

	"[email-masked]" is the UPN.
	It might be connecting from "foo.com".

I want to restrict the UPN "[email-masked]" and only
allow the VCAR to apply when connecting from "example.com", if
they connect from any other domain, I do not want them to have access.

Yes your examples grant or deny the UPN, but is what is missing
is where they are connecting FROM.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 29 Jan 2002 12:37:15 -0500

> past. So you have invented something new? Or is it a typo?

In the previous proposal OWNER and NONOWNER were listed as
valid values for the UPN rule part.

In my proposal these values are listed as valid values for
the properties GRANT and DENY.  The GRANT and DENY properties
are only used to specify what used to be in the UPN rule part
of RIGHTS value type.  That's new, but I wouldn't claimed I
invented it!

In the previous proposal SELF was listed as a valid value for
propvalue and was meant to be used with VALUE (but the ABNF
wasn't written properly to allow it).

In my proposal I assumed that CAP-QL would also have a way to
express SELF, and I used a function for that (i.e., SELF()).
I've simply transposed this concept in my proposal.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 29 Jan 2002 11:10:09 -0700

> RESTRICTION only applies to permissions WRITE and MODIFY.

So, RESTRICTION would NEVER be in a VCAR that was only READ?

If so, I missed that or the ABNF or TEXT needs to be updated.

>         USING_PROPERTIES ATTENDEE att

I read the text to mean that I would get ALL ATTENDEE properties
where the ATTENDEE value = SELF.

>         USING_PROPERTIES ATTENDEE att

I read the text to mean that I would get ALL ATTENDEE properties
where the ATTENDEE value = SELF.

I an not figure out how anyone not on this list and reading this
email would know the difference.

Could you propose some text that could be included in CAP
that could explain to someone that is reading CAP for the
fist time? It would help me understand what you are trying
to do that you can not already do.

---

From: Doug Royer <[email-masked]>
Date: Tue, 29 Jan 2002 11:32:00 -0700

> wasn't written properly to allow it).

In previous proposals:

SELF 	- was a tag that meant 'currently authenticated UPN'
	 in VCAR and VQUERY

OWNER	- Was a tag that meant 'currently authenticated UPN
	- IF they are the owner'.
	  In both VCAR and VQUERY.

NONOWNER- Was a tag that meant 'currently authenticated UPN'
	- IF they are NOT the owner of the calendar.
	  In both VCAR and VQUERY.

*	- stood for 'any currently authenticated UPN.
	  In both VCAR and VQUERY.

> I've simply transposed this concept in my proposal.

So my question is, do we want to change OWNER -> OWNER(),
and NONOWNER() to NONOWNER() and so on?

If not, lets make them all the same format. (All as
functions, or all not as functions).

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 29 Jan 2002 14:40:16 -0500

> is where they are connecting FROM.

It is not missing.  It simply does not belong in the VCAR.

VCARs are supposed to allow calendar users to grant and deny
rights to other authenticated users, regardless of where they
are connecting from, the authentication mechanism they've used,
or whether they are using TLS or not.

AFAIK, this was not identified as a requirement and is certainly
outside the scope for CAP 1.0.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 29 Jan 2002 15:19:23 -0500

> If so, I missed that or the ABNF or TEXT needs to be updated.

This information was specified in the restriction table
at the end of my proposal.

But it wouldn't hurt to add a comment in the text as well.

> where the ATTENDEE value = SELF.

This is incorrect.

For instance,

would get you all the properties of VEVENT components
for which one of the ATTENDEE property is set to SELF.
And,

   SCOPE:SELECT ORGANIZER FROM VEVENT
         USING_PROPERTIES ATTENDEE att
         WHERE att = SELF()

would get you the ORGANIZER property of VEVENT components
for which one of the ATTENDEE property is set to SELF.

> where the ATTENDEE value = SELF.

In this case the intent is to specify that we only
want to get those ATTENDEE properties that matches
the condition.

> to do that you can not already do.

Sure.  I'll come up with something.

Just to make sure we are on the same page.
This is a CAP-QL issue.  Not a VCAR issue.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 29 Jan 2002 13:19:46 -0700

Bernard Desruisseaux wrote:

> are connecting from,

Why then do we have anonymous@named-domain UPNs?

> the authentication mechanism they've used,

I did not propose anything todo with TLS.

> outside the scope for CAP 1.0.

Again that's why we have anonymous@realm. What is to
keep them from supplying anonymous@realm if they are not from
realm? Nothing - that's what I noticed was missing.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 29 Jan 2002 15:47:44 -0500

> *       - stood for 'any currently authenticated UPN.

Which proposals are you referring to?  I've looked in the
archive and I could not find any proposal for VQUERY that
made mention of these tags.

> and NONOWNER() to NONOWNER() and so on?

OWNER no.

NONOWNER no.

SELF okay since it is used in CAP-QL.

> functions, or all not as functions).

Again, as I said, the only change I did, as part of my
proposal, was to bring SELF in the CAP-QL vocabulary.
Whether we make SELF a function or not in CAP-QL should
not have any impact on the tags OWNER and NONOWNER for
the GRANT and DENY properties.  Don't mix apples with
oranges as my old math teacher used to say!

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 29 Jan 2002 15:57:44 -0500

> Why then do we have anonymous@named-domain UPNs?

I don't know.  You brought this up:

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

> realm? Nothing - that's what I noticed was missing.

I propose NO anonymous@realm.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 29 Jan 2002 14:58:25 -0700

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

Yes I did bring it up. The reason was so that we could authenticate
BY CONNECTED from DOMAIN, yet we failed to complete the
proposal in access rights. Which is my point and why I
sent the above email and email on this topic.

> I propose NO anonymous@realm.

Too late. Already in CAP and not realistic. Publicly
available calendars exist and are going to exist. We can't
mandate that you can only look at a public schedule if
you already have an account.

And the reason that anonymous@realm existed was so that
calendar administrators could select the realm of the
anonymous connections. Which only seems to be related
to the UPN they authenticated with. But it does not solve
the problem that was only half proposed by creating 
anonymous@realm.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 30 Jan 2002 13:23:44 -0500

> the problem that was only half proposed by creating

The UPN "[email-masked]" doesn't mean that "bernard" is
connecting from the domain "steltor.com".  It simply means
that someone had the proper credentials to authenticate
himself as "[email-masked]".

Now, whether the user "[email-masked]" is required to
connect from a specific domain or not is the matter of the
authentication mechanism, not of VCAR.

Same applies to anonymous users.

A calendar administrator could configure, in a proprietary way,
the authentication mechanisms supported by his CS to enforce
that anonymous authentication for the REALM "toto.com" (i.e.,
UPN=@toto.com) is only possible for connections being made from
the domain "toto.com".

I don't think any changes are required in CAP.

We simply need to agree on the syntax of UPN.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Jan 2002 11:50:32 -0700

> himself as "[email-masked]".

YES - THAT IS EXACTLY MY POINT.

How do I say that [email-masked]' only has
access if he is connecting from 'steltor.com' ?
Otherwise he has NO access.

That is why anonymous@place was proposed. So we
could limit access based on not only the UPN (anonymous),
but the limit it to where they are connecting from.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 30 Jan 2002 14:43:23 -0500

> Otherwise he has NO access.

My point is that it could be left to the implementor.
I see this as an administrative task that is outside
the scope of the CAP protocol.

Regards,
Bernard

---

From: "Graham Gilmore" <[email-masked]>
Date: Wed, 30 Jan 2002 15:01:25 -0500

> Otherwise he has NO access.

    Why would we want to define this area of CS administration in CAP?  I
thought it was for calendaring, period.  A reasonable CS authentication
mechanism should be able to forbid anyone to log in as [email-masked],
unless they are connecting from steltor.com.  In fact, mandating that
[email-masked]' MUST mean that the user has connected from 'host.com'
will severely LIMIT the flexibility of CS administrators to choose realm
names, or set up things like separate calendaring realms for different org
units in a company without completely changing their internal network
architecture.
    With a reasonable CS implementation, it shouldn't be hard to do things
like:
(a) deny authentication as the UPN [email-masked]' if the user is not
connecting from the domain steltor.com
(b) If the user is wants to authenticate anonymously, give them the UPN
[email-masked] if they're connecting from inside royer.com,
otherwise give them the UPN [email-masked] (and set up VCARs
to give appropriate rights to anonymous in those CAP realms).
(c) Have users logging in assigned a UPN in a CAP realm corresponding to
their machine's NT workgroup.

    I'm sure CS administrators can think of other possibilities.  What would
we gain by tying CAP realms to network domains inside CAP?

    Graham

---

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

Graham Gilmore wrote:
>     Why would we want to define this area of CS administration in CAP?

Old point, that is why we added anonymous@domain.

We just never finished the work.

Cap requirements:

4.6     Security

   CAP MUST specify:

     - How the CUA authenticates itself to the CS (not the calendar).

       Authentication to the CS is required for all access to the CS.
       The CS MUST be able to uniquely identify each user for the
       purposes of authentication and authorization.

     - How anonymous access to calendars is specified (if allowed).

     - How the CUA authenticates to CS using SASL.

     - How the CUA and the CS negotiate encryption mechanism for a
     secure connection.

     - How calendars can be made secure from unwanted access and false
     entries.

 -->    - How the CUA and CS can specify denial of service to another
     calendar user.

---

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

> the scope of the CAP protocol.

We it's not, that's why we have anonymous@domain.

So how do we deal with it?

---

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

> Old point, that is why we added anonymous@domain.

You may have added anonymous@domain for this reason.
But "why would we want to define this area of CS
administration in CAP?" in the first place?

>  -->    - How the CUA and CS can specify denial of service to another

Calendar users being represented by UPN, you simply have to say:

   DENY:user@realm

I'm sorry but the text you quoted doesn't specify that the CU
(or CUA) must have a way to segregate another calendar user
based on where it is connecting from.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Jan 2002 15:59:21 -0700

> administration in CAP?" in the first place?

Lets drop VCARs then - that is also CS administration.

---

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

> Lets drop VCARs then - that is also CS administration.

No.  

It is the responsability of a CU to grant or deny
rights to other authenticated calendar users (UPN)
(by using VCAR).

It is the responsability of the calendar administrator
to setup his authentication policy as he pleased, and
how exactly he is supposed to do that does not need to
be specified in CAP.

Regards,
Bernard