Subject: RFC 2446: Delegation text needs some changes

From: [email-masked]
Date: Thu, 31 Jan 2002 14:23:54 -0500

In RFC 2446 we wrote:

     .  Send a "REPLY" to the "Organizer" with the following updates:
     .  The "Delegator's" "ATTENDEE" property "partstat" parameter set
        to "delegated" and the "delegated-to" parameter is set to the
        address of the "Delegate"
     .  Add an additional "ATTENDEE" property for the "Delegate" with
        the "delegated-from" property parameter set to the "Delegator"
     .  Indicate whether they want to continue to receive updates when
        the "Organizer" sends out updated versions of the event.
        Setting the "rsvp" property parameter to "TRUE" will cause the
        updates to be sent, setting it to "FALSE" causes no further
        updates to be sent. Note that in either case, if the "Delegate"
        declines the invitation the "Delegator" will be notified.
     .  The "Delegator" MUST also send a copy of the original "REQUEST"
        method to the "Delegate".

however there is a small problem w/the last line.  If the Delegator 
actually does this then they CANNOT add a new ATTENDEE line with the 
Delegatees info NOR can they update their own ATTENDEE line to reflect the 
delegation.    In addition it is NOT legal for the Delegator to include a 
COMMENT to tell the Delgatee something like "Im in FL that week.  I need 
you to go for me!" or "I dont like meetings w/Joe so Im sending you 
insetad!". 

It should be allowable that a Delegator can send non-process info like a 
COMMENT (or other IANA properties/parameters) in the Delegation notice.

The phrase "send a copy of the original" implys that these 
changes/additions cannot be done.  Without the changes, the Delegatee has 
no way to know why they got a REQUEST from the Delegator and not from the 
Organizer. 

We intended to make sure that the Delegator sent an accurate 
representation of the Organizers REQUEST but we did this (accdientally) at 
the expense of some feature sets or functionality.  I will try to work up 
some change text for this (that preserves the base intent but allows for 
needed or future changes) and present it to the WG for discussion unless 
there is strong dissent about the need for it.

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: Thu, 31 Jan 2002 15:50:43 -0700

[email-masked] wrote:
> Delegatees info NOR can they update their own ATTENDEE line to reflect
> the delegation.    In addition it is NOT legal for the Delegator to
> include a COMMENT to tell the Delgatee something like "Im in FL that
> week.  I need you to go for me!" or "I dont like meetings w/Joe so Im
> sending you insetad!".
> 
> 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.

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. And then everyone, delegatee
included is notified. The delegatee's CUA can see that they
are tagged as DELEGATED-TO and know what it means. If they
decline they can send an update as described above.

> changes/additions cannot be done.  Without the changes, the Delegatee
> has no way to know why they got a REQUEST from the Delegator and not
> from the Organizer.

Yea, that is busted.

> representation of the Organizers REQUEST but we did this
> (accdientally) at the expense of some feature sets or functionality.
>  I will try to work up some change text for this (that preserves the
> base intent but allows for needed or future changes) and present it to
> the WG for discussion unless there is strong dissent about the need
> for it.