Reviewer: Robert Sparks Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-calext-jscalendar-25 Reviewer: Robert Sparks Review Date: 2020-03-03 IETF LC End Date: 2020-03-09 IESG Telechat date: Not scheduled for a telechat Summary: This document has minor issues to address before being published as a Proposed Standard RFC. Caveats: I did not carefully verify that the initial registry values (of which there are many) matched the document text. Minor issues: ABNF is used, but there is no reference to RFC 5234. The document shepherd report implies that the ABNF has not been verified (see item 19 in that report). The first registry in section 8.4.3 should be explicit that it is a registry for values of the "@type" property. Right now the reader has to infer that. It's not stated clearly whether a patch should succeed or fail if the resulting object doesn't meet this specification's requirements. Side question: if a patch changes 'updated' (4.1.6) in an object that didn't already have a 'created' (4.1.5), should it fail if it doesn't also result in an object that has a 'created'? Or is it ok to lose the original creation time information? The security consideration section only points to section 7 of RFC 3986 for potential issues related to the URIs that can be carried in this representation. I don't think that's sufficient. There should be some discussion (or a pointer to discussions) about the potential for malicious construction of jscalendar objects containing potentially very large numbers of URIs in, say, as Link objects (4.2.7). Is there an opportunity for amplified attacks here? (Especially if these URLs might be automatically referenced by any client, and even more so if the object is sent from a calendar with a large number of subscribers.) Have you considered any tighter integrity checking for (4.2.7) links? Maybe a checksum property? It doesn't look like application/jscalendar+json has had a media type review. Nits: Introduction, second sentence: "It" is ambiguous. As written, it could point to "This document" or "a data model". You sort of mean the later, but I think you really mean the JSON representation (especially when you say "process"), but you don't talk about that here. Introduction, design considerations list, last bullet: This bullet is currently written as description of the end result, not as a design consideration. Please restate it to match the rest of the elements in the list. Last full paragraph on page 2: "unlike most common JSON data representations" is asserted without data. The document doesn't really need it. I suggest simply deleting the phrase from the sentence. I don't expect anything to change at this point, but I do have to point to the dissonance in the conventions A[] and A[B]. It would have been far less confusing for A have the same semantic in both cases (preferably value), than the current situation where it means value for A[], but key for A[B]. 1.4.3 last paragraph: You don't need to use MUST in this example - it's not a requirement on the protocol. I suggest replacing "MUST be" with "is correctly". In 4.2.5 at 'locationTypes', it would be better to point to the actual registry (https://www.iana.org/assignments/location-type-registry/location-type-registry.xhtml) than only to RFC4589. Do you want to say anything about what should happen if the size of a resource (as represented by 'size' in 4.2.7) doesn't match the actual fully decoded size? I think you mean for this property to be an informational estimate, and you should explicitly say the actual size could be quite different. In 4.2.10, 'american-football""' should be 'american-football"' (one fewer ") In 4.3.2 at 'byDay', why do you have * symbols around 'An *NDay* object'? In 4.4.5 at 'scheduleUpdated', do you really want to couple this so tightly to iTIP? Perhaps you should say "the last time this participant provided an update" and point to iTIP as how these are typically provided? Major issues: Minor issues: Nits/editorial comments: -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
