Subject: [Cbor] Is draft-bormann-cbor-time-tag unnecessary?

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 20 Jul 2017 03:59:57 +0200

Hi all,

I think the new time tag is unnecessary. It's more complex than extending
tag 1 to accept BigDecimal and BigFloats, and it costs more bytes (20 vs 15
for a current use of picosecond resolution, if I counted right).

One objection could be that RFC7049 already specifies that only types 0, 1,
and 7 will appear inside tag 1, and so generic parsers could be confused if
people put bignums there. Two responses:
1) I believe people are mostly designing individual protocols with CBOR,
and not relying on deployed generic parsers being able to handle new
protocols. When a particular protocol specifies use of the time tag, it
needs to specify which numeric formats are ok inside it (e.g. "no floats"
is quite reasonable), and that protocol's parsers can be implemented to
match.
2) If we can't change tag 1, I think it's still simpler to add a POSIX time
tag that allows more numeric formats, rather than adding the proposed
map-based format.

I think a new tag would be justified to encode a different time standard
like TAI or real UTC, whenever folks need those.

Jeffrey

---

From: Sean Leonard <[email-masked]>
Date: Wed, 19 Jul 2017 22:17:02 -0700

> On Jul 19, 2017, at 6:59 PM, Jeffrey Yasskin <[email-masked]> wrote:
> 
> Hi all,
> 
> I think the new time tag is unnecessary. It's more complex than extending tag 1 to accept BigDecimal and BigFloats, and it costs more bytes (20 vs 15 for a current use of picosecond resolution, if I counted right).
> 
> One objection could be that RFC7049 already specifies that only types 0, 1, and 7 will appear inside tag 1, and so generic parsers could be confused if people put bignums there. Two responses:
> 1) I believe people are mostly designing individual protocols with CBOR, and not relying on deployed generic parsers being able to handle new protocols. When a particular protocol specifies use of the time tag, it needs to specify which numeric formats are ok inside it (e.g. "no floats" is quite reasonable), and that protocol's parsers can be implemented to match.
> 2) If we can't change tag 1, I think it's still simpler to add a POSIX time tag that allows more numeric formats, rather than adding the proposed map-based format.

I have always believed that it is, or should be, acceptable to extend the tags to accept more major types.

This is also the same issue with tag 36 for “MIME Message”, as discussed in the WG document draft-bormann-cbor-tags-oid-06.

Ultimately it is a “style issue” that nobody has raised serious objections against (to expanding a tag); however, the matter has not been thoroughly discussed and “consensus-ed” upon, either.

(In this message at this time, I do not express an opinion about whether a new time tag is necessary.)

Regards,

Sean

> 
> I think a new tag would be justified to encode a different time standard like TAI or real UTC, whenever folks need those.

> 
> Jeffrey
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor