Subject: Re: Groups revisited

From: [email-masked]
Date: Wed, 16 Feb 2000 20:57:20 -0500

Bruce/Richard:

Regarding the long note on Groups (which I don't want to reprint because 
it's now too long) -  basically, I think you both are saying the same 
thing.  Bruce, I think you may have hit upon something.  Everyone is 
really getting down into the nitty gritty on groups and worried that there 
is a problem.  But, to summarize what you are saying (or what I think you 
are saying) is that a group is really just a list of UPN's.  All the 
calendar product has to do is read the list and validate the members as if 
they were each an independent UPN.  Correct? If so, that seems like a 
"well, duh..."  Am I missing something, or does this really sound like 
it's a non issue and simplier than everyone has been assuming.   If it is 
true, than implementing groups should not be as hard as we envisioned??

Also, I agree with Bruce's comment about not using the Personal NAB to 
authenticate UPN's.

---

From: [email-masked] (Richard Shusterman)
Date: Wed, 23 Feb 2000 12:23:40 -0800

[email-masked] wrote:

> Bruce/Richard:
>
> Regarding the long note on Groups (which I don't want to reprint
> because it's now too long) -  basically, I think you both are saying
> the same thing.  Bruce, I think you may have hit upon something.
> Everyone is really getting down into the nitty gritty on groups and
> worried that there is a problem.  But, to summarize what you are
> saying (or what I think you are saying) is that a group is really just
> a list of UPN's.  All the calendar product has to do is read the list
> and validate the members as if they were each an independent UPN.
> Correct? If so, that seems like a "well, duh..."  Am I missing
> something, or does this really sound like it's a non issue and
> simplier than everyone has been assuming.   If it is true, than
> implementing groups should not be as hard as we envisioned??

I don't think it's really a question of "is this hard". Without group
support, I don't think
CAP will be useful for most scheduling environments. I think Bruce and I
are in
agreement on this point. However, I want this group support to be
optional for some
CS/CUA implementations that don't require scheduling, just calendaring.
Also, we need
groups that can work with multiple directory implementations and for the
thin CUA
implementations that don't want to use multiple client protocols, we
should have minimal
group lookup/expansion capabilities available thru CAP.

> Also, I agree with Bruce's comment about not using the Personal NAB to

Agreed, this was a bad example on my part. However, some CS
implementations
may be able to use Personal NAB's in group expansions.

---

From: Doug Royer <[email-masked]>
Date: Sun, 27 Feb 2000 10:53:14 -0800

Within the context of groups, when do you get MULTIPLE UPNs?
There was talk that you MUST do a UPNEXPAND each time you
authenticate? Seems a silly to have an extra round trip.
Why not do it as part of the authentication reply?

Then I still do NOT know what you do with them. At what point
does the CUA ever pass them back to the CS? If never, then
what's the point?

Perhaps those of you that understand UPN's can send some text or
email describing when you get them? The current CAP draft and
the text from Paul (I think it was from Paul) does not seem to say.

I think Bruce says they comeback as part of the authentication reply?
Yet no one that proposed any new text has replied to that question.
And I can't find any text that says that.

There was no proposed changes to the ABNF or any text, or any example
in CAP-draft that shows when you get them, other than UPNEXPAND.

As I understoon groups of calendars, it was meant to be something like:
If you happen (at run time) to be part of group-A, and there is
a calendar that has modify permission to cal-group-a, then you
can modify that calendar. So why does the CUA ever need to know
the UPN of group-A ? 'user' has or does not have permission
to modify cal-group-a. Why does the CUA care what the value
of the UPN property is that allowd that? Why can't it just
work, or you get permission denied?

I still don't get it :-)

Would it be something like:

   C: AUTHENTICATE <user> <password>
   S: 2.0
   S: .
   S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   S: Content-Transfer-Encoding: 7bit
   S:
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/CAPserver//EN
   S: VERSION:2.1
   S: CAPVERSION=1.0
   S: ITIPVERSION=1.0
   S: AUTH=KERBEROS_V4
   S: AUTH=DIGEST_MD5
   S: CAR=CAR-FULL-1
   S: MINDATE=19700101T000000Z
   S: MAXDATE=20370201T000000Z
?  S: UPN=user
?  S: UPN=group-A
   S: END:VCALENDAR
   S: .