Subject: Confirming consensus on using big-endian

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 21 Dec 2016 12:55:36 +0000

Hi,

we had very strong consensus during the Seoul meeting to use big-endian encoding for QUIC. We'd like to confirm this consensus on the list. 

If you *disagree*, please reply to the list by Jan 6, 2017.

Lars

---

From: Watson Ladd <[email-masked]>
Date: Wed, 21 Dec 2016 06:12:03 -0800

> If you *disagree*, please reply to the list by Jan 6, 2017.

Big endian *for what*? I'm sure I agree, I just don't know with what I
am agreeing!

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 21 Dec 2016 14:17:55 +0000

> Big endian *for what*? I'm sure I agree, I just don't know with what I

For the header fields in the QUIC specification that this WG is standardizing.

Lars

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 21 Dec 2016 08:23:29 -0800

On Wednesday, December 21, 2016 6:18 AM, Lars Eggert wrote:
>> ... 

I agree. Most QUIC numbers are encoded with variable length, so the impact
of endian conversion is really low. Uniformity with the other layers (TLS)
is an advantage.

-- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Dec 2016 10:34:30 -0500

The only case where this is likely to be an issue is with crypto data some
of which is bigendian and some of which is little. I can't ever remember
which is which.

Where cryptodata is concerned, just specify the fields as opaque blobs,
that is byte[] or OCTET STRING. Most of the CMS and PKIX stuff does this
for the same reason.