[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: W-19 - open item - can we defer it?
<x-html>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Bruce_Kahn@iris.com wrote:
<blockquote TYPE=CITE>
<br><font face="sans-serif"><font size=-1>Doug provided the citation:</font></f
ont>
<p><font face="Courier New"><font size=-1>>>From draft-ietf-calsch-capreq-03.tx
t
(the latest):</font></font>
<br><font face="Courier New"><font size=-1>></font></font>
<br><font face="Courier New"><font size=-1>>4.3.1 Deferred
Requirements for Operations on a Calendar</font></font>
<br><font face="Courier New"><font size=-1>></font></font>
<br><font face="Courier New"><font size=-1>> CAP is not required
to specify</font></font>
<br><font face="Courier New"><font size=-1>> -
How to copy a calendar on a CS or between CSs.</font></font>
<br><font face="Courier New"><font size=-1>> -
How a group operations on a set of calendars.</font></font>
<br><font face="sans-serif"><font size=-1>[Snip]</font></font>
<p><font size=-1><font face="sans-serif">Please reread that last one carefully.
It does _<u>not</u>_ preclude us having groups on ACLs, it discusses "</font><f
ont face="Courier New">operations
on a <font color="#FF0000">set of calendars</font></font><font face="sans-serif
">".
The work item was quoted as "</font></font><font face="Times New Roman"><font s
ize=+0>CAP
Group definitions, dynamic and static and how groups are used in VCARs.
Policy definitions, in a VCAR format.</font></font><font face="sans-serif"><fon
t size=-1>"
and not referring to groupings of calendars.</font></font>
<p><font face="sans-serif"><font size=-1>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??)</font></font><
/blockquote>
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.
<p>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".
<p>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.
<br>
<p>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 <b>priceless</b>.
<p>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.
<p>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.
<br>
<p>The last definition of a group calendar is merely a misunderstanding
that we should make sure is cleared up.
<p>Satisfied Bruce? :-)
<p>dmadeo</html>
</x-html>