- From: Scott Schmit <i.grok@comcast.net>
- Date: Sat, 2 Mar 2013 02:00:36 -0500
- To: ietf-http-wg@w3.org
- Message-ID: <20130302070036.GC22385@odin.ulthar.us>
On Fri, Mar 01, 2013 at 09:47:32PM -0800, James M Snell wrote: > On Fri, Mar 1, 2013 at 9:38 PM, Scott Schmit wrote: > > On Wed, Feb 27, 2013 at 01:16:16PM -0800, James M Snell wrote: > > > Numeric values: > > > > > > 1. Numeric values are encoded as variable-length, unsigned integers. > > "Big-endian" or "little-endian"? > > > > I've seen some references which state that the MSBs go first, others > > that say the LSBs go first. (Wikipedia led me down the MSB path, which > > confused me at first. Google's protocol buffers does LSBs first.) > > LSB.. I'm currently following the same scheme as protobufs but that's not > set in stone. An advantage of LSB first is that it's not as awkward to encode. A disadvantage is that you can't be sure that someone is using an intentionally-inefficient encoding until they finish the number, if they ever do. (All the leading zeros are at the end.) > > I assume that the uvarint length will be capped in some way? Is that > > per-field or is there an overall cap? > > 64-bit integers encode with a maximum of 10-bytes. If you run that out > you'll see that it gives us *plenty* of time ;-) Well, I assume we're going to use uvarints for more than just dates. :) Besides, I was thinking about the problems people had with UTF-8 at first with inefficient encodings, and with numbers I can imagine someone playing games with overflows to achieve some effect too. -- Scott Schmit
Received on Saturday, 2 March 2013 07:01:06 UTC