Subject: Modifying VALARM (Was: VCAR: CARID Property)

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 14 Jan 2002 11:00:48 -0500

Doug Royer wrote:
> 
> Bernard Desruisseaux wrote:
> >
> > 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? :-)
> 

You lost me Doug.  This thread is about *VCAR* not VALARM.

If I'm not mistaken, you are re-opening the issue that
was closed at the end of November 2001.

http://www.imc.org/ietf-calendar/mail-archive/msg02442.html

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

The CS doesn't (shouldn't) change the UID of any component
automatically.  If the user wants to change the UID he can
do it himself with the "modify" command.   Now, whether the
user should be allowed to modify the UID or not is another
issue.

The same way a user shouldn't be allowed to change the
ORGANIZER property of a VEVENT he has been invited to,
we need to specify whether a user should be allowed to
modify a VALARM part of a VEVENT.

Before trying to clarify to which CUA a VALARM applies,
as was discussed in a separate thread, we should put our
energy on trying to clarify to which calendar user a VALARM
applies, and more specifically, which calendar user owns
the VALARM.

In my opinion a calendar user should be allowed to add
VALARM (as well as VCARs) to VEVENTs he has been invited
to.  As for the VALARMs that was contained in the orignal
VEVENT he was invited to, they should simply we flagged
properly so that the user can simply ignore them (i.e.,
"I can ignore this VALARM since I'm not the owner of it").

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

In my opinion, we should be looking at a more general solution,
that is, a solution that could apply to both VALARM and VCAR and
possibly other components contained within VEVENT, and other
components, in the future.

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: Mon, 14 Jan 2002 11:54:13 -0700

> http://www.imc.org/ietf-calendar/mail-archive/msg02442.html

The email link above points to VALARM, not VCAR?
As does the subject line?
So it was on topic?

> user should be allowed to modify the UID or not is another

Not UID - but the contents of the VALARM.

Once a user changes the contents of a VALARM, the UID is BOGUS
and does NOT uniquely identify anything. At that point
you have two or more VALARMs with the same UID. Now UID
means unique-but-not-really. We would then BUST UID.

> modify a VALARM part of a VEVENT.

I agree. If I change the ORGANIZER - I am busted.

I should be allowed to change the TRIGGER time or change
ACTION from DISPLAY to EMAIL in *my* calendar - without a 
COUNTER/DECLINE-COUNTER simply because its is tied to a UID
provided by the ORGANIZER.

> applies, and more specifically, which calendar user owns

If you add UID to VALARM, then the ORGANIZER that has
control of that UID, controls the contents of that VALARM.
That's why it can't be a UID.

> components, in the future.

The VALARMs and VCARs problem is the same, and different than
VEVENT UID.

That is why we had CARID's and proposed ALARMID.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 14 Jan 2002 14:40:20 -0500

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

[ See new thread "Modifying VALARM" ]

> > 2- Let's add a NAME property in VCAR components to
> >    allow users to specify a localizable display name
> >    in their VCARs.
> 
> 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? 

Actually, the parameter is LANGUAGE.

I agree that we should allow multiple NAME properties,
but I would leave it to the CUA to decide what to do
when the NAME property is not specified.

> (or if I understand you below,
> if it is a CUA property only - it is out of scope for
> CAP).

The NAME property would be stored in the CS.  Other than that
it wouldn't impact CAP any more than, say, the LOCATION property
of VEVENT! :-)

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

No.  I propose we get rid of the property CARID.
And since the UID property is meant to uniquely
identify components, I propose that we store the
CAR-MIN predefined names in the NAME property.

> 
> > 4- CARREF should be made to unique ids (UID) instead
> >    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.

CARREF have since been dropped.  So this is no longer an issue.

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

The evaluation of VCARs can't work this way.  With a default
value of '0', no matter how many '1' you'll AND you'll always
end up with 0!

According to the draft (section 2.4.2):

   The access for a particular UPN is the union of all grants
   for that UPN minus the union of its denies.

the hardware register analogy could probably work as follows
for the VCARs contained in a VAGENDA:

   (a) "OR"  all the GRANT (1) to "0000...0000";
   (b) "AND" all the DENY  (0) to "1111...1111";
   (c) "AND" the results of (a) and (b);

On the other hand, the hardware register analogy doesn't work as
nicely when it comes to consider decreed VCARs (0 = explicitly denied,
1 = explicitly granted, ? = not explicitly denied or granted)!

> 
> > > > 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.
> 
> 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.
> 
> >
> > 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.
> 
> 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.
> 
> > Although CUAs may try to evaluate the VCARs, only the CS
> > 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.
> 
> > > > 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).
> 
> 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.
> 
> > 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?
> 
> 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.

It is one thing to know whether your are granted a specific
right or not, but another to get the stored value of a VCAR.
The purpose of the "search" command is to get the value of
stored components not a computed representation of them.

Although it may be acceptable for the "search" command to
return computed values for special read-only properties
(i.e., CURRENT_DATETIME) I don't think it is appropriate for
read/write properties such as VCAR.

If the "search" command always return a computed VCAR, then
the "modify" command will also need to handle VCAR in a special
way, that is, it will have to replace all the stored VCARs by
the new VCAR being submitted.  Otherwise, the CU will be shooting
in the dark as he will have no mean of getting the stored value
of his VCARs.  Furthremore, what if someone created a new VCAR
between the time you got your computed VCAR and you modified it?

Let's say my VAGENDA has two (2) VCARs that denies you access.
How will I know that I need to modify 2 VCARs in order to grant
you access, and not only the VCAR that was returned to me by the
search command?

While the "create" command will allow me to add new VCARs in my
VAGENDA, the "search" command will be of no use when I'll want to
delete the VCARs that I have created.

As we all know, it will not always be possible for a CUA to get
all the VCARs (computed or not) that applies to the UPN by using
the search command.  Maybe we should consider another command
to let CUA query the CS to know whether a specific right has
been granted to the UPN or not.

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

Indeed.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 14 Jan 2002 15:16:28 -0500

> The email link above points to VALARM, not VCAR?

Of course!  You changed the topic from VCAR to VALARM, so
it is only normal that my reply discuss issues related to
VALARMs!

> As does the subject line?

Re: Modifying VALARM (Was: VCAR: CARID Property)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^

> So it was on topic?

Nope!  But anyway...

> provided by the ORGANIZER.

But what's gonna happen when you'll received an update
from the ORGANIZER?  You'll lose all your changes?

IMHO, I should be able to ignore the VALARM sent to me by
the ORGANIZER, and I should be able to create by own VALARM.
If I can't create my own VALARM, that would imply that I
can't have a VALARM when the ORGANIZER didn't create one.

> That's why it can't be a UID.

UID is not the problem.  The problem is that unlike
VEVENT, VALARM don't have an ORGANIZER property.
What would you think of adding an ORGANIZER property?
It would provide an easy way to configure a CUA to
ignore all VALARM for which I'm not the ORGANIZER.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 14 Jan 2002 14:48:13 -0700

Bernard Desruisseaux wrote:

> identify components, ...

The assumption is that if you have UID=1, that knowing
that tells you that the contents are consistent in the
world, and that those consistent contents are tied 1:1
to the NAME? - That's just not true.

> .. I propose that we store the

If we go with that (UID):

Are you saying that if I change the contents of a VCAR and you
have specified a UID, that I have to
 COUNTER/DECLINE-COUNTER/REQUEST+new-SEQUENCE
in order for our VCAR's to be in sync?

   If no, how do you propose to keep the UID's uniquely
   defining the contents when we are free to change the contents?

Are you specifying that if I change a VCAR that I got from you that
I MUST change the UID if I change the contents? 

  If yes - then you are specifying that the ID of a VCAR
  is local to the CS only.

      If yes - then why would they have to be "globally" unique IDs?

  If no - I can't change the contents of a globally identified
  object without it being updated from the OWNER. And that
  would mean that any VCAR you send is in effect a decreed
  VCAR with in it scope.

> value of '0', no matter how many '1' you'll AND you'll always

Your right - I used a bad analogy!

> stored components not a computed representation of them.

Not true. Where is that in the draft?

(1) If you don't have full access - your not going to see them.
    That does not mean you don't have any rights, it means
    your not allowed to look at what rights you do or don't have.
    And therefore any non-OWNER UPN (#1) MAY see a set(UPN#1)
    VCAR results and at the same time another non-OWNER UPN (#2)
    will set a set(UPN#2) VCAR results where set(UPN#1) != set(UPN#2).

(2) The CAR-MIN VCARs are by CARID name. The results of a VQUERY
    on a CAR-MIN (or any VCAR) can change over time without
    that specific named VCAR changing. The example I sent out
    a week or so ago was like this:

	Using the CAR-MIN of 'REQUESTONLY'

   You can initially store the REQUESTONLY VCAR with:

 (WE NEED TO PUT GRANT/DENY and VCAR BACK INTO CAP, this example
  is from memory!)

	BEGIN:VCAR
	CARID:REQUESTONLY
	GRANT:UPN=*;....
	END:VCAR

   Later you can say:

	BEGIN:VCAR
	CARID:I do not want Doug to make requests on my calendar.
	DENY:UPN=doug;ACTION=CREATE;OBJECT=METHOD;VALUE=REQUEST;
	END:VCAR

  Now when I connect and do a VQUERY for REQUESTONLY, 'I' get:

	BEGIN:VCAR
	CARID:REQUESTONLY
	DENY:UPN=doug;ACTION=CREATE;OBJECT=METHOD;VALUE=REQUEST;
	END:VCAR

  When someone other then the OWNER does a VQUERY, 'they' might get:

	BEGIN:VCAR
	CARID:REQUESTONLY
	GRANT:UPN=<their-upn>
	END:VCAR

The results of a VQUERY are most defiantly dynamic.
And not just because of the predefined VCARs, but becaue
each UPN could have different access rights to reading VCARs.

> read/write properties such as VCAR.

It has to be. We had agreed that for security reasons, you
can't see what you don't have access to see. That includes VCARs.
It could be a security problem for you to let me see that
user 'joe', 'sam', and 'ted', do have permission. If I can't
do something - I get "permission denied" and there is NO
promise that I can fetch any VCAR to see why - thus I do
get different resutls from the same VCARs than another UPN.

> of his VCARs.

I agree that OWNER MUST NOT issue a VCAR that would restrict
their rights to see everyting. They can stick it to themself
if they try hard. Another reason for decreed VCARs. The CS
implementation may implement decreed VCARs that prevent
the OWNER from restricting themself for just the reasons
you point out.

But it can not be true for anyone else because they might
not have the access to see all of the VCARs and their full
contents.

>  Furthremore, what if someone created a new VCAR

The same is true ether way. What would keep another authorized
CUA from changing  the contents after you did a VQUERY and
before you applied any update? We had agreed not to have
the 'lock' command a long time ago.

> you access, and not only the VCAR that was returned to me by the

	SELECT * FROM VCAR

    Would yield everything OWNER can see. That means everything
    including both deny properties. This assumes of course that
    OWNER have not denied themself the rights to see these results.

Note: not all VCARs need have names - so no matter what name or
      non-name the VCAR exists in, you will have to get all of
      them to know the net result of all of your VCARs.

> delete the VCARs that I have created.

You can MODIFY them into nothing-ness. (I will be posting the
return of the MODIFY command in a day or so).

> been granted to the UPN or not.

I think that the only UPN that MUST BE able to fetch all
of the VCARs is the OWNER. Everyone else only sees what
they are allowed to see - as it applied to them at the
time they ask.

I can't find the definition of the predefined VCARs anymore.
WOULD SOMEONE PLEASE PUT THEM BACK INTO CAP? This would clear
up a lot of debate. I just noticed that they have been removed.
That is probably why we are having this debate.

They exist because this WG felt that CUA's need to be able to
find out if they can do basic things without having to perform
a SELECT * FROM VCAR each time they connected and compute the
results. They existed so that they could dynamically just find
out how any of the pre-defined VCARs applied to the currently
authenticated UPN. - exactly what you are asking for is the
reason the predefined VCARs exist.

---

From: Doug Royer <[email-masked]>
Date: Mon, 14 Jan 2002 15:17:06 -0700

> can't have a VALARM when the ORGANIZER didn't create one.

I had proposed just such a mechanism a few of weeks ago
to resolve this issue. I prposed a way for a CUA to tag
which TRIGGERS it wishes to ignore and which it wishes
to not ignore. I also proposed not to publish those 
CAP only paramaters to avoid the that half of this issue.

> ignore all VALARM for which I'm not the ORGANIZER.

As they only exist inside of a VEVNET or VTODO.
So yes they do have an implied ORGANIZER.

I had send email  where I had proposed a way to tag them
to solve this problem (subject line did not match topic :-).
It allows the CUA to decide IF it is going to honor a VALARM,
and how to tag local ones. 

Your proposal would eliminate all VALARMS if not OWNER?
What if I wanted to honor those VALARMs, or just 'this id'd' one?

  http://www.imc.org/ietf-calendar/mail-archive/msg02554.html

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 17 Jan 2002 11:49:00 -0500

>    defining the contents when we are free to change the contents?

What is different from VEVENT?  To my knowledge, there is
nothing that prevents me from modifying a VEVENT stored in
one of my VAGENDA without telling anyone.  VEVENTs with
the same UID are not guaranteed to be identical.

>   would mean that any VCAR you send is in effect a decreed

I wouldn't be allowed to add a VALARM in my own copy of a
VEVENT?

> That is probably why we are having this debate.

I'm not sure these definitions were ever in the draft itself.
As far as I know, VCAR were first proposed as VACL (vehicle?)

  http://www.imc.org/ietf-calendar/archive1/msg02819.html

and then reviewed and renamed to VCAR (car!)

  http://www.imc.org/ietf-calendar/archive1/msg02880.html

Then a modified version of this text appeared in
"Proposed Changes To iCalendar Needed For CAP".

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

Finally, on January 3rd 2002, George put the text in
the latest interim versions of the draft.

  http://www.calsch.org/ietf/drafts.html

As you'll noticed the text is still "half baked" and
needs some work.

> reason the predefined VCARs exist.

My point is that since VCARs are coalesced it will be hard
to manage them.

I propose we use the EXPAND property (or a new property with
a more appropriate name) of the VQUERY component to specify
whether we want the VCARs returned by the search command to
be coalesced or not.

By specifying EXPAND:TRUE in the VQUERY you would get the
coalesced VCAR, by default you would get the VCAR exactly
as they are stored in the CS.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Thu, 17 Jan 2002 12:10:59 -0700

Bernard Desruisseaux wrote:

> > ...I think that the only UPN that MUST BE able to fetch all

Yes - I just repeated Bruce's argument (to George) that they have
their name changed a bit. I am working with 'some' version
of 06, but as they have the same name, I don't know which one.

> My point is that since VCARs are coalesced it will be hard

Yes - I like your EXPAND idea - I think it needs some more
restrictions for security reasons.

> whether we want the VCARs returned by the search command to

Great idea - but only to OWNER.

> as they are stored in the CS.

Only for OWNER. Otherwise I can pick apart you security
by guessing at things. As in I do not want NON-OWNERS to
know what the 'raw' VCARs are.

So could you agree to:

  When performing a VQUERY on VCARs, for security reasons
  non-OWNERs only get the coalesced VCARs.

  That would mean that OWNERs might want to use EXPAND:TRUE
  when acting as any CU using a calendar. And MUST use EXPAND:FALSE
  when managing the VCARs.

  And it adds the requirement that a CS MUST store the raw
  VCARs and be able to reply with both raw and coalesced VCARs.

  The default for EXPAND is FALSE.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Thu, 17 Jan 2002 12:12:52 -0700

( I broke your reply into 2 separate messages)

> the same UID are not guaranteed to be identical.

They are identical! That is a definition of them. Without
them being identical it breaks iTIP - and badly.  So each time
the ORGANIZER pushes a new copy (SEQUENCE incremented) and changes
something - it blows away your copy? I hope you are not doing that!
I hope you meant 'what if'.

Nothing can keep you from doing it, but that breaks iTIP.
And I agree it is the same issue as far as UID goes, which
is why I don't what it to be UID :-)

I'll call "non-local" object changes anyting that changes any
data from what was sent by the ORGANIZER in a way that any
CUA can not distiguish it from the original without asking
the ORGANIZER.

Maybe we need to say that in CAP? If you tweak with "non-local"
objects where you are not the ORGANIZER, you MUST change the UID?
Otherwise we have an unmanageable mess. 

Which is why I made the proposal on how to update components
and tag those changes as local - and NOT to propagate them
to non-OWNERs. So that you can have local alarms and tag
ORGANIZER alarms as not-enabled and do these things. Because
if you just tweak with the objects, and there is no standard
way to tweak with those object, UID:unique-id means NOTHING at
all and is all I would have to do to blow away all your changes
is send an updated object.

> I wouldn't be allowed to add a VALARM in my own copy of a

Not currently without breaking iTIP, that is why I made
the proposal.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 17 Jan 2002 15:06:50 -0500

>   non-OWNERs only get the coalesced VCARs.

I agree as a MAY.

>   The default for EXPAND is FALSE.

I agree, but I really think we should come up with
a better property name than EXPAND.  Specifying
EXPAND:TRUE to get coalesced VCARs sounds strange
to me!  How about COALESCE? :-)

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Thu, 17 Jan 2002 15:27:28 -0700

> to me!  How about COALESCE? :-)

COALESCE sounds good to me.