Subject: VCAR: CARID Property

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 20 Nov 2001 16:55:06 -0500

Here's some issues with the CARID property specified in
the document "Proposed changes to iCalendar needed for CAP"
(iCal-updates) which is available at the following URL:

http://calsch.org/ietf/iCal-updates.html

1- The "CARID" property specifies the local identifier
   for the "VCAR" calendar components.

   By looking at the examples provided in the document
   "iCal-updates" it seems that an additional property
   should be added to the VCAR component to allow users
   to specify a localizable display name in their VCARs.
   In my opinion CARID should not be displayed to users.
   The value of CARID should only be used with CARREF.

   I propose to add the property NAME in VCAR components.

2- Do we really need a VCAR specific property to hold
   VCAR identifiers?  Couldn't we simply use the UID
   property for that purpose?

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

---

From: Doug Royer <[email-masked]>
Date: Wed, 21 Nov 2001 14:01:29 -0700

>    I propose to add the property NAME in VCAR components.

I could go for that.

>    property for that purpose?

Same as with ALARMID. They could use the name UID.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 21 Nov 2001 15:18:33 -0600

To be consistent should it be NAME or CN? (as in "common name" which I think
is what we use elsewhere)?

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Wednesday, November 21, 2001 3:01 PM
To: [email-masked]
Subject: Re: VCAR: CARID Property

I could go for that.

---

From: Doug Royer <[email-masked]>
Date: Wed, 21 Nov 2001 14:52:48 -0700

> is what we use elsewhere)?

CN is a parameter (not a property).

That is:

	CARID;CN="My calendar rights as owner.":OWERRIGHTS

I think that Bernard proposed:

	CARID:OWNERRIGHTS
	NAME:My calendar rights as owner.

From 2445 (CN) - I don't think it matches:

   Description: This parameter can be specified on properties with a
   CAL-ADDRESS value type. The parameter specifies the common name to be
   associated with the calendar user specified by the property. The
   parameter value is text. The parameter value can be used for display
   text to be associated with the calendar address specified by the
   property.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 21 Nov 2001 17:01:56 -0500

> is what we use elsewhere)?

No. CN is a parameter, not a property, and was meant for
something else.  Here's what iCalendar says for CN:

> 4.2.2 Common Name
> 
>    Parameter Name: CN
> 
>    Purpose: To specify the common name to be associated with the
>    calendar user specified by the property.

The property NAME which is already used in VAGENDAs,
could be defined to specify a localizable display
name for components (e.g., VAGENDAs, VCARs, and
VQUERYs).

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 21 Nov 2001 17:45:26 -0500

>         NAME:My calendar rights as owner.

In fact, I proposed to use UID instead of CARID,
so that would be:

  UID:OWNERRIGHTS

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Wed, 21 Nov 2001 16:46:13 -0700

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

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

-Doug

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 22 Nov 2001 10:26:09 -0500

> For ALARMID, we are not pre-defining any, so UID would be okay

On the other hand, when I would write the following VCAR:

      BEGIN:VCAR
      GRANT:CARREF:OWNERRIGHTS
      ...
      END:VCAR

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

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.

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

What would you think of using reserved names for the CAR-MIN
VCARs instead?  It is not ideal, since we would have to make
the CUA responsible for the localization of these reserved
names, but on the other hand, it should be sufficient to meet
our requirements.  For instance:

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

That raises another question with respect to overriding
inherited VCARs:

Was a VCAR with the CARID:OWNERRIGHTS (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)?

If (a) is true, why the CAR-MIN VCAR need to be handled in
a special way?

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.

BTW, OWNERRIGHTS is not part of the predefined CARID,
but that's beside the point.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 Nov 2001 14:25:54 -0700

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

> >         DEFAULTOWNER is the CARID.
> >
>       GRANT:CARREF:DEFAULTOWER

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

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

> re-defining (their new definition would hide the previous

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.

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

> It is not ideal, since we would have to make
> 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.

>but on the other hand, it should be sufficient to meet
>    NAME:DEFAULTOWNER

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?

> Was a VCAR with the CARID:DEFALTOWNER(a) supposed to override

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

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

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.

> more than once.  Any VCAR can override the CAR-MIN VCARs

I think that my example shows that the same CARID is used
more than once in a CS- and needs to be.

-Doug