[ih] Forwarded with permission: History of RFC 154 (look it up!)
Bob Braden
braden at ISI.EDU
Fri Nov 8 08:57:51 PST 2002
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 91
----- Begin Included Message -----
>From steve at stevecrocker.com Tue Nov 5 21:17:32 2002
From: "Steve Crocker" <steve at stevecrocker.com>
To: "'Bob Braden'" <braden at ISI.EDU>
Cc: <steve at stevecrocker.com>
Subject: RE: What the hell...?
Date: Wed, 6 Nov 2002 00:17:13 -0500
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-AntiVirus: scanned by AMaViS 0.2.1
Bob,
You asked what I had in mind when I wrote RFC 154. I checked the
preceding RFCs and it all came back to me. In RFC 107, I believe I was
responsible for the following paragraph.
The ALL, GVB, and RET command are modified to treat two
quantities.
Their formats are given under Control Command, below. The GVB command
is further modified to make it possible to ask for none of the
allocation to be returned. The new GVB command has four eight bit
fields. The first two fields are the op code and the link, as before.
The next two fields contain number fM and fB which control how much of
message and a bit allocation are to be returned. Each of these
numbers is interpreted as "the number of 128ths of the current
allocation" to be returned if it is in the range of 0 to 128, and is
to be interpreted as "all of the current allocation", if it is in the
range 128 to 255.
Note that 128 is included in both treatments. This was deliberate on my
part, a subtle -- perhaps too subtle -- emphasis that the behavior
crossing from below 128 to above 128 was continuous, i.e. the fraction
128/128 is the same as "all."
The underlying idea was to create specifications which have some
robustness at the edges wherever possible, and to make it clear that
implementers had a choice in dealing with the boundary condition. The
idea of robust specifications is motivated by the same consideration of
the modern slogan "be conservative in what you send and liberal in what
you receive."
In retrospect, I would have done better to say all this in the original
RFC and not slip this in implicitly.
Jim White took issue with my wording, assuming it was unintended
imprecision. Here's his RFC 132 in its entirety:
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[l] the appropriate allocation if and
only if the high-order of the left-most bit of the corresponding
fraction is 1.
I then wrote RFC 154 in response.
Feel free to share this note with whomever you wish.
Steve
P.S. Another mildly odd part of the RFC 107 text is that GVB 0 is
specifically added. Since GVB 0 is a no-op, it's not clear why it's
mentioned. I don't recall whether there was a particular motivation for
this. I suppose it could function as a sort of "keep alive" function or
perhaps it permitted the receiver to send GVB commands on a regular
basis without needing to suppress them if nothing needed to be returned,
but I'm making this up as I type this and not recalling any specific
rationale from the time.
----- End Included Message -----
----------
X-Sun-Data-Type: html
X-Sun-Encoding-Info: quoted-printable
X-Sun-Content-Length: 5399
X-Sun-Content-Lines: 122
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR></HEAD>
<BODY><!-- Converted from text/rtf format --><SPAN lang=3Den-us><FONT =
face=3DArial=20
size=3D2>
<P>Bob,</FONT></SPAN> </P>
<P><SPAN lang=3Den-us><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D406423004-06112002>You asked what I had in mind when I wrote RFC =
154. I checked the preceding RFCs and it all came back to =
me. =20
</SPAN>I<SPAN class=3D406423004-06112002>n</SPAN> RFC 107, I believe I =
was=20
responsible for the following paragraph.</FONT></FONT></SPAN></P>
<UL>
<P><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>The ALL, =
GVB, and RET=20
command are modified to treat two quantities.</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>Their formats are =
given under=20
Control Command, below. The GVB command</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>is further modified =
to make it=20
possible to ask for none of the</FONT></SPAN> <BR><SPAN =
lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2>allocation to be returned. The new =
GVB command=20
has four eight bit</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT =
face=3D"Courier New"=20
size=3D2>fields. The first two fields are the op code and the =
link, as=20
before.</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3D"Courier =
New" size=3D2>The=20
next two fields contain number fM and fB which control how much=20
of</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>message=20
and a bit allocation are to be returned. Each of =
these</FONT></SPAN>=20
<BR><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>numbers is =
interpreted as=20
"the number of 128ths of the current</FONT></SPAN> <BR><SPAN =
lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2>allocation" to be returned if it is in =
the range of=20
0 to 128, and is</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT =
face=3D"Courier New"=20
size=3D2>to be interpreted as "all of the current allocation", if it =
is in=20
the</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>range=20
128 to 255.</FONT></SPAN> </P></UL>
<P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Note that 128 is =
included in both=20
treatments. This was deliberate on my part, a subtle -- perhaps =
too subtle=20
-- emphasis that the behavior crossing from below 128 to above 128 was=20
continuous, i.e. the fraction 128/128 is the same as =
"all."</FONT></SPAN></P>
<P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>The underlying idea =
was to create=20
specifications which have some robustness at the edges wherever =
possible<SPAN=20
class=3D406423004-06112002>, and to make it clear that implementers had =
a choice=20
in dealing with the boundary condition. The idea of robust=20
specifications is motivated by the same </SPAN>consideration <SPAN=20
class=3D406423004-06112002>of the modern slogan "be conservative in what =
you send=20
and liberal in what you receive."</SPAN></FONT></SPAN></P>
<P><SPAN lang=3Den-us><FONT face=3DArial size=3D2><SPAN =
class=3D406423004-06112002>In=20
retrospect, I would have done better to say all this in the original RFC =
and not=20
slip this in implicitly.</SPAN></FONT></SPAN></P>
<P><SPAN lang=3Den-us><FONT face=3D"Times New Roman">Jim White took =
issue with my=20
wording, assuming it was unintended imprecision. Here's his RFC =
132 in its=20
entirety:</FONT></SPAN> </P>
<UL>
<P><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>TYPOGRAPHICAL ERROR IN RFC=20
107<BR>______________________________<BR><BR>On page 5 of RFC 107, at =
the end=20
of the section titled 'V.<BR>Flow Control', the partial =
sentence:<BR><BR>Each=20
of these numbers is interpreted as "the number<BR>of 128ths of the =
current=20
allocation" to be returned<BR>if it is in the range zero to=20
128...<BR><BR>should read:<BR><BR>...if it is the range of zero to=20
127,...<BR>---<BR><BR>That is, return al[l] the appropriate allocation =
if=20
and<BR>only if the high-order of the left-most bit of the=20
corresponding<BR>fraction is 1.<BR></FONT></SPAN></P></UL>
<P><SPAN lang=3Den-us><FONT face=3D"Times New Roman">I then wrote RFC =
154 in=20
response.</FONT></SPAN></P>
<P><SPAN lang=3Den-us><SPAN class=3D406423004-06112002><FONT =
face=3DArial size=3D2>Feel=20
free to share this note with whomever you wish.</FONT></SPAN></SPAN></P>
<P><SPAN lang=3Den-us><FONT face=3D"Times New Roman">Steve</FONT></SPAN> =
</P>
<P><SPAN lang=3Den-us><FONT face=3D"Times New Roman">P.S. Another mildly =
odd part of=20
the RFC 107 text is that GVB 0 is specifically added. Since GVB 0 =
is a=20
no-op, it's not clear why it's mentioned. I don't recall whether =
there was=20
a particular motivation for this. I suppose it could function as a =
sort of=20
"keep alive" function or perhaps it permitted the receiver to send GVB =
commands=20
on a regular basis without needing to suppress them if nothing needed to =
be=20
returned, but I'm making this up as I type this and not recalling any =
specific=20
rationale from the time.</FONT></SPAN></P></BODY></HTML>
More information about the Internet-history
mailing list