changeset 7:328798b2a7d1

partial
author Henry S. Thompson <ht@inf.ed.ac.uk>
date Tue, 02 Jul 2024 13:47:11 +0100
parents b281db304428
children d4e5d6b079bc
files draft-ietf-extra-processimip-07.txt
diffstat 1 files changed, 55 insertions(+), 0 deletions(-) [+]
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/draft-ietf-extra-processimip-07.txt	Tue Jul 02 13:47:11 2024 +0100
@@ -0,0 +1,55 @@
+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