[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 "user@xxxxxxxxxxx" to "user@xxxxxxxxxxx or group@xxxxxxxxxxx"


(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 upn@xxxxxxxxxxx
S: 2.0 upn@xxxxxxxxxxx
S: cap://cal.example.com/calid3
S: .

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

C: LOOKUP group@xxxxxxxxxxx
S: 2.0 group@xxxxxxxxxxx
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 group@xxxxxxxxxxx
S: 2.0 group@xxxxxxxxxxx
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 group@xxxxxxxxxxx
S: 2.0 group@xxxxxxxxxxx
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.