Subject: Re: 05 sendata -> beep.

From: [email-masked]
Date: Thu, 24 Jan 2002 13:31:24 -0500

George, in your reply to Doug you reference a conference call.  The 
agreement in a conference call must also be an agreement on the list.  I'm 
not sure we do have agreement on this topic.  Can you repost it to the 
list - I know this sounds redundant.  But I want to ensure we know the 
list reads the item "explicitly" and we are sure everyone agrees.  If no 
one comes back and says that what you posted is wrong does not necessarily 
make it right.  If one person comes back and says it is wrong, first off, 
that person must defend why they believe that and then offer text or 
explanations to prove that belief.  Therefore, I really want to make sure 
we review what Doug has said.  I too remember that we wanted to ensure 
that CAP objects remained iCalendar objects so they can be passed around 
via other methods if your calendar product does not have access to a CAP 
server.  Otherwise, no one will use the product.  If I can not be assured 
that my calendar request makes it to everyone I invite - why would I use 
the product.  Or am I missing something here.  I really wish some other 
folks would comment on these topics.  It would help the chairs and editors 
come to conclusions and resolutions.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

George Babics <[email-masked]>
Sent by: [email-masked]
01/24/02 11:43

        To:     [email-masked]
        cc: 
        Subject:        Re: 05 sendata -> beep.

Doug Royer wrote:
> 
> George Babics wrote:
> >
> > Doug Royer wrote:
> >
> > > The CAP 'COMMANDS' were (05):
> > >
> > >         ABORT                   - now in CAP-BEEP   - GREAT
> > >         AUTHENTICATE            - part of BEEP      - EASY
> > >         CALIDEXPAND             - NOT in 06 at all  - and I don't 
care :-)
> >
> > >         CAPABILITY              - now in CAP-BEEP   - GREAT
> > >         CONTINUE                - now in CAP-BEEP   - GREAT
> > >         DISCONNECT              - part of BEEP - or is it MISSING?
> > >         IDENTIFY                - now in CAP-BEEP   - GREAT
> > >         SENDDATA                - NOT in 06 at all  - MISSING
> > >         STARTTLS                - part of BEEP      - EASY
> > >
> > >         UPNEXPAND               - NOT in 06 at all  -
> > >                 The was determined needed as viewed by the WG as a
> > >                 way to expand a group-UPN into its list of users so
> > >                 the CUA could determine who (non-group UPN) the 
command
> > >                 would effect.
> >
> >   Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as 
viewed by the WG.
> >   See:
> >
> >     http://www.imc.org/ietf-calendar/mail-archive/msg02128.html
> 
> First - I really don't care if they are gone. I never saw that
> they were needed.
> 
> Second - one company agreeing with itself it not really that
> impressive of a reason :-)

This was agreed to, in a CAP conference call, by many people.
It was posted on the list to see if anyone else had objections
to removing them. No one else commented.

George

---

From: George Babics <[email-masked]>
Date: Thu, 24 Jan 2002 13:39:22 -0500

Hi Pat,

  What I said in the e-mail was that during a CAP editors conference
call, it was suggested we remove the UPNEXPAND and CALIDEXPAND commands.
This suggestion was posted to the list, and no one objected removing them.
Thus, we removed them from CAP.

  If someone does feel that the commands are necessary, please speak up
and let us know!

George

[email-masked] wrote:
> 
> George, in your reply to Doug you reference a conference call.  The agreement in a conference call
> must also be an agreement on the list.  I'm not sure we do have agreement on this topic.  Can you
> repost it to the list - I know this sounds redundant.  But I want to ensure we know the list reads
> the item "explicitly" and we are sure everyone agrees.  If no one comes back and says that what
> you posted is wrong does not necessarily make it right.  If one person comes back and says it is
> wrong, first off, that person must defend why they believe that and then offer text or
> explanations to prove that belief.  Therefore, I really want to make sure we review what Doug has
> said.  I too remember that we wanted to ensure that CAP objects remained iCalendar objects so they
> can be passed around via other methods if your calendar product does not have access to a CAP
> server.  Otherwise, no one will us! e the product.  If I can not be assured that my calendar
> request makes it to everyone I invite - why would I use the product.  Or am I missing something
> here.  I really wish some other folks would comment on these topics.  It would help the chairs and
> editors come to conclusions and resolutions.
> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652
> 
>   Sent by: [email-masked]            To:        [email-masked]
>                                                        cc:
>   01/24/02 11:43                                       Subject:        Re: 05 sendata -> beep.
> 
> Doug Royer wrote:
> >
> > George Babics wrote:
> > >
> > > Doug Royer wrote:
> > >
> > > >         CALIDEXPAND             - NOT in 06 at all  - and I don't care :-)
> > >
> > > >                 the CUA could determine who (non-group UPN) the command
> > > >                 would effect.
> > >
> > >   Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as viewed by the WG.
> > >   See:
> > >

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Jan 2002 12:34:35 -0700

>   If someone does feel that the commands are necessary, please speak up

This is not an intent to agree or disagree. It is my intention
to understand. After re-reading the email sent by Patrice, it
appears that he was reading bogus text that was placed in 05.

In Montreal we invented the 'USER GROUP' idea that is in CAP:

   User Group (UG)

         A collection of Calendar Users and/or User Groups.  These
         groups are expanded by the CS and may reside either locally or
         in an external database or directory.  The group membership may
         be fixed or dynamic over time.

Then there was debate over how that effected UPNs and VCARs.
Someone in effect asked:

	If a UPN is in fact a UG, how will I ever be able
	to manage my VCARs if I don't know who is in the UPN (UG) ?]

	How can I decide IF I want a UG in the list of CUs that
	I wish to restrict or allow if I don't know who is
	'random-ug-name' ?

So UPNEXPAND was invented.

Now re-reading the 05 draft, the person that ADDED UPNEXPAND
added the WRONG TEXT! They seem to have added the CALIDEXPAND
text to the UPNEXPANT section - that was a large TYPO that seems
to have never been caught until now.

The UPNEXPAND command was a command to be handed any UPN.
The results would be:

	(1) That UPN (if not a UG)
OR	
	(2) A list of UPNs that belonged to that list.

So - the real question needs to be:

DOES ANYONE CARE THAT A CUA CAN NOT FIND THE UPNs THAT ARE UG's ?

Without UPNEXPAND - we should remove UG from CAP as there
is no way to manage or know who they (UG's) are.

As I recall, Bruce, Stelcor (then CS&T), Paul, and others
wanted that feature. Those that wanted to do what is commonly
called 'group calendaring' will care the most.

  Patrice Lapierre wrote in part ...:
  > 
  >   If that is the case, aren't the command CALIDEXPAND
  > and UPNEXPAND redundant. It seems that similar results
  > could be obtained by using a READ method combined with
  >  a VQUERY that performs a selection on respectively
  > the PARENT and OWNER properties.
  >

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 24 Jan 2002 15:47:08 -0500

> is no way to manage or know who they (UG's) are.

I disagree.  A calendar store is not a directory.

CAP doesn't need to provide a way to find the members of
calendar user groups, anymore than it needs to provide a
way to get the list of users (i.e., UPNs) of a given CS.

CUAs will simply have to query a directory service to find
these information.  It is already given that CUA will need
to query a directory service to find the common name matching
a given UPN (who's that guy with the UPN [email-masked]?).

We need to keep UG in CAP.  UGs greatly simplify access rights
administration.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878