Subject: [Jcardcal] Barry Leiba's Discuss on draft-ietf-jcardcal-jcal-09: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Fri, 21 Mar 2014 16:58:57 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-jcardcal-jcal-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-jcardcal-jcal/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I very much like this document, and will switch to "Yes" after we resolve
a couple of easy points.

RFC 4627 is clearly a normative reference, not an informative one.  Apart
from that, the replacement to 4627 is in the RFC Editor queue, and will
become an RFC before this document does.  I strongly suggest replacing
the 4627 reference with one to the I-D, so the new RFC gets dropped in by
the RFC Editor.  (If you do that, the eval() advice in Section 6 needs to
change accordingly.)

-- Section 4 --

   Character escaping and line folding MUST be applied to the resulting
   iCalendar data as required by [RFC5545] and [RFC6868].

The line folding part is in conflict with Section 3.1:

   The reverse order applies when converting from jCal to iCalendar.
   First, JSON escaping MUST be unescaped.  Afterwards, iCalendar
   escaping MUST be applied.  Finally, long lines SHOULD be folded as
   described in [RFC5545].

Which is meant, SHOULD (Section 3.1) or MUST (Section 4) ?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Non-blocking comments to consider:

-- Appendix B --
I'm quite unhappy with using raw ABNF to describe JSON payloads.  You're
duplicating the ABNF in the JSON spec, and it's prone to errors, not to
mention being hard to read.  What you want to do here is to specify JSON
structures, not to specify the JSON syntax itself.

Look at RFC 7071 Section 6.2 for one way that this has been handled. 
http://tools.ietf.org/html/draft-newton-json-content-rules-01 specifies
another way.  Please consider changing to one of those.

I know that Cyrus has responded that he's reluctant to change this now,
but please consider it: I think this section is essentially useless as it
stands.  On the other hand, note that this is a non-blocking comment, so
I will not hold anything up if you decide to leave it be.

-- Section 3 --
Pedantic nit pet peeve:

   In [RFC5545], iCalendar objects are comprised of a set of
   "components", "properties", "parameters" and "values".

In correct usage, the whole "comprises" the parts.  So:

NEW
   In [RFC5545], an iCalendar object comprises a set of
   "components", "properties", "parameters" and "values".
END

(If you don't like that, use "is composed of" instead of "is comprosed
of".)

---

From: Pete Resnick <[email-masked]>
Date: Fri, 21 Mar 2014 19:15:21 -0500

Barry (who likes to hit the "send the email" button repeatedly ;-) ),

On 3/21/14 6:58 PM, Barry Leiba wrote:
> the RFC Editor.

I put this one in the RFC Editor note.

> (If you do that, the eval() advice in Section 6 needs to
> change accordingly.)
>    

Yeah, still gotta do that.

The rest I'll let Phillip take a stab at first.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Barry Leiba <[email-masked]>
Date: Fri, 21 Mar 2014 20:37:54 -0400

> Barry (who likes to hit the "send the email" button repeatedly ;-) ),

In fact, I did not; I pressed it once.  Something else cause the
repetitious sends.

Mea non culpa.

b