As per Relevance of the word perspective, we have this rfc below:
Network Working Group R.
Request for Comments: 1127
October 1989
A Perspective on the Host Requirements
Status of This
This RFC is for information only; it does not constitute a standard
draft standard, or proposed standard, and it does not define
protocol. Distribution of this memo is unlimited
This RFC contains an informal summary of the discussions
conclusions of the IETF Working Group on Host Requirements while
was preparing the Host Requirements RFCs. This summary has
purposes: (1) to inform the community of host protocol issues
need further work; (2) to preserve some history and context as
starting point for future revision efforts; and (3) to provide
insight into the results of the Host Requirements effort
1.
A working group of the Internet Engineering Task Force (IETF)
recently completed and published a monumental standards document
software requirements for Internet hosts [RFC-1122, RFC-1123].
document has been published as two RFC's: "Requirements for
Hosts -- Communication Layers", referred to here as "HR-CL",
"Requirements for Internet Hosts -- Application and Support",
referred to here as "HR-AS". Together, we refer to them as the
Requirements RFCs, or "HR RFCs".
Creation of the Host Requirements document required the
efforts of about 20 Internet experts, with significant
from another 20. The Host Requirements working group held 7
meetings over the past 20 months, and exchanged about 3 megabytes
electronic mail. The HR RFCs went through approximate 20
drafts
This group of people struggled with a broad range of issues in
implementations of the Internet protocols, attempting to
theoretical and architectural concerns with the sometimes
imperatives of the real world. The present RFC recaps the results
this struggle, with the issues that were settled and those
remain for future work. This exegesis has several goals
Braden [Page 1]
RFC 1127 Perspective on Host Requirements October 1989
(1) to give the Internet technical community some insight into
results of the host requirements effort
(2) to inform the community of areas that need further work;
(3) to preserve some history and context of the effort as a
point for a future revision
1.1 GOALS OF THE HOST REQUIREMENTS
The basic purpose of the Host Requirements RFCs is to define
requirements for Internet host software. However, the document
far beyond a simple prescription of requirements, to include
(a) a bibliography of the documents essential to an implementor
(b) corrections and updates to the original standards RFC's
(c) material to fill gaps in the previous specifications
(d) limitations on implementation choices, where appropriate
(e) clarification of important issues and the intent of
protocols;
(f) documentation of known solutions to recurring problems as
as implementation hints
Broadly speaking, the Host Requirements working group started
the following goals for Internet host software
(1)
(2)
(3)
(4)
(5) Architectural
Of these, interoperability was clearly preeminent,
architectural purity had the lowest priority. It is more
to assign relative importance to extensibility, functionality,
efficiency, as it varied from one topic to another
At a more technical level, the working group pursued a set of
goals that included the following
Braden [Page 2]
RFC 1127 Perspective on Host Requirements October 1989
* Discourage hosts from unexpectedly acting as gateways
* Discourage the use of bad IP addresses
* Eliminate broadcast storms
* Discourage gratuitous Address Mask Reply messages
* Facilitate the use IP Type-of-Service for routing and queueing
* Encourage implementations of IP multicasting
* Encourage TCP connection robustness
* Encourage (mandate!) implementation of known TCP
enhancements
* Encourage user interfaces that support the full capabilities
the protocols
* Encourage more complete implementations of FTP
* Encourage robust mail
* Discourage the source-routing of mail in the Internet
* Encourage error logging
In addition to these general technical goals, the working
decided to discourage the use of certain protocol features: e.g.,
IP Stream Id option, ICMP Information Request and Reply messages,
RFC-795 TOS mappings, WKS records in the Domain Name System, and
Page structure
The HR RFC tries to deal only with the software implementation,
with the way in which that software is configured and applied.
are a number of requirements on Internet hosts that were omitted
the HR RFC as administrative or configuration issues
The HR RFCs contain many, many detailed requirements
clarifications that are straightforward and (almost) non
controversial
Indeed, many of these are simply restatements or reinforcement
requirements that are already explicit or implicit in the
standards RFC's. Some more cynical members of the working
refer to these as "Read The Manual" provisions. However, they
included in the HR RFCs because at least one implementation
Braden [Page 3]
RFC 1127 Perspective on Host Requirements October 1989
failed to abide by these requirements. In addition, many
of the HR RFCs are simply applications of Jon Postel's
Principle [1.2.2 in either RFC].
However, not all issues were so easy; the working group
with a number of deep and controversial technical issues. Where
result was a reasonable consensus, then definite,
recommendations and requirements resulted. We list these
issues in Section 2. Section 2 also lists a number of areas
the HR RFCs fill gaping holes in the current specifications by
extended discussions of particular issues
However, in some other cases the working group was unable to reach
crisp decision or even a reasonable consensus; we list these
issues in Section 3. Future discussion is needed to ascertain
of these issues really do have "right answers", and which
reasonably be left as implementation choices. Section 4
some other areas that the working group did not tackle but which
further work outside the context of the HR RFCs (although the
may be reflected in a future revision). Finally, Appendix I
specific issues for consideration by a future HR RFC revision effort
while Appendix II lists the issues that are relevant to a revision
the Gateway Requirements RFC
It should be noted that this categorization of issues is imperfect;
few issues appear (legitimately) in more than one category
For brevity, we do not attempt to define all the terminology
explain all the concepts mentioned here. For those cases
further clarification is needed, we include (in square brackets
references to the corresponding sections of the HR RFCs
2. SETTLED
Here are the areas in which the Host Requirements working group
able to reach a consensus and take a definite stand
- ARP Cache Management [CL 2.3.2.1]
Require a mechanism to flush out-of-date ARP cache entries
- Queueing packets in ARP [CL 2.3.2.2]
Recommend that ARP queue unresolved packet(s) in the link layer
- Ethernet/802.3 Interoperability [CL 2.3.3]
Impose interoperability requirements for Ethernet and IEEE 802.3
Braden [Page 4]
RFC 1127 Perspective on Host Requirements October 1989
encapsulation
- Broadcast Storms [CL 2.4, 3.2.2]
Require many provisions to prevent broadcast storms
In particular, require that the link-layer driver pass a flag
the IP layer to indicate if a packet was received via a link
layer broadcast, and require that this flag be used by the
layer
- Bad IP
Include numerous provisions to discourage the use of bad
addresses
- Address Mask Replies [CL 3.2.2.9]
Discourage gratuitous ICMP Address Mask Reply messages
- Type-of-
Include various requirements on IP, transport, and
layers to make Type-of-Service (TOS) useful
- Time-to-Live [CL 3.2.1.7]
Require that Time-to-Live (TTL) be configurable
- Source Routing [CL 3.2.1.8(e)]
Require that host be able to act as originator or
destination of a source route
- IP Multicasting [CL 3.3.7]
Encourage implementation of local IP multicasting
- Reassembly Timeout [CL 3.3.2]
Require a fixed reassembly timeout
- Choosing a Source Address [CL 3.3.4.3, 3.4, 4.1.3.5, 4.2.3.7]
Require that an application on a multihomed host be able
either specify which local IP address to use for a new
connection or UDP request, or else leave the local
"wild" and let the IP layer pick one
Braden [Page 5]
RFC 1127 Perspective on Host Requirements October 1989
- TCP Performance [CL 4.2.12.15, 4.2.3.1-4]
Require TCP performance improvements
- TCP Connection Robustness [CL 4.2.3.5, 4.2.3.9]
Encourage robustness of TCP connections
- TCP Window Shrinking [CL 4.2.2.16]
Discourage the shrinking of TCP windows from the right
- Dotted-Decimal Host Numbers [AS 2.1]
Recommend that applications be able to accept dotted-
host numbers in place of host names
- Telnet End-of-Line [AS 3.3.1]
Include compatibility requirements for Telnet end-of-line
- Minimal FTP [AS 4.1.2.13]
Enlarge the minimum FTP implementation
- Robust Mail Delivery [AS 5.3.2, 5.3.4, 6.1.3.4]
Recommend the use of long timeouts and of alternative
for multihomed hosts, to obtain robust mail delivery
- Source-Routing of Mail [AS 5.2.6, 5.2.16, 5.2.19]
Discourage the use of source routes for delivering mail. (
was one of the few cases where the working group opted for
architecturally pure resolution of an issue.)
- Fully-Qualified Domain Names [AS 5.2.18]
Require the use of fully-qualified domain names in RFC-822
addresses
- Domain Name System Required [AS 6.1.1]
Require that hosts implement the Domain Name System (DNS).
- WKS Records Detracted [AS 2.2, 5.2.12, 6.1.3.6]
Recommend against using WKS records from DNS
Braden [Page 6]
RFC 1127 Perspective on Host Requirements October 1989
- UDP Preferred for DNS Queries [AS 6.1.2.4, 6.1.3.2]
Require that UDP be preferred over TCP for DNS queries
- DNS Negative Caching [AS 6.1.3.3]
Recommend that DNS name servers and resolvers cache
responses and temporary failures
Finally, here is a list of areas in which the HR RFCs
extended discussion of issues that have been inadequately
in the past
- ARP cache handling [CL 2.3.2.1]
- Trailer encapsulation [CL 2.3.1]
- Dead gateway detection algorithms [CL 3.3.1.4]
- IP multihoming models [CL 3.3.4]
(Note that this topic is also one of the significant
issues; see the next section.)
- Maximum transmission unit (MTU and transport-layer maximum
segment size (MSS) issues [CL 3.3.2, 3.3.3, 3.4, 4.1.4,
4.2.2.6]
- TCP silly-window syndrome (SWS) avoidance
[CL 4.2.3.3, 4.2.3.4]
- Telnet end-of-line issues [AS 3.3.1]
- Telnet interrupt/SYNCH usage [AS 3.2.4]
- FTP restart facility [AS 4.1.3.4]
- DNS efficiency issues [AS 6.1.3.3]
- DNS user interface: aliases and search lists [AS 6.1.4.3]
There are some other areas where the working group tried to produce
more extended discussion but was not totally successful; one
is error logging (see Appendix I below).
Braden [Page 7]
RFC 1127 Perspective on Host Requirements October 1989
3. OPEN
For some issues, the disagreement was so serious that the
group was unable to reach a consensus. In each case, some spoke
MUST or SHOULD, while others spoke with equal fervor for MUST NOT
SHOULD NOT. As a result, the HR RFCs try to summarize the
viewpoints but take no stand; the corresponding requirements
given as MAY or OPTIONAL. The most notorious of these
issues are as follows
- Hosts forwarding source-routed datagrams, even though the
are not otherwise acting as gateways [CL 3.3.5]
- The multihoming model [CL 3.3.4]
- ICMP Echo Requests to a broadcast or multicast
[CL 3.2.2.6]
- Host-only route caching [CL 3.3.1.3]
- Host wiretapping routing protocols [CL 3.3.1.4]
- TCP sending an ACK when it receives a segment that appears to
out-of-order [CL 4.2.2.21]
There was another set of controversial issues for which the HR
did take a compromise stand, to allow the disputed functions
circumscribe their use. In many of these cases, there were one
more significant voices for banning the feature altogether
- Host acting as gateways [CL 3.1]
- Trailer encapsulation [CL 2.3.1]
- Delayed TCP acknowledgments [CL 4.2.3.2]
- TCP Keep-alives [CL 4.2.3.6]
- Ignoring UDP checksums [CL 4.1.3.4]
- Telnet Go-Aheads [AS 3.2.2]
- Allowing 8-bit data in Telnet NVT mode [AS 3.2.5]
Braden [Page 8]
RFC 1127 Perspective on Host Requirements October 1989
4. OTHER FUTURE
General Issues
(1) Host Initialization
When a host system boots or otherwise initializes, it
certain network configuration information in order to communicate
e.g., its own IP address(es) and address mask(s). In the case
a diskless workstation, obtaining this information is an
part of the booting process
The ICMP Address Mask messages and the RARP (Reverse ARP)
each provide individual pieces of configuration information.
working group felt that such piecemeal solutions are a mistake
and that a comprehensive approach to initialization would
in a uniform mechanism to provide all the required
information at once. The HR working group recommends that a
working group be established to develop a unified approach
system initialization
(2) Configuration
Vendors, users, and network administrators all want host
that is "plug-and-play". Unfortunately, the working group
often forced to require additional configuration parameters
satisfy interoperability, functionality, and/or efficiency
[1.2.4 in either RFC]. The working group was fully aware of
drawbacks of configuration parameters, but based upon
experience with existing implementations, it felt that
flexibility was sometimes more important than
simplicity
Some of the configuration parameters are forced
interoperability with earlier, incorrect implementations.
little can be done to ease this problem, although retirement
the offending systems will gradually solve it. However, it
be desirable to re-examine the other required
options, in an attempt to develop ways to eliminate some of them
Link-Layer Issues
(2) ARP Cache
"Proxy ARP" is a link-layer mechanism for IP routing, and its
results in difficult problems in managing the ARP cache
Even without proxy ARP, the management dynamics of the IP
Braden [Page 9]
RFC 1127 Perspective on Host Requirements October 1989
cache interact in subtle ways with transport-layer dynamics
introducing routing via proxy ARP brings a third protocol
into the problem, complicating the inter-layer dynamics
further
The algorithms for maintaining the ARP cache need to be
and experimented with, to create more complete and
algorithms and requirements
(3) FDDI Bit-order in MAC
On IEEE 802.3 or 802.4 LAN, the MAC address in the header uses
same bit-ordering as transmission of the address as data.
802.5 and FDDI networks, however, the MAC address in the header
in a different bit-ordering from the equivalent 6 bytes sent
data. This will make it hard to do MAC-level bridging
FDDI and 802.3 LAN's, for example, although gateways (IP routers
can still be used
The working group concluded that this is a serious but
problem with no obvious fix, and that resolving it was beyond
scope of the HR working group
IP-Layer
(4) Dead Gateway
A fundamental requirement for a host is to be able to detect
the first-hop gateway has failed. The early TCP/
experimentation was based on the ARPANET, which provided
notification of gateway failure; as a result, dead
detection algorithms were not much considered at that time.
very general guidelines presented by Dave Clark [RFC-816]
inadequate for implementors. The first attempt at applying
guidelines was the introduction of universal gateway pinging
TOPS-20 systems; this quickly proved to be a major generator
ARPANET traffic, and was squelched. The most widely
implementation of the Internet protocols, 4.2BSD, solved
problem in an extra-architectural manner, by letting the
wiretap the gateway routing protocol (RIP). As a result of
history, the HR working group was faced with an absence
documentated techniques that a host conforming to the
architecture could use to detect dead gateways
After extensive discussion, the working group agreed on
outline of an appropriate algorithm. A detailed algorithm was
fact written down, to validate the discussion in the HR RFCs
This algorithm, or a better one, should be tried
Braden [Page 10]
RFC 1127 Perspective on Host Requirements October 1989
and documented in a new RFC
(5) Gateway
A host needs to discover the IP addresses of gateways on
connected networks. One approach, begun but not finished
members of the HR working group, would be to define a new pair
ICMP query messages for gateway discovery. In the future,
discovery should be considered as part of the complete
initialization problem
(6) MTU
Members of the HR working group designed IP options that a
could use to discover the minimum MTU of a particular
path [RFC-1063]. To be useful, the Probe MTU options would
to be implemented in all gateways, which is an obstacle to
adoption. Code written to use these options has never
tested. This work should be carried forward; an effective
choice will become increasingly important for efficient
service
(7) Routing Advice from
A working group member produced a draft specification for
messages a host could use to ask gateways for routing
[Lekashman]. While this is not of such pressing importance as
issues listed previously, it deserves further consideration
perhaps experimentation
(8) Dynamic TTL
Serious connectivity problems have resulted from host
that has too small a TTL value built into the code. HR-
specifies that TTL values must be configurable, to allow TTL to
increased if required for communication in a future Internet
conformance with this requirement would solve the
problems. However, configurable parameters are an
headache, so it has been suggested that a host could have
algorithm to determine the TTL ("Internet diameter") dynamically
Several algorithms have been suggested, but considerably more
would be required to validate them. This is a lower-
problem than issues (4)-(6).
(9) Dynamic Discovery of Reassembly Timeout
The maximum time for retaining a partially-reassembled datagram
another parameter that creates a potential operational headache
Braden [Page 11]
RFC 1127 Perspective on Host Requirements October 1989
An appropriate reassembly timeout value must balance
reassembly buffer space against reliable reassembly. The
value thus may depend upon the system and upon subtle
properties (delay dispersion) of the Internet. Again,
discovery could be desirable
(10) Type-of-Service Routing in
As pointed out previously, the HR RFCs contain a number
provisions designed to make Type-of-Service (TOS) useful.
includes the suggestion that the route cache should have a
or specifying the TOS of a particular route. However,
algorithms for using TOS specifications need to be developed
documented
(11) Using
An RFC is needed to provide a thorough explanation of
implications of subnetting for Internet protocols and for
administration
Transport-Layer Issues
(12) RST
It has been proposed that TCP RST (Reset) segments can
text to provide an explicit explanation of the reason for
particular RST. A proposal has been drafted [CLynn].
(13) Performance
HR-CL contains a number of requirements on TCP
algorithms; Van Jacobson's slow start and congestion avoidance
Karn's algorithm, Nagle's algorithm, and SWS prevention at
sender and receiver. Implementors of new TCPs really need
guidance than could possibly be included in the HR RFCs.
working group suggested that an RFC on TCP performance is needed
to describe each of these issues more deeply and especially
explain how they fit together
Another issue raised by the HR RFCs is the need for validation (
rejection) of Van Jacobson's fast retransmit algorithm
Application-Layer Issues
(14) Proposed FTP
A number of minor extensions proposed for FTP should be
Braden [Page 12]
RFC 1127 Perspective on Host Requirements October 1989
and accepted or rejected. We are aware of the
proposals
(a) Atomic Store
The FTP specification leaves undefined the disposition of
partial file created when an FTP session fails during a
operation. It was suggested that this ambiguity could
resolved by defining a new store command, Store Atomic (STOA).
The receiver would delete the partial file if the
failed before the final data-complete reply had been sent
This assumes the use of a transfer mode (e.g., block) in
end-of-file can be distinguished from TCP connection failure
of course
(b) NDIR
"NDIR would be a directories-only analogue to the NLST command
Upon receiving an NDIR command an FTP server would return
list of the subdirectories to the specified directory or
group; or of the current directory if no argument was sent
... The existing NLST command allows user FTPs to
user-interface niceties such as a "multiple get" command.
also allows a selective (as opposed to generative) file-
user interface: the user can pick the desired file out of
list instead of typing its name." [Matthews
However, the interface needs to distinguish files
directories. Up to now, such interfaces have relied on a
in many FTP servers, which have included directory names in
list returned by NLST. As hosts come into conformance
HR-AS, we need an NDIR command to return directory names
(c) Adaptive
It has been suggested that a sophisticated adaptive
compression algorithm, like that provided by the
"compress" command, should be added as an alternative
transfer mode
(15) SMTP: Global Mail
While writing requirements for electronic mail, the working
was urged to set rules for SMTP and RFC-822 that would
universal, applicable not only to the Internet environment
also to the other mail environments that use one or both of
protocols. The working group chose to ignore this Siren call,
instead limit the HR RFC to requirements specific to the Internet
Braden [Page 13]
RFC 1127 Perspective on Host Requirements October 1989
However, the networking world would certainly benefit from
global agreements on mail routing. Strong passions are
here
(16) DNS: Fully Replacing hosts.
As noted in HR-AS [AS 6.1.3.8], the DNS does not yet
all the potentially-useful information included in the DDN NIC'
hosts.txt file. The DNS should be expanded to cover the hosts.
information. RFC-1101 [RFC-1101] is a step in the
direction, but more work is needed
5.
We have summarized the results of the Host Requirements
Group, and listed a set of issues in Internet host protocols
need future effort
6.
[RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts --
Communications Layers", RFC 1122, IETF Host Requirements
Group, October 1989.
[RFC-1123] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, IETF Host Requirements
Group, October 1989.
[RFC-1009] Braden, R., and J. Postel, "Requirements for
Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.
[RFC-1101] Mockapetris, P., "DNS Encoding of Network Names and
Types", RFC 1101, USC/Information Sciences Institute, April 1989.
[RFC-1063] Mogul, J., C. Kent, C. Partridge, and K. McCloghrie, "
MTU Discovery Options", RFC-1063, DEC, BBN, & TWG, July 1988.
[RFC-816] Clark, D., "Fault Isolation and Recovery", RFC-816, MIT
July 1982.
[CLynn] Lynn, C., "Use of TCP Reset to Convey Error Diagnostics",
Internal Memo, BBN, December 1988.
[Lekashman] Message to ietf-hosts mailing list from John Lekashman
14 September 1988.
[Matthews] Message to Postel from Jim Matthews, 3 August 1989.
Braden [Page 14]
RFC 1127 Perspective on Host Requirements October 1989
APPENDIX I -- ISSUES FOR FUTURE
In order to complete the HR RFCs, it was necessary to defer
technical issues. These issues should be considered by the
responsible for the first update of the HR RFCs
The issues pending at the time of publication are listed here,
order by protocol layer
General Issue
Error
The working group felt that more complete and explicit guidance
error logging procedures is needed than is presently contained
Section 1.2.3 (both HR RFCs).
Link Layer Issues
- Stolen IP
How should a host react when it detects through ARP traffic
some other host has "stolen" its IP address
IP Layer Issues
- "Raw Mode"
HR-CL could define an optional "raw mode" interface from
application layer to IP
- Rational
When a host performs intentional fragmentation, it should make
first fragment as large as possible (this same requirement
be placed on gateways).
- Interaction of Multiple
HR-CL does not give specific rules for the interactions
multiple options in the same IP header; this issue was
deferred to a revision of the Gateway Requirements RFC. However
this issue might be revisited for hosts
- ICMP Error for Source-Routed
It was suggested that when a source-routed packet arrives with
error, any ICMP error message should be sent with
Braden [Page 15]
RFC 1127 Perspective on Host Requirements October 1989
corresponding return route. This assumes that the ICMP
message is more likely to be delivered successfully with
source route than without it
- "Strong" IP Options and ICMP
The HR RFCs takes the general approach that a host should
whatever it does not understand, so that possible
extensions -- e.g., new IP options or new ICMP message types --
will cause minimum problems for existing hosts. The result
this approach is that when new facilities are used with old hosts
a "black hole" can result. Several people have suggested
this is not always what is wanted; it may sometimes be more
to obtain an ICMP error message from the old host. To
Jeremey Siegel
"The basic premise is that if an option is to have any
meaning at all within an '[upward] compatible' environment,
must be known whether or not the option actually *carries*
meaning. An absurd analogy might be programming languages:
could make a compiler which simply ignored unknown sorts
statements, thereby allowing for future expansion of
language
Right now, there are four "classes" of options; only two
defined. Take one of the other classes, and define it
that any options in that class, if unrecognized, cause an
error message. Thus anyone who wants to propose a "strong
option (one which requires full participation by all
involved to operate correctly) can assign it to that class
Options in the current classes may still be passed through
they are unknown; only "weak" options will be assigned to
classes in the future."
- Network
As explained in HR-CL [CL 3.1.2.3], we believe that a
future transition for the interpretation of IP addresses may
eased if hosts always treat an IP address as an indivisible 32-
bit number. However, there are various circumstances where a
has to distinguish its own network number. Charlie Lynn
suggested that indivisibility can be retained if a host
configured with both an address mask (indicating subnetting) and
network mask (with network but not subnet bits).
- WhoAmI
The following requirement is needed: for a multihomed host,
Braden [Page 16]
RFC 1127 Perspective on Host Requirements October 1989
UDP-based application should (must?) be able to query
communication layers to obtain a list of all local IP
for the host
- New Destination Unreachable
For each of the new ICMP Destination Unreachable codes defined
HR-CL [CL 3.2.2.1], it should be documented whether the error
"soft" or "hard".
- ICMP Error
Section 3.3.8 of HR-CL requires a host to send ICMP
messages, yet in nearly all individual cases the
requirements say that errors are to be silently ignored.
working group recognized this contradiction but was unwilling
resolve it
At every choice point, the working group opted towards
requirement that would avoid broadcast storms. For example, (1)
ICMP errors cannot be sent for broadcasts, and also (2)
errors are to be silently ignored. This is redundant;
provision (1) or (2) alone, if followed, should
broadcast storms. The general area of responses to errors
broadcast storms could be reassessed and the individual
reviewed
Transport-Layer Requirements
- Delayed ACK
A more precise and complete definition of the conditions
delaying a TCP ACK segment may be desirable; see Section 4.2.3.2
of HR-CL
Telnet Requirements
- Flushing
The DISCUSSION in Section 3.2.4 of HR-AS concerns three
ways for a User Telnet to flush output. It would be helpful
users and implementers if one of these could be recommended
the others; however, when the working group discussed the matter
there seemed to be compelling arguments for each choice.
issue needs more study
Braden [Page 17]
RFC 1127 Perspective on Host Requirements October 1989
- Telnet LineMode
This important new option is still experimental, but when
becomes a standard, implementation should become recommended
required
FTP Requirements
- Reply
A number of problems have been raised with FTP reply codes
(a) Access Control
Note that a 550 message is used to indicate access
problems for a read-type operation (e.g., RETR, RNFR), while a 553
message is used for the same purpose for a write-type
(e.g., STOR, STOU, RNTO).
LIST, NLST, and STAT may fail with a 550 reply due to an
control violation
MKD should fail with a 553 reply if a directory already
with the same name
(b) Directory Operations (RFC-959 Appendix II
An RMD may result in a 450 reply if the directory is busy
Many of the reply codes shown in the text of Appendix II
wrong. A positive completion for CWD should be 250. The 521
shown for MKD should be 553 (see above), while the 431 shown
CWD should be a 550.
(c) HELP and SITE
The positive completion reply to a HELP command should be
214.
HELP or SITE with an invalid argument should return a 504 reply
- Bidirectional
The FTP specification allows an implementation in which
transfer takes place in both directions simultaneously,
few if any implementations support this. Perhaps HR-AS
take a stand for or against this
Braden [Page 18]
RFC 1127 Perspective on Host Requirements October 1989
SMTP Requirements
- Offline
Some on the working group felt that the SMTP SEND command
intended to display a message immediately on the recipient'
terminal, should produce an error message if delivery must
deferred
- Header-like
John Klensin proposed
"Header-like fields whose keywords do not conform to RFC822
strongly discouraged; gateways SHOULD filter them out or
them into the message body. If, however, they are not removed
Internet hosts not acting as gateways SHOULD NOT utilize
inspect them. Hence address-like subfields of those fields
NOT be altered by the gateway."
- Syntax of Received:
The precise syntax of a revised Received: line (see Section 5.2.8
of HR-AS) could be given. An unresolved question concerned
use of "localhost" rather than a fully-qualified domain name
the FROM field of a Received: line. Finally, new syntax
proposed for the Message Id field
Appendix II -- Gateway
The working group identified a set of issues that should
considered when the Gateway Requirements RFC [RFC-1009] ("GR RFC")
revised
- All-Subnets
This facility is not currently widely implemented, and HR-CL
users of this fact. The GR RFC should take a stand on whether
not gateways ought to implement the necessary routing
- Rational
When a gateway performs intentional fragmentation, it should
the first fragment as large as possible
- Illegal Source
It has been suggested that a gateway should not forward a
Braden [Page 19]
RFC 1127 Perspective on Host Requirements October 1989
containing an illegal IP source address, e.g., zero
- Option
Specific rules should be given for the order of
multiple options in the same IP header. Two approaches have
used: to process options in the order presented, or to parse
all and then process them in some "canonical" order
The legality should also be defined for using broadcast
multicast addresses in IP options that include IP addresses
Security
A future revision of the Host Requirements RFCs should incorporate
more complete discussion of security issues at all layers
Author's
Robert
USC/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292-6695
Phone: (213) 822 1511
EMail: Braden@ISI.
Braden [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
