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

[Philipp Kewisch <[e-mail]>]

Hi Klaas,

thank you for your corrections. Here is my feedback:
> - 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)
The ABNF is considered informative, I was told for jCard that not too
much weight should be put into it. Nevertheless, I am happy to mention
it if you like. How is this for the introduction to section 3?

OLD
   This section describes how iCalendar data is converted to jCal using
   a simple mapping between the iCalendar data model and JSON elements.
NEW
   This section describes how iCalendar data is converted to jCal using
   a simple mapping between the iCalendar data model and JSON elements.
   Aside from the formal description in this section, an informative ABNF is
   specified in Appendix B.
END

> - 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?

Thanks, I've changed it (almost) as you suggested.

OLD
   Each individual iCalendar property is represented in jCal by an array
   with three fixed elements, followed by one or more additional
   elements, depending on if the property is a multi-value property as
   described in Section 3.1.2 of [RFC5545].
NEW
   In jCal, each individual iCalendar property MUST be represented by an
   array with three fixed elements, followed by one or more additional
   elements, depending on if the property is a multi-value property as
   described in Section 3.1.2 of [RFC5545].
END

> - Paragraph 9.2 should RFC4627 not be a normative rather than informative reference?
Yes, indeed. I've changed this and also updated references to rfc7159.
While doing this I noticed that we referenced a regex that was in
rfc4627 but no longer in rfc7159. I've made some changes:

OLD
   With this in mind, a parser for JSON data should be used for jCal
   that is aware of the security implications.  For example, the use of
   JavaScript's eval() function is only allowed using the regular
   expression in Section 6 of [RFC4627].  A native parser with full
   awareness of the JSON format should be preferred.
NEW
   With this in mind, a parser for JSON data should be used for jCal that
   is aware of the security implications. For example, the use of
   JavaScript's eval() function is considered an unacceptable security
   risk, as described in [RFC7159], Section 12. A native parser with full
   awareness of the JSON format should be preferred.
END

Regards,
Philipp