Subject: [secdir] secdir review of draft-ietf-jcardcal-jcal-09

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Tue, 25 Feb 2014 14:36:58 +0000

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document specifies jCal, a JSON format for iCalendar data as well as semantically lossless conversion between iCalendar and jCal and vv.

I believe the document is well written and ready for publication with a few small nits:

- Paragraph 3 (converting from iCal to jCal):

The  text looks very much like production rules, why not give ABNF? (Ah wait, now that I have read the full document I see that that appears in Appendix B, I think you should at least point to Appendix B here)

- Paragraph 3.4 and onwards

It is unclear to me when you write for example "Each individual iCalendar property is represented in jCal by …" whether you really mean to write: "Each individual iCalendar property MUST be represented in jCal by…." 
I assume you want to be normative in specifying the format?

- Paragraph 9.2 should RFC4627 not be a normative rather than informative reference?

Klaas

---

From: Barry Leiba <[email-masked]>
Date: Tue, 25 Feb 2014 07:20:37 -0800

> - Paragraph 9.2 should RFC4627 not be a normative rather than informative reference?

Absolutely, because in Section 2 we have this:

   The underlying format used for jCal is JSON.  Consequently, the terms
   "object" and "array" as well as the four primitive types (strings,
   numbers, booleans, and null) are to be interpreted as described in
   Section 1 of [RFC4627].

That 4627 defines terms that are used in this document, it's a
normative reference.

Also, authors, note that draft-ietf-json-rfc4627bis is now in AUTH48,
so you'll almost certainly be changing the reference to that new RFC
(it will be 7158) by the time this document is approved.

Barry