Subject: Re: [calsify] WGLC for draft-ietf-calsify-rfc2447bis-07.txt

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 Jan 2010 23:38:56 +0000

Cyrus Daboo wrote:

> Hi,

Hi Cyrus,
Thank you for the review. My belated response:

> --On December 1, 2009 2:21:03 PM +0100 Eliot Lear <[email-masked]> wrote:
>
>> We are entering working group last call for
>> draft-ietf-calsify-rfc2447bis-07.txt, iMIP.  At this time I would ask 
>> you
>> to please identify any outstanding issues you have with the draft, if 
>> you
>> have not already done so.  I am in the process of checking all examples.
>> You can find a copy of the draft at
>> http://tools.ietf.org/html/draft-ietf-calsify-rfc2447bis-07.
>
> My review:
>
> - Abstract: change '(iCAL)' to '(iCalendar)'.
>
> - Introduction: change 'over MIME as defined in' to 'over Internet 
> email (using MIME) as defined in'.

Both changed, thanks.

> - §2: The terminology for "originator" and "respondent" are a little 
> messy. As per iTIP. "originator" is the person sending the message. 
> That could be the ORGANIZER or ATTENDEE. iTIP does not have the 
> concept of a "respondent", but rather uses "recipient" to refer to the 
> use receiving the scheduling message (and that too could be either the 
> ORGANIZER or an ATTENDEE). Since "respondent" is really only used in 
> one place I suggest we remove it and replace it with "recipient" in 
> §2.2.1. Then the following should be done:
>
> -- §2, ¶2 & ¶3 change to:
>
>    The sections below refer to the "originator" and the "recipient" of an
>    iMIP message. In the case of a "request" method, the originator is the
>    "Organizer" and the recipient is an "Attendee" of the event. In the
>    case of a "response" method, the originator is an "Attendee" and the
>    recipient is the "Organizer" of the event.
>
>    The [RFC-5322] "Reply-To" header typically contains the email address
>    of the originator of the scheduling message. However, this cannot be
>    guaranteed as Mail User Agents (MUA) are not required to enforce iMIP
>    semantics.

Ok, I used your text.

> - §2, ¶3 - why is Reply-to even mentioned here? If it is mentioned, 
> why is there no discussion on what goes in the From or To fields? I 
> think this is something lacking in the spec. What is more there needs 
> to be a clear statement that when a recipient replies to a scheduling 
> message with another scheduling message (as opposed to a "regular" 
> email message), they MUST use the addressing information in the 
> iCalendar data and not that in the email headers (i.e. discard From:, 
> Reply-To: etc).

I am still thinking about the best way of dealing with this.

> - §2.2.1, ¶3: why is the reference to "[RFC-1847]" at the start?

Hmm. To qualify "message flow"?

> - §2.3, ¶1: change 'the "ATTENDEE" property' to 'the "ORGANIZER" and 
> "ATTENDEE" properties'
>
> - §2.4 title: change 'Content Type' to 'Content-Type'.

Changed.

> - §2.4: this has terms like '"method" parameter' when referring to a 
> MIME header parameter. But the main terminology section stated that 
> iCalendar parameters would appear in lower case with the work 
> "parameter" after them. So there is the potential for confusion here 
> (we have the same issue with CalDAV and iCalendar and "property"). I 
> suggest we change the document to use upper case for the iCalendar 
> parameters, which matches how those are displayed in iCalendar and 
> iTIP. Also, when talking about MIME parameters, we should explicitly 
> state "MIME parameter" rather than just "parameter".

I've tried to do that, but I am not sure if I've done it consistently in 
the document. Please check the following version.

> - §2.4, ¶10: missing reference '<<add ref>>'.

This required some digging. I've added a reference to Content-Language 
header field.

> - §2.5 Example: change 'ACME' to 'example.com' - do that for all 
> examples.

I've changed to use:

PRODID:-//Example/ExampleCalendarClient//EN

as in RFC 5546.

> - §3, ¶1: comment left at the end of the paragraph needs to be addressed.

Can you recommend some specific text?

> - §3, ¶4: change 'Section 3 of [iTIP]' to 'Section 1.4 of [iTIP]'.
>
> - §4.3 title: 'Inline Attachment' is confusing as iCalendar refers to 
> "inline attachments" as ones where the attachment data is directly in 
> the iCalendar property. I suggest just removing 'and Inline 
> Attachment' from the end of the title. 

Changed.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 Jan 2010 23:38:56 +0000

Hi Cyrus,

Both changed, thanks.

Ok, I used your text.

Changed.

I've changed to use:

as in RFC 5546.

Changed.

_______________________________________________
calsify mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/calsify