RFC 7049 - Concise Binary Object Representation (CBOR) • Hacker News Board

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#51

Post by angersock » Wed, Oct 30, 2013, 5:26 PM UTC

Arelius wrote: post #49

angersock wrote: post #39

Earlier quoted context omitted.

Name me a particular time where a file format has ever had increased robustness, speed, security, or implementation simplicity because it did not specify record size ahead of time. Please convince me of the reliability of sentinel values and null-terminated strings.

Apologies, I didn't read the spec before hand. I thought you were suggesting that the format have fixed sized fields rather then fields with tagged lengths. In that case I'd agree with you.

No sweat. :)

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#52

Post by arh68 » Wed, Oct 30, 2013, 10:04 PM UTC

arh68 wrote: post #50

MichaelGG wrote: post #42

Can anyone enlighten me on why number equivalency is a good idea? The spec says that even if you're expecting an integer like 0, encoders can decide to use floating point, and things should just work. One of the first statements is that "7" should be able to be represented in multiple ways. That doesn't seem concise.

Hmm, that's not the impression I got. I don't think they're arguing you should use multiple encodings willy nilly. Rather, they're avoiding the limit of exactly 1 encoding for every input (maximum flexibility in the spec). Of course, in real-world implementations, the encoder and the decoder will have a shared view of what should be in a CBOR data item. For example, an agreed-to format might be "the item is an array…

Also, there's actually a much more relevant section later on in the spec (just got to p18):

   For constrained
   applications, where there is a choice between representing a specific
   number as an integer and as a decimal fraction or bigfloat (such as
   when the exponent is small and non-negative), there is a quality-of-
   implementation expectation that the integer representation is used
   directly.

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#53

Post by Someone » Thu, Oct 31, 2013, 9:46 PM UTC

drdaeman wrote: post #38

Someone wrote: post #32

Earlier quoted context omitted.

Whats terribly wrong with http://tools.ietf.org/html/rfc7049#section-2.4.1 ?

The minor issues are missing timezone and precision information. But, most importantly, use of integers for datetime values hides type-level semantics. It's just integers and you, the end user, and not the deserializer, is responsible for handling the types. I think it's quite inconvenient to do tons of `data["since"] = parse_datetime(data["since"])` all the time, for every model out there.

But they also allow strings with time zone information:

"Tag value 0 is for date/time strings that follow the standard format described in [RFC3339], as refined by Section 3.3 of [RFC4287]."

RFC4287: "A Date construct is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset."