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

From: [email-masked]
Date: Wed, 9 Sep 2009 09:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-06.txt
	Pages		: 22
	Date		: 2009-9-9
	
This document, iCalendar Message-Based Interoperability Protocol
   (iMIP), specifies a binding from the iCalendar Transport-independent
   Interoperability Protocol (iTIP) to Internet email-based transports.
   Calendaring entries defined by the iCalendar Object Model (iCAL) are
   composed using constructs from RFC 5322, RFC 2045, RFC 2046, RFC 2047
   and RFC 2049.

   This document is a product of Calendaring and Scheduling Standards
   Simplification (calsify) working group. More information about the
   IETF CALSIFY working group activities can be found on the IETF web
   site at <http://www.ietf.org/html.charters/calsify-charter.html>.

   The issue tracker for the Calsify WG is located at:
    <http://www.ofcourseimright.com/cgi-bin/roundup/calsify>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2447bis-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Sep 2009 12:19:17 +0100

>	Filename	: draft-ietf-calsify-rfc2447bis-06.txt
There were only minor changes in this version, namely changing the 
reference to RFC 2822 to point to RFC 5322, and updated boilerplate.

In order to get this document finished, I need to get feedback on the 
following:

>3 Security Considerations
>
>   The security threats that applications must address when implementing
>   iTIP are detailed in [iTIP]. In particular two spoofing threats are
>   identified in [iTIP]: Spoofing the "Organizer", and Spoofing an
>   "Attendee". To address these threats, the originator of an iCalendar
>   object must be authenticated by a recipient. Once authenticated, a
>   determination can be made as to whether or not the originator is
>   authorized to perform the requested operation. Compliant applications
>   MUST support signing and encrypting text/calendar body parts using a
>   mechanism based on Security Multiparts for MIME [RFC-1847] to
>   facilitate the authentication of the originator of the iCalendar
>   object. The steps for processing a signed iMIP message are described
>   below:
>
>   1. The iCalendar object MUST be signed by the "Organizer" sending an
>   update/initial request or the "Attendee" sending a reply.  <<Or the
>   person sending on their behalf? Clearly if somebody else is sending
>   the invitation, she can't sign using the key belonging to the
>   organizer>>
>
What do we want to say about the delegated case?

>   Once a signed and/or encrypted iMIP message is received and
>   successfully verified (as detailed above) by a CUA, the CUA SHOULD
>   remember whether the sender of the message is using signing and/or
>   encrypting.  If an unsigned iMIP message is received from the same
>   sender later on, the receiving CUA SHOULD warn the user about a
>   possible man-in-the-middle attack and SHOULD ignore the message,
>   unless explicitly overriden by the user. <<Should it also try to
>   notify the other end?>>
>
I would like to get feedback on whether notifying the other end is a 
good idea in this case.

Thanks,
Alexey

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Sep 2009 13:22:09 +0200

Thank you, Alexey, for posting this draft.  I would ask that people
respond as quickly as possible to Alexey's request for feedback.  My
plan is to start a WGLC on this document within the next three weeks.

Eliot

---

From: Reinhold Kainhofer <[email-masked]>
Date: Thu, 10 Sep 2009 13:58:49 +0200

> >A New Internet-Draft is available from the on-line Internet-Drafts
[...]
> 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

Among other things, most examples in the draft (also in this bis-06 version) 
are vCalendar rather than iCalendar files. This means:

- -) filename="event.vcs", i.e. vcs file extension is used
- -) PROFILE:REQUEST, PROFILE-VERSION:1.0 used
- -) due dates of the wrong form    DUE:19970701T090000-0700
- -) ATTSTAT attribute instead of PARTSTAT used: 
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:[email-masked]
- -) STATUS:NEEDS ACTION instead of STATUS:NEEDS-ACTION

Also, the draft speaks of the mime-type "multiple/alternative". Does this 
mime-type exist at all? Or should it rather be "multipart/alternative"?

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, [email-masked], http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Sep 2009 13:05:55 +0100

Reinhold Kainhofer wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
My appologies for not paying attention. I will look at your review.

>- -) STATUS:NEEDS ACTION instead of STATUS:NEEDS-ACTION
Ok, I will fix.

>mime-type exist at all?
No, fixed in my copy. Thanks for spotting this.

>Or should it rather be "multipart/alternative"?
>  
>
Regards,
Alexey