Re: [Jcardcal] Questions on remaining open tickets

[Bert Greevenbosch <[e-mail]>]

Hi Philipp,

Thanks a lot for merging the resolutions into the draft.

Here is my response to your questions:

<QUOTE>
=== http://trac.tools.ietf.org/wg/jcardcal/trac/ticket/48 ===
* What happened to the more verbose points in the numbered items. For example, why do we not want to mention that if there are no parameters, the object should be there and empty?
* What happened to the second example, why only one?
</QUOTE>

I have taken draft-ietf-jcardcal-jcard-05 (http://tools.ietf.org/html/draft-ietf-jcardcal-jcard-05#page-5) as a basis. I can't find changes in the numbered items or the missing second example. Maybe it was removed already in an earlier version of the draft?

<QUOTE>
=== http://trac.tools.ietf.org/wg/jcardcal/trac/ticket/43 ===
* Is it advisable to make the ABNF authoritative? I'd say so, because it matches whats in the ISO spec and the ISO spec is harder to get. In that case I'd just add (authoritative) to the hang text, like I suggested in the ticket.
</QUOTE>

Do you mean with "authoritive", that it is not "informative", i.e. not "non-normative"? I would prefer to keep it non-normative. The ABNF should be flawless in both cases, is it? I have checked the ABNF, and it seems pretty solid to me, but if we find some inconsistencies later, it should be clear that the specification text prevails, not the ABNF.  Also I worry a bit about the whitespace, which JSON allows at many places, but indeed RFC 4627 already has a note on the whitespace issue.

<QUOTE>
=== http://trac.tools.ietf.org/wg/jcardcal/trac/ticket/49 ===
* I've added a paragraph to note that the version property must come first, this matches what vCard requires. Any objections?
NEW:
       Also in accordance to [RFC6350], the "version"
       property MUST be the first element of the array containing the
       properties of a jCard.
</QUOTE>

Yes, this makes it easy to classify the jCard early in the parsing process. And since the overall jCard object is represented as an array, we can be sure the "version" property will stay in the first element even when handled by generic JSON software.

<QUOTE>
=== http://trac.tools.ietf.org/wg/jcardcal/trac/ticket/34 ===
* This one is still open. Not sure how to handle this ticket, are we waiting on a response?
</QUOTE>

I asked Stephen Farrell off-list about this. My opinion is, that there is so much freedom e.g. in the ordering of jCard properties / parameters and representation of floats, that fixing a unique date format does not help to create a consistent format that gives the same cryptographic hash for jCards that contain the same semantics.

Best regards,
Bert
(as a participant)

---

From: [e-mail] [mailto:[e-mail]] On Behalf Of Philipp Kewisch
Sent: 13 September 2013 05:34
To: [e-mail]
Subject: [Jcardcal] Questions on remaining open tickets

Hello Folks,

I have some questions on what has been discussed in my absense, to resolve the last remaining tickets:

=== http://trac.tools.ietf.org/wg/jcardcal/trac/ticket/48 ===
* What happened to the more verbose points in the numbered items. For example, why do we not want to mention that if there are no parameters, the object should be there and empty?
* What happened to the second example, why only one?

=== http://trac.tools.ietf.org/wg/jcardcal/trac/ticket/43 ===
* Is it advisable to make the ABNF authoritative? I'd say so, because it matches whats in the ISO spec and the ISO spec is harder to get. In that case I'd just add (authoritative) to the hang text, like I suggested in the ticket.

=== http://trac.tools.ietf.org/wg/jcardcal/trac/ticket/49 ===
* I've added a paragraph to note that the version property must come first, this matches what vCard requires. Any objections?
NEW:
       Also in accordance to [RFC6350], the "version"
       property MUST be the first element of the array containing the
       properties of a jCard.

=== http://trac.tools.ietf.org/wg/jcardcal/trac/ticket/34 ===
* This one is still open. Not sure how to handle this ticket, are we waiting on a response?


Are there any other remaining issues that were not in the tickets? I went through all my unread email, so I think I have them all. Pending the above tickets I will upload a new version so you can see what has changed, its been quite a bit this time.

Philipp