Greetings,

   I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

   My summary of the review is "Ready With Issues".

   This draft defines an extension to an email filtering language to
process machine-readable calendar data that is encapsulated in MIME.
It's pretty straightforward.

   The Security Considerations seem fine for the content. Also the
Privacy Considerations (there are none) seem correct as well.

   One issue I have is in section 4 where it discusses actions to take
when processing this data. In the case of calendar data in multiple
MIME parts that are not semantically equivalent it says, "...the action
MUST NOT process the message. Otherwise, the action MUST only process
one representation of the data." And that is very confusing from a
normative perspective. If it's MUST NOT then that's pretty final,
there shouldn't be an "Otherwise..." after a MUST NOT.

   As a nit, what are the reasons that an implementation might choose
to not remove alarms from calendar data (it's a SHOULD remove in
section 4). I think it deserves some elaboration.

   Another nit, "It is an error if [:updatesonly and :calendarid] are
used in the same 'processcalendar' action" (section 4.4) should be
restated to use normative MUST NOT language. And the specific error
should be stated.

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius