Subject: [ietf-calsify] comments on draft-ietf-calsify-rfc2447bis-07.txt

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Oct 2009 14:16:15 +0200

<Chair hat off>

Thanks, Alexey, for putting out this draft.  I have some questions and 
comments about the latest draft.  Most of these are nits.

In Section 2.4 you write:

> Note 1: A MIME message containing multiple iCalendar objects with
>     different method values must be further encapsulated with a
>     "multipart/mixed" MIME entity.

Do you mean MUST instead of must?

In Section 3, Security Considerations, as others have pointed out, time 
has passed, and it probably is not reasonably to only mention RFC 1847.  
However, I think we should probably go further and recommend the use of 
our own standards such as DKIM.  Having some understanding of trust 
boundaries seems to me important at this stage.  While 1847 would 
provide strong trust, it's nowhere near as used as, say, DKIM or SPF.  
I'm not saying do away, with 1847 text, but I think we have some text to 
add.

On encoding, I wonder if this is best left to the basic MIME / SMTP 
encoding practices.  Do we really need to discuss 7 or 8 bit here?  Is 
this a serious problem that someone has had?

Nit: your draft has the word FORMFEED where formfeeds should be.

Nit: Section 2.3 is entitled [RFC-5322] Addresses.  I would prefer to 
see a common name such as "Email addresses".  Let's face it.  We 
probably haven't seen the last of updates to this standard, for better 
or worse, and unless you think you are normatively referencing a 
definition of "email addresses" that is likely to change, I don't see 
the point of obscuring what we're talking about.

Nit: Section 1.2.  Is it me or is this section excessive?  I agree with 
the 2119 langauge, but do we need to go to the lengths of the following:

>     Properties defined by [iCAL] are referred to with capitalized,
>     quoted-strings of text, followed by the word "property". For example,
>     "ATTENDEE" property refers to the iCalendar property used to convey
>     the calendar address of a calendar user.
>    

Ok, I haven't checked your examples.  That will be next.

Eliot
_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Oct 2009 17:29:47 +0100

> Do you mean MUST instead of must?
Yes, changed.
> In Section 3, Security Considerations, as others have pointed out, 
> time has passed, and it probably is not reasonably to only mention RFC 
> 1847.  However, I think we should probably go further and recommend 
> the use of our own standards such as DKIM.  Having some understanding 
> of trust boundaries seems to me important at this stage.  While 1847 
> would provide strong trust, it's nowhere near as used as, say, DKIM or 
> SPF.  I'm not saying do away, with 1847 text, but I think we have some 
> text to add.
Agreed. Send me the text ;-)
> this a serious problem that someone has had?
This is just trying to point out that iTIP messages contain UTF-8 and 
thus need to be encoded when 8BITMIME/BINARYMIME are absent.

On one hand there are still email clients that do just-send-8bit, which 
worries me a bit. On the other hand most of SMTP servers are 8bit-clean.
So I would rather keep the warning about 7bit transport in the document.
> Nit: your draft has the word FORMFEED where formfeeds should be.
Yes, I didn't do post-processing of nroff output.
> see a common name such as "Email addresses".
Agreed.
> Let's face it.  We probably haven't seen the last of updates to this 
> standard, for better or worse, and unless you think you are 
> normatively referencing a definition of "email addresses" that is 
> likely to change, I don't see the point of obscuring what we're 
> talking about.
Actually in some places the document really should be referencing 
mailto: URIs. I've added that as another normative reference.
> Nit: Section 1.2.  Is it me or is this section excessive?  I agree 
> with the 2119 langauge, but do we need to go to the lengths of the 
> following:
This text is pretty much the same as in iCalendar/iTIP documents. I 
don't have a strong opinion of whether it should stay or go. Other opinions?
> Ok, I haven't checked your examples.  That will be next.
That would be helpful. Are you planning to use any particular iMIP 
client, or are you just thinking about visual inspection?