- We
sincerely appreciate the careful attention given to our
book by those readers who noted the following errors.
BOOK ERRATA
Error
.01
Page 38, the first
sentence on the page should read:
|
The top
level domain (TLD) is the least significant octet (eight
bits) in a four-octet Internet protocol (IP, a 4 x
8 = 32-bit address) that comprises...
We thank
Paul Colquhoun for bringing this error to our
attention.
|
Error.02
Page 52, the third
paragraph should read as follows:
|
Each
octet in a 32-bit address is allowed to have an
alphanumeric equivalent, which is called a "label".
A domain name is a sequence of
[alphanumeric] labels separated by
dots.
In the section entitled "2.3.1
Preferred Name Syntax" in RFC 1035:
The DNS specifications attempt
to be as general as possible in the rules for
constructing domain names. The idea is that the
name of any existing object can be expressed as
a domain name with minimal changes. However,
when assigning a domain name for an object, the
prudent user will select a name which satisfies
both the rules of the domain system and any
existing rules for the object, whether these
rules are published or implied by existing
programs.
For example, when naming a mail
domain, the user should satisfy both the rules
of this memo and those in RFC-822. When creating
a new host name, the old rules for HOSTS.TXT
should be followed. This avoids problems when
old software is converted to use domain names.
- The label consists of "any
one of the 52 alphabetic characters A through
Z in upper case and a through z in lower case
or any one of the ten digits 0 through
9."
- Note that while upper and
lower case letters are allowed in domain
names, no significance is attached to the
case. That is, two names with the same
spelling but different case are to be treated
as if identical. The labels must follow the
rules for ARPANET host names. They must start
with a letter, end with a letter or digit,
and have as interior characters only letters,
digits, and hyphen. There are also some
restrictions on the length. Labels must be 63
characters or less.
The labels must follow the rules
for ARPANET host names. They must start with a
letter, end with a letter or digit, and have as
interior characters only letters, digits, and
hyphen. There are also some restrictions on the
length. Labels must be 63 characters or
less.
For example, the following
strings identify hosts in the Internet:
- A.ISI.EDU
- XX.LCS.MIT.EDU
- SRI-NIC.ARPA
The following syntax will result
in fewer problems with many applications that
use domain names (e.g., mail, TELNET).
- <domain> ::=
<subdomain> | " "
- <subdomain> ::=
<label> | <subdomain> "."
<label>
- <label> ::= <letter>
[ [ <ldh-str> ] <let-dig> ]
- <ldh-str> ::=
<let-dig-hyp> | <let-dig-hyp>
<ldh-str>
- <let-dig-hyp> ::=
<let-dig> | "-"
- <let-dig> ::=
<letter> | <digit>
- <letter> ::= any one of
the 52 alphabetic characters A through Z in
upper case and a through z in lower case
- <digit> ::= any one of the
ten digits 0 through 9
The dash ( - ) is the only symbol,
besides the dot separator, that the DNS allows in a
label.
Once
again, we thank Paul Colquhoun for his careful
reading of our book and specially for a well
documented email message that brought several book
errors to our attention. For Errata 02, we have
rewritten the middle section of page 52, based upon
quotes from RFCs 1034 and 1035. Paul also pointed
out that:
" . . .
the above range ( 'A' to 'Z', 'a' to 'z', '0' to
'9' and '-' ) is the range that the latest versions
of the Unix name server software ( BIND ) is
enforcing as the only allowable characters. In
particular BIND is treating the underscore ("_" )
as an error, and can be set to ignore any domain
names which contain this character."
|
Error.03
Page 96, section 4.7
should read as
follows:
|
Socket - A
48-bit quantity that is the
combination of the Port address (16 bits) and the
Internet Address (32 bits)."
We thank
Paul Colquhoun for bringing these two errors to our
attention.
|
Error.04
Pages 103-104
|
Paul
Colquhoun suggested that we add the following
comments at the end of Section 4.9.3:
RFC 1475 "TP/IX: The Next Internet"
was one of the competing proposals for the next
version of the IP protocol suite. The proposal that
was eventual chosen was a modified version of a
proposal called SIP put forward by S. Deering and
P. Francis. Called IPv6 (or IPng) it uses 128-bit
addresses and is detailed in the following RFCs
(and others).
- RFC 1752: The Recommendation for
the IP Next Generation Protocol
- RFC 1883: Internet Protocol,
Version 6 (IPv6) Specification
- RFC 1884: IP Version 6
Addressing Architecture
- RFC 1885: Internet Control
Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6)
- RFC 1887: An Architecture for
IPv6 Unicast Address Allocation
- RFC 1888: OSI NSAPs and
IPv6
- RFC 1933: Transition Mechanisms
for IPv6 Hosts and Routers
- RFC 1970: Neighbor Discovery for
IP Version 6 (IPv6)
- RFC 2133: Basic Socket Interface
Extensions for IPv6
- RFC 2185: Routing Aspects of
IPv6 Transition
|
Error.05
Page 123. The last paragraph
in Section 4.18.3 should read as follows:
|
As we
examine Dr. Postel's chronology, we catch a glimmer
of the organizational competition that may have
occurred in the assigned numbers/Internet numbers
activity he originated in 1971. Postel"s
fifteen-year streak of uninterrupted responsibility
for all networking numbers ended
abruptly -- but only
temporarily -- in 1987 (Section 4.14) when
the authority for 32-bit Internet Protocol (IP)
Addresses was transferred from ISI to SRI-NIC. ISI,
Postel, and Reynolds did retain a piece of the
networking numbers pie, namely, authority for all
Internet protocol parameters "Assigned
Numbers" other than the Class A, Class B,
and Class C 32-bit addresses of computer networks.
Postel and ISI are responsible for the significant
.US top level domain.
After a brief period at SRI-NIC --
and up to and including 1997 -- IANA has retained
ultimate responsibility for the overall DNS as well
as officially sanctioned regional
registries for
Internet Protocol (IP) addresses as well as
autonomous system numbers. Such regional registries
include over the DNS once involvement of the U.S.
Government ceases on September 30, 1998. By August
31, 1998, IANA had produced a draft, which had gone
through three iterations, for the "IANA-2" or
"NewCorp"-- the successor to IANA (also known as
the old IANA).
We thank
Rob Hassett for bringing our unspecific, and
misleading, wording to our attention on August 20,
1998.
|
Error.06
Page 123. The first
paragraph in Section 4.19 should read as
follows:
|
An
examination of RFC file sizes for the "numbers"
standards provides evidence of the magnitude of the
change involving SRI-NIC versus ISI (Figure 4-9).
As the ARPA-Internet grew, the size of the
"Assigned Numbers" RFC file steadily increased. In
Figure 4-9 (Series 1), we plot the file sizes of
RFCs 204, 349, 739, 750, 755, 758, 762, 770, 776,
790, 820, 870, 900, 923, 943, 960, 990, 1010, 1060,
1340, and 1700 versus their respective ISI
distribution dates. We also plot (Series 2) the
"Internet Numbers" file sizes for RFCs 997, 1020,
1062, and 1166 versus their respective SRI -NIC
distribution dates. It can be observed from Figure
4-9 that a significant drop, from 167 KB to 74KB,
occurred for ISI between RFC 990 (November 1986)
and RFC 1010 (May 1987); we infer that this drop
corresponded to the temporary
transfer of responsibility
for the IP addresses and Autonomous System Numbers
(ASNs) from ISI to SRI-NIC.
We thank
Rob Hassett for bringing our unspecific, and
misleading, wording to our attention on August 20,
1998.
|
Error.07
Page 90 and Page 130,
Footnote 2, were incorrectly
attributed and should read:
|
The
second document is Anthony M.
Rutkowski's "known detailed history" of
the Internet Assiged Numbers Authority
(IANA).2
2.
Anthony M. Rutkowski, "US DOD
[Internet] Assigned Numbers [Authority]*, Network
Information Centers (NICs), Contractors, and
Activities.: 1996 at. http://www.wia.org/pub/iana.html.
We thank
Craig McTaggart, a graduate student of the Faculty
of Law, University of Toronto, for questioning the
attribution on August 22, 1999, which sent us back
to the source.
|
|
-
-
|
WHAT'S INSIDE?
CONTENTS
TABLES
FIGURES
CD-ROM
CHECK
OUR BOOKLIST FOR OTHER
INTERNET BOOKS ON THE DOMAIN NAME SYSTEM AND ISSUES
IN CYBERSPACE.
|
|