On 2 November 2017 at 09:53, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > -------- > In message <ABC96E9C-7426-4DEB-9E06-6CF0EA4FC46E@mnot.net>, Mark > Nottingham wri > tes: > >Just a thought; maybe we shouldn't be defining "numbers" here, but > >instead "i32" or similar. > > The reason we have non-integers is the q=%f ordering parameter, and > that the pre-cursor draft tried to be a general purpose serialization. > > Neither of those may not be a good enough reasons to keep number > under this new scope/goal. > > So what's the goal with this header format? It feels like it's being moved towards defining a rich set of types, where I thought it was aimed at providing a simple set that provides good coverage (at the absolute minimum: scalar, list, dictionary -- beyond that, scalar tokens, binary blobs, quoted strings, and numbers). If it's going toward richness, is there going to be an eventual need for, for example, a "q-value" type? Or a "timestamp"? Those can look like numbers, but that's an implementation detail and conceptually they are different. If the general definition of "number" were changed from "up to 15 digits" to "guaranteed up to 15 digits, maybe more in other circumstances" and each header field in question specified the minimum/maximum/etc. for its particular case, what would that break? I'm imagining the general definition to include a standard reaction to numbers with too many digits (beyond 15) for a particular implementation, and the individual header fields could build on that general exception. Am I missing something? Is this different from tokens/blobs/strings that are too long? Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Thursday, 2 November 2017 00:23:22 UTC