* "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and the case carefully weighed before choosing
a different course.
* "MAY"
This word or the adjective "OPTIONAL" means that this item
is truly optional. One vendor may choose to include the
item because a particular marketplace requires it or
because it enhances the product, for example; another
vendor may omit the same item.
An implementation is not compliant if it fails to satisfy one
or more of the MUST requirements for the protocols it
implements. An implementation that satisfies all the MUST and
all the SHOULD requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the MUST
requirements but not all the SHOULD requirements for its
protocols is said to be "conditionally compliant".
1.3.3 Terminology
This document uses the following technical terms:
Segment
A segment is the unit of end-to-end transmission in the
TCP protocol. A segment consists of a TCP header followed
by application data. A segment is transmitted by
encapsulation in an IP datagram.
Message
This term is used by some application layer protocols
(particularly SMTP) for an application data unit.
Datagram
A [UDP] datagram is the unit of end-to-end transmission in
the UDP protocol.
RFC1123 INTRODUCTION October 1989
Multihomed
A host is said to be multihomed if it has multiple IP
addresses to connected networks.
1.4 Acknowledgments
This document incorporates contributions and comments from a large
group of Internet protocol experts, including representatives of
university and research labs, vendors, and government agencies.
It was assembled primarily by the Host Requirements Working Group
of the Internet Engineering Task Force (IETF).
The Editor would especially like to acknowledge the tireless
dedication of the following people, who attended many long
meetings and generated 3 million bytes of electronic mail over the
past 18 months in pursuit of this document: Philip Almquist, Dave
Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
(BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
In addition, the following people made major contributions to the
effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
(BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
(DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
Technology), and Mike StJohns (DCA). The following also made
significant contributions to particular areas: Eric Allman
(Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
(Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
(IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
(Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
(Toronto).
We are grateful to all, including any contributors who may have
been inadvertently omitted from this list.
=7= |