Subject: W-19 CAP Group Definitions - corrections to yesterday's work

From: Bob Mahoney <[email-masked]>
Date: Wed, 26 Jan 2000 15:48:26 -0500

Updates and corrections to yesterday's Group proposal (Throw away 
yesterday's mail).  Commentary is in []'s.

--------------------------------
(CAP section "Definitions")

User Group (UG)

A collection of Calendar Users and/or User Groups.  These groups are 
expanded by the CS and may reside either locally or in an external 
database or directory.  The group membership may be fixed or dynamic 
over time.

Calendar (C)

<definition remains unchanged>

Calendar Collection (CC)

A collection of Calendars, Resource Calendars, and/or other Calendar 
Collections.  These collections are expanded by the CS and may reside 
either locally or in an external database or directory.  The 
calendars in the collection may be fixed or dynamic over time.

Resource Calendar (RC)

A non-human Calendar, associated with an organizational resource. 
There is no syntactic difference between an RC and a Calendar.

(Global modification for UPN definition)

Change " CU" to "CU or UG"; Change "[email-masked]" to 
"[email-masked] or [email-masked]"

(CAP section "User Group")

A User Group is used to represent a collection of CUs or other UGs 
that can be referenced in VCARS.  A UG is represented in CAP as a 
UPN.  The CUA cannot distinguish between CUs and UGs.

UGs are expanded as necessary by the CS.  The CS MUST accept a CUA 
request for UG expansion, although the CS may be configured to 
restrict some responses.  The CS MAY expand a UG (including nested 
UGs) to obtain a list of unique CUs.  Duplicate UPNs are filtered 
during expansion.  Incomplete expansion should be treated as a 
failure.

[ Editor's Note: We need to explore the issue and impact of directory 
permissions and precedence.]

The CS SHOULD not preserve UG expansions across operations.  A UG may 
reference a static list of members, or it may represent a dynamic 
list.  Each operation SHOULD generate its own expansion in order to 
recognize changes to UG membership.  However, during fan out to other 
CSs, the originating CS SHOULD expand all UGs so that the target CS 
receives only a list of unique CUs.  This is to prevent confusion 
when two CSs do not share the same UG database or directory.

[Editor's Note: Doug had an issue here relating to multiple CUs not 
having a common directory.  We think the above text resolves this]

CAP does not define commands or methods for managing UGs.

Examples:

      Small UG - The Three Stooges.  There is only and always three at 
any one time.
      Large UG - The MIT graduating class of 1999.  This is a static list.
      Dynamic UG - The IETF membership, which is a large and changing 
list of members.
      Nested UG - The National Football League, made up of the AFC and 
NFC, which are made up of 3 divisions each...

(CAP table "CAP Calendaring Commands")

Add:

Command		Description

EXPAND		Return the members of the argument CSID.  Successful 
result yields one or more Calendars and/or Resource Calendars.  More 
than one C or RC returned implies that the CSID was a CC.

LOOKUP                      Return the members of the argument UPN. 
Successful result yields one or more CSIDs.  More than one CSID 
returned implies that the UPN was a UG.

(CAP section "VCalendar Access Rights")

Change: "Calendar User" to "CU or UG"

(CAP section "Access Rights")

Change: "Calendar User" to "CU or UG"

Add:

VCARS principals can be CU or UG UPNs. Whenever VCARs are evaluated, 
all referenced User Groups MUST be evaluated as an expanded list.  UG 
expansion SHOULD NOT persist across operations.

[Editor's Note: This is where we need to define precedence rules.]

(CAP section "State Diagram")

Add:

While in the Identified state, allow EXPAND and LOOKUP commands.

(CAP section "Capability Command")

Add:

Capability                 Occurs                 Description
-------------------------------------------------------------------
MAXEXPANDLIST   0 or 1                   An integer value that 
specifies the maximum number
                                                                 of 
UPNs that can be returned by the EXPAND Command.

MAXLOOKUPLIST   0 or 1                   An integer value that 
specifies the maximum number
                                                                 of 
CSIDs that can be returned by the LOOKUP Command.

[Doug- this is structured to mirror the other entries in the 
Capabilities Section...]

(CAP section "Transfer Protocol Commands")

Add:

EXPAND Command

Arguments:   CSID

Data:        data as described below

Result:      2.0 Successful, and requested data follows
              2.1 Permission Denied
              2.2 Requested CSID not found
              2.3 Result exceeds MAXEXPANDLIST
              2.4 Misc. EXPAND error

Example #1: Request lookup of CSID which is a Calendar Collection

C: EXPAND cap://cal.example.com/calid14
S: 2.0 cap://cal.example.com/calid14
S: cap://cal.example.com/calid2
S: cap://cal.example.com/calid5
S: cap://cal.example.com/calid66
S: .

Example #2: Request lookup of a CSID which is a Resource Calendar

C: EXPAND cap://cal.example.com/conf5
S: 2.0 cap://cal.example.com/conf5
S: cap://cal.example.com/conf5
S: .

Example #3: Request CSID which exceeds MAXEXPANDLIST

C: EXPAND cap://cal.example.com/calid76
S: 2.0 cap://cal.example.com/calid76
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid12
S: cap://cal.example.com/calid21
S: cap://cal.example.com/calid33
S: 2.3 Expansion resulted in too much data
S: .

Example #4: CS loses contact with directory server during EXPAND

C: EXPAND cap://cal.example.com/calid76
S: 2.0 cap://cal.example.com/calid76
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid5
S: 2.4 Lost contact with directory server
S: .

LOOKUP Command

Arguments:   UPN

Data:        data as described below

Result:      2.0 Successful, and requested data follows
              2.1 Permission Denied
              2.2 Requested UPN not found
              2.3 Result exceeds MAXLOOKUPLIST
              2.4 Misc. LOOKUP error

Example #1: Request lookup of a UPN which is a CU

C: LOOKUP [email-masked]
S: 2.0 [email-masked]
S: cap://cal.example.com/calid3
S: .

Example #2: Request lookup of UPN which is a UG

C: LOOKUP [email-masked]
S: 2.0 [email-masked]
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid6
S: cap://cal.example.com/calid1342
S: .

Example #3: Request lookup exceeds MAXLOOKUPLIST

C: LOOKUP [email-masked]
S: 2.0 [email-masked]
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid12
S: cap://cal.example.com/calid21
S: cap://cal.example.com/calid33
S: 2.3 Lookup resulted in too much data
S: .

Example #4: CS loses contact with directory server during LOOKUP

C: LOOKUP [email-masked]
S: 2.0 [email-masked]
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid5
S: 2.4 Lost contact with directory server
S: .

(CAP section "RIGHTS Value Type")

Change:

"The UPN rule part specifies the authenticated CU that the calendar 
access rights applies to."

to

"The UPN rule part specifies the CU or UG that the VCARs apply to.