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

From: [email-masked]
Date: Tue, 19 Oct 1999 16:52:49 -0400

Doug provided the citation:

>>From draft-ietf-calsch-capreq-03.txt (the latest):
>
>4.3.1   Deferred Requirements for Operations on a Calendar
> 
>   CAP is not required to specify:
> 
>     - How to copy a calendar on a CS or between CSs.
> 
>     - How a group operations on a set of calendars.
[Snip]

Please reread that last one carefully.  It does _not_ preclude us having groups on ACLs, it discusses "operations on a set of calendars".  The work item was quoted as "CAP Group definitions, dynamic and static and how groups are used in 
VCARs. Policy definitions, in a VCAR format." and not referring to groupings of calendars.

As a user, I would view the lack of 'groups' on VCARs as a functional hole 
in CAP since I my choice of mail clients and servers that handle it just 
fine.  Yes, there are some added intricacies to calendars that do not 
exist in mail but users dont care how hard it is for us to iron out now; 
they just have a set of existing expectations that I dont think can be 
tossed out lightly...  (Im somewhat surprised that David Madeo and other 
end user reps are not tossing their hats into the ring on this yet.  Have 
they all timed out??)

My previous question still stands:  could post the argument for why _not_ to have groups in CAP?

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked] (Steve Mansour)
Date: Tue, 19 Oct 1999 14:25:34 -0700

> _not_ to have groups in CAP?

The short answer is that it simplifies things a lot.

Sounds like you have something in mind. Could you explain what you're
thinking:

   * How are the members of the group resolved/expanded?
   * Are you thinking that the CAP server maintains some notion of
     groups of UPNs or that these groups are managed by something else?
   * Is it just left to the server implemenation?

There are many issues with all these things, but it would help to
understand better how you had envisioned this group capability would
function.

-Steve

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Oct 1999 16:23:20 -0700

> My previous question still stands:  could post the argument for why _not_ to

I think the word 'group' needs to be defined. And I am not sure
which usage you mean (or the requirements doc means).

I thought we all agreed that transaction locking was out. Which is
something that is need to operate on a set of calendars (a group?).
The complications arise when we try to back out changes. (What if
x of y calendars can not take the appointment [quota issue or something]?)
How do you back out any inserts into any other calendars?

So as I read the requirements doc, a statement that describes
that the problem exists, covers the issue. I am open to other ideas
or to see what others think. That is just what I thought.

I *REALLY* am not trying to force any issue. I *AM* trying to
drive issues to closure by stating what I think, and as in
this case - find out that I may be wrong.

-Doug

---

From: David Madeo <[email-masked]>
Date: Wed, 20 Oct 1999 01:06:22 -0400

[email-masked] wrote:

> >   CAP is not required to specify
> Please reread that last one carefully.  It does _not_ preclude us
> having groups on ACLs, it discusses "operations on a set of
> calendars".  The work item was quoted as "CAP Group definitions,
> dynamic and static and how groups are used in VCARs. Policy
> definitions, in a VCAR format." and not referring to groupings of
> calendars.
>
> As a user, I would view the lack of 'groups' on VCARs as a functional
> hole in CAP since I my choice of mail clients and servers that handle
> it just fine.  Yes, there are some added intricacies to calendars that
> do not exist in mail but users dont care how hard it is for us to iron
> out now; they just have a set of existing expectations that I dont
> think can be tossed out lightly...  (Im somewhat surprised that David
> Madeo and other end user reps are not tossing their hats into the ring
> on this yet.  Have they all timed out??)

I think (as others are suggesting) that "groups" is an overloaded term
which we'd do well to either flesh out definitions for, or avoid the use
of.

There are "operations on more than calendar" which Doug refers to, the
"lists of users" groups which Bruce is discussing, and I suspect more
than one person is thinking of a "non-human" calendar that a group of
people use as a "group calendar".

I think Doug's area is a complex topic where it's all or nothing,
requiring either transaction locks, or two passes to verify that
everyone or noone was scheduled.  I'll completely avoid this one, since
I suspect it's either a narrow niche I don't care about, or extremely
useful  in a way I'm not able to comprehend right now.

The "lists of users" type of groups is more interesting to me.  One of
my other projects right now involves setting ACL's based on either users
or groups defined in LDAP.    The ability to define an ACL based on an
LDAP group entry which includes uniquemembers and which happens to be an
internal  mailgroup is priceless.

My users already keep the mailgroups based on organizational units up to
date.  The HR department is automatically populating groups of people
based on cost centers.   The end users know how to add themselves to
topic oriented mailgroups (such as our internal "yankeestickets"
mailgroup).  As a result, I don't have to do any work in setting up
ACL's:  the users do it for me.  They pick which mailgroups they'd like
to grant access to, and the rest happens automagically.  95% of the
ACL's are defined with groups rather than users.  So there's little or
no need to constantly update VCAR's to list new individuals, or remove
old ones.

So yes, I'd strongly argue for allowing VCAR's to store LDAP DN's as an
entity, which can be expanded when required, rather than when saving the
VCAR.  The downside is of course that we have 30,000 "group" entries in
our LDAP database, so a cache may well be warranted.  And if the (thin)
client doesn't know or want to know about LDAP.

The last definition of a group calendar is merely a misunderstanding
that we should make sure is cleared up.

Satisfied Bruce? :-)

dmadeo