Re: W-19 - open item - can we defer it?

[Bruce_Kahn@xxxxxxxx]

Doug replied:
>Okay - now you wish to administer the VCAR for a user-list(group). If it
>is not expanded by the CS how will you ever find who is on the list?
>Or as some have expressed, how to find out if you have permission to
>do something.

Of course the CS will have to do some expansion to properly evaluate the 
entries.  Ive never claimed it would not have to.  However, doing it at 
the time you set the VCAR is NOT the proper time.  The proper way should 
be when they are needed (say when you Authenticate and the CS builds up 
any meta information about the CU it needs for later work).  If the CS 
does an 'up front' expansion, you lose the usefulness of groups.  They 
become some hacked up form of macro.

If the admins/CU change the users in a group, just how would the CS know 
to go back and 'update' any VCARs that it previously exploded out?!  Thats 
MUCH MUCH more work than doing dynamic group expansion when necessary and 
its just plain ugly!  (Imagine how the CS would try to deal with removal 
of a CU from 1 group but not another where both are on the same VCAR; 
would it be good enough to realize that it should not really remove a CU?? 
 Ugh!!)

>The only issue as I see it is how do you administer the list
>and MUST or MAY it be expanded dynamically to a CUA.

For interoperability to work, this cannot be just a hit or miss deal.  We 
must have just 1 way to do this or groups on VCARs wont function 
consistantly.  Imagine one CUA that just uses groups for VCARs but the CS 
does static explosion of members.  Besides the mess I pointed out above, 
just what would the scenario be for what the CUA sees when it reads the 
VCARs back (or sets new values).  Would the CUA be required to send the 
FULL VCARs list back (it would have to in your mixed behaviour case) or 
could it just send a new ADD message with a new VCAR with a new user??  If 
the CUA were to query the CS for the VCARs, would you expect the CS to 
rebuild the original list that the CUA set or just return the exploded 
entries?  As a CUA writer I would find that what I sent in was not the 
same as when I got back and Id have to do some form of reconciliation. And 
all for nothing really...  (There could be cases where VCAR ADDs do not 
'take' and that should be indicated when the CUA attempts the ADD, not by 
guessing based on what comes back on a query.)

>There still needs to be an interoperable way to find out who is on a
>dynamic list. That can be done with or without CAP (LDAP Tool for 
example).

We have already have some directory (LDAP or other really) needs such as 
how to find out CAP or iTIP addresses, etc so having yet another directory 
link is not so arcane or horrific.  Every CUA/CS will need some form of 
directory link so it can handle address look and resolution, credential 
lookups for authentication or UPN checking, etc.   There may be some ties 
between current MUAs/PIMs and the CUAs (ie: Notes has its NAB and your 
mail file/calendar, Outlook has its MUA/CUA and Address Book, etc).  Just 
wheredo you expect your CUA to store that new CAP address you got off 
someones vCard??

So far we have not directly required 1 specific directory (LDAP, X.500, 
Active Directory, etc.) and I dont think we need to expressly call them 
out.  What is probably needed is something like the locating draft that 
covers how to get said info from different sources.

>I assert that if you are a CAP client:
>
>                (A) And you have access to read the VCAR, then the 
expansion
>                    must be possible (Assuming you have permission and it 
is
>                    not a violation of site administrative policy) 
Otherwise you
>                    would be requiring all CUAs to understand all dynamic 
list
>                    implementations - Not possible.

Agreed.  Sounds like you want to mandate some specific directory links 
that both the CUA and CS share.  Do you have any particular mechanism in 
mind or something generalized like the locating draft was?  BTW: It is 
possible that the expansion yields different data for the CUA and the CS 
if they use different directories (ie: a CUA uses a personal address book 
or different LDAP server than the, say, LDAP server that the CS uses.) 
Some could call this an error, others may call this a config/admin 
issue...

>                                (A.1) If the CS is unable or unwilling to 
expand the
>                                      list, OR the CS administrator has 
elected not to
>                                      allow list expansion:

Expand WHEN??  That is the crux here.  Expand when added (statically) or 
when needed (dynamically)??


>                                                Then return as the VCAR 
something like this IF
>                                                they happen to be a 
MEMBER of the LIST and
>                                                were GRANTed or DENYed 
access the the CS would
>                                                dynamicly create a wire 
VCAR into:
[Snip]
>
>                                                Because ether way there 
would have to be a unique
>                                                ID for the group name and 
they simply would or would
>                                                not have access to the 
resource specified by
>                                                that VCAR.
>
>                                                Then a CUA WOULD be able 
to determine in advance
>                                                if the CU had permission 
for an operation without
>                                                dynamic list expansion. 
Determinable by a MEMBER=GROUP
>                                                parameter to GRANT or 
DENY.

I dont think this would work if there were > 1 lists set on the VCAR.  For 
example, if I set a GRANT 'full access' to the list IrisCSAdmins and I set 
'read only access' to the list IrisQEFolks then just how would the CS 
rebuild the proper VCAR for a user who is a member of > 1 list??  In order 
for this to work, the CS would have to keep meta information about each 
UPN in all VCARs and track which group(s) they came from, etc. 

This still would not solve the problems of A) subsequent list changes not 
being applied to the VCARs and B) keeping parity with the VCARs input vs 
output when set and then querried.

>                (B) If you do NOT have access to read the VCAR, the 
answer of
>                    how to show them is irrelevant.
>
>I think this addresses all of the issues.

Sorry but it does not.  The issues of scalability, maintenance and 
updating are not covered.  You covered what the CS could do when VCARs are 
querried by a CUA, not when they are set or the other issues above.

>I do not think that we should
>define a way to administer user-group-lists. And I do not think that
>we can mandate that CUA's or CS's  MUST have user-group-lists.

If we do not have a very very common feature of current MUAs and non-RFC 
2445 PIMs like groups then we can close up shop and head home.   There 
would be no acceptance by our end users if we say "Hey, guess what?!  We 
have this great new standard for Interpersonal C&S but we decided you 
cannot have any groups like you do now in your current products."  How 
many medium and large customers would buy a product like that??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@xxxxxxxx
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...