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

From: [email-masked]
Date: Tue, 19 Oct 1999 15:13:26 -0400

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 to deal with (ie: new members to the group must be 
manually added everywhere the group was exploded by all CUs!  Ugh!!).  The 
use of dynamic groups is the only really likeable choice from a CUs 
perspecitive.  They dont have to make manual 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 what 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 
of 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 to 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...

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: Doug Royer <[email-masked]>
Date: Tue, 19 Oct 1999 12:22:56 -0700

>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.

[email-masked] wrote:
> 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 to
> deal with (ie: new members to the group must be manually added everywhere the
> group was exploded by all CUs!  Ugh!!).  The use of dynamic groups is the only
> really likeable choice from a CUs perspecitive.  They dont have to make manual
> 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 what
> 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 of
> 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 to
> 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...
> 
> Bruce

---

From: [email-masked] (Richard Shusterman)
Date: Tue, 19 Oct 1999 12:55:04 -0700

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 "directory
service implications" since there is no common directory implementation of groups.
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?

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Oct 1999 13:39:46 -0700

> useful is a VCAR that can't specify a dynamic group of users?

A VCAR can specify a list of users:

BEGIN:VCAR
CARID:Permisssions for group 'A'
GRANT:UPN=<user1>...
GRANT:UPN=<user2>...
END:VCAR

---

From: David Madeo <[email-masked]>
Date: Tue, 19 Oct 1999 17:40:50 -0400

> >      - How to copy a calendar on a CS or between CSs.

As an aside, I think I have an issue with this.  I tell my users one of the main
benefits of the interoperability work is that they won't be trapped again in a
proprietary data format.  The last time we switched products, we had to throw away a
lot of data due to a products inability to export it's data.  I'm not sure how many
more episodes like that my career can survive.

While I can certainly appreciate the complexity of a real moveuser tool, I'd like to
see an agreement on at least the details of an export and import of a Calendar.
I just skimmed the CAP document quickly to look for references on how to extract not
only components, but the calendar properties and the VCAR's.  While it certainly looks
like you can do it, I'd appreciate a paragraph explicity explaining what we expect.

Comments?

dmadeo

---

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

David Madeo wrote:

> ...
> While I can certainly appreciate the complexity of a real moveuser tool, I'd
> like to see an agreement on at least the details of an export and import of
> a Calendar. I just skimmed the CAP document quickly to look for  references
> on how to extract not only components, but the calendar properties and the
> VCAR's.  While it certainly looks like you can do it, I'd appreciate a
> paragraph explicity explaining what we expect.
> 
> Comments?

Great issue. I have added it as 'W-29 import/export".

I agree with you, it will be needed. Also for calendar synchronization
with disconnected devices. There will need to be a way for a intermediate
tool to pull calendars from 2 or more sources, compare, and perhaps
with a users input - merge. The tool it self is not in scope, but
I think it will be a need that we must address (in addition to
import/export). And I think that import/export will also address
the issue.

I do however remember discussions (I forget the results) where this
was discussed and some problems with supporting synchronization were
deemed out of scope. Just supporting import/export may solve the
issue and address the both needs.

-Doug