[ietf-calsify] comments on draft-ietf-calsify-rfc2447bis-07.txt
lear at cisco.com
Wed Oct 21 05:16:15 PDT 2009
<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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ietf-calsify