Document: draft-ietf-extra-processimip-07
Intended RFC status: Proposed Standard
Review type: artart - Last Call review
Reviewer: Henry S. Thompson
Review Date: 2024-06-28
Result: 

*Summary*

*Substantive points*

Section 4: "based on the iTIP method (see Section 1.4 of [RFC5546]) of
the message, calendar objects are created, updated or deleted..." --
but the introduction says "sometimes the enclosed iCalendar [RFC5545]
data does not include an iTIP method property".

I'm confused at this point:  If there _is_, for example, an iTIP
"REQUEST" method specified, does the processcalendar script _replace_,
_modify_ or _supplement_ that method, or what?

Section 4: "contains calendar data in multiple MIME [RFC2045] parts"
-- This seems underspecified.  It makes most sense for multiple
calendar parts all in a single multipart/alternative, but why
shouldn't multiple calendar parts with different semantics be allowed
(possibly nested at some depth) in a multipart/mixed?


*Minor points*

Section 3:  I take it that by "capability identifier" is meant
"capability name" or "capability string" as used in RFC5228.  Please
change the name of this section to one of these, and include a
reference to 5228.

Section 4: Similarly, in the opening sentence of this section a
reference to 5228 would be welcome.

Section 4: "If the calendar data is malformed in any way" -- this
hides a potential multitude of detail.  I presume that in part this
means "malformed according to the media type specified for the
encapsulated calendar data", but also implies something along the
lines of "or if the specified media type is not supported".  That is,
no sniffing or just scanning for strings that look like dates.



*Nits*

[iMIP] appears to be an RFC now:  iCalendar Message-Based
Interoperability Protocol (iMIP) RFC 6047

ht
-- 

[1] https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-12