Subject: Re: VCAR: CARID Property

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Dec 2001 12:25:52 -0500

For those that haven't follow this thread closely
here's a summary of my proposition :

1- Let's add a UID property in VCAR components to have
   a way to uniquely identify them.  How can we go
   wrong by putting unique ids in components? :-)

2- Let's add a NAME property in VCAR components to
   allow users to specify a localizable display name
   in their VCARs.

3- Let's use the NAME property in VCAR components to
   hold the predefined names of the CAR-MIN VCARs.
   These predefined names would not be localized, but
   a CUA could always display them in a localized form.

4- CARREF should be made to unique ids (UID) instead
   of names (NAME) which are not unique.

Here's some examples:

Definition of the CAR-MIN DEFAULTOWNER:

   BEGIN:VCAR
   UID:[email-masked]
   NAME:DEFAULTOWNER
   ...
   END:VCAR

Definition of a VCAR that grants READ rights
to Doug:

   BEGIN:VCAR
   UID:[email-masked]
   NAME;LANGUAGE=FR-ca:Octroyer droits de lecture a Doug
   ...
   END:VCAR

Definition of a VCAR that makes a reference
to the previous VCAR:

   BEGIN:VCAR
   UID:[email-masked]
   GRANT:CARREF=[email-masked]
   ...
   END:VCAR

Doug Royer wrote:
> 
> Bernard Desruisseaux wrote:
> 
> > BTW, OWNERRIGHTS is not part of the predefined CARID,
> > but that's beside the point.
> 
> Should have said DEFAULTOWNER -- :-)
> (This one moved from the end, I modified the text send by Bernard
>  and myself by replacing OWNERRIGHTS with the correct tag: DEFAULTOWNER).
> 
> > Doug Royer wrote:
> > >
> > > Bernard Desruisseaux wrote:
> > >
> > > > 2- Do we really need a VCAR specific property to hold
> > > >    VCAR identifiers?  Couldn't we simply use the UID
> > > >    property for that purpose?
> > >
> > > The more I think about this, the more I am concerned that
> > > it's not a good idea. Take the predefined CARID's for example:
> > >
> > >         DEFAULTOWNER is the CARID.
> > >
> > > However MANY different calendars will not have the same contents
> > > for that VCAR. So it is no longer a unique ID for a VCAR. It is only
> > > unique for its scope. So by definition we would be defining VCARS
> > > with Unique IDs that were not Unique IDs. And a VCAR/UID would then
> > > not uniquely define a VCAR.
> > >
> > > For ALARMID, we are not pre-defining any, so UID would be okay
> > > with me.
> >
> > On the other hand, when I would write the following VCAR:
> >
> >       BEGIN:VCAR
> >       GRANT:CARREF:DEFAULTOWER
> >       ...
> >       END:VCAR
> 
> You could, but I don't think that is a valid VCAR.
> Did you mean the following VCAR that uses an existing VCAR?
> 
>         BEGIN:VCAR
>         GRANT;CARID=DEFAULTOWNER:...
>         ...
>         END:VCAR

I mistakenly put a colon (:) after CARREF instead of an
equal sign (=).  Other than that, my examples follows the
specification (http://calsch.org/ietf/iCal-updates.html).

On the other hand, I would agree that we need to review
how VCAR should make reference to other VCARs.  I will
propose something to the list.

> > I wouldn't know for sure that it will always make reference
> > to the same VCAR.

As I said above, by making reference to non-unique CARID,
VCARs making reference to a VCAR that has just been deleted
will all of a sudden start making reference to another VCAR.
In my opinion, this could lead to bad surprise.

References (CARREF) should be made to unique ids (UID) to
avoid such surprise.

> > Furthermore, a VQUERY performed on a hierarchy of VAGENDAs
> > could return multiple VCARs with the same CARID.  The calendar
> > user wouldn't have any way to distinguish the returned VCARs.
> 
> For the same TARGET, the contents of CARID 'foo' is only the
> same at one instance in time. And a VCAR is contained in the hierarchy
> of BEGIN/END matched to a TARGET and CMDID, thus TARGET+CARID is
> unique at one point in time.
> 
> It is true that TARGET:1 and TARGET:2 can each have a CARID:123
> and they might not have same contents. That's my point - it is
> CARID is only unique per calendar. Unlike UID which is supposed
> to be unique in the world.
> 
> With CARID, a CUA can find out what it can do, and there is
> a handle to help organize them in a calendar. But the contents
> of that VCAR are not static - only the CARID value is static
> and as CUA's need to find out what they can do, that is why
> the predefined CARIDs were created - so a CUA can find
> things by predefined name - CARID.
> 
> > Finally, enforcing specific identifier for the CAR-MIN VCAR
> > will not allow users to make reference to the VCAR they are
> > re-defining (their new definition would hide the previous
> > definition(s)).
> 
> The point of the defined VCARs is that a CUA can find
> if it can do specific things and find the calendars specific
> contents for that known named CARID. So no matter what
> the contents of that VCAR, a CUA can find its REQUESTONLY by
> doing a VQUERY for REQUESTONLY by name.
> 
> Otherwise a CUA would have to VQUERY for all VCARs, then
> sort them itself.

You are assuming that a CU will always have READ access
to all the VCARs that applies to him.  If I'm giving you
access to my calendar I may not want you to know who else
has access to my calendar.

Although CUAs may try to evaluate the VCARs, only the CS
will be able to evaluate them properly.

> 
> > What would you think of using reserved names for the CAR-MIN
> > VCARs instead?
> 
> The predefined CARIDs are part of CAR-MIN. So, what do
> you mean by 'instead'? Did you mean CAR-MIN only? If so
> we would have two version of VCAR. Currently one is just an
> extension of the other.

I meant using the NAME property to hold the value of
predefined "names", e.g.,

   NAME:DEFAULTOWNER

while using UID to hold an Id unique in the world :

   UID:[email-masked]

> 
> > It is not ideal, since we would have to make
> > the CUA responsible for the localization of these reserved
> > names,
> 
> The point is that they are FIXED names, so a CUA can do
> a VQUERY by name - localizing the 'reserved names' breaks
> that ability.

The NAMEs would NOT be stored localized on the server in order
to keep this ability.  As I said, it would be the responsiblity
of the CUA to localized these reserved-names (if at all).

> >but on the other hand, it should be sufficient to meet
> > our requirements.  For instance:
> >
> >    BEGIN:VCAR
> >    UID:[email-masked]
> >    NAME:DEFAULTOWNER
> >    ...
> >    END:VCAR
> 
> How? Above you said that DEFAULTOWNER can be localized, so
> tell me, how I find the DEFAULTOWNER if you call it 'asldkfjfjs'
> in your locale? Show me a VQUERY that can fetch DEFAULTOWNER
> no matter what the localized name?

I meant to say that the CUA could localized DEFAULTOWNER if it
wants to, not that the NAME could not be stored localized in
the server.  So the CUA would always query the NAME DEFAULTOWNER.

> 
> > That raises another question with respect to overriding
> > inherited VCARs:
> >
> > Was a VCAR with the CARID:DEFALTOWNER(a) supposed to override
> > all RIGHTS value type of other VCARs with the same CARID
> > in the calendar hierarchy, or (b) simply specific GRANT and
> > DENY as you mentioned in your reply to (VCAR: Overriding
> > inherited VCAR)?
> 
> In all cases, a calendars specific VCARS details override any
> inherited VCAR details. So yes (b).
> 
> I took your original question to mean:
> 
>         What happens if the VCAR for a calendar overrides
>         some (but not all) of the GRANT/DENY that it would
>         have inherited?
> 
> I think I said that those specific differences are resolved
> to the calendar specific VCARs - the specific calendar VCAR
> details win.
> 
>         Top level calendar:
> 
>                 BEGIN:VCAR
>                 CARID:REQUESTONLY
>                 GRANT:UPN=joe,sam,tom;....
>                 ...
>                 END:VCAR
> 
>         Target Sub-Calendar under the Top level calendar:
> 
>                 BEGIN:VCAR
>                 CARID:REQUESTONLY
>                 DENY:UPN=joe:...
>                 ...
>                 END:VCAR
> 
> Sam and Tom only can do METHOD:REQUEST on the target calendar.
> A VQUERY for REQUSESTONLY on the target calendar would return:
> 
>                 BEGIN:VCAR
>                 CARID:REQUESTONLY
>                 GRANT:UPN=sam,tom
>                 ...
>                 END:VCAR

Hold on, if the VCAR returned by the "search" command is
the computed VCAR as you say, how will I be able to get
the value of the stored VCAR so that I can modify it?

Although it may seem handy to return computed VCAR to CUA,
we have to keep in mind that the main goal is to allow
calendar users to set their access rights through CAP, not
to perform the evaluation of VCARs themselves.

> Even though no specific VCAR with those contents was specifically
> stored. The predefined VCARs are by function identifiable
> by CARID, not by contents. That's why UID is not valid, at
> no point would that UID in a VCAR uniquely identify any contents.
> 
> > If (a) is true, why the CAR-MIN VCAR need to be handled in
> > a special way?
> 
> CAR-MIN is a subset of CAR-FULL. The fact is that there
> are some VCARs predefined by 'function', VQUERYable by predefined
> CARIDs who's contents are not predefined and thus not unique.
> 
> > If (b) is true, there is no reason to use the same CARID
> > more than once.  Any VCAR can override the CAR-MIN VCARs
> > regardless of its CARID.
> 
> I think that my example shows that the same CARID is used
> more than once in a CS- and needs to be.
> 
> -Doug

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

---

From: Patrice Lapierre <[email-masked]>
Date: Fri, 21 Dec 2001 11:37:35 -0500

>    of names (NAME) which are not unique.

  Actually, it is already specified that the identifier 
specified by CARREF must be unique to the CS. From section 1.2 
of the "Proposed Changes To iCalendar Needed For CAP":

  "The CARREF rule part specifies a reference to a particular "VCAR"
   calendar component. The text is matched to a CARID property value
   within a "VCAR" calendar component. This allows for a particular set of
   calendar access rights to be defined once and referenced multiple
   times. The "VCAR" identifier specified by this rule part is unique to
   the calendar store."

  Given that restriction, it would make sence to use UID instead of
CARID. And to retrieve CAR-MIN VCARS a CUA shouldn't have any problems 
searching on the NAME property.
  
--
Patrice.

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Dec 2001 12:02:27 -0700

>    wrong by putting unique ids in components? :-)

Does the UID change each time there is a local change 
to the VALARM contents?

If yes, then that can break MODIFY.

If no, then you have multiple VALARMs with the SAME
UID (The one or more different VALARMS each the same UID each
in a unique calendar/sub-calendar), and NOT the same contents.
So how to you MODIFY?!

I think both break things. This needs to be thought out.

I don't think it can be done that way.

Proposal:

	(1) Add SEQUENCE as a MUST for VALARM in the CS
	    that starts at zero (0). If the incoming object does
	    not have any, then the CUA MUST add them before depositing
	    them in the CS.
	
	    This would make them unique per object and solve the
	    MODIFY problem.

	(2) Create a new SCOPE parameter for the SEQUENCE property.

            The default value if not specified is 'global', and
	    can be set to 'local'. Where 'local' means only visible
	    to the calendar owners(s) and 'local' VALARMS MUST NOT
	    be sent to non-calendar-owner(s).

	    This would allow global (ORGANIZER originated VALARMS),
	    to have numbers starting at zero. And it would allow
	    local VALARMS to start with a sequence of zero:

		BEGIN:VALARM
		SEQUENCE:0
		...
		END:VALARM
		BEGIN:VALARM
		SEQUENCE;SCOPE=local:0
		...
		END:VALARM

            This would solve the MODIFY problem.

	(3) Add a new ENABLE parameter to TRIGGER with a default
	    value of 'true', and could be set to 'false'. If
	    not specified it default to 'true'.

 	    AND ENABLE is local to the calendar ONLY. That means
	    the ORGANIZER MUST NOT set or specify ENABLE, and the
	    owner MUST NOT export the ENABLE parameter to non-owners
	    of the object when exporting from the local store.

	    This would allow local users to enable or disable
	    both local and global VALARMS.

		...
		BEGIN:VALARM
		SEQUENCE:2
		TRIGGER;ENABLE=false:20020101T000000Z
		SUMMARY:NEW YEAR
		...
		END:VALARM
		BEGIN:VALARM
		SEQUENCE;SCOPE=local:0
		TRIGGER:20020101T000000
		SUMMARY:NEW YEAR
		...
		END:VALARM
		...

Now with this the ORGANIZER can modify VALARMS, and the local
owner can decide the users preferences for TRIGGERS.  I think this
solves the MODIFY problem by uniquely identifying VALARMS in each
object (by using SEQUENCE and SCOPE) and gives the local user control
over VALARM TRIGGERs without breaking MODIFY.

I don't see how using UID solves the MODIFY uniqueness problem 
(I see that it adds more problems). Plus using UID does
not allow the local user to alter TRIGGERs without breaking MODIFY.

>    allow users to specify a localizable display name

Then lets add the LANG parameter to the NAME property
and allow multiple NAME properties in each object?
And the NAME property is optional, and if not specified
its value is CARID? (or if I understand you below,
if it is a CUA property only - it is out of scope for
CAP).

>    a CUA could always display them in a localized form.

So are you proposing that in this case the CARID and the NAME
be the same, or are you saying that if NAME is not present
you can use CARID?

>    of names (NAME) which are not unique.

UID does not apply to VCAR's, the SAME UID has different
contents - it there for does not uniquely identify anything.
Lets stop overloading UID just because it is an id. CARID
is by function, who's contents is not unique.

> References (CARREF) should be made to unique ids (UID) to

You see VCARS as static. They are NOT static. CARREF can break
things if you don't have control over the object pointed to
by CARREF. And as VCARs are both inherited and a logical AND
there is no reason to have a CARREF. Simply define the VCAR
you want. Add or delete from it, and/or add or delete more VCAR
rules.  You do NOT process them in order. They are more like bits
in a hardware register who's default value is zero (for deny). You
get your parents bits, AND them to your bits - the '1' (grant)'s
that are left - are what you can do. And if the next time you try
an operation if your parent bits have changed and it does not allow
something, it won't work no matter how many other VCARS you have
or pointed to.

> > > user wouldn't have any way to distinguish the returned VCARs.

If for what ever reason, you get multiple VCAR's with the same
CARID - then they are the same within the same scope. If they are not
the same - your  CS is busted. That's the idea. If you change by CARID,
you CHANGE THEM ALL within that sphere of influence. If you want to
modify one entry and not have that CARID apply to that object or
sets of objects, then remove that CARID from that object or set
of objects and add VCARS that you want.

> has access to my calendar.

No, I am not.

As the default is DENY, I only have to show you what the
currently authenticated UPN has access to. The CUA may make
no other assumptions. The calendar owner MAY have full access,
but might not.

> will be able to evaluate them properly.

True, but the CUA will see those as DENY as the CS will
not have shown them a VCAR of GRANT. 

Again, they are not static. Any UPN including the OWNER, can
only see what they are allowed to see, everything else to
them at that point in time, in that session, for that UPN,
is DENY - no matter what may actually be in the CS. For example,
the CS administrator my have access, and not even the calendar
owner can tell.

> of the CUA to localized these reserved-names (if at all).

Then it is out of scope for CAP as it is the CUA <-> CS protocol.
What ever you do in a CUA -only- is not in scope for CAP.

> the value of the stored VCAR so that I can modify it?

They are NOT static they are fluid. You grand or deny access only.
If you were to "GRANT;UPN=Bennard" TEN (10) times, it is only set once.
You would not get ten VCARs back you would only get one.

> to perform the evaluation of VCARs themselves.

The CUA does not care how the GRANT or DENY was set. Just that
is it. And it can send a new GRANT or DENY to the CS and it may
or might not be taken depending on the currently authenticated
users access.

A CUA does not have to understand VCAR's. It MUST BE prepared
to deal with 'permission denied'.