[ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-06.txt

Eliot Lear lear at cisco.com
Mon Dec 7 07:57:06 PST 2009


Alexey,  Reinhold,

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.

Thanks again,

Eliot

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
>>>> directories.
>>>>
>>>>
>>>>          
>> [...]
>>
>>
>>      
>>> 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:
>> http://reinhold.kainhofer.com/Computing/Review_RFC2447bis_2008-10.pdf
>> http://reinhold.kainhofer.com/Computing/Review_RFC2447bis_2008-10.html
>>
>>      
> 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
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>    



More information about the ietf-calsify mailing list