Re: Groups revisited

[rans@xxxxxxxxxxxx (Richard Shusterman)]

pregen@xxxxxxxxxxxxxxxxxx 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
> authenticate UPN's.

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