Subject: W-19 CAP Group Definitions

From: Bob Mahoney <[email-masked]>
Date: Tue, 25 Jan 2000 18:22:52 -0500

From Day One of the Interim meeting:

We've made an attempt on Group Definitions and Operations.  Our 
suggested text follows, referenced by CAP sections (not by section 
number).   We're also working on other security-related portions of 
the draft, and are likely to borrow some text from section 6 of 
draft-ietf-ldaptext-authmeth-04.txt.   More to follow tomorrow.

Please post comments to the list:

-Bob, for the members in attendance

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

Calendar Group (CG)

A collection of Calendar Users and/or other Calendar 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.

(Global modification for UPN definition)

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

(CAP section "Calendar Group")

A Calendar Group is used to represent a collection of calendar users 
or other Calendar Groups that can be specified as ATTENDEEs or 
referenced in VCARS.  A CG is represented in CAP as a UPN.  The CUA 
cannot distinguish between user and group UPNs.

Calendar Groups are expanded as necessary by the CS.  Subject to 
administrator configuration (as with the EXPN command in SMTP), the 
CS MUST respond to a CUA request for group expansion.  When relevant 
to completing an operation, the CS may expand a CG (including nested 
CGs) to obtain a list of unique CUs.  Duplicate UPNs are filtered 
during expansion.  Incomplete expansion should be treated as a 
failure.

The CS SHOULD not preserve CG expansions across operations.  A CG 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 group membership.  However, during fan out to 
other CSs, the originating CS SHOULD expand all CGs 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 CG database or directory.

CAP does not define commands or methods for managing Calendar Groups.

Examples:

      Small CG - The Three Stooges.  There is only and always three at 
any one time.
      Large CG - The MIT graduating class of 1999.  This is a static list.
      Dynamic CG - The IETF membership, which is a large and changing 
list of CUs.
      Nested CG - 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 UPN.  Successful 
result yields only CU UPNs.

(CAP section "VCalendar Access Rights")

Change: "Calendar User" to "Calendar User or Calendar Group"

(CAP section "Access Rights")

Change: "Calendar User" to "Calendar User or Calendar Group"

Add:

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

(CAP section "State Diagram")

Add:

While in the Identified state, allow EXPAND command.

(CAP section "Capability Command")

Add:

MAXEXPANDLIST to list of capabilities returned

MAXEXPANDLIST   0 or 1

An integer value that specifies the maximum number of UPNs that can 
be returned by the EXPAND Method.

(CAP section "Transfer Protocol Commands")

Add:

EXPAND 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 MAXEXPANDLIST
              2.4 Misc. EXPAND error

Example #1: Request expansion of UPN which is a Calendar Group

C: EXPAND [email-masked]
S: 2.0 [email-masked]
S: IDENTITY=[email-masked]
S: IDENTITY=[email-masked]
S: IDENTITY=[email-masked]
S: .

Example #2: Request expansion of a UPN which is a Calendar User

C: EXPAND [email-masked]
S: 2.0 [email-masked]
S: IDENTITY=[email-masked]
S: .

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

C: EXPAND [email-masked]
S: 2.0 [email-masked]
S: IDENTITY=[email-masked]
S: IDENTITY=[email-masked]
S: 2.4 Lost contact with directory server
S: .

(CAP section "RIGHTS Value Type")

Change:

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

to

"The UPN rule part specifies the Calendar User or Calendar Group that 
the calendar access rights applies to.

---

From: [email-masked] (Steve Mansour)
Date: Tue, 25 Jan 2000 19:49:00 -0800

Bob,

Good job getting this text together! This is _very_ helpful in getting the
draft completed. I'll watch for comments. If there are no issues raised I'll
use it to update the draft.

-Steve

---

From: Doug Royer <[email-masked]>
Date: Tue, 25 Jan 2000 21:19:58 -0800

> -Bob, for the members in attendance

Given if CG-1 contains list-A and list-B. Then what if you  have
permission to see list-A but not list-B. How should that be
treated?

> confusion when two CSs do not share the same CG database or directory.

If during fanout CS-1 and CS-2 do NOT contain the same CG database
or directory, then do you mean that CS-1 SHOULD request CS-2 to
do the expansion, then CS-1 MUST apply unique filters? What if
CS-2 says 'no I will not expand this list', yet CS-1 can
expand its list? Does it return the CS-1 list, plus the group-name/UPN
from CS-2?

> result yields only CU UPNs.

How does a CS say that it will not expand the list?

> be returned by the EXPAND Method.

How do you say unlimited? How about:

	0   = I will not expand any lists, everything request will yield 2.1 
	-1  = Unlimited.

> S: 2.4 Lost contact with directory server

And how about:

 C: EXPAND [email-masked]
 S: 2.1
 S: .

---

From: Bob Mahoney <[email-masked]>
Date: Wed, 26 Jan 2000 11:39:02 -0500

We need to change our definition of groups.

We now realize there are two types of groups, Users and Calendars.

Definitions:

Users are represented as UPNs.  A given UPN can be either a Calendar 
User (CU) or a User Group (UG).  We do not want to continue using the 
term Calendar Group (CG).   By looking at a UPN, a CUA cannot 
determine whether it is a CU or a UG.   Only the CS can expand a UG 
into a list of CUs.

Calendars are represented as CSIDs.  A given CSID can be either a 
Calendar (C), a Calendar Collection (CC), or a Resource Calendar 
(RC).  By looking at a CSID, a CUA cannot determine whether it is a 
C, CC, or RC.  Only the CS can expand a CC into a list of Cs or RCs.

(There is no syntactic difference between a C and RC. They are only 
different in the semantic content that is imposed by the data that 
they contain and by their calendar properties.)

Commands:

We want to keep the EXPAND command from yesterday.  EXPAND will 
accept a CSID and return one or more Cs or RCs.  More than one C or 
RC returned implies that the CSID was a CC.

We want to add a new command called LOOKUP, which will accept a UPN, 
and returns one or more CSIDs.  More than one CSID returned implies 
that the UPN was a UG.

The reverse lookup from a CSID to a UPN is accomplished by looking at 
the owner property of the calendar.

Read this aloud- it will help.  We'll follow up later with revisions 
to yesterday's text.

-Bob

---

From: Doug Royer <[email-masked]>
Date: Wed, 26 Jan 2000 09:50:26 -0800

> they contain and by their calendar properties.)

Where is the definition of "Resource Calendar (RC)". I could
make a guess :-) And which properties or property values? From
you text above I do not know what an RC is.

> the owner property of the calendar.

We allow more than one owner for a calendar. What would that tell you?

And why is it different than just asking for the calendar owner
properties? It looks to me as if it is the same as just doing a VQUERY
for the calendar owner property values? If so, lets not  invent
another way to do the same thing.

---

From: Bob Mahoney <[email-masked]>
Date: Wed, 26 Jan 2000 13:22:02 -0500

>you text above I do not know what an RC is.

We're adding that.  :-)

>We allow more than one owner for a calendar. What would that tell you?

That's ok- it doesn't need to be a one-to-one mapping.

>another way to do the same thing.

Exactly.  We were just including that for the sake of completeness.

-Bob

---

From: Doug Royer <[email-masked]>
Date: Wed, 26 Jan 2000 11:32:48 -0800

> Exactly.  We were just including that for the sake of completeness.

Exactly what? :-)

Exactly you agree it is not needed as it is the same?

Or exactly (because it is not the same) we need it?

-Doug

---

From: Bob Mahoney <[email-masked]>
Date: Wed, 26 Jan 2000 14:40:50 -0500

>Or exactly (because it is not the same) we need it?

Sorry!

"We included this for completeness only in our email (not the CAP 
text)- you are correct that it is the same as a VQUERY against a 
Calendar."

>  the owner property of the calendar.

read:

"The reverse lookup from a CSID to one or more UPNs is accomplished 
by issuing a VQUERY and looking at the OWNER attribute."

-Bob

---

From: Doug Royer <[email-masked]>
Date: Wed, 26 Jan 2000 12:40:47 -0800

> by issuing a VQUERY and looking at the OWNER attribute."

Sorry - I associated it with the LOOKUP command.
So now I am confused differently.

> > and returns one or more CSIDs.  More than one CSID returned implies

If my UPN is UPN-doug, and I own X different calendars, What would
you get back? One CSID for each calendar?

Or are you saying that if 'LOOKUP UPN-doug' returns more than one CSID
then any reference to UPN-doug applies to ALL of those CSID's.

What do you do with that information? Why is it needed?

Can you authenticate with a UG UPN? If not, when would you see them?
If you can authenticate with a UG UPN, do your operations apply
to all CSID's that it expands to? If so, we are introducing transaction
problems and we have deferred that to CAP-<later.version>.

If the CS says you do not have permission to access that information,
what feature(s) do you loose? I can still VQUERY on the CSID's, I can
still authenticate as UPN-doug. I am not sure what LOOKUP does for
me other than allow a CUA to look at the list (what for?).

If the CS (in previous email to this list) says that a UG can be
dynamicily altered and MUST NOT treat a UG as a static list. What
is to keep the LOOKUP results from being invalid the instant they
are returned? It looks to me that it allows a CUA to store a static
list? Which looks to me as if it also should not be allowed. So I 
do not yet see a need for LOOKUP.

---

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

>then any reference to UPN-doug applies to ALL of those CSID's.

This is addressed in the revised text we just sent.

>What do you do with that information? Why is it needed?

You have a UPN, and you need a CSID to schedule with, i.e., this is 
the ATTENDEE.  Another example is that you have a group of users that 
I want to invite to an event, and you want the list to be static.  (a 
snapshot of the current expansion of that UG)

>Can you authenticate with a UG UPN? If not, when would you see them?

No, but you want to see them for the reason above, as well as for VCARs.

>are returned?

Nothing...

>It looks to me that it allows a CUA to store a static

We say that neither the CS nor the CUA should preserve UG expansions 
across operations.  (Obviously some implementations will cache that 
expansion for a short period of time)

-bob

---

From: Doug Royer <[email-masked]>
Date: Wed, 26 Jan 2000 14:12:47 -0800

> snapshot of the current expansion of that UG)

I can see its usage as long as you can not schedule to a group name.
If you could then as people get added and deleted from the group name
then your original schedule request is bogus. As are (if you included
the entire ATTENDEE list in the REQUEST) the other ATTENDEE coppies.
I could see a flurry of updates to REQUEST if the list changes daily.

So if the CUA via an EXPAND gets a list name, then shows the CU
the list. And if only non-CG names are in the ATTENDEE list, I
can see how a CUA might use the list to generate an original REQUEST.
How would they update the component as members are added/deleted?

What if someone move between group-a to group-b, then they reply
that they will be attending - Is there a way for the CS or CUA
to know that they should be un-invited?

What if the CS policy is not to expand CG's. Can you still
schedule? If so, how would you send out the REQUEST's?

The CS NEEDS to know individuals (MAILTO) or individual calendars (CSID) only
in the ATTENDEE property. There needs to be a 1:1 mapping in the ATTENDEE lists. 
so status information can be maintained. Otherwise the 1st user in the
list to say 'no I will not attend' speaks for the entire group (CG).

We MUST never allow a CG in an ATTENDEE list? As there would be no way
to track who replied or what their ATTENDEE status was.

How do you get that CG-UPN?  It can not be in an ATTENDEE list.
So you could not have gotten it from a PUBLISH or REQUEST.
Were did it come from? Is it external to CAP (As in you just know
via email or something)?

I can see how a CG-UPN could be in a VCAR for dynamic expansion
of permissions. But how does it get specified? I could pass
down one with a VCAR/create, but how did I know the name in
order to specify it?

You can send email to a list expander, not the same problem.
You could send components to a CG, but not schedule with a CG - correct?