Subject: [Jcardcal] Questions on remaining open tickets

From: Philipp Kewisch <[email-masked]>
Date: Thu, 12 Sep 2013 23:33:39 +0200

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

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 13 Sep 2013 01:31:30 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Philipp Kewisch
Sent: 13 September 2013 05:34
To: [email-masked]
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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 13 Sep 2013 10:16:24 +0200

One thing first: I think it would be best to publish what you have now 
even if there are a few remaining issues. Then we can check that all the 
other issues have indeed been fixed and move on.

> 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…

+1

The intent is for the ABNF to reflect the ISO standard, not to create a 
new standard.

> 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 da…

I don't understand this one. Don't we already have a "unique date 
format"? We use the extended format if it's available, extended format 
otherwise. There is really only one way to encode any given date/time value.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 13 Sep 2013 09:19:23 +0000

Hi Simon,

> > 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.
> 

Indeed for the "date" value type we have a single representation. However, for "time" and "date-time" we have multiple ways to express the same, especially due to optional inclusion of time zone information.

For example

   ["x-time ", {}, "time", "12:30:00"] and
   ["x-time ", {}, "time", "12:30:00-08:00"]
   ["x-time ", {}, "time", "12:30:00-08"]
   ["x-time ", {}, "time", "20:30:00Z"]

may mean the same.

Best regards,
Bert

---

From: Simon Perreault <[email-masked]>
Date: Fri, 13 Sep 2013 11:36:16 +0200

>     ["x-time ", {}, "time", "20:30:00Z"]

No, they each mean different things.

You could find a moment in time that fits with all four above. But there 
are also moments that only fit with one, two, or three of the above. 
Each time string above defines a set of moments that intersects with the 
other ones. But the four sets are different. The set is the message, and 
the set is what would be authenticated by an HMAC. Each set has only one 
textual representation, which means we're good.

Oh, and we have the same situation with dates.

Simon

---

From: Philipp Kewisch <[email-masked]>
Date: Sat, 14 Sep 2013 21:10:16 +0200

> 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. Mayb…
I rather think it was added based on some review comments. I will add in 
the slight changes and you can let me know how it is when I upload -06.
> 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…
Yes, normative is what I meant. The ABNF is flawless to the best of my 
knowledge. I'm fine with keeping it informative, in this case I will add 
a sentence describing its only informative, or at least change the 
hangText to "ABNF Schema (informative):".

Note also this is only about the ABNF with the date formats, the ABNF at 
the bottom was discussed separately.

Philipp