Subject: Re: RFC 2446: Delegation text needs some changes

From: [email-masked]
Date: Tue, 5 Feb 2002 15:50:56 -0500

Doug replied with:
> > It should be allowable that a Delegator can send non-process info like
> > a COMMENT (or other IANA properties/parameters) in the Delegation
> > notice.
> 
> As COMMENT is already defined, the delegatee would have no way
> of knowing if the COMMENT was from the ORGANIZER or the Delegate.
> I think we would need a new property.

I think you are adding some extra semantics/usages to the COMMENT 
property.  We added COMMENT with the definition of:

   Purpose: This property specifies non-processing information intended
   to provide a comment to the calendar user.

but implicit in this was that it was intended to be a 'single shot usage' 
between the sender and the recipient.  It was not something that was to be 
preserved and passed along.  Otherwise you start to have problems with 
stuff like "When do I purge off COMMENTs?", "Who said what?" (with any 
degree of assuredness), etc.

You could make your CUA encapsulate the COMMENT in a new COMMENT if you 
like but do NOT want to try and 'preserve' someone elses supposed COMMENTs 
(or perhaps you do).  In any case, you wont be able to do that in iTIP 
since many restriction tables contain:

     COMMENT        0 or 1

which is a further indication that COMMENT is not intended to be preserved 
indefinitely.  After all, why would I send back the Organizers COMMENT to 
then when I really want to send my own back instead???

> Instead; How about we modify the last sentence of the above 2445 text
> to say:
> 
>    The "ORGANIZER" MUST send out a new REQUEST with
>    an updated SEQUENCE number.
> 
> That I think solves the problem.

Sorry, it doesnt.  It makes the entire workflow process 'thrash' if you do 
that.  Just because I delegate a meeting request to Steve, the Organizer 
now has to invalidate all responses from all other Invitees (the net 
effect of blindly reving SEQUENCE)??  You go and try to sell that to folks 
and Ill offer them a better solution! ;^b

Its clear from the 2446 that we need to revise the restriction tables so 
that we can include delegation information otherwise it wont really matter 
what the prose says since it will be wrong.

If we are going to fix it, we should fix it so that it works the way CUs 
will expect it to work.  The normal set of steps are described in the 
cited text; just the last line is wrong because it precludes the 
previously described actions.  Perhaps you think the other actions are 
whats wrong??

The solution is to allow the Delegator to make minor changes to the 
Organizers 'original' REQUEST (ie: Adding the Delegatees info, supplying 
back a COMMENT of their own to the Organzier saying why the Delegatee is 
coming [or why the Delegator cannot or both], etc). 

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 15:30:30 -0700

[email-masked] wrote:
> but implicit in this was that it was intended to be a 'single shot
> usage' between the sender and the recipient.  It was not something
> that was to be preserved and passed along.  Otherwise you start to
> have problems with stuff like "When do I purge off COMMENTs?", "Who
> said what?" (with any degree of assuredness), etc.

Yes. I can live with that. However if it is a 'one-shot' comment,
then we need to add that text somewhere? Or if we are 'planning'
to use it that way - we need some CAP text.

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 15:38:36 -0700

[email-masked] wrote:

> Sorry, it doesnt.  It makes the entire workflow process 'thrash' if
> you do that.  Just because I delegate a meeting request to Steve, the
> Organizer now has to invalidate all responses from all other Invitees
> (the net effect of blindly reving SEQUENCE)??  You go and try to sell
> that to folks and Ill offer them a better solution! ;^b

As I recall, the ORGANIZER has two valid choices:

	(1) Send everyone the same VEVENT (or whatever).
            And that one VEVENT contains ALL of the ATTENDEEs.
or
	(2) Send a uique VEVENT to everyone where only the 
            destination ATTENDEE was in the VEVENT.

If (1), then the ORGANIZER MUST update everyone when it changes.

If (2), then the ORGANIZER ONLY has to update the changed ATTENDEE
(and the delegatee?).

So, if (2), no, if (1) I see your point.

> Its clear from the 2446 that we need to revise the restriction tables
> so that we can include delegation information otherwise it wont really
> matter what the prose says since it will be wrong.

Yes.

> If we are going to fix it, we should fix it so that it works the way
> CUs will expect it to work.  The normal set of steps are described in
> the cited text; just the last line is wrong because it precludes the

No - I just forgot about (1) above.

> Organizers 'original' REQUEST (ie: Adding the Delegatees info,
> supplying back a COMMENT of their own to the Organzier saying why the
> Delegatee is coming [or why the Delegator cannot or both], etc).

I think I agree, then the ORGANIZER can decide if they need
to update everyone (1) or in the case of (2) - nothing as
the ORGANIZER and ATTENDEE are in sync for that ATTENDEE.