Subject: [Jcardcal] Richard Barnes' Yes on draft-ietf-jcardcal-jcard-05: (with COMMENT)

From: "Richard Barnes" <[email-masked]>
Date: Wed, 17 Jul 2013 11:59:51 -0700

Richard Barnes has entered the following ballot position for
draft-ietf-jcardcal-jcard-05: 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.

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

C1. In Section 3.1: It would be helpful to give a brief example of
"escaping mandated by JSON"
OLD: "escaping mandated by JSON."
NEW: "escaping mandated by JSON (e.g., for control characters)."
 
C2. In Section 3.2.1: This sentence doesn't make sense to me: "The value
could turn out to be a structured value, in which case the data type is
an array."  It seems like the value could also be a number, boolean,
null, or object; not just array.

C3. It seems like your rule for multi-valued properties (collapse them
all into a single property) ensures that each property only has one line
in the array.  So why not instead use an object, keyed on property name? 
It seems like this would be simpler to program with.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Jul 2013 13:42:38 -0400

> It seems like this would be simpler to program with.

Some vCard properties can appear more than once (those defined in 6350
with cardinality "1*" or "*").  Using objects named by the property
name would result in multiple JSON objects with the same name.  That
is allowed in JSON (and is a matter of great debate right now in the
json working group), but no one thinks it's a good thing to be
encouraged.

Barry

---

From: Richard Barnes <[email-masked]>
Date: Thu, 18 Jul 2013 17:52:54 -0400

> json working group), but no one thinks it's a good thing to be

Ok, maybe I was confused by Section 3.2.1.2, and I'm confusing multiple
values for properties rather than multiple appearances.  I was thinking
that multiple appearances were being collapsed:

CATEGORIES:TRAVEL AGENT
CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY

~~> ["categories", {}, "text", "travel agent", "internet", "ietf",
"industry", "information technology"]

Now that I say that, I realize it violates the "round trip fidelity goal",
and is clearly nonsense :)  I've cleared this comment.

--Richard

---

From: Philipp Kewisch <[email-masked]>
Date: Sun, 21 Jul 2013 23:19:32 +0200

> NEW: "escaping mandated by JSON (e.g., for control characters)."
Done.

> null, or object; not just array.
Indeed, the value is not restricted to being an array. For example, for 
a "text" value you would normally expect a JSON string:

[ "fn", {}, "text", "Mr. John Q. Public, Esq." ]

On the other hand, if its a structured value, it may also be an array, 
even though the type is still "text":

["adr", {}, "text", [ "", "", "123 Main Street", "Any Town", "CA", 
"91921-1234", "U.S.A." ] ]

If the type of the property dictates a type different from string, it 
may alternatively be that different type or array. Consider this 
property, which is a simple boolean property:

["x-non-smoking", {}, "boolean", true]

Now lets say another property is defined to be a structured value of 
booleans, then the property value is an array, even though the type is 
"boolean":

["x-wierd-bits", {}, "boolean", [true, false, false, true, true, false] ]

The purpose of the sentence is to make clear that the parser should 
check for this case. I had hoped the section about Structured Property 
Values describes this sufficiently?

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Jul 2013 10:39:14 -0400

> Indeed, the value is not restricted to being an array. For example, for a
> "text" value you would normally expect a JSON string:
>
> If the type of the property dictates a type different from string, it may
> alternatively be that different type or array. Consider this property,
> which is a simple boolean property:
>
> The purpose of the sentence is to make clear that the parser should check
> for this case. I had hoped the section about Structured Property Values
> describes this sufficiently?
>

I think the section on Structured Property Values is clear.  I may have
just misunderstood the phrase "structured value" to mean "any JSON", rather
than in the more limited sense of Section 3.2.1.4.  Perhaps the following
wording  for that paragraph would be clearer?

OLD:
"""
As described in Section 3.2.1.4, it is important for a parser check the
data type of the value even if it is assumed to be a string in most cases.
 The value could turn out to be a structured value, in which case the data
type is an array.
"""
NEW:
"""
Section 3.2.1.4 describes how vCard structured text values are expressed as
JSON arrays in jCard. Thus, it is important for a parser check the data
type of the value even if it is assumed to be a string in most cases.  The
value could turn out to be a structured value, in which case the data type
is an array.
"""

--Richard