Subject: [Cbor] draft-ietf-cbor-7049bis

From: Jim Schaad <[email-masked]>
Date: Tue, 11 Jul 2017 10:25:50 -0700

Paul,

Here are a few comments for you to mull over.

Section 2.1 - Major type 2 -  After the long discussion in the JSON working
group about bad Unicode code points, it would probably be a good idea to
have a statement here (which I do notice is echoed in other places) about
the fact that the Unicode string must be valid according to some measure of
valid.

Section 2.4.1 - Does it make any sense to put in a comment that the POSIX
time ignores leap seconds

Section 3.3.1 - I do not understand the second bullet item. Either it does
not seem to be an error - or it is the same as the previous item.  Did you
mean to say that the key is processed but the end of the data comes before
the value is processed?

Section 3.3.2 - formatting - why is the last paragraph not a bullet point?

Section 3.7 needs a re-write esp. given that many of the specs are
"violating" the guidance in this section.  Also the use of both signed and
unsigned ints seems to be totally reasonable but also violates the guidance.

Section 3.9 - I will again express unhappiness with the language on sorting
keys.  It would be good to re-write this so that it is clear what is being
done and why.  Having to encode in order to sort is both good and bad.

Section 3.10 - 3 to last paragraph - should 'update the encoder at the same'
be decoder not encoder?

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Jul 2017 20:26:29 +0200

Hi Jim,

thank you for the input.

> the fact that the Unicode string must be valid according to some measure of

(I think this is about major type 3, text strings.  Major type 2 is byte strings.)

One way to handle this here might be adding a reference to a specification that defines what Unicode is.  Note that CBOR does not take a position on many of the minor quibbles in the Unicode world, or specify a specific Unicode version — the intention is that the spec grows with the common usage of Unicode.  The only reference that is there already is that of UTF-8, and CBOR is intended to be strict about that specification.  But I don’t think that, say, CBOR with a Unicode non-character, needs to be considered invalid CBOR.

> time ignores leap seconds

It doesn’t ignore those (to the contrary, it creates hard to handle non-linearities at exactly those points), it handles them by glossing over them in a specific (and not necessarily intuitive) way.
Trying to reproduce the POSIX specification here is likely to create more confusion than solve any.
I’m not sure draft-touch-time will be ready in time for this document, but it would make a nice informative reference once it is done.

> mean to say that the key is processed but the end of the data comes before

Maybe; maybe that example (the whole list is about examples) is not as useful as we thought.

> Section 3.3.2 - formatting - why is the last paragraph not a bullet point?

Because it is not about "malformed indefinite-length data items” — the point in that paragraph is that we don’t have an active indefinite-length data item and see a “break” stop code.

> "violating" the guidance in this section.

It sure makes sense to align that guidance with the best practice that has evolved since it was written.
What specific parts would you want to change?
(Note that much of the section is about JSON interoperability, which maybe should be more clearly separated from more general considerations.)

> Also the use of both signed and

The last paragraph actually recommends that — what other parts of the guidance are being violated?

> done and why.  Having to encode in order to sort is both good and bad.

Yes, when I wrote the cbor-canonical addition to the cbor-ruby gem, I decided to simply encode everything in a map key twice…

One problem is that the map key ordering spec violates the POLS (principle of least surprise): Most people would expect lexicographical order (in the computer science sense of that word) here.  That order also has certain performance advantages (it may be possible to decide on the order between two items before looking at the entire items).  But that is not what the spec currently says, and so far we haven’t heard that this guidance really needs to change.

The parenthetical recommendation against mixing types of keys probably should go; implementations have generally managed to avoid the pitfalls here.

> Section 3.10 - 3 to last paragraph - should 'update the encoder at the same'

Well, maybe encoding/decoding layer…. But yes, the specific sentence is about the decoder.

Thanks again; more input on potential editorial improvements is very welcome.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Tue, 11 Jul 2017 12:17:10 -0700

Some responses inline.

Jim

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2017 11:26 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: draft-ietf-cbor-7049bis 

Hi Jim,

thank you for the input.

> Section 2.1 - Major type 2 -  After the long discussion in the JSON 
> working group about bad Unicode code points, it would probably be a 
> good idea to have a statement here (which I do notice is echoed in 
> other places) about the fact that the Unicode string must be valid 
> according to some measure of valid.

[JLS] That is what I get for making notes and then trying to flesh them out rather than writing the full comment at the time.

[JLS] I cannot remember what the decision that JSON made about this.  I would say that we should be making the same answer here.

> Section 2.4.1 - Does it make any sense to put in a comment that the 
> POSIX time ignores leap seconds

[JLS] I think we are saying the same thing.  The time computation pretends that leap seconds never existed. However, I don't need to have that mentioned which is why I was asking if it made sense.

> Section 3.3.1 - I do not understand the second bullet item. Either it 
> does not seem to be an error - or it is the same as the previous item.  
> Did you mean to say that the key is processed but the end of the data 
> comes before the value is processed?

[JLS] I would have called it a malformed indefinite length encoding - so it makes more sense to me as a bullet point.  I can deal with this as is, I just think it reads better the other way.

[JLS] It depends on if you think that the union of signed and unsigned is a single type or if it is two types.  I think of it as two types since the major type number is different.

> Section 3.9 - I will again express unhappiness with the language on 
> sorting keys.  It would be good to re-write this so that it is clear 
> what is being done and why.  Having to encode in order to sort is both good and bad.

[JLS] I would be really happy to stop this violation of POLS.  We have some discussions on that during last call on the current RFC.

Grüße, Carsten