Index Journeys
RFC 132 UNKNOWN CORRECTIONS · HISTORY · ADMINISTRATION

Typographical Error in RFC 107

A correction to a range specification in RFC 107's flow control section.

On rfc-editor.org ↗
PUBLISHED
April 1971
AUTHORS
J.E. White
STREAM
Legacy
BUILDS ON
RFC 107 — Output of the Host-Host Protocol Glitch Cleaning Committee
OBSOLETED BY
RFC 154 — Exposition Style
PUBLICATION DATE
April 28, 1971
RFC LENGTH
1 page
RFC CORRECTED
RFC 107
ERROR TYPE
Range specification (0-128 vs 0-127)
DOI
10.17487/RFC0132
LINEAGE · FROM THE RFC INDEXOpen full graph →
'71RFC 107Output of the Host-Host Protocol Glitch Cleaning Committee'71RFC 132Typographical Error in RFC 107'71RFC 154Exposition Style

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
NETWORK WORKING GROUP                                           Jim White
Request for Comments #132                                       UCSB
NIC #6708                                                       April 28, 1971






                     TYPOGRAPHICAL ERROR IN RFC 107
                     ______________________________


On page 5 of RFC 107, at the end of the section titled 'V.
Flow Control', the partial sentence:

     Each of these numbers is interpreted as "the number
     of 128ths of the current allocation" to be returned
     if it is in the range zero to 128...

should read:

     ...if it is the range of zero to 127,...
                                      ---

That is, return al the appropriate allocation if and
only if the high-order of the left-most bit of the corresponding
fraction is 1.


       [ This RFC was put into machine readable form for entry ]
     [ into the online RFC archives by Mohnish Harisinganey 5/97 ]

AI ELI5

On this page
PROBLEMRFC 107 contains an error in its flow control section: it specifies a range from zero to 128, which is off by one.
MECHANISMThe correct range should be zero to 127, allowing for 128 distinct values as intended. The allocation should be returned only when the high-order (leftmost) bit of the corresponding fraction is 1.
REPLACED BY RFC 154This one-page correction clarifies the specification, but was itself superseded by RFC 154, which presumably incorporated this and other clarifications.

§1The Error

This one-page note by Jim White of UCSB points out a typographical error in RFC 107. On page 5 of that RFC, in the section titled 'V. Flow Control', there is a partial sentence that reads: 'Each of these numbers is interpreted as "the number of 128ths of the current allocation" to be returned if it is in the range zero to 128...' The range is incorrect; it should read 'if it is in the range of zero to 127...' with only 127 as the upper bound.

RFC 107 says a number should be between 0 and 128, but 0 to 128 gives you 129 slots. It should say 0 to 127 to get 128 slots.

§2Allocation Logic

The correction clarifies that the allocation is to be returned only when the high-order bit of the corresponding fraction is 1. By specifying the range as zero to 127 rather than zero to 128, the protocol correctly maps an 8-bit field to 128 distinct states (0 through 127), which is the standard interpretation.

When the first bit is 1, you return all your allocation. The range zero to 127 makes this work correctly with an 8-bit number.

§3Why This Matters

Off-by-one errors in protocol specifications can cause subtle but serious problems. An endpoint that implements the range zero to 128 (129 values) will behave differently than one using zero to 127 (128 values), causing interoperability failures or incorrect flow control behavior. Early RFC corrections like this one were important for maintaining consistency across the emerging ARPA network implementations.

Getting the number wrong breaks the protocol. That is why even tiny corrections like this one mattered in the early internet.