Subject: Representation of numeric values in RFCs

From: Lou Berger <[email-masked]>
Date: Mon, 13 May 2013 11:23:26 -0400

Hi,

Does anyone have a good reference that points to how values should be
represented in RFCs to indicate different bases, in particular base 10
and base 16?

I'm talking with a set of authors who believe it's perfectly reasonable
to intermix hexadecimal and decimal representation in the same document
without any distinction.  I expected to find it documented somewhere
(other than K&R) that unqualified values are decimal and that the '0x'
prefix is used for hexadecimal representation, but have been unable to
find this statement in any IETF or RFC Editor document.

Much thanks,
Lou

PS Note today is not April 1st!

---

From: John Scudder <[email-masked]>
Date: Mon, 13 May 2013 11:30:30 -0400

Lou,

It's hard to credit that there's a real need to specify that values are base 10 unless otherwise indicated. This would seem to come under the heading "duh". If a document does use a different base, it seems to me like the better part of valor to call bases out specifically. Instances I can think of off the top of my head state the (non-10) base explicitly in line where used, but if it's prevalent enough in the document in question it would seem fine to state the convention (0x for hex, leading-0 for octal, etc) at the beginning of the document.

--John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 May 2013 08:37:43 -0700

On 5/13/2013 8:30 AM, John Scudder wrote:
> It's hard to credit that there's a real need to specify that values are base 10 unless otherwise indicated. This would seem to come under the heading "duh".

For a community that often shows binary, octal and hex numbers, a 
practice of /always/ specifying the base would seem a pretty modest 
safety practice.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 May 2013 16:39:38 +0100

Hi,

I don't find anything in Heather's work-in-progress revised style guide (maybe
something to add?), but I would have thought it "obvious".

Unambiguous is the watch-word. If there is any scope for confusion by even the
least able of our community, then the I-D fails the ambiguity test and should
attract a Discuss according to several views of
http://www.ietf.org/iesg/statement/discuss-criteria.html

I think you read all unprefixed numbers as decimal. Hex, octal, and binary have
established prefixes. There are obviously a few cases where the decimal and hex
numbers are the same and the difference does not *need* to be highlighted.

A

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lou Berger
> Sent: 13 May 2013 16:23
> To: Working Group Chairs; RFC Series Editor
> Subject: Representation of numeric values in RFCs
> 
> Hi,
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 13 May 2013 11:43:31 -0400

Hi John,
	The real issue is that they author's don't see a problem with
intermixing representations without any indication in the same document.
 Clearly this is broken.  I've asked to that they always use the '0x'
prefix.  They didn't like this idea.  I have a workaround that I think
is acceptable for *this document*, but wanted to raise the general
question to see if there was a reasonable/authoritative reference out
there for the next time.

Thanks,

Lou

On 5/13/2013 11:30 AM, John Scudder wrote:
> Lou,
> 
> It's hard to credit that there's a real need to specify that values
> are base 10 unless otherwise indicated. This would seem to come under
> the heading "duh". If a document does use a different base, it seems
> to me like the better part of valor to call bases out specifically.
> Instances I can think of off the top of my head state the (non-10)
> base explicitly in line where used, but if it's prevalent enough in
> the document in question it would seem fine to state the convention
> (0x for hex, leading-0 for octal, etc) at the beginning of the
> document.
> 
> --John
>

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 13 May 2013 11:40:48 -0400

On May 13, 2013, at 11:37 AM, Dave Crocker <[email-masked]> wrote:

> For a community that often shows binary, octal and hex numbers, a practice of /always/ specifying the base would seem a pretty modest safety practice.

Sure, what's one more piece of boilerplate, after all? We're already used to ignoring it. While we're at it, should we have a mandatory section to specify the language and regional dialect the document was written in? 

--John

---

From: Lou Berger <[email-masked]>
Date: Mon, 13 May 2013 11:50:42 -0400

Adrian,

> something to add?), but I would have thought it "obvious".

I'm frankly amazed that the discussion that prompted my comment is even
taking place.

Lou

---

From: Acee Lindem <[email-masked]>
Date: Mon, 13 May 2013 15:56:26 +0000

As I posted to the CCAMP WG, we always precede hexadecimal values with 0x in OSPF RFCs and drafts. 
Individual bits are explicitly referred to as being set or cleared. Multi-bit binary encoding are handled with care. 
Thanks,
Acee

---

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Mon, 13 May 2013 11:57:19 -0400

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lou Berger
...
> I'm frankly amazed that the discussion that prompted my comment is even

Yes, this seems like singular stubbornness that a DISCUSS would fix, if not WG consensus. 
We can't close every hole with more words or policy, but stand with you.

Al

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 May 2013 09:10:02 -0700

> question to see if there was a reasonable/authoritative reference out

Lou: Do note that WG authors serve at the pleasure of the WG chair. If they are not doing their job (making a clear spec that has WG consensus), you can fire them. Clearly, a good step back from this is "As WG chair, I think the document is unclear unless you write it this way." Unless the WG balks at that statement, it should be clear to the authors what they need to do.

--Paul Hoffman

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 May 2013 12:50:26 -0400

> numbers are the same and the difference does not *need* to be highlighted.

IMO it is fine to assume decimal if there is no prefix and there isn't 
something specific in context to say otherwise.

But beware "hex, octal, and binary have established prefixes". Note that 
C and its descendents assume numbers beginning with "0" are *octal*. 
This is an egregious design choice, that has bitten me more than once, 
even though I know better.

There may be some C programmers writing drafts that may *assume* that 
everyone knows and follows this convention.

	Thanks,
	Paul

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 13 May 2013 18:03:04 +0100

On 13/05/2013 16:37, Dave Crocker wrote:
>> the heading "duh".
Dave

That seems rather unnecessary. Decimal is the normal default, including 
the page number, the RFC number and the bit-field number. The important 
thing is to make sure no one forgets to note the base when it is other 
than ten.

A subsidiary question is when one should say one and when "1" etc.

- Stewart

---

From: Lou Berger <[email-masked]>
Date: Mon, 13 May 2013 13:14:21 -0400

On 5/13/2013 12:10 PM, Paul Hoffman wrote:
> Lou: Do note that WG authors serve at the pleasure of the WG chair.
> If they are not doing their job (making a clear spec that has WG
> consensus), you can fire them. Clearly, a good step back from this is
> "As WG chair, I think the document is unclear unless you write it
> this way." Unless the WG balks at that statement, it should be clear
> to the authors what they need to do.
> 

So I think I have the specific WG issue covered, but wanted to raise the
topic more generally as I've been seeing a trend towards authors who are
'less experienced' in the typical language used in RFCs and thought it
would be good to identify if there was some authoritative language on
the topic. Seems like there's not...

Thanks!

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 13 May 2013 13:21:00 -0400

Heather,
	Given that there seems to be an interest in the IETF in improving the
direction/advice provided to newcomers, perhaps it makes sense to
document this in your favorite RFC style guide?  What do you think?

Thanks,
Lou

On 5/13/2013 12:59 PM, Heather Flanagan (RFC Series Editor) wrote:
> On 5/13/13 8:39 AM, Adrian Farrel wrote:
>> Hi,
>>
> I admit, I am also surprised this is a question.  There are commonly
> used methods to refer to the various numeral systems, such as the prefix
> 0x for hex and 0o for octal.  If someone has a need to use more than one
> numeral system in a document, I would expect them to use the common
> formats and be consistent with that usage within the document or set of
> documents.  If a document uses more than one numeral system, being
> explicit throughout the document for each instance of a number will
> eliminate any ambiguity that could impede the ability to implement
> whatever is being described in the text.
> 
>>
> Agreed.  I would rather ambiguity be sorted out while the document is
> still being reviewed by the community rather than in AUTH48.
> 
>>
> I would say, if there is any question that a reasonable person could
> read it and be confused, then go ahead and prefix the numbers.
> 
> -Heather Flanagan, RSE
> 
>>
>> A
>>

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 13 May 2013 09:59:16 -0700

-Heather Flanagan, RSE

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 13 May 2013 10:31:49 -0700

> document this in your favorite RFC style guide?  What do you think?
Yes, I agree.  Sandy and I have added it to our list of things to include. 

Thanks for copying me on this thread!
Heather

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 May 2013 16:12:36 +0000

Well, there are some things that are "traditionally" (whatever that means) always in hex. For example from RFC 3947:
             The content of the payload is the MD5
   hash of

      RFC 3947

   The exact content in hex for the payload is

      4a131c81070358455c5728f20e95452f

I think this would be obviously hex even if all the digits turned out to be below 0xa (a 1:3,402,824 likelihood)

Or anything that looks like this bit from RFC 5114:
      yA =                   1B3A6345 1BD886E6 99E67B49 4E288BD7
           F8E0D370 BADDA7A0 EFD2FDE7 D8F66145 CC9F2804 19975EB8
           08877C8A 4C0C8E0B D48D4A54 01EB1E87 76BFEEE1 34C03831
           AC273CD9 D635AB0C E006A42A 887E3F52 FB8766B6 50F38078
           BC8EE858 0CEFE243 968CFC4F 8DC3DB08 4554171D 41BF2E86
           1B7BB4D6 9DD0E01E A387CBAA 5CA672AF CBE8BDB9 D62D4CE1
           5F17DD36 F91ED1EE DD65CA4A 06455CB9 4CD40A52 EC360E84
           B3C926E2 2C4380A3 BF309D56 849768B7 F52CFDF6 55FD053A
           7EF70697 9E7E5806 B17DFAE5 3AD2A5BC 568EBB52 9A7A61D6
           8D256F8F C97C074A 861D827E 2EBC8C61 34553115 B70E7103
           920AA16D 85E52BCB AB8D786A 68178FA8 FF7C2F5C 71648D6F

(I'm not even bothering to calculate the odds of this turning out all below 0xa)

Or the hexdump style:
   11 22 33 44 83 52 13 34

Usually with big numbers, you'll have a thousands separator if it's decimal, so it's easy to spot the hex on the 127-bit number above. It's more of an issue with small numbers such as 30. You wouldn't want one implementation to use 48 (decimal) while another uses 30 (decimal).

I'd say definitely err on the side of clarity if there's any chance of anyone mistaking the bases.

Yoav

On May 13, 2013, at 6:50 PM, Lou Berger <[email-masked]>
 wrote:

> Email secured by Check Point

---

From: Dave Cridland <[email-masked]>
Date: Wed, 22 May 2013 15:03:31 +0100

On Mon, May 13, 2013 at 5:12 PM, Yoav Nir <[email-masked]> wrote:

> Well, there are some things that are "traditionally" (whatever that means)
> always in hex. For example from RFC 3947:
I would agree this could be assumed to be hex, but I don't see the harm in
stating it in prose, in part because:

>>> '4a131c81070358455c5728f20e95452f'.decode('base64')
'\xe1\xadw\xd5\xcf5\xd3\xbd7\xe7\xce9\xe5\xce{\xdb\xc7\xf6\xd1\xefy\xe3\x9d\x9f'

Bear in mind that long strings of hex are almost always legal Base 64
encoding (the length has to be divisible by 4, but that's not uncommon), so
it's not just bases that can be confused.

In general, though, prefixing a hash result (for example) would be odd to
my eyes, so it'd be better specified in prose - as RFC 3947 does in the
quoted section above, in fact.

The point is clarity rather than syntax.

Dave.