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

[rans@xxxxxxxxxxxx (Richard Shusterman)]

Since I submitted this work item, I think I should pipe in here.

The term "group" here was meant for "groups of users" not group operations on a
 set
of calendars. There is a difference. And as Steve pointed out, there are "direc
tory
service implications" since there is no common directory implementation of grou
ps.
But as Bruce points out, how useful is CAP without groups or more specifically,
 how
useful is a VCAR that can't specify a dynamic group of users?

Doug Royer wrote:

> >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.
>
>      - How to undelete a calendar.
>
>      - Auto processing on scheduled components in a calendar that need
>      action.
>
>        For example, if someone tries to create a meeting on a calendar
>        for a user who is on vacation, the CS may automatically delegate
>        the meeting to another user.
>
>
> Bruce_Kahn@iris.com wrote:
> >
> > Doug replied:
> > >I agree. We did say that group operations will not be addressed at
> > >this time.
> >
> > That agreement was not the WG and it was not everyone...
> >
> > The concept of groups is really two pronged: they can be static or dynamic.
> >  Doing static groups (ie: explode them out at the time you use them) is not
 a
> > viable solution for any real system.  Just too many poor usability issues t
o
> > deal with (ie: new members to the group must be manually added everywhere t
he
> > group was exploded by all CUs!  Ugh!!).  The use of dynamic groups is the o
nly
> > really likeable choice from a CUs perspecitive.  They dont have to make man
ual
> > changes on all the places the original group was used.
> >
> > However this puts the cart before the horse: Do we want to preclude the use
 of
> > groups entirely is what needs to be answered first.  Being one of the guys
who
> > is gonna have to build this engine I certainly whince at the thought of wha
t
> > this entails for my implementation.  However as a CU I most certanly would
> > want to have groups just like I currently have in eMail and in iCalendar.
> >
> > Since iCalendar is "group enabled", why would we want to preclude the use o
f
> > groups in CAP??  This kinda reminds me of the Volkswaggen commercial where
the
> > guys tie the mattress onto their roof before the light changes but manage t
o
> > tie their doors shut...
> >
> > Perhaps it would help others to decide either way if someone could post the
> > argument for why _not_ to have groups in CAP?  I certainly dont recall the
> > reason why not to have them...
>