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

["Klaas Wierenga (kwiereng)" <[e-mail]>]

Hi Philipp,

Looks good to me!

Klaas

Sent from my iPhone

> On 20 mrt. 2014, at 23:58, "Philipp Kewisch" <[e-mail]> wrote:
> 
> 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