Subject: [Jcardcal] Barry Leiba's Yes on draft-ietf-jcardcal-jcard-06: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Mon, 30 Sep 2013 17:37:50 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-jcardcal-jcard-06: Yes

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-jcard/

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

UPDATE for -06: I find this version much easier to follow -- the
organizational issues have been fixed, as I see it, and thanks very much
for dealing with this -- I know it was a lot of work.

I still have a few non-blocking comments that I hope you'll fix in one
more pass.  But they are non-blocking, and if you really don't want to
deal with any more updates I'll be disappointed, but will not start
buying automatic weapons.  Consider these as you would last call
comments.

-- Section 3.2 --
An example that's just a skeleton seems a bit useless, and there are
examples in the next section.  Maybe it's good enough to say, "For
examples, see Section 3.3 and Appendix B."

And for the last paragraph, maybe:
OLD
   Consumers of this format wishing to define content that can contain
   multiple syntactic entities within the same JSON document can use a
   simple JSON array, each element being a jCard object.
NEW
   Consumers of this format wishing to define content that can
   represent multiple jCards within the same JSON document can use a
   simple JSON array, each element being a jCard object.
END

-- Section 3.3 --

I think two examples would be better merged into one, with a lead-in such
as this:

   In the following example, the "categories" property is
   multi-valued and has two values, while all other properties
   are single-valued:

(If you don't do this, the second example is wrong, in that it does not
have "version" as the first property in the array.  Better to just merge
them, eh?)

-- Section 3.3.1.2 --

I suggest that it would be best to make it clear that because the value
of the "group" parameter will be used as part of the property name in the
vCard version, the value is limited to characters that are permitted in
vCard property names: ALPHA, DIGIT, and "-".  You might put this into the
"Format definition" in the registration template.

-- Section 3.3.1.2.1 --

This one is unchanged from my original review: You say that the group
name's case MUST be preserved; why?  vCard says that group names are
case-insensitive, so why aren't group names put into lowercase, just as
property names are?

-- Section 3.4 --
The example is wrong, because it does not have "version" as the first
property in the array.  I think the right fix here is to isolate just the
"role" property array (as you do with "adr" above).

-- Section 3.4.2 --
The example is wrong, because it does not have "version" as the first
property in the array.  The right fix for this one is just to add a
"version" property.

-- Section 8 --

I think the "optional parameters" and "encoding considerations" would be
a little better this way, because asking someone to look through a big
document to find the relevant part is a lot to ask:

OLD
   Optional parameters:  version as defined for the text/vcard media
      type in [RFC6350].

   Encoding considerations:  Same as encoding considerations of
      application/json as specified in [RFC4627].
NEW
   Optional parameters:  "version", as defined for the text/vcard media
      type in [RFC6350], Section 10.1.

   Encoding considerations:  Same as encoding considerations of
      application/json as specified in [RFC4627], Section 6.
END