diff options
Diffstat (limited to 'usr.sbin/sendmail/doc/rfc/rfc819.txt')
| -rw-r--r-- | usr.sbin/sendmail/doc/rfc/rfc819.txt | 1044 |
1 files changed, 1044 insertions, 0 deletions
diff --git a/usr.sbin/sendmail/doc/rfc/rfc819.txt b/usr.sbin/sendmail/doc/rfc/rfc819.txt new file mode 100644 index 0000000..d66f8d9 --- /dev/null +++ b/usr.sbin/sendmail/doc/rfc/rfc819.txt @@ -0,0 +1,1044 @@ + + +Network Working Group Zaw-Sing Su (SRI) +Request for Comments: 819 Jon Postel (ISI) + August 1982 + + + + The Domain Naming Convention for Internet User Applications + + + + +1. Introduction + + For many years, the naming convention "<user>@<host>" has served the + ARPANET user community for its mail system, and the substring + "<host>" has been used for other applications such as file transfer + (FTP) and terminal access (Telnet). With the advent of network + interconnection, this naming convention needs to be generalized to + accommodate internetworking. A decision has recently been reached to + replace the simple name field, "<host>", by a composite name field, + "<domain>" [2]. This note is an attempt to clarify this generalized + naming convention, the Internet Naming Convention, and to explore the + implications of its adoption for Internet name service and user + applications. + + The following example illustrates the changes in naming convention: + + ARPANET Convention: Fred@ISIF + Internet Convention: Fred@F.ISI.ARPA + + The intent is that the Internet names be used to form a + tree-structured administrative dependent, rather than a strictly + topology dependent, hierarchy. The left-to-right string of name + components proceeds from the most specific to the most general, that + is, the root of the tree, the administrative universe, is on the + right. + + The name service for realizing the Internet naming convention is + assumed to be application independent. It is not a part of any + particular application, but rather an independent name service serves + different user applications. + +2. The Structural Model + + The Internet naming convention is based on the domain concept. The + name of a domain consists of a concatenation of one or more <simple + names>. A domain can be considered as a region of jurisdiction for + name assignment and of responsibility for name-to-address + translation. The set of domains forms a hierarchy. + + Using a graph theory representation, this hierarchy may be modeled as + a directed graph. A directed graph consists of a set of nodes and a + + +Su & Postel [Page 1] + + + +RFC 819 August 1982; + + + collection of arcs, where arcs are identified by ordered pairs of + distinct nodes [1]. Each node of the graph represents a domain. An + ordered pair (B, A), an arc from B to A, indicates that B is a + subdomain of domain A, and B is a simple name unique within A. We + will refer to B as a child of A, and A a parent of B. The directed + graph that best describes the naming hierarchy is called an + "in-tree", which is a rooted tree with all arcs directed towards the + root (Figure 1). The root of the tree represents the naming universe, + ancestor of all domains. Endpoints (or leaves) of the tree are the + lowest-level domains. + + U + / | \ + / | \ U -- Naming Universe + ^ ^ ^ I -- Intermediate Domain + | | | E -- Endpoint Domain + I E I + / \ | + ^ ^ ^ + | | | + E E I + / | \ + ^ ^ ^ + | | | + E E E + + Figure 1 + The In-Tree Model for Domain Hierarchy + + The simple name of a child in this model is necessarily unique within + its parent domain. Since the simple name of the child's parent is + unique within the child's grandparent domain, the child can be + uniquely named in its grandparent domain by the concatenation of its + simple name followed by its parent's simple name. + + For example, if the simple name of a child is "C1" then no other + child of the same parent may be named "C1". Further, if the + parent of this child is named "P1", then "P1" is a unique simple + name in the child's grandparent domain. Thus, the concatenation + C1.P1 is unique in C1's grandparent domain. + + Similarly, each element of the hierarchy is uniquely named in the + universe by its complete name, the concatenation of its simple name + and those for the domains along the trail leading to the naming + universe. + + The hierarchical structure of the Internet naming convention supports + decentralization of naming authority and distribution of name service + capability. We assume a naming authority and a name server + + +Su & Postel [Page 2] + + + +RFC 819 August 1982; + + + associated with each domain. In Sections 5 and 6 respectively the + name service and the naming authority are discussed. + + Within an endpoint domain, unique names are assigned to <user> + representing user mailboxes. User mailboxes may be viewed as + children of their respective domains. + + In reality, anomalies may exist violating the in-tree model of naming + hierarchy. Overlapping domains imply multiple parentage, i.e., an + entity of the naming hierarchy being a child of more than one domain. + It is conceivable that ISI can be a member of the ARPA domain as well + as a member of the USC domain (Figure 2). Such a relation + constitutes an anomaly to the rule of one-connectivity between any + two points of a tree. The common child and the sub-tree below it + become descendants of both parent domains. + + U + / | \ + / . \ + . . ARPA + . . | \ + USC | \ + \ | . + \ | . + ISI + + Figure 2 + Anomaly in the In-Tree Model + + Some issues resulting from multiple parentage are addressed in + Appendix B. The general implications of multiple parentage are a + subject for further investigation. + +3. Advantage of Absolute Naming + + Absolute naming implies that the (complete) names are assigned with + respect to a universal reference point. The advantage of absolute + naming is that a name thus assigned can be universally interpreted + with respect to the universal reference point. The Internet naming + convention provides absolute naming with the naming universe as its + universal reference point. + + For relative naming, an entity is named depending upon the position + of the naming entity relative to that of the named entity. A set of + hosts running the "unix" operating system exchange mail using a + method called "uucp". The naming convention employed by uucp is an + example of relative naming. The mail recipient is typically named by + a source route identifying a chain of locally known hosts linking the + + + +Su & Postel [Page 3] + + + +RFC 819 August 1982; + + + sender's host to the recipient's. A destination name can be, for + example, + + "alpha!beta!gamma!john", + + where "alpha" is presumably known to the originating host, "beta" is + known to "alpha", and so on. + + The uucp mail system has demonstrated many of the problems inherent + to relative naming. When the host names are only locally + interpretable, routing optimization becomes impossible. A reply + message may have to traverse the reverse route to the original sender + in order to be forwarded to other parties. + + Furthermore, if a message is forwarded by one of the original + recipients or passed on as the text of another message, the frame of + reference of the relative source route can be completely lost. Such + relative naming schemes have severe problems for many of the uses + that we depend upon in the ARPA Internet community. + +4. Interoperability + + To allow interoperation with a different naming convention, the names + assigned by a foreign naming convention need to be accommodated. + Given the autonomous nature of domains, a foreign naming environment + may be incorporated as a domain anywhere in the hierarchy. Within + the naming universe, the name service for a domain is provided within + that domain. Thus, a foreign naming convention can be independent of + the Internet naming convention. What is implied here is that no + standard convention for naming needs to be imposed to allow + interoperations among heterogeneous naming environments. + + For example: + + There might be a naming convention, say, in the FOO world, + something like "<user>%<host>%<area>". Communications with an + entity in that environment can be achieved from the Internet + community by simply appending ".FOO" on the end of the name in + that foreign convention. + + John%ISI-Tops20-7%California.FOO + + Another example: + + One way of accommodating the "uucp world" described in the last + section is to declare it as a foreign system. Thus, a uucp + name + + "alpha!beta!gamma!john" + + +Su & Postel [Page 4] + + + +RFC 819 August 1982; + + + might be known in the Internet community as + + "alpha!beta!gamma!john.UUCP". + + Communicating with a complex subdomain is another case which can + be treated as interoperation. A complex subdomain is a domain + with complex internal naming structure presumably unknown to the + outside world (or the outside world does not care to be concerned + with its complexity). + + For the mail system application, the names embedded in the message + text are often used by the destination for such purpose as to reply + to the original message. Thus, the embedded names may need to be + converted for the benefit of the name server in the destination + environment. + + Conversion of names on the boundary between heterogeneous naming + environments is a complex subject. The following example illustrates + some of the involved issues. + + For example: + + A message is sent from the Internet community to the FOO + environment. It may bear the "From" and "To" fields as: + + From: Fred@F.ISI.ARPA + To: John%ISI-Tops20-7%California.FOO + + where "FOO" is a domain independent of the Internet naming + environment. The interface on the boundary of the two + environments may be represented by a software module. We may + assume this interface to be an entity of the Internet community + as well as an entity of the FOO community. For the benefit of + the FOO environment, the "From" and "To" fields need to be + modified upon the message's arrival at the boundary. One may + view naming as a separate layer of protocol, and treat + conversion as a protocol translation. The matter is + complicated when the message is sent to more than one + destination within different naming environments; or the + message is destined within an environment not sharing boundary + with the originating naming environment. + + While the general subject concerning conversion is beyond the scope + of this note, a few questions are raised in Appendix D. + + + + + + + +Su & Postel [Page 5] + + + +RFC 819 August 1982; + + +5. Name Service + + Name service is a network service providing name-to-address + translation. Such service may be achieved in a number of ways. For + a simple networking environment, it can be accomplished with a single + central database containing name-to-address correspondence for all + the pertinent network entities, such as hosts. + + In the case of the old ARPANET host names, a central database is + duplicated in each individual host. The originating module of an + application process would query the local name service (e.g., make a + system call) to obtain network address for the destination host. With + the proliferation of networks and an accelerating increase in the + number of hosts participating in networking, the ever growing size, + update frequency, and the dissemination of the central database makes + this approach unmanageable. + + The hierarchical structure of the Internet naming convention supports + decentralization of naming authority and distribution of name service + capability. It readily accommodates growth of the naming universe. + It allows an arbitrary number of hierarchical layers. The addition + of a new domain adds little complexity to an existing Internet + system. + + The name service at each domain is assumed to be provided by one or + more name servers. There are two models for how a name server + completes its work, these might be called "iterative" and + "recursive". + + For an iterative name server there may be two kinds of responses. + The first kind of response is a destination address. The second + kind of response is the address of another name server. If the + response is a destination address, then the query is satisfied. If + the response is the address of another name server, then the query + must be repeated using that name server, and so on until a + destination address is obtained. + + For a recursive name server there is only one kind of response -- + a destination address. This puts an obligation on the name server + to actually make the call on another name server if it can't + answer the query itself. + + It is noted that looping can be avoided since the names presented for + translation can only be of finite concatenation. However, care + should be taken in employing mechanisms such as a pointer to the next + simple name for resolution. + + We believe that some name servers will be recursive, but we don't + believe that all will be. This means that the caller must be + + +Su & Postel [Page 6] + + + +RFC 819 August 1982; + + + prepared for either type of server. Further discussion and examples + of name service is given in Appendix C. + + The basic name service at each domain is the translation of simple + names to addresses for all of its children. However, if only this + basic name service is provided, the use of complete (or fully + qualified) names would be required. Such requirement can be + unreasonable in practice. Thus, we propose the use of partial names + in the context in which their uniqueness is preserved. By + construction, naming uniqueness is preserved within the domain of a + common ancestry. Thus, a partially qualified name is constructed by + omitting from the complete name ancestors common to the communicating + parties. When a partially qualified name leaves its context of + uniqueness it must be additionally qualified. + + The use of partially qualified names places a requirement on the + Internet name service. To satisfy this requirement, the name service + at each domain must be capable of, in addition to the basic service, + resolving simple names for all of its ancestors (including itself) + and their children. In Appendix B, the required distinction among + simple names for such resolution is addressed. + +6. Naming Authority + + Associated with each domain there must be a naming authority to + assign simple names and ensure proper distinction among simple names. + + Note that if the use of partially qualified names is allowed in a + sub-domain, the uniqueness of simple names inside that sub-domain is + insufficient to avoid ambiguity with names outside the subdomain. + Appendix B discusses simple name assignment in a sub-domain that + would allow the use of partially qualified names without ambiguity. + + Administratively, associated with each domain there is a single + person (or office) called the registrar. The registrar of the naming + universe specifies the top-level set of domains and designates a + registrar for each of these domains. The registrar for any given + domain maintains the naming authority for that domain. + +7. Network-Oriented Applications + + For user applications such as file transfer and terminal access, the + remote host needs to be named. To be compatible with ARPANET naming + convention, a host can be treated as an endpoint domain. + + Many operating systems or programming language run-time environments + provide functions or calls (JSYSs, SVCs, UUOs, SYSs, etc.) for + standard services (e.g., time-of-day, account-of-logged-in-user, + convert-number-to-string). It is likely to be very helpful if such a + + +Su & Postel [Page 7] + + + +RFC 819 August 1982; + + + function or call is developed for translating a host name to an + address. Indeed, several systems on the ARPANET already have such + facilities for translating an ARPANET host name into an ARPANET + address based on internal tables. + + We recommend that this provision of a standard function or call for + translating names to addresses be extended to accept names of + Internet convention. This will promote a consistent interface to the + users of programs involving internetwork activities. The standard + facility for translating Internet names to Internet addresses should + include all the mechanisms available on the host, such as checking a + local table or cache of recently checked names, or consulting a name + server via the Internet. + +8. Mail Relaying + + Relaying is a feature adopted by more and more mail systems. + Relaying facilitates, among other things, interoperations between + heterogeneous mail systems. The term "relay" is used to describe the + situation where a message is routed via one or more intermediate + points between the sender and the recipient. The mail relays are + normally specified explicitly as relay points in the instructions for + message delivery. Usually, each of the intermediate relays assume + responsibility for the relayed message [3]. + + A point should be made on the basic difference between mail + relaying and the uucp naming system. The difference is that + although mail relaying with absolute naming can also be considered + as a form of source routing, the names of each intermediate points + and that of the destination are universally interpretable, while + the host names along a source route of the uucp convention is + relative and thus only locally interpretable. + + The Internet naming convention explicitly allows interoperations + among heterogeneous systems. This implies that the originator of a + communication may name a destination which resides in a foreign + system. The probability is that the destination network address may + not be comprehensible to the transport system of the originator. + Thus, an implicit relaying mechanism is called for at the boundary + between the domains. The function of this implicit relay is the same + as the explicit relay. + + + + + + + + + + +Su & Postel [Page 8] + + + +RFC 819 August 1982; + + +9. Implementation + + The Actual Domains + + The initial set of top-level names include: + + ARPA + + This represents the set of organizations involved in the + Internet system through the authority of the U.S. Defense + Advanced Research Projects Agency. This includes all the + research and development hosts on the ARPANET and hosts on + many other nets as well. But note very carefully that the + top-level domain "ARPA" does not map one-to-one with the + ARPANET -- domains are administrative, not topological. + + Transition + + In the transition from the ARPANET naming convention to the + Internet naming convention, a host name may be used as a simple + name for an endpoint domain. Thus, if "USC-ISIF" is an ARPANET + host name, then "USC-ISIF.ARPA" is the name of an Internet domain. + +10. Summary + + A hierarchical naming convention based on the domain concept has been + adopted by the Internet community. It is an absolute naming + convention defined along administrative rather than topological + boundaries. This naming convention is adaptive for interoperations + with other naming conventions. Thus, no standard convention needs to + be imposed for interoperations among heterogeneous naming + environments. + + This Internet naming convention allows distributed name service and + naming authority functions at each domain. We have specified these + functions required at each domain. Also discussed are implications + on network-oriented applications, mail systems, and administrative + aspects of this convention. + + + + + + + + + + + + + +Su & Postel [Page 9] + + + +RFC 819 August 1982; + + +APPENDIX A + + The BNF Specification + + We present here a rather detailed "BNF" definition of the allowed + form for a computer mail "mailbox" composed of a "local-part" and a + "domain" (separated by an at sign). Clearly, the domain can be used + separately in other network-oriented applications. + + <mailbox> ::= <local-part> "@" <domain> + + <local-part> ::= <string> | <quoted-string> + + <string> ::= <char> | <char> <string> + + <quoted-string> ::= """ <qtext> """ + + <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext> + + <char> ::= <c> | "\" <x> + + <domain> ::= <naming-domain> | <naming-domain> "." <domain> + + <naming-domain> ::= <simple-name> | <address> + + <simple-name> ::= <a> <ldh-str> <let-dig> + + <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> + + <let-dig> ::= <a> | <d> + + <let-dig-hyp> ::= <a> | <d> | "-" + + <address> :: = "#" <number> | "[" <dotnum> "]" + + <number> ::= <d> | <d> <number> + + <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> + + <snum> ::= one, two, or three digits representing a decimal integer + value in the range 0 through 255 + + <a> ::= any one of the 52 alphabetic characters A through Z in upper + case and a through z in lower case + + <c> ::= any one of the 128 ASCII characters except <s> or <SP> + + <d> ::= any one of the ten digits 0 through 9 + + + +Su & Postel [Page 10] + + + +RFC 819 August 1982; + + + <q> ::= any one of the 128 ASCII characters except CR, LF, quote ("), + or backslash (\) + + <x> ::= any one of the 128 ASCII characters (no exceptions) + + <s> ::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@", + """, and the control characters (ASCII codes 0 through 31 inclusive + and 127) + + Note that the backslash, "\", is a quote character, which is used to + indicate that the next character is to be used literally (instead of + its normal interpretation). For example, "Joe\,Smith" could be used + to indicate a single nine character user field with comma being the + fourth character of the field. + + The simple names that make up a domain may contain both upper and + lower case letters (as well as digits and hyphen), but these names + are not case sensitive. + + Hosts are generally known by names. Sometimes a host is not known to + the translation function and communication is blocked. To bypass + this barrier two forms of addresses are also allowed for host + "names". One form is a decimal integer prefixed by a pound sign, "#". + Another form, called "dotted decimal", is four small decimal integers + separated by dots and enclosed by brackets, e.g., "[123.255.37.2]", + which indicates a 32-bit ARPA Internet Address in four 8-bit fields. + (Of course, these numeric address forms are specific to the Internet, + other forms may have to be provided if this problem arises in other + transport systems.) + + + + + + + + + + + + + + + + + + + + + + +Su & Postel [Page 11] + + + +RFC 819 August 1982; + + +APPENDIX B + + An Aside on the Assignment of Simple Names + + In the following example, there are two naming hierarchies joining at + the naming universe 'U'. One consists of domains (S, R, N, J, P, Q, + B, A); and the other (L, E, F, G, H, D, C, K, B, A). Domain B is + assumed to have multiple parentage as shown. + + U + / \ + / \ + J L + / \ + N E + / \ / \ + R P D F + / \ | \ \ + S Q C (X) G + \ / \ \ + B K H + / + A + + Figure 3 + Illustration of Requirements for the Distinction of Simple Names + + Suppose someone at A tries to initiate communication with destination + H. The fully qualified destination name would be + + H.G.F.E.L.U + + Omitting common ancestors, the partially qualified name for the + destination would be + + H.G.F + + To permit the case of partially qualified names, name server at A + needs to resolve the simple name F, i.e., F needs to be distinct from + all the other simple names in its database. + + To enable the name server of a domain to resolve simple names, a + simple name for a child needs to be assigned distinct from those of + all of its ancestors and their immediate children. However, such + distinction would not be sufficient to allow simple name resolution + at lower-level domains because lower-level domains could have + multiple parentage below the level of this domain. + + In the example above, let us assume that a name is to be assigned + + +Su & Postel [Page 12] + + + +RFC 819 August 1982; + + + to a new domain X by D. To allow name server at D to resolve + simple names, the name for X must be distinct from L, E, D, C, F, + and J. However, allowing A to resolve simple names, X needs to be + also distinct from A, B, K, as well as from Q, P, N, and R. + + The following observations can be made. + + Simple names along parallel trails (distinct trails leading from + one domain to the naming universe) must be distinct, e.g., N must + be distinct from E for B or A to properly resolve simple names. + + No universal uniqueness of simple names is called for, e.g., the + simple name S does not have to be distinct from that of E, F, G, + H, D, C, K, Q, B, or A. + + The lower the level at which a domain occurs, the more immune it + is to the requirement of naming uniqueness. + + To satisfy the required distinction of simple names for proper + resolution at all levels, a naming authority needs to ensure the + simple name to be assigned distinct from those in the name server + databases at the endpoint naming domains within its domain. As an + example, for D to assign a simple name for X, it would need to + consult databases at A and K. It is, however, acceptable to have + simple names under domain A identical with those under K. Failure of + such distinct assignment of simple names by naming authority of one + domain would jeopardize the capability of simple name resolution for + entities within the subtree under that domain. + + + + + + + + + + + + + + + + + + + + + + + +Su & Postel [Page 13] + + + +RFC 819 August 1982; + + +APPENDIX C + + Further Discussion of Name Service and Name Servers + + The name service on a system should appear to the programmer of an + application program simply as a system call or library subroutine. + Within that call or subroutine there may be several types of methods + for resolving the name string into an address. + + First, a local table may be consulted. This table may be a + complete table and may be updated frequently, or it may simply be + a cache of the few latest name to address mappings recently + determined. + + Second, a call may be made to a name server to resolve the string + into a destination address. + + Third, a call may be made to a name server to resolve the string + into a relay address. + + Whenever a name server is called it may be a recursive server or an + interactive server. + + If the server is recursive, the caller won't be able to tell if + the server itself had the information to resolve the query or + called another server recursively (except perhaps for the time it + takes). + + If the server is iterative, the caller must be prepared for either + the answer to its query, or a response indicating that it should + call on a different server. + + It should be noted that the main name service discussed in this memo + is simply a name string to address service. For some applications + there may be other services needed. + + For example, even within the Internet there are several procedures + or protocols for actually transferring mail. One need is to + determine which mail procedures a destination host can use. + Another need is to determine the name of a relay host if the + source and destination hosts do not have a common mail procedure. + These more specialized services must be specific to each + application since the answers may be application dependent, but + the basic name to address translation is application independent. + + + + + + + +Su & Postel [Page 14] + + + +RFC 819 August 1982; + + +APPENDIX D + + Further Discussion of Interoperability and Protocol Translations + + The translation of protocols from one system to another is often + quite difficult. Following are some questions that stem from + considering the translations of addresses between mail systems: + + What is the impact of different addressing environments (i.e., + environments of different address formats)? + + It is noted that the boundary of naming environment may or may not + coincide with the boundary of different mail systems. Should the + conversion of naming be independent of the application system? + + The boundary between different addressing environments may or may + not coincide with that of different naming environments or + application systems. Some generic approach appears to be + necessary. + + If the conversion of naming is to be independent of the + application system, some form of interaction appears necessary + between the interface module of naming conversion with some + application level functions, such as the parsing and modification + of message text. + + To accommodate encryption, conversion may not be desirable at all. + What then can be an alternative to conversion? + + + + + + + + + + + + + + + + + + + + + + + +Su & Postel [Page 15] + + + +RFC 819 August 1982; + + +GLOSSARY + + address + + An address is a numerical identifier for the topological location + of the named entity. + + name + + A name is an alphanumeric identifier associated with the named + entity. For unique identification, a name needs to be unique in + the context in which the name is used. A name can be mapped to an + address. + + complete (fully qualified) name + + A complete name is a concatenation of simple names representing + the hierarchical relation of the named with respect to the naming + universe, that is it is the concatenation of the simple names of + the domain structure tree nodes starting with its own name and + ending with the top level node name. It is a unique name in the + naming universe. + + partially qualified name + + A partially qualified name is an abbreviation of the complete name + omitting simple names of the common ancestors of the communicating + parties. + + simple name + + A simple name is an alphanumeric identifier unique only within its + parent domain. + + domain + + A domain defines a region of jurisdiction for name assignment and + of responsibility for name-to-address translation. + + naming universe + + Naming universe is the ancestor of all network entities. + + naming environment + + A networking environment employing a specific naming convention. + + + + + +Su & Postel [Page 16] + + + +RFC 819 August 1982; + + + name service + + Name service is a network service for name-to-address mapping. + + name server + + A name server is a network mechanism (e.g., a process) realizing + the function of name service. + + naming authority + + Naming authority is an administrative entity having the authority + for assigning simple names and responsibility for resolving naming + conflict. + + parallel relations + + A network entity may have one or more hierarchical relations with + respect to the naming universe. Such multiple relations are + parallel relations to each other. + + multiple parentage + + A network entity has multiple parentage when it is assigned a + simple name by more than one naming domain. + + + + + + + + + + + + + + + + + + + + + + + + + + +Su & Postel [Page 17] + + + +RFC 819 August 1982; + + +REFERENCES + + [1] F. Harary, "Graph Theory", Addison-Wesley, Reading, + Massachusetts, 1969. + + [2] J. Postel, "Computer Mail Meeting Notes", RFC-805, + USC/Information Sciences Institute, 8 February 1982. + + [3] J. Postel, "Simple Mail Transfer Protocol", RFC-821, + USC/Information Sciences Institute, August 1982. + + [4] D. Crocker, "Standard for the Format of ARPA Internet Text + Messages", RFC-822, Department of Electrical Engineering, University + of Delaware, August 1982. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Su & Postel [Page 18] + |
