[ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-06.txt
lear at cisco.com
Mon Dec 7 07:57:06 PST 2009
Thanks for bringing these issues to the fore. What I propose is that we
start a separate discussion for each, which I will do shortly. In the
meantime, I ask that others please take some time and also review the
document and the message below.
On 12/5/09 2:55 PM, Alexey Melnikov wrote:
> Dear Reinhold,
> Reinhold Kainhofer wrote:
>> Am Donnerstag, 10. September 2009 13:19:17 schrieb Alexey Melnikov:
>>> Internet-Drafts at ietf.org wrote:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> There were only minor changes in this version, namely changing the
>>> reference to RFC 2822 to point to RFC 5322, and updated boilerplate.
>> I see that none of my comments (sent almost a year ago) for the bis-05 draft
>> have been incorporated:
> Sorry for slow response. I believe I've addressed all of your comments,
> except for the following:
>> 8. Sec 2.2.1, p.5/6: The last sentence on page 5 says that the
>> "Organizer" must ignore a message from spoof at ..., while the last
>> sentence of this section says that it is left to implementations to
>> provide mechanisms to treat the "sent-by". Aren't these two sentences
>> contradicting each other? Also, what exactly is meant by »an iTIP]
>> message from spoof at xyz.example.net«? Section 2 says that the Reply-To
>> header cannot reliably be used to determine the sender, so how can one
>> determine it?
>> 15. Item 1 of the list: The current comment to allow signing by the
>> person sending on their behalf again build down to the question how to
>> determine if that person is allowed to send on the Organizer's or
>> Attendee's behalf.
>> 16. Item 3 of the list: This item says to ignore the message if it
>> cannot be correlated to an Attendee or Organizer. This, however
>> creates problems with forwarded/delegated calendar components and
>> out-of-sequence replies. In particular, imagine an attendee delegating
>> a VEVENT to user2. If the REPLY of user2 reaches the Organizer prior
>> to the REPLY of user1 delegating to user2, the Organizer will not know
>> anything about the delegation and thus ignore the REPLY of user2 if he
>> follows the advice of this list item...
>> This, in turn creates further problems: user2 will not know that the
>> Organizer ignored his message and that he was not added as an
>> ATTENDEE. Consequently, he will not get any REQUEST messages when the
>> VEVENT is changed (e.g. to a different location or a different time)
>> and still assume the original date and location.
>> 17. The advice in the second-to-last sentence of the section (»One way
>> to achieve this is to reject iMIP messages sent by users other than
>> the "ORGANIZER" or the "ATTENDEE"s.«) makes forwarding and sending on
>> behalf of others impossible (why do we have these actions specified at
>> all, then?) and creates problems with out-of-sequence replies on
>> delegation as explained above.
> ietf-calsify mailing list
> ietf-calsify at osafoundation.org
More information about the ietf-calsify