Mercurial > hg > ietf
comparison draft-ietf-extra-processimip-07.txt @ 7:328798b2a7d1
partial
| author | Henry S. Thompson <ht@inf.ed.ac.uk> |
|---|---|
| date | Tue, 02 Jul 2024 13:47:11 +0100 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| 5:b281db304428 | 7:328798b2a7d1 |
|---|---|
| 1 Document: draft-ietf-extra-processimip-07 | |
| 2 Intended RFC status: Proposed Standard | |
| 3 Review type: artart - Last Call review | |
| 4 Reviewer: Henry S. Thompson | |
| 5 Review Date: 2024-06-28 | |
| 6 Result: | |
| 7 | |
| 8 *Summary* | |
| 9 | |
| 10 *Substantive points* | |
| 11 | |
| 12 Section 4: "based on the iTIP method (see Section 1.4 of [RFC5546]) of | |
| 13 the message, calendar objects are created, updated or deleted..." -- | |
| 14 but the introduction says "sometimes the enclosed iCalendar [RFC5545] | |
| 15 data does not include an iTIP method property". | |
| 16 | |
| 17 I'm confused at this point: If there _is_, for example, an iTIP | |
| 18 "REQUEST" method specified, does the processcalendar script _replace_, | |
| 19 _modify_ or _supplement_ that method, or what? | |
| 20 | |
| 21 Section 4: "contains calendar data in multiple MIME [RFC2045] parts" | |
| 22 -- This seems underspecified. It makes most sense for multiple | |
| 23 calendar parts all in a single multipart/alternative, but why | |
| 24 shouldn't multiple calendar parts with different semantics be allowed | |
| 25 (possibly nested at some depth) in a multipart/mixed? | |
| 26 | |
| 27 | |
| 28 *Minor points* | |
| 29 | |
| 30 Section 3: I take it that by "capability identifier" is meant | |
| 31 "capability name" or "capability string" as used in RFC5228. Please | |
| 32 change the name of this section to one of these, and include a | |
| 33 reference to 5228. | |
| 34 | |
| 35 Section 4: Similarly, in the opening sentence of this section a | |
| 36 reference to 5228 would be welcome. | |
| 37 | |
| 38 Section 4: "If the calendar data is malformed in any way" -- this | |
| 39 hides a potential multitude of detail. I presume that in part this | |
| 40 means "malformed according to the media type specified for the | |
| 41 encapsulated calendar data", but also implies something along the | |
| 42 lines of "or if the specified media type is not supported". That is, | |
| 43 no sniffing or just scanning for strings that look like dates. | |
| 44 | |
| 45 | |
| 46 | |
| 47 *Nits* | |
| 48 | |
| 49 [iMIP] appears to be an RFC now: iCalendar Message-Based | |
| 50 Interoperability Protocol (iMIP) RFC 6047 | |
| 51 | |
| 52 ht | |
| 53 -- | |
| 54 | |
| 55 [1] https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-12 |