Mercurial > hg > ietf
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