diff options
| author | fukachan <fukachan> | 2001-10-08 05:35:29 +0000 |
|---|---|---|
| committer | fukachan <fukachan> | 2001-10-08 05:35:29 +0000 |
| commit | 72b9fdcd785f7657f694dac0380da169d0f05bf9 (patch) | |
| tree | 2e2cf6a76e2d3b530eef4ae47e30ff30d1aa49c7 | |
| parent | 8046f9e53bed4322a1b4d2c43502d25989924198 (diff) | |
| download | fml8-72b9fdcd785f7657f694dac0380da169d0f05bf9.tar.gz fml8-72b9fdcd785f7657f694dac0380da169d0f05bf9.tar.bz2 fml8-72b9fdcd785f7657f694dac0380da169d0f05bf9.zip | |
add missing rfc in the rfc links (obsolete, update)
52 files changed, 71157 insertions, 0 deletions
diff --git a/Documentation/en/rfc/rfc-index.txt b/Documentation/en/rfc/rfc-index.txt new file mode 100644 index 00000000..d58d4c01 --- /dev/null +++ b/Documentation/en/rfc/rfc-index.txt @@ -0,0 +1,11362 @@ + + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + RFC INDEX + ------------- + +(CREATED ON: 10/04/2001.) + +This file contains citations for all RFCs in numeric order. + +RFC citations appear in this format: + + #### Title of RFC. Author 1, Author 2, Author 3. Issue date. + (Format: ASCII) (Obsoletes xxx) (Obsoleted by xxx) (Updates xxx) + (Updated by xxx) (Also FYI ####) (Status: ssssss) + +or + + #### Not Issued. + +For example: + + 1129 Internet Time Synchronization: The Network Time Protocol. D.L. + Mills. Oct-01-1989. (Format: TXT=298, PS=551697, PDF=197036 bytes) + (Also RFC1119) (Status: UNKNOWN) + +Key to citations: + +#### is the RFC number. + +Following the RFC number are the title, the author(s), and the +publication date of the RFC. Each of these is terminated by a period. + +Following the number are the title (terminated with a period), the +author, or list of authors (terminated with a period), and the date +(terminated with a period). + +The format and length follow in parenthesis. One or more of the +following alternative formats are listed: ASCII text (TXT), PostScript +(PS), and/or Adobe (PDF). Each format is followed by an equals sign +and the number of bytes for that version. For example (Format: +TXT=aaaaa, PS=bbbbbb bytes) shows that the ASCII text version is aaaaa +bytes, and the PostScript version of the RFC is bbbbbb bytes. + +Obsoletes xxxx refers to other RFCs that this one replaces; +Obsoleted by xxxx refers to RFCs that have replaced this one. +Updates xxxx refers to other RFCs that this one merely updates but +does not replace); Updated by xxxx refers to RFCs that have updated +(but not replaced) this one. Generally, only immediately succeeding +and/or preceding RFCs are indicated, not the entire history of each +related earlier or later RFC in a related series. + +The (Also FYI ##) or (Also STD ##) or (Also BCP ##) phrase gives the +equivalent FYI, STD, or BCP number if the RFC is also in those +document sub-series. Finally, the Status field gives the document's +current status (see RFC 2026). + +RFCs may be obtained in a number of ways, using HTTP, FTP, or email. +See the RFC Editor Web page http://www.rfc-editor.org + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + RFC INDEX + --------- + + + +0001 Host Software. S. Crocker. Apr-07-1969. (Format: TXT=21088 bytes) + (Status: UNKNOWN) + +0002 Host software. B. Duvall. Apr-09-1969. (Format: TXT=17145 bytes) + (Status: UNKNOWN) + +0003 Documentation conventions. S.D. Crocker. Apr-09-1969. (Format: + TXT=2323 bytes) (Obsoleted by RFC0010) (Status: UNKNOWN) + +0004 Network timetable. E.B. Shapiro. Mar-24-1969. (Format: TXT=5933 + bytes) (Status: UNKNOWN) + +0005 Decode Encode Language (DEL). J. Rulifson. Jun-02-1969. (Format: + TXT=26408 bytes) (Status: UNKNOWN) + +0006 Conversation with Bob Kahn. S.D. Crocker. Apr-10-1969. (Format: + TXT=1568 bytes) (Status: UNKNOWN) + +0007 Host-IMP interface. G. Deloche. May-01-1969. (Not online) + (Status: UNKNOWN) + +0008 Functional specifications for the ARPA Network. G. Deloche. + May-05-1969. (Not online) (Status: UNKNOWN) + +0009 Host software. G. Deloche. May-01-1969. (Not online) (Status: + UNKNOWN) + +0010 Documentation conventions. S.D. Crocker. Jul-29-1969. (Format: + TXT=3348 bytes) (Obsoletes RFC0003) (Obsoleted by RFC0016) (Updated + by RFC0024, RFC0027, RFC0030) (Status: UNKNOWN) + +0011 Implementation of the Host-Host software procedures in GORDO. G. + Deloche. Aug-01-1969. (Not online) (Obsoleted by RFC0033) (Status: + UNKNOWN) + +0012 IMP-Host interface flow diagrams. M. Wingfield. Aug-26-1969. (Not + online) (Status: UNKNOWN) + +0013 Zero Text Length EOF Message. V. Cerf. Aug-20-1969. (Format: + TXT=1070 bytes) (Status: UNKNOWN) + +0015 Network subsystem for time sharing hosts. C.S. Carr. Sep-25-1969. + (Format: TXT=10695 bytes) (Status: UNKNOWN) + +0016 M.I.T. S. Crocker. Aug-27-1969. (Format: TXT=682 bytes) + (Obsoletes RFC0010) (Obsoleted by RFC0024) (Updated by RFC0024, + RFC0027, RFC0030) (Status: UNKNOWN) + +0017 Some questions re: Host-IMP Protocol. J.E. Kreznar. Aug-27-1969. + (Format: TXT=6065 bytes) (Status: UNKNOWN) + +0018 IMP-IMP and HOST-HOST Control Links. V. Cerf. Sep-01-1969. + (Format: TXT=634 bytes) (Status: UNKNOWN) + +0019 Two protocol suggestions to reduce congestion at swap bound + nodes. J.E. Kreznar. Oct-07-1969. (Format: TXT=3392 bytes) (Status: + UNKNOWN) + +0020 ASCII format for network interchange. V.G. Cerf. Oct-16-1969. + (Format: TXT=18504 bytes) (Status: UNKNOWN) + +0021 Network meeting. V.G. Cerf. Oct-17-1969. (Format: TXT=2143 bytes) + (Status: UNKNOWN) + +0022 Host-host control message formats. V.G. Cerf. Oct-17-1969. + (Format: TXT=4606 bytes) (Status: UNKNOWN) + +0023 Transmission of Multiple Control Messages. G. Gregg. Oct-16-1969. + (Format: TXT=690 bytes) (Status: UNKNOWN) + +0024 Documentation Conventions. S.D. Crocker. Nov-21-1969. (Format: + TXT=3460 bytes) (Obsoletes RFC0016) (Updates RFC0010, RFC0016) + (Updated by RFC0027, RFC0030) (Status: UNKNOWN) + +0025 No High Link Numbers. S.D. Crocker. Oct-30-1969. (Format: TXT=479 + bytes) (Status: UNKNOWN) + +0027 Documentation Conventions. S.D. Crocker. Dec-09-1969. (Format: + TXT=3661 bytes) (Updates RFC0010, RFC0016, RFC0024) (Updated by + RFC0030) (Status: UNKNOWN) + +0028 Time Standards. W.K. English. Jan-13-1970. (Format: TXT=557 + bytes) (Status: UNKNOWN) + +0029 Response to RFC 28. R.E. Kahn. Jan-19-1970. (Format: TXT=790 + bytes) (Also RFC0028) (Status: UNKNOWN) + +0030 Documentation Conventions. S.D. Crocker. Feb-04-1970. (Format: + TXT=4041 bytes) (Updates RFC0010, RFC0016, RFC0024, RFC0027) (Status: + UNKNOWN) + +0031 Binary Message Forms in Computer. D. Bobrow, W.R. Sutherland. + Feb-01-1968. (Format: TXT=11191 bytes) (Status: UNKNOWN) + +0032 Connecting M.I.T. Computers to the ARPA Computer-To-Computer + Communication Network. D. Vedder. Feb-05-1969. (Format: TXT=2216 + bytes) (Status: UNKNOWN) + +0033 New Host-Host Protocol. S.D. Crocker. Feb-12-1970. (Format: + TXT=44167 bytes) (Obsoletes RFC0011) (Updated by RFC0036, RFC0047) + (Status: UNKNOWN) + +0034 Some Brief Preliminary Notes on the Augmentation Research Center + Clock. W.K. English. Feb-26-1970. (Format: TXT=2534 bytes) (Status: + UNKNOWN) + +0035 Network Meeting. S.D. Crocker. Mar-03-1970. (Format: TXT=1282 + bytes) (Status: INFORMATIONAL) + +0036 Protocol Notes. S.D. Crocker. Mar-16-1970. (Format: TXT=13893 + bytes) (Updates RFC0033) (Updated by RFC0039, RFC0044) (Status: + UNKNOWN) + +0037 Network Meeting Epilogue, etc. S.D. Crocker. Mar-20-1970. + (Format: TXT=9107 bytes) (Status: UNKNOWN) + +0038 Comments on Network Protocol from NWG/RFC #36. S.M. Wolfe. + Mar-20-1970. (Format: TXT=2536 bytes) (Status: UNKNOWN) + +0039 Comments on Protocol Re: NWG/RFC #36. E. Harslem, J.F. Heafner. + Mar-25-1970. (Format: TXT=4779 bytes) (Updates RFC0036) (Status: + UNKNOWN) + +0040 More Comments on the Forthcoming Protocol. E. Harslem, J.F. + Heafner. Mar-27-1970. (Format: TXT=3825 bytes) (Status: UNKNOWN) + +0041 IMP-IMP Teletype Communication. J.T. Melvin. Mar-30-1970. + (Format: TXT=1038 bytes) (Status: UNKNOWN) + +0042 Message Data Types. E. Ancona. Mar-31-1970. (Format: TXT=5247 + bytes) (Status: UNKNOWN) + +0043 Proposed Meeting. A.G. Nemeth. Apr-08-1970. (Format: TXT=1600 + bytes) (Status: UNKNOWN) + +0044 Comments on NWG/RFC 33 and 36. A. Shoshani, R. Long, A. + Landsberg. Apr-10-1970. (Format: TXT=7381 bytes) (Updates RFC0036) + (Status: UNKNOWN) + +0045 New Protocol is Coming. J. Postel, S.D. Crocker. Apr-14-1970. + (Format: TXT=1130 bytes) (Status: UNKNOWN) + +0046 ARPA Network protocol notes. E. Meyer. Apr-17-1970. (Format: + TXT=41338 bytes) (Status: UNKNOWN) + +0047 BBN's Comments on NWG/RFC #33. W.R. Crowther. Apr-20-1970. + (Format: TXT=5343 bytes) (Updates RFC0033) (Status: UNKNOWN) + +0048 Possible protocol plateau. J. Postel, S.D. Crocker. Apr-21-1970. + (Format: TXT=41696 bytes) (Status: UNKNOWN) + +0049 Conversations with S. Crocker (UCLA). E. Meyer. Apr-25-1970. + (Format: TXT=12384 bytes) (Status: UNKNOWN) + +0050 Comments on the Meyer Proposal. E. Harslem, J. Haverty. + Apr-30-1970. (Format: TXT=4070 bytes) (Status: UNKNOWN) + +0051 Proposal for a Network Interchange Language. M. Elie. + May-04-1970. (Not online) (Status: UNKNOWN) + +0052 Updated distribution list. J. Postel, S.D. Crocker. Jul-01-1970. + (Format: TXT=5088 bytes) (Updated by RFC0069) (Status: UNKNOWN) + +0053 Official protocol mechanism. S.D. Crocker. Jun-09-1970. (Format: + TXT=2330 bytes) (Status: UNKNOWN) + +0054 Official Protocol Proffering. S.D. Crocker, J. Postel, J. + Newkirk, M. Kraley. Jun-18-1970. (Format: TXT=20131 bytes) (Updated + by RFC0057) (Status: UNKNOWN) + +0055 Prototypical implementation of the NCP. J. Newkirk, M. Kraley, J. + Postel, S.D. Crocker. Jun-19-1970. (Format: TXT=48070 bytes) (Status: + UNKNOWN) + +0056 Third Level Protocol: Logger Protocol. E. Belove, D. Black, R. + Flegal, L.G. Farquar. Jun-01-1970. (Format: TXT=13066 bytes) (Status: + UNKNOWN) + +0057 Thoughts and Reflections on NWG/RFC 54. M. Kraley, J. Newkirk. + Jun-19-1970. (Format: TXT=8360 bytes) (Updates RFC0054) (Status: + UNKNOWN) + +0058 Logical Message Synchronization. T.P. Skinner. Jun-26-1970. + (Format: TXT=3767 bytes) (Status: UNKNOWN) + +0059 Flow Control - Fixed Versus Demand Allocation. E. Meyer. + Jun-27-1970. (Format: TXT=17691 bytes) (Status: UNKNOWN) + +0060 Simplified NCP Protocol. R.B. Kalin. Jul-13-1970. (Format: + TXT=18941 bytes) (Status: UNKNOWN) + +0061 Note on Interprocess Communication in a Resource Sharing Computer + Network. D.C. Walden. Jul-17-1970. (Format: TXT=43946 bytes) + (Obsoleted by RFC0062) (Status: UNKNOWN) + +0062 Systems for Interprocess Communication in a Resource Sharing + Computer Network. D.C. Walden. Aug-03-1970. (Format: TXT=55784 bytes) + (Obsoletes RFC0061) (Status: UNKNOWN) + +0063 Belated Network Meeting Report. V.G. Cerf. Jul-31-1970. (Format: + TXT=2961 bytes) (Status: UNKNOWN) + +0064 Getting rid of marking. M. Elie. Jul-01-1970. (Format: TXT=7556 + bytes) (Status: UNKNOWN) + +0065 Comments on Host/Host Protocol document #1. D.C. Walden. + Aug-29-1970. (Format: TXT=5628 bytes) (Status: UNKNOWN) + +0066 NIC - third level ideas and other noise. S.D. Crocker. + Aug-26-1970. (Format: TXT=4575 bytes) (Obsoleted by RFC0123) (Updated + by RFC0080, RFC0093) (Status: UNKNOWN) + +0067 Proposed Change to Host/IMP Spec to Eliminate Marking. W.R. + Crowther. Jan-01-1970. (Format: TXT=1534 bytes) (Status: UNKNOWN) + +0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, + RET, and RFNM. M. Elie. Aug-31-1970. (Format: TXT=5041 bytes) + (Status: UNKNOWN) + +0069 Distribution List Change for MIT. A.K. Bhushan. Sep-22-1970. + (Format: TXT=841 bytes) (Updates RFC0052) (Status: UNKNOWN) + +0070 Note on Padding. S.D. Crocker. Oct-15-1970. (Format: TXT=12790 + bytes) (Updated by RFC0228) (Status: UNKNOWN) + +0071 Reallocation in Case of Input Error. T. Schipper. Sep-25-1970. + (Format: TXT=1265 bytes) (Status: UNKNOWN) + +0072 Proposed Moratorium on Changes to Network Protocol. R.D. + Bressler. Sep-28-1970. (Format: TXT=4047 bytes) (Status: UNKNOWN) + +0073 Response to NWG/RFC 67. S.D. Crocker. Sep-25-1970. (Format: + TXT=1268 bytes) (Status: UNKNOWN) + +0074 Specifications for network use of the UCSB On-Line System. J.E. + White. Oct-16-1970. (Not online) (Updated by RFC0217, RFC0225) + (Status: UNKNOWN) + +0075 Network Meeting. S.D. Crocker. Oct-14-1970. (Format: TXT=1318 + bytes) (Status: UNKNOWN) + +0076 Connection by name: User oriented protocol. J. Bouknight, J. + Madden, G.R. Grossman. Oct-28-1970. (Format: TXT=26504 bytes) + (Status: UNKNOWN) + +0077 Network meeting report. J. Postel. Nov-20-1970. (Format: + TXT=19196 bytes) (Status: UNKNOWN) + +0078 NCP Status Report: UCSB/Rand. E. Harslem, J.F. Heafner, J.E. + White. Oct-01-1970. (Format: TXT=1303 bytes) (Status: UNKNOWN) + +0079 Logger Protocol error. E. Meyer. Nov-16-1970. (Format: TXT=1515 + bytes) (Status: UNKNOWN) + +0080 Protocols and Data Formats. E. Harslem, J.F. Heafner. + Dec-01-1970. (Not online) (Obsoleted by RFC0123) (Updates RFC0066) + (Updated by RFC0093) (Status: UNKNOWN) + +0081 Request for Reference Information. J. Bouknight. Dec-03-1970. + (Format: TXT=956 bytes) (Status: UNKNOWN) + +0082 Network Meeting Notes. E. Meyer. Dec-09-1970. (Format: TXT=38023 + bytes) (Status: UNKNOWN) + +0083 Language-machine for data reconfiguration. R.H. Anderson, E. + Harslem, J.F. Heafner. Dec-18-1970. (Not online) (Status: UNKNOWN) + +0084 List of NWG/RFC's 1-80. J.B. North. Dec-23-1970. (Format: + TXT=12613 bytes) (Status: UNKNOWN) + +0085 Network Working Group meeting. S.D. Crocker. Dec-28-1970. + (Format: TXT=1547 bytes) (Status: UNKNOWN) + +0086 Proposal for a Network Standard Format for a Data Stream to + Control Graphics Display. S.D. Crocker. Jan-05-1971. (Format: + TXT=7117 bytes) (Updated by RFC0125) (Status: UNKNOWN) + +0087 Topic for Discussion at the Next Network Working Group Meeting. + A. Vezza. Jan-12-1971. (Format: TXT=3593 bytes) (Status: UNKNOWN) + +0088 NETRJS: A third level protocol for Remote Job Entry. R.T. Braden, + S.M. Wolfe. Jan-13-1971. (Not online) (Obsoleted by RFC0189) (Status: + UNKNOWN) + +0089 Some historic moments in networking. R.M. Metcalfe. Jan-19-1971. + (Not online) (Status: UNKNOWN) + +0090 CCN as a Network Service Center. R.T. Braden. Jan-25-1971. + (Format: TXT=11929 bytes) (Status: UNKNOWN) + +0091 Proposed User-User Protocol. G.H. Mealy. Dec-27-1970. (Format: + TXT=27005 bytes) (Status: UNKNOWN) + +0093 Initial Connection Protocol. A.M. McKenzie. Jan-27-1971. (Format: + TXT=1746 bytes) (Updates RFC0066, RFC0080) (Status: UNKNOWN) + +0094 Some thoughts on Network Graphics. E. Harslem, J.F. Heafner. + Feb-03-1971. (Format: TXT=13516 bytes) (Status: UNKNOWN) + +0095 Distribution of NWG/RFC's through the NIC. S.D. Crocker. + Feb-04-1971. (Format: TXT=8938 bytes) (Obsoleted by RFC0155) (Status: + UNKNOWN) + +0096 An Interactive Network Experiment to Study Modes of Access the + Network Information Center. R.W. Watson. Feb-12-1971. (Format: + TXT=11334 bytes) (Status: INFORMATIONAL) + +0097 First Cut at a Proposed Telnet Protocol. J.T. Melvin, R.W. + Watson. Feb-15-1971. (Not online) (Status: UNKNOWN) + +0098 Logger Protocol Proposal. E. Meyer, T. Skinner. Feb-11-1971. + (Format: TXT=24536 bytes) (Updated by RFC0123) (Status: UNKNOWN) + +0099 Network Meeting. P.M. Karp. Feb-22-1971. (Format: TXT=1010 bytes) + (Updated by RFC0116) (Status: UNKNOWN) + +0100 Categorization and guide to NWG/RFCs. P.M. Karp. Feb-26-1971. + (Format: TXT=62473 bytes) (Status: UNKNOWN) + +0101 Notes on the Network Working Group meeting, Urbana, Illinois, + February 17, 1971. R.W. Watson. Feb-23-1971. (Format: TXT=30343 + bytes) (Updated by RFC0108, RFC0123) (Status: UNKNOWN) + +0102 Output of the Host-Host Protocol glitch cleaning committee. S.D. + Crocker. Feb-22-1971. (Format: TXT=8511 bytes) (Updated by RFC0107) + (Status: UNKNOWN) + +0103 Implementation of Interrupt Keys. R.B. Kalin. Feb-24-1971. + (Format: TXT=7592 bytes) (Status: UNKNOWN) + +0104 Link 191. J.B. Postel, S.D. Crocker. Feb-25-1971. (Format: + TXT=1017 bytes) (Status: UNKNOWN) + +0105 Network Specifications for Remote Job Entry and Remote Job Output + Retrieval at UCSB. J.E. White. Mar-22-1971. (Format: TXT=21938 bytes) + (Updated by RFC0217) (Status: UNKNOWN) + +0106 User/Server Site Protocol Network Host Questionnaire. T.C. + O'Sullivan. Mar-03-1971. (Format: TXT=6946 bytes) (Status: UNKNOWN) + +0107 Output of the Host-Host Protocol Glitch Cleaning Committee. R.D. + Bressler, S.D. Crocker, W.R. Crowther, G.R. Grossman, R.S. Tomlinson, + J.E. White. Mar-23-1971. (Format: TXT=18109 bytes) (Updates RFC0102) + (Updated by RFC0111, RFC0124, RFC0132, RFC0154, RFC0179) (Status: + UNKNOWN) + +0108 Attendance list at the Urbana NWG meeting, February 17-19, 1971. + R.W. Watson. Mar-25-1971. (Format: TXT=1597 bytes) (Updates RFC0101) + (Status: UNKNOWN) + +0109 Level III Server Protocol for the Lincoln Laboratory NIC 360/67 + Host. J.M. Winett. Mar-24-1971. (Not online) (Also RFC0393) (Status: + UNKNOWN) + +0110 Conventions for using an IBM 2741 terminal as a user console for + access to network server hosts. J.M. Winett. Mar-25-1971. (Not + online) (Updated by RFC0135) (Status: UNKNOWN) + +0111 Pressure from the Chairman. S.D. Crocker. Mar-31-1971. (Format: + TXT=2098 bytes) (Updates RFC0107) (Updated by RFC0130) (Status: + UNKNOWN) + +0112 User/Server Site Protocol: Network host questionnaire responses. + T.C. O'Sullivan. Apr-01-1971. (Not online) (Status: UNKNOWN) + +0113 Network activity report: UCSB Rand. E. Harslem, J.F. Heafner, + J.E. White. Apr-05-1971. (Format: TXT=3442 bytes) (Updated by + RFC0227) (Status: UNKNOWN) + +0114 File Transfer Protocol. A.K. Bhushan. Apr-10-1971. (Format: + TXT=38981 bytes) (Updated by RFC0133, RFC0141, RFC0171, RFC0172) + (Status: UNKNOWN) + +0115 Some Network Information Center policies on handling documents. + R.W. Watson, J.B. North. Apr-16-1971. (Format: TXT=16775 bytes) + (Status: UNKNOWN) + +0116 Structure of the May NWG Meeting. S.D. Crocker. Apr-12-1971. + (Format: TXT=2395 bytes) (Updates RFC0099) (Updated by RFC0131, + RFC0156) (Status: UNKNOWN) + +0117 Some comments on the official protocol. J. Wong. Apr-07-1971. + (Format: TXT=7128 bytes) (Status: UNKNOWN) + +0118 Recommendations for facility documentation. R.W. Watson. + Apr-16-1971. (Format: TXT=4573 bytes) (Status: UNKNOWN) + +0119 Network Fortran subprograms. M. Krilanovich. Apr-21-1971. (Not + online) (Status: UNKNOWN) + +0120 Network PL1 subprograms. M. Krilanovich. Apr-21-1971. (Format: + TXT=37192 bytes) (Status: UNKNOWN) + +0121 Network on-line operators. M. Krilanovich. Apr-21-1971. (Format: + TXT=29419 bytes) (Status: UNKNOWN) + +0122 Network specifications for UCSB's Simple-Minded File System. J.E. + White. Apr-26-1971. (Format: TXT=47638 bytes) (Updated by RFC0217, + RFC0269, RFC0399, RFC0431) (Status: UNKNOWN) + +0123 Proffered Official ICP. S.D. Crocker. Apr-20-1971. (Format: + TXT=4812 bytes) (Obsoletes RFC0066, RFC0080) (Obsoleted by RFC0165) + (Updates RFC0098, RFC0101) (Updated by RFC0127, RFC0143, RFC0148) + (Status: UNKNOWN) + +0124 Typographical error in RFC 107. J.T. Melvin. Apr-19-1971. + (Format: TXT=659 bytes) (Updates RFC0107) (Status: UNKNOWN) + +0125 Response to RFC 86: Proposal for Network Standard Format for a + Graphics Data Stream. J. McConnell. Apr-18-1971. (Format: TXT=8133 + bytes) (Updates RFC0086) (Updated by RFC0177) (Status: UNKNOWN) + +0126 Graphics Facilities at Ames Research Center. J. McConnell. + Apr-18-1971. (Format: TXT=1974 bytes) (Status: UNKNOWN) + +0127 Comments on RFC 123. J. Postel. Apr-20-1971. (Format: TXT=2305 + bytes) (Obsoleted by RFC0145) (Updates RFC0123) (Updated by RFC0151) + (Status: UNKNOWN) + +0128 Bytes. J. Postel. Apr-21-1971. (Format: TXT=2745 bytes) (Status: + UNKNOWN) + +0129 Request for comments on socket name structure. E. Harslem, J. + Heafner, E. Meyer. Apr-22-1971. (Format: TXT=11175 bytes) (Updated by + RFC0147) (Status: UNKNOWN) + +0130 Response to RFC 111: Pressure from the chairman. J.F. Heafner. + Apr-22-1971. (Format: TXT=2580 bytes) (Updates RFC0111) (Status: + UNKNOWN) + +0131 Response to RFC 116: May NWG meeting. E. Harslem, J.F. Heafner. + Apr-22-1971. (Format: TXT=5375 bytes) (Updates RFC0116) (Status: + UNKNOWN) + +0132 Typographical Error in RFC 107. J.E. White. Apr-28-1971. (Format: + TXT=1058 bytes) (Obsoleted by RFC0154) (Updates RFC0107) (Status: + UNKNOWN) + +0133 File Transfer and Recovery. R.L. Sundberg. Apr-27-1971. (Format: + TXT=8322 bytes) (Updates RFC0114) (Status: UNKNOWN) + +0134 Network Graphics meeting. A. Vezza. Apr-29-1971. (Format: + TXT=2684 bytes) (Status: UNKNOWN) + +0135 Response to NWG/RFC 110. W. Hathaway. Apr-29-1971. (Not online) + (Updates RFC0110) (Status: UNKNOWN) + +0136 Host accounting and administrative procedures. R.E. Kahn. + Apr-29-1971. (Format: TXT=8016 bytes) (Status: UNKNOWN) + +0137 Telnet Protocol - a proposed document. T.C. O'Sullivan. + Apr-30-1971. (Not online) (Updated by RFC0139) (Status: UNKNOWN) + +0138 Status report on proposed Data Reconfiguration Service. R.H. + Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. + Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood. Apr-28-1971. (Format: + TXT=46641 bytes) (Status: UNKNOWN) + +0139 Discussion of Telnet Protocol. T.C. O'Sullivan. May-07-1971. (Not + online) (Updates RFC0137) (Updated by RFC0158) (Also RFC0393) + (Status: UNKNOWN) + +0140 Agenda for the May NWG meeting. S.D. Crocker. May-04-1971. + (Format: TXT=6934 bytes) (Updated by RFC0149) (Status: UNKNOWN) + +0141 Comments on RFC 114: A File Transfer Protocol. E. Harslem, J.F. + Heafner. Apr-29-1971. (Format: TXT=3781 bytes) (Updates RFC0114) + (Status: UNKNOWN) + +0142 Time-Out Mechanism in the Host-Host Protocol. C. Kline, J. Wong. + May-03-1971. (Format: TXT=4372 bytes) (Status: UNKNOWN) + +0143 Regarding proffered official ICP. W. Naylor, J. Wong, C. Kline, + J. Postel. May-03-1971. (Format: TXT=6963 bytes) (Obsoleted by + RFC0165) (Updates RFC0123, RFC0145) (Status: UNKNOWN) + +0144 Data sharing on computer networks. A. Shoshani. Apr-30-1971. + (Format: TXT=13744 bytes) (Status: UNKNOWN) + +0145 Initial Connection Protocol Control Commands. J. Postel. + May-04-1971. (Not online) (Obsoletes RFC0127) (Obsoleted by RFC0165) + (Updated by RFC0143) (Status: UNKNOWN) + +0146 Views on issues relevant to data sharing on computer networks. + P.M. Karp, D.B. McKay, D.C.M. Wood. May-12-1971. (Format: TXT=9828 + bytes) (Status: UNKNOWN) + +0147 Definition of a socket. J.M. Winett. May-07-1971. (Format: + TXT=6438 bytes) (Updates RFC0129) (Status: UNKNOWN) + +0148 Comments on RFC 123. A.K. Bhushan. May-07-1971. (Format: TXT=1149 + bytes) (Updates RFC0123) (Status: UNKNOWN) + +0149 Best Laid Plans. S.D. Crocker. May-10-1971. (Format: TXT=1057 + bytes) (Updates RFC0140) (Status: UNKNOWN) + +0150 Use of IPC Facilities: A Working Paper. R.B. Kalin. May-05-1971. + (Format: TXT=28163 bytes) (Status: UNKNOWN) + +0151 Comments on a proffered official ICP: RFCs 123, 127. A. Shoshani. + May-10-1971. (Format: TXT=3623 bytes) (Updates RFC0127) (Status: + UNKNOWN) + +0152 SRI Artificial Intelligence status report. M. Wilber. + May-10-1971. (Format: TXT=2726 bytes) (Status: UNKNOWN) + +0153 SRI ARC-NIC status. J.T. Melvin, R.W. Watson. May-15-1971. + (Format: TXT=8573 bytes) (Status: UNKNOWN) + +0154 Exposition Style. S.D. Crocker. May-12-1971. (Format: TXT=1293 + bytes) (Obsoletes RFC0132) (Updates RFC0107) (Status: UNKNOWN) + +0155 ARPA Network mailing lists. J.B. North. May-01-1971. (Format: + TXT=11054 bytes) (Obsoletes RFC0095) (Obsoleted by RFC0168) (Status: + UNKNOWN) + +0156 Status of the Illinois site: Response to RFC 116. J. Bouknight. + Apr-26-1971. (Format: TXT=1171 bytes) (Updates RFC0116) (Status: + UNKNOWN) + +0157 Invitation to the Second Symposium on Problems in the + Optimization of Data Communications Systems. V.G. Cerf. May-12-1971. + (Format: TXT=3159 bytes) (Status: UNKNOWN) + +0158 Telnet Protocol: A Proposed Document. T.C. O'Sullivan. + May-19-1971. (Not online) (Obsoleted by RFC0495) (Updates RFC0139) + (Updated by RFC0318) (Also RFC0393) (Status: UNKNOWN) + +0160 RFC brief list. Network Information Center. Stanford Research + Institute. May-18-1971. (Format: TXT=12173 bytes) (Obsoleted by + RFC0200, RFC0999) (Updates NIC 6716) (Status: UNKNOWN) + +0161 Solution to the race condition in the ICP. A. Shoshani. + May-19-1971. (Format: TXT=2026 bytes) (Status: UNKNOWN) + +0162 NETBUGGER3. M. Kampe. May-22-1971. (Format: TXT=3153 bytes) + (Status: UNKNOWN) + +0163 Data transfer protocols. V.G. Cerf. May-19-1971. (Format: + TXT=5465 bytes) (Status: UNKNOWN) + +0164 Minutes of Network Working Group meeting, 5/16 through 5/19/71. + J.F. Heafner. May-25-1971. (Format: TXT=58597 bytes) (Status: + UNKNOWN) + +0165 Proffered official Initial Connection Protocol. J. Postel. + May-25-1971. (Not online) (Obsoletes RFC0145, RFC0143, RFC0123) + (Updated by NIC 7101) (Status: UNKNOWN) + +0166 Data Reconfiguration Service: An implementation specification. + R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. + Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood. May-25-1971. (Format: + TXT=42094 bytes) (Status: UNKNOWN) + +0167 Socket conventions reconsidered. A.K. Bhushan, R.M. Metcalfe, + J.M. Winett. May-24-1971. (Format: TXT=7643 bytes) (Also RFC0147, + RFC0129) (Status: UNKNOWN) + +0168 ARPA Network mailing lists. J.B. North. May-26-1971. (Format: + TXT=13294 bytes) (Obsoletes RFC0155) (Obsoleted by RFC0211) (Status: + UNKNOWN) + +0169 Computer networks. S.D. Crocker. May-27-1971. (Not online) + (Status: UNKNOWN) + +0170 RFC List by Number. Network Information Center, Stanford Research + Institute. Jun-01-1971. (Format: TXT=17670 bytes) (Obsoleted by + RFC0200) (Status: UNKNOWN) + +0171 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, + E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D. + Watson, J. White. Jun-01-1971. (Format: TXT=20616 bytes) (Obsoleted + by RFC0264) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN) + +0172 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, + E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. + Watson, J. White. Jun-23-1971. (Format: TXT=21328 bytes) (Obsoleted + by RFC0265) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN) + +0173 Network Data Management Committee Meeting Announcement. P.M. + Karp, D.B. McKay. Jun-04-1971. (Format: TXT=4239 bytes) (Status: + UNKNOWN) + +0174 UCLA - Computer Science Graphics Overview. J. Postel, V.G. Cerf. + Jun-08-1971. (Format: TXT=5037 bytes) (Status: UNKNOWN) + +0175 Comments on "Socket Conventions Reconsidered". E. Harslem, J.F. + Heafner. Jun-11-1971. (Format: TXT=2225 bytes) (Status: UNKNOWN) + +0176 Comments on "Byte size for connections". A.K. Bhushan, R. + Kanodia, R.M. Metcalfe, J. Postel. Jun-14-1971. (Format: TXT=7269 + bytes) (Status: UNKNOWN) + +0177 Device independent graphical display description. J. McConnell. + Jun-15-1971. (Format: TXT=20474 bytes) (Updates RFC0125) (Updated by + RFC0181) (Status: UNKNOWN) + +0178 Network graphic attention handling. I.W. Cotton. Jun-27-1971. + (Format: TXT=24522 bytes) (Status: UNKNOWN) + +0179 Link Number Assignments. A.M. McKenzie. Jun-22-1971. (Format: + TXT=1221 bytes) (Updates RFC0107) (Status: UNKNOWN) + +0180 File system questionnaire. A.M. McKenzie. Jun-25-1971. (Format: + TXT=8154 bytes) (Status: UNKNOWN) + +0181 Modifications to RFC 177. J. McConnell. Jul-21-1971. (Format: + TXT=4892 bytes) (Updates RFC0177) (Status: UNKNOWN) + +0182 Compilation of list of relevant site reports. J.B. North. + Jun-25-1971. (Format: TXT=2565 bytes) (Status: UNKNOWN) + +0183 EBCDIC codes and their mapping to ASCII. J.M. Winett. + Jul-21-1971. (Not online) (Status: UNKNOWN) + +0184 Proposed graphic display modes. K.C. Kelley. Jul-06-1971. + (Format: TXT=18678 bytes) (Status: UNKNOWN) + +0185 NIC distribution of manuals and handbooks. J.B. North. + Jul-07-1971. (Format: TXT=1406 bytes) (Status: UNKNOWN) + +0186 Network graphics loader. J.C. Michener. Jul-12-1971. (Not online) + (Status: UNKNOWN) + +0187 Network/440 Protocol Concept. D.B. McKay, D.P. Karp. Jul-01-1971. + (Format: TXT=25042 bytes) (Status: UNKNOWN) + +0188 Data management meeting announcement. P.M. Karp, D.B. McKay. + Jan-28-1971. (Format: TXT=3383 bytes) (Status: UNKNOWN) + +0189 Interim NETRJS specifications. R.T. Braden. Jul-15-1971. (Format: + TXT=41383 bytes) (Obsoletes RFC0088) (Obsoleted by RFC0599) (Updated + by RFC0283) (Status: UNKNOWN) + +0190 DEC PDP-10-IMLAC communications system. L.P. Deutsch. + Jul-13-1971. (Not online) (Status: UNKNOWN) + +0191 Graphics implementation and conceptualization at Augmentation + Research Center. C.H. Irby. Jul-13-1971. (Format: TXT=8179 bytes) + (Status: UNKNOWN) + +0192 Some factors which a Network Graphics Protocol must consider. + R.W. Watson. Jul-12-1971. (Not online) (Status: UNKNOWN) + +0193 NETWORK CHECKOUT. E. Harslem, J.F. Heafner. Jul-14-1971. (Format: + TXT=3622 bytes) (Obsoleted by RFC0198) (Updated by RFC0198) (Status: + UNKNOWN) + +0194 The Data Reconfiguration Service -- Compiler/Interpreter + Implementation Notes. V. Cerf, E. Harslem, J. Heafner, B. Metcalfe, + J. White. Jul-14-1971. (Format: TXT=32716 bytes) (Status: UNKNOWN) + +0195 Data computers-data descriptions and access language. G.H. Mealy. + Jul-16-1971. (Format: TXT=8704 bytes) (Status: UNKNOWN) + +0196 Mail Box Protocol. R.W. Watson. Jul-20-1971. (Format: TXT=7016 + bytes) (Obsoleted by RFC0221) (Status: UNKNOWN) + +0197 Initial Connection Protocol - Reviewed. A. Shoshani, E. Harslem. + Jul-14-1971. (Format: TXT=7094 bytes) (Status: UNKNOWN) + +0198 Site Certification - Lincoln Labs 360/67. J.F. Heafner. + Jul-20-1971. (Format: TXT=855 bytes) (Obsoletes RFC0193) (Obsoleted + by RFC0214) (Updates RFC0193) (Status: UNKNOWN) + +0199 Suggestions for a network data-tablet graphics protocol. T. + Williams. Jul-15-1971. (Not online) (Status: UNKNOWN) + +0200 RFC list by number. J.B. North. Aug-01-1971. (Format: TXT=19256 + bytes) (Obsoletes RFC0170, RFC0160) (Obsoleted by NIC 7724) (Status: + UNKNOWN) + +0202 Possible Deadlock in ICP. S.M. Wolfe, J. Postel. Jul-26-1971. + (Format: TXT=2796 bytes) (Status: UNKNOWN) + +0203 Achieving reliable communication. R.B. Kalin. Aug-10-1971. + (Format: TXT=9253 bytes) (Status: UNKNOWN) + +0204 Sockets in use. J. Postel. Aug-05-1971. (Format: TXT=1379 bytes) + (Updated by RFC0234) (Status: UNKNOWN) + +0205 NETCRT - a character display protocol. R.T. Braden. Aug-06-1971. + (Not online) (Status: UNKNOWN) + +0206 User Telnet - description of an initial implementation. J.E. + White. Aug-09-1971. (Not online) (Status: UNKNOWN) + +0207 September Network Working Group meeting. A. Vezza. Aug-09-1971. + (Format: TXT=3356 bytes) (Obsoleted by RFC0212) (Status: UNKNOWN) + +0208 Address tables. A.M. McKenzie. Aug-09-1971. (Format: TXT=5858 + bytes) (Status: UNKNOWN) + +0209 Host/IMP interface documentation. B. Cosell. Aug-13-1971. + (Format: TXT=2566 bytes) (Status: UNKNOWN) + +0210 Improvement of Flow Control. W. Conrad. Aug-16-1971. (Format: + TXT=3329 bytes) (Status: UNKNOWN) + +0211 ARPA Network mailing lists. J.B. North. Aug-18-1971. (Not online) + (Obsoletes RFC0168) (Obsoleted by RFC0300) (Status: UNKNOWN) + +0212 NWG meeting on network usage. Information Sciences Institute + University of Southern California. Aug-23-1971. (Format: TXT=4356 + bytes) (Obsoletes RFC0207) (Updated by RFC0222) (Status: UNKNOWN) + +0213 IMP System change notification. B. Cosell. Aug-20-1971. (Format: + TXT=1589 bytes) (Status: UNKNOWN) + +0214 Network checkpoint. E. Harslem. Aug-21-1971. (Format: TXT=3152 + bytes) (Obsoletes RFC0198) (Status: UNKNOWN) + +0215 NCP, ICP, and Telnet: The Terminal IMP implementation. A.M. + McKenzie. Aug-30-1971. (Format: TXT=16645 bytes) (Status: UNKNOWN) + +0216 Telnet access to UCSB's On-Line System. J.E. White. Sep-08-1971. + (Not online) (Status: UNKNOWN) + +0217 Specifications changes for OLS, RJE/RJOR, and SMFS. J.E. White. + Sep-08-1971. (Format: TXT=2956 bytes) (Updates RFC0074, RFC0105, + RFC0122) (Status: UNKNOWN) + +0218 Changing the IMP status reporting facility. B. Cosell. + Sep-08-1971. (Format: TXT=1131 bytes) (Status: UNKNOWN) + +0219 User's view of the datacomputer. R. Winter. Sep-03-1971. (Not + online) (Status: UNKNOWN) + +0221 Mail Box Protocol: Version 2. R.W. Watson. Aug-27-1971. (Format: + TXT=9805 bytes) (Obsoletes RFC0196) (Obsoleted by RFC0278) (Status: + UNKNOWN) + +0222 Subject: System programmer's workshop. R.M. Metcalfe. + Sep-13-1971. (Not online) (Updates RFC0212) (Updated by RFC0234) + (Status: UNKNOWN) + +0223 Network Information Center schedule for network users. J.T. + Melvin, R.W. Watson. Sep-14-1971. (Format: TXT=5369 bytes) (Status: + UNKNOWN) + +0224 Comments on Mailbox Protocol. A.M. McKenzie. Sep-14-1971. + (Format: TXT=3583 bytes) (Status: UNKNOWN) + +0225 Rand/UCSB network graphics experiment. E. Harslem, R. Stoughton. + Sep-13-1971. (Format: TXT=13573 bytes) (Updates RFC0074) (Status: + UNKNOWN) + +0226 Standardization of host mnemonics. P.M. Karp. Sep-20-1971. + (Format: TXT=2012 bytes) (Obsoleted by RFC0247) (Status: UNKNOWN) + +0227 Data transfer rates (Rand/UCLA). J.F. Heafner, E. Harslem. + Sep-17-1971. (Format: TXT=2451 bytes) (Updates RFC0113) (Status: + UNKNOWN) + +0228 Clarification. D.C. Walden. Sep-22-1971. (Format: TXT=715 bytes) + (Updates RFC0070) (Status: UNKNOWN) + +0229 Standard host names. J. Postel. Sep-22-1971. (Format: TXT=3388 + bytes) (Obsoleted by RFC0236) (Status: UNKNOWN) + +0230 Toward reliable operation of minicomputer-based terminals on a + TIP. T. Pyke. Sep-24-1971. (Format: TXT=7040 bytes) (Status: UNKNOWN) + +0231 Service center standards for remote usage: A user's view. J.F. + Heafner, E. Harslem. Sep-21-1971. (Format: TXT=9692 bytes) (Status: + UNKNOWN) + +0232 Postponement of network graphics meeting. A. Vezza. Sep-23-1971. + (Format: TXT=899 bytes) (Status: UNKNOWN) + +0233 Standardization of host call letters. A. Bhushan, R. Metcalfe. + Sep-28-1971. (Format: TXT=3206 bytes) (Status: UNKNOWN) + +0234 Network Working Group meeting schedule. A. Vezza. Oct-05-1971. + (Format: TXT=1634 bytes) (Updates RFC0222, RFC0204) (Status: UNKNOWN) + +0235 Site status. E. Westheimer. Sep-27-1971. (Format: TXT=7994 bytes) + (Obsoleted by RFC0240) (Status: UNKNOWN) + +0236 Standard host names. J. Postel. Sep-27-1971. (Format: TXT=5112 + bytes) (Obsoletes RFC0229) (Status: UNKNOWN) + +0237 NIC view of standard host names. R.W. Watson. Oct-05-1971. + (Format: TXT=2212 bytes) (Obsoleted by RFC0273) (Status: UNKNOWN) + +0238 Comments on DTP and FTP proposals. R.T. Braden. Sep-29-1971. + (Format: TXT=2735 bytes) (Updates RFC0171, RFC0172) (Status: UNKNOWN) + +0239 Host mnemonics proposed in RFC 226 (NIC 7625). R.T. Braden. + Sep-23-1971. (Format: TXT=2236 bytes) (Also RFC0226, RFC0229, + RFC0236) (Status: UNKNOWN) + +0240 Site Status. A.M. McKenzie. Sep-30-1971. (Format: TXT=7948 bytes) + (Obsoletes RFC0235) (Obsoleted by RFC0252) (Status: UNKNOWN) + +0241 Connecting computers to MLC ports. A.M. McKenzie. Sep-29-1971. + (Format: TXT=3739 bytes) (Status: UNKNOWN) + +0242 Data Descriptive Language for Shared Data. L. Haibt, A.P. + Mullery. Jul-19-1971. (Format: TXT=18151 bytes) (Status: UNKNOWN) + +0243 Network and data sharing bibliography. A.P. Mullery. Oct-05-1971. + (Format: TXT=12432 bytes) (Obsoleted by RFC0290) (Status: UNKNOWN) + +0245 Reservations for Network Group meeting. C. Falls. Oct-05-1971. + (Format: TXT=1142 bytes) (Status: UNKNOWN) + +0246 Network Graphics meeting. A. Vezza. Oct-05-1971. (Format: TXT=856 + bytes) (Status: UNKNOWN) + +0247 Proffered set of standard host names. P.M. Karp. Oct-12-1971. + (Format: TXT=7122 bytes) (Obsoletes RFC0226) (Status: UNKNOWN) + +0249 Coordination of equipment and supplies purchase. R.F. Borelli. + Oct-08-1971. (Format: TXT=4561 bytes) (Status: UNKNOWN) + +0250 Some thoughts on file transfer. H. Brodie. Oct-07-1971. (Format: + TXT=2446 bytes) (Status: UNKNOWN) + +0251 Weather data. D. Stern. Oct-13-1971. (Format: TXT=1907 bytes) + (Status: UNKNOWN) + +0252 Network host status. E. Westheimer. Oct-08-1971. (Format: + TXT=5531 bytes) (Obsoletes RFC0240) (Obsoleted by RFC0255) (Status: + UNKNOWN) + +0253 Second Network Graphics meeting details. J.A. Moorer. + Oct-19-1971. (Format: TXT=1981 bytes) (Status: UNKNOWN) + +0254 Scenarios for using ARPANET computers. A. Bhushan. Oct-29-1971. + (Not online) (Status: UNKNOWN) + +0255 Status of network hosts. E. Westheimer. Oct-26-1971. (Format: + TXT=4002 bytes) (Obsoletes RFC0252) (Obsoleted by RFC0266) (Status: + UNKNOWN) + +0256 IMPSYS change notification. B. Cosell. Nov-03-1971. (Format: + TXT=1240 bytes) (Status: UNKNOWN) + +0263 "Very Distant" Host interface. A.M. McKenzie. Dec-17-1971. + (Format: TXT=3914 bytes) (Status: UNKNOWN) + +0264 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, + E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. + White. Jan-04-1972. (Not online) (Obsoletes RFC0171) (Obsoleted by + RFC0354) (Updated by RFC0310) (Also RFC0265) (Status: UNKNOWN) + +0265 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, + E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. + Watson, J. White. Nov-17-1971. (Format: TXT=3914 bytes) (Obsoletes + RFC0172) (Obsoleted by RFC0354) (Updated by RFC0281, RFC0294, + RFC0310) (Also RFC0264) (Status: UNKNOWN) + +0266 Network host status. E. Westheimer. Nov-08-1971. (Format: + TXT=3174 bytes) (Obsoletes RFC0255) (Obsoleted by RFC0267) (Status: + UNKNOWN) + +0267 Network Host Status. E. Westheimer. Nov-22-1971. (Format: + TXT=7862 bytes) (Obsoletes RFC0266) (Obsoleted by RFC0287) (Status: + UNKNOWN) + +0268 Graphics facilities information. J. Postel. Nov-24-1971. (Format: + TXT=1298 bytes) (Status: UNKNOWN) + +0269 Some Experience with File Transfer. H. Brodie. Dec-06-1971. + (Format: TXT=5961 bytes) (Updates RFC0122) (Status: UNKNOWN) + +0270 Correction to BBN Report No. 1822 (NIC NO 7958). A.M. McKenzie. + Jan-01-1972. (Format: TXT=1371 bytes) (Updates NIC 7959) (Status: + UNKNOWN) + +0271 IMP System change notifications. B. Cosell. Jan-03-1972. (Format: + TXT=4022 bytes) (Status: UNKNOWN) + +0273 More on standard host names. R.W. Watson. Oct-18-1971. (Format: + TXT=4589 bytes) (Obsoletes RFC0237) (Status: UNKNOWN) + +0274 Establishing a local guide for network usage. E. Forman. + Nov-01-1971. (Format: TXT=7114 bytes) (Status: UNKNOWN) + +0276 NIC course. R.W. Watson. Nov-08-1971. (Format: TXT=1183 bytes) + (Status: UNKNOWN) + +0278 Revision of the Mail Box Protocol. A.K. Bhushan, R.T. Braden, E. + Harslem, J.F. Heafner, A.M. McKenzie, J.T. Melvin, R.L. Sundberg, + R.W. Watson, J.E. White. Nov-17-1971. (Format: TXT=7526 bytes) + (Obsoletes RFC0221) (Status: UNKNOWN) + +0280 A Draft of Host Names. R.W. Watson. Nov-17-1971. (Format: + TXT=3629 bytes) (Status: UNKNOWN) + +0281 Suggested addition to File Transfer Protocol. A.M. McKenzie. + Dec-08-1971. (Format: TXT=12006 bytes) (Updates RFC0265) (Status: + UNKNOWN) + +0282 Graphics meeting report. M.A. Padlipsky. Dec-08-1971. (Format: + TXT=18100 bytes) (Status: UNKNOWN) + +0283 NETRJT: Remote Job Service Protocol for TIPS. R.T. Braden. + Dec-20-1971. (Format: TXT=18771 bytes) (Updates RFC0189) (Status: + UNKNOWN) + +0285 Network graphics. D. Huff. Dec-15-1971. (Format: TXT=18076 bytes) + (Status: UNKNOWN) + +0286 Network Library Information System. E. Forman. Dec-21-1971. + (Format: TXT=2079 bytes) (Status: UNKNOWN) + +0287 Status of Network Hosts. E. Westheimer. Dec-22-1971. (Format: + TXT=9217 bytes) (Obsoletes RFC0267) (Obsoleted by RFC0288) (Status: + UNKNOWN) + +0288 Network host status. E. Westheimer. Jan-06-1972. (Format: + TXT=8501 bytes) (Obsoletes RFC0287) (Obsoleted by RFC0293) (Updated + by RFC0293) (Status: UNKNOWN) + +0289 What we hope is an official list of host names. R.W. Watson. + Dec-21-1971. (Format: TXT=5069 bytes) (Obsoleted by RFC0384) (Status: + UNKNOWN) + +0290 Computer networks and data sharing: A bibliography. A.P. Mullery. + Jan-11-1972. (Format: TXT=34329 bytes) (Obsoletes RFC0243) (Status: + UNKNOWN) + +0291 Data Management Meeting Announcement. D.B. McKay. Jan-14-1972. + (Format: TXT=3375 bytes) (Status: UNKNOWN) + +0292 Graphics Protocol: Level 0 only. J.C. Michener, I.W. Cotton, K.C. + Kelley, D.E. Liddle, E. Meyer. Jan-12-1972. (Format: TXT=22342 bytes) + (Status: UNKNOWN) + +0293 Network Host Status. E. Westheimer. Jan-18-1972. (Format: + TXT=7639 bytes) (Obsoletes RFC0288) (Obsoleted by RFC0298) (Updates + RFC0288) (Status: UNKNOWN) + +0294 The Use of "Set Data Type" Transaction in File Transfer Protocol. + A.K. Bhushan. Jan-25-1972. (Format: TXT=3924 bytes) (Updates RFC0265) + (Status: UNKNOWN) + +0295 Report of the Protocol Workshop, 12 October 1971. J. Postel. + Jan-02-1972. (Format: TXT=5432 bytes) (Status: UNKNOWN) + +0296 DS-1 display system. D.E. Liddle. Jan-27-1972. (Not online) + (Status: UNKNOWN) + +0297 TIP Message Buffers. D.C. Walden. Jan-31-1972. (Format: TXT=3517 + bytes) (Status: UNKNOWN) + +0298 Network host status. E. Westheimer. Feb-11-1972. (Format: + TXT=8770 bytes) (Obsoletes RFC0293) (Obsoleted by RFC0306) (Status: + UNKNOWN) + +0299 Information Management System. D. Hopkin. Feb-11-1972. (Format: + TXT=1825 bytes) (Status: UNKNOWN) + +0300 ARPA Network mailing lists. J.B. North. Jan-25-1972. (Format: + TXT=16357 bytes) (Obsoletes RFC0211) (Obsoleted by RFC0303) (Status: + UNKNOWN) + +0301 BBN IMP (#5) and NCC Schedule March 4, 1971. R. Alter. + Feb-11-1972. (Format: TXT=1487 bytes) (Status: UNKNOWN) + +0302 Exercising The ARPANET. R.F. Bryan. Feb-08-1972. (Format: + TXT=5452 bytes) (Status: UNKNOWN) + +0303 ARPA Network mailing lists. Network Information Center. Stanford + Research Institute. Mar-03-1972. (Format: TXT=18193 bytes) (Obsoletes + RFC0300) (Obsoleted by RFC0329) (Status: UNKNOWN) + +0304 Data management system proposal for the ARPA network. D.B. McKay. + Feb-17-1972. (Not online) (Status: UNKNOWN) + +0305 Unknown Host Numbers. R. Alter. Feb-23-1972. (Format: TXT=1998 + bytes) (Status: UNKNOWN) + +0306 Network host status. E. Westheimer. Feb-15-1972. (Format: + TXT=7485 bytes) (Obsoletes RFC0298) (Obsoleted by RFC0315) (Status: + UNKNOWN) + +0307 Using network Remote Job Entry. E. Harslem. Feb-24-1972. (Format: + TXT=12032 bytes) (Status: UNKNOWN) + +0308 ARPANET host availability data. M. Seriff. Mar-13-1972. (Format: + TXT=5948 bytes) (Status: UNKNOWN) + +0309 Data and File Transfer Workshop Announcement. A.K. Bhushan. + Mar-17-1972. (Format: TXT=9404 bytes) (Status: UNKNOWN) + +0310 Another Look at Data and File Transfer Protocols. A.K. Bhushan. + Apr-03-1972. (Format: TXT=18593 bytes) (Updates RFC0264, RFC0265) + (Status: UNKNOWN) + +0311 New Console Attachments to the USCB Host. R.F. Bryan. + Feb-29-1972. (Format: TXT=3141 bytes) (Status: UNKNOWN) + +0312 Proposed Change in IMP-to-Host Protocol. A.M. McKenzie. + Mar-22-1972. (Format: TXT=3562 bytes) (Status: UNKNOWN) + +0313 Computer based instruction. T.C. O'Sullivan. Mar-06-1972. + (Format: TXT=19880 bytes) (Status: UNKNOWN) + +0314 Network Graphics Working Group Meeting. I.W. Cotton. Mar-14-1972. + (Format: TXT=1836 bytes) (Status: UNKNOWN) + +0315 Network Host Status. E. Westheimer. Mar-08-1972. (Format: + TXT=7818 bytes) (Obsoletes RFC0306) (Obsoleted by RFC0319) (Status: + UNKNOWN) + +0316 ARPA Network Data Management Working Group. D.B. McKay, A.P. + Mullery. Feb-23-1972. (Format: TXT=15494 bytes) (Status: UNKNOWN) + +0317 Official Host-Host Protocol Modification: Assigned Link Numbers. + J. Postel. Mar-20-1972. (Format: TXT=1593 bytes) (Obsoleted by + RFC0604) (Status: UNKNOWN) + +0318 Telnet Protocols. J. Postel. Apr-03-1972. (Format: TXT=34928 + bytes) (Updates RFC0158) (Updated by RFC0435) (Also RFC0139, RFC0158) + (Status: UNKNOWN) + +0319 Network Host Status. E. Westheimer. Mar-21-1972. (Format: + TXT=8955 bytes) (Obsoletes RFC0315) (Updated by RFC0326) (Status: + UNKNOWN) + +0320 Workshop on Hard Copy Line Printers. R. Reddy. Mar-27-1972. (Not + online) (Status: UNKNOWN) + +0321 CBI Networking Activity at MITRE. P.M. Karp. Mar-24-1972. + (Format: TXT=20500 bytes) (Status: UNKNOWN) + +0322 Well known socket numbers. V. Cerf, J. Postel. Mar-26-1972. + (Format: TXT=1735 bytes) (Status: UNKNOWN) + +0323 Formation of Network Measurement Group (NMG). V. Cerf. + Mar-23-1972. (Format: TXT=15777 bytes) (Updated by RFC0388) (Status: + UNKNOWN) + +0324 RJE Protocol meeting. J. Postel. Apr-03-1972. (Format: TXT=1176 + bytes) (Status: UNKNOWN) + +0325 Network Remote Job Entry program - NETRJS. G. Hicks. Apr-06-1972. + (Format: TXT=17499 bytes) (Status: UNKNOWN) + +0326 Network Host Status. E. Westheimer. Apr-03-1972. (Format: + TXT=7944 bytes) (Obsoleted by RFC0330) (Updates RFC0319) (Status: + UNKNOWN) + +0327 Data and File Transfer workshop notes. A.K. Bhushan. Apr-27-1972. + (Format: TXT=11792 bytes) (Status: UNKNOWN) + +0328 Suggested Telnet Protocol Changes. J. Postel. Apr-29-1972. + (Format: TXT=2685 bytes) (Status: UNKNOWN) + +0329 ARPA Network Mailing Lists. Network Information Center. Stanford + Research Institute. May-17-1972. (Format: TXT=23861 bytes) (Obsoletes + RFC0303) (Obsoleted by RFC0363) (Status: UNKNOWN) + +0330 Network Host Status. E. Westheimer. Apr-13-1972. (Format: + TXT=8085 bytes) (Obsoletes RFC0326) (Obsoleted by RFC0332) (Status: + UNKNOWN) + +0331 IMP System Change Notification. J.M. McQuillan. Apr-19-1972. + (Format: TXT=2339 bytes) (Obsoleted by RFC0343) (Status: UNKNOWN) + +0332 Network Host Status. E. Westheimer. Apr-25-1972. (Format: + TXT=8427 bytes) (Obsoletes RFC0330) (Obsoleted by RFC0342) (Updates + RFC0330) (Status: UNKNOWN) + +0333 Proposed experiment with a Message Switching Protocol. R.D. + Bressler, D. Murphy, D.C. Walden. May-15-1972. (Format: TXT=62507 + bytes) (Status: UNKNOWN) + +0334 Network Use on May 8. A.M. McKenzie. May-01-1972. (Format: + TXT=1376 bytes) (Status: UNKNOWN) + +0335 New Interface - IMP/360. R.F. Bryan. May-01-1972. (Format: + TXT=934 bytes) (Status: UNKNOWN) + +0336 Level 0 Graphic Input Protocol. I.W. Cotton. May-05-1972. + (Format: TXT=3787 bytes) (Status: UNKNOWN) + +0338 EBCDIC/ASCII Mapping for Network RJE. R.T. Braden. May-17-1972. + (Not online) (Status: UNKNOWN) + +0339 MLTNET: A "Multi Telnet" Subsystem for Tenex. R. Thomas. + May-05-1972. (Format: TXT=7941 bytes) (Status: UNKNOWN) + +0340 Proposed Telnet Changes. T.C. O'Sullivan. May-15-1972. (Format: + TXT=2656 bytes) (Also RFC0328) (Status: UNKNOWN) + +0342 Network Host Status. E. Westheimer. May-15-1972. (Format: + TXT=8382 bytes) (Obsoletes RFC0332) (Obsoleted by RFC0344) (Status: + UNKNOWN) + +0343 IMP System change notification. A.M. McKenzie. May-19-1972. + (Format: TXT=3370 bytes) (Obsoletes RFC0331) (Obsoleted by RFC0359) + (Status: UNKNOWN) + +0344 Network Host Status. E. Westheimer. May-22-1972. (Format: + TXT=8221 bytes) (Obsoletes RFC0342) (Obsoleted by RFC0353) (Status: + UNKNOWN) + +0345 Interest in Mixed Integer Programming (MPSX on NIC 360/91 at + CCN). K.C. Kelley. May-26-1972. (Format: TXT=1999 bytes) (Status: + UNKNOWN) + +0346 Satellite Considerations. J. Postel. May-30-1972. (Format: + TXT=2778 bytes) (Status: UNKNOWN) + +0347 Echo process. J. Postel. May-30-1972. (Format: TXT=1377 bytes) + (Status: UNKNOWN) + +0348 Discard Process. J. Postel. May-30-1972. (Format: TXT=1181 bytes) + (Status: UNKNOWN) + +0349 Proposed Standard Socket Numbers. J. Postel. May-30-1972. + (Format: TXT=1663 bytes) (Obsoleted by RFC0433) (Also RFC0322, + RFC0204) (Status: UNKNOWN) + +0350 User Accounts for UCSB On-Line System. R. Stoughton. May-18-1972. + (Format: TXT=5117 bytes) (Status: UNKNOWN) + +0351 Graphics information form for the ARPANET graphics resources + notebook. D. Crocker. Jun-05-1972. (Format: TXT=2150 bytes) (Status: + UNKNOWN) + +0352 TIP Site Information Form. D. Crocker. Jun-05-1972. (Format: + TXT=2266 bytes) (Status: UNKNOWN) + +0353 Network host status. E. Westheimer. Jun-12-1972. (Format: + TXT=8747 bytes) (Obsoletes RFC0344) (Obsoleted by RFC0362) (Status: + UNKNOWN) + +0354 File Transfer Protocol. A.K. Bhushan. Jul-08-1972. (Format: + TXT=58074 bytes) (Obsoletes RFC0264, RFC0265) (Obsoleted by RFC0542) + (Updated by RFC0385, RFC0454, RFC0683) (Status: UNKNOWN) + +0355 Response to NWG/RFC 346. J. Davidson. Jun-09-1972. (Format: + TXT=3717 bytes) (Status: UNKNOWN) + +0356 ARPA Network Control Center. R. Alter. Jun-21-1972. (Format: + TXT=1963 bytes) (Status: UNKNOWN) + +0357 Echoing strategy for satellite links. J. Davidson. Jun-26-1972. + (Format: TXT=30103 bytes) (Status: UNKNOWN) + +0359 Status of the Release of the New IMP System (2600). D.C. Walden. + Jun-22-1972. (Format: TXT=2015 bytes) (Obsoletes RFC0343) (Status: + UNKNOWN) + +0360 Proposed Remote Job Entry Protocol. C. Holland. Jun-24-1972. (Not + online) (Obsoleted by RFC0407) (Status: UNKNOWN) + +0361 Deamon Processes on Host 106. R.D. Bressler. Jul-05-1972. + (Format: TXT=1480 bytes) (Status: UNKNOWN) + +0362 Network Host Status. E. Westheimer. Jun-28-1972. (Format: + TXT=8631 bytes) (Obsoletes RFC0353) (Obsoleted by RFC0366) (Status: + UNKNOWN) + +0363 ARPA Network mailing lists. Network Information Center. Stanford + Research Institute. Aug-08-1972. (Format: TXT=25356 bytes) (Obsoletes + RFC0329) (Obsoleted by RFC0402) (Status: UNKNOWN) + +0364 Serving remote users on the ARPANET. M.D. Abrams. Jul-11-1972. + (Format: TXT=11253 bytes) (Status: UNKNOWN) + +0365 Letter to All TIP Users. D.C. Walden. Jul-11-1972. (Format: + TXT=10331 bytes) (Status: UNKNOWN) + +0366 Network Host Status. E. Westheimer. Jul-11-1972. (Format: + TXT=8278 bytes) (Obsoletes RFC0362) (Obsoleted by RFC0367) (Status: + UNKNOWN) + +0367 Network host status. E. Westheimer. Jul-19-1972. (Format: + TXT=8057 bytes) (Obsoletes RFC0366) (Obsoleted by RFC0370) (Status: + UNKNOWN) + +0368 Comments on "Proposed Remote Job Entry Protocol". R.T. Braden. + Jul-21-1972. (Format: TXT=3883 bytes) (Status: UNKNOWN) + +0369 Evaluation of ARPANET services January-March, 1972. J.R. Pickens. + Jul-25-1972. (Format: TXT=24414 bytes) (Status: UNKNOWN) + +0370 Network Host Status. E. Westheimer. Jul-31-1972. (Format: + TXT=8389 bytes) (Obsoletes RFC0367) (Updated by RFC0376) (Status: + UNKNOWN) + +0371 Demonstration at International Computer Communications + Conference. R.E. Kahn. Jul-12-1972. (Format: TXT=3728 bytes) (Status: + UNKNOWN) + +0372 Notes on a Conversation with Bob Kahn on the ICCC. R.W. Watson. + Jul-12-1972. (Format: TXT=6040 bytes) (Status: UNKNOWN) + +0373 Arbitrary Character Sets. J. McCarthy. Jul-14-1972. (Format: + TXT=7783 bytes) (Status: UNKNOWN) + +0374 IMP System Announcement. A.M. McKenzie. Jul-19-1972. (Format: + TXT=3963 bytes) (Status: UNKNOWN) + +0376 Network Host Status. E. Westheimer. Aug-08-1972. (Format: + TXT=8861 bytes) (Updates RFC0370) (Status: UNKNOWN) + +0377 Using TSO via ARPA Network Virtual Terminal. R.T. Braden. + Aug-10-1972. (Format: TXT=7093 bytes) (Status: UNKNOWN) + +0378 Traffic statistics (July 1972). A.M. McKenzie. Aug-10-1972. + (Format: TXT=5730 bytes) (Obsoleted by RFC0391) (Status: UNKNOWN) + +0379 Using TSO at CCN. R.T. Braden. Aug-11-1972. (Format: TXT=8674 + bytes) (Status: UNKNOWN) + +0381 Three aids to improved network operation. J.M. McQuillan. + Jul-26-1972. (Format: TXT=9305 bytes) (Updated by RFC0394) (Status: + UNKNOWN) + +0382 Mathematical Software on the ARPA Network. L. McDaniel. + Aug-03-1972. (Format: TXT=2041 bytes) (Status: UNKNOWN) + +0384 Official site idents for organizations in the ARPA Network. J.B. + North. Aug-28-1972. (Format: TXT=10401 bytes) (Obsoletes RFC0289) + (Status: UNKNOWN) + +0385 Comments on the File Transfer Protocol. A.K. Bhushan. + Aug-18-1972. (Format: TXT=13030 bytes) (Updates RFC0354) (Updated by + RFC0414) (Status: UNKNOWN) + +0386 Letter to TIP users-2. B. Cosell, D.C. Walden. Aug-16-1972. + (Format: TXT=12475 bytes) (Status: UNKNOWN) + +0387 Some experiences in implementing Network Graphics Protocol Level + 0. K.C. Kelley, J. Meir. Aug-10-1972. (Format: TXT=9059 bytes) + (Updated by RFC0401) (Status: UNKNOWN) + +0388 NCP statistics. V. Cerf. Aug-23-1972. (Format: TXT=8458 bytes) + (Updates RFC0323) (Status: UNKNOWN) + +0389 UCLA Campus Computing Network Liaison Staff for ARPA Network. B. + Noble. Aug-30-1972. (Format: TXT=2819 bytes) (Obsoleted by RFC0423) + (Status: UNKNOWN) + +0390 TSO Scenario. R.T. Braden. Sep-12-1972. (Format: TXT=6103 bytes) + (Status: UNKNOWN) + +0391 Traffic statistics (August 1972). A.M. McKenzie. Sep-15-1972. + (Format: TXT=4695 bytes) (Obsoletes RFC0378) (Status: UNKNOWN) + +0392 Measurement of host costs for transmitting network data. G. + Hicks, B.D. Wessler. Sep-20-1972. (Format: TXT=14462 bytes) (Status: + UNKNOWN) + +0393 Comments on Telnet Protocol Changes. J.M. Winett. Oct-03-1972. + (Format: TXT=9435 bytes) (Also RFC0109, RFC0139, RFC0158, RFC0318, + RFC0328) (Status: UNKNOWN) + +0394 Two Proposed Changes to the IMP-Host Protocol. J.M. McQuillan. + Sep-27-1972. (Format: TXT=5780 bytes) (Updates RFC0381) (Status: + UNKNOWN) + +0395 Switch Settings on IMPs and TIPs. J.M. McQuillan. Oct-03-1972. + (Format: TXT=1827 bytes) (Status: UNKNOWN) + +0396 Network Graphics Working Group Meeting - Second Iteration. S. + Bunch. Nov-13-1972. (Format: TXT=2224 bytes) (Updated by RFC0474) + (Status: UNKNOWN) + +0398 ICP Sockets. J.R. Pickens, E. Faeh. Sep-22-1972. (Format: + TXT=3846 bytes) (Status: UNKNOWN) + +0399 SMFS Login and Logout. M. Krilanovich. Sep-26-1972. (Format: + TXT=3024 bytes) (Obsoleted by RFC0431) (Updates RFC0122) (Status: + UNKNOWN) + +0400 Traffic Statistics (September 1972). A.M. McKenzie. Oct-18-1972. + (Format: TXT=5435 bytes) (Status: UNKNOWN) + +0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates. + J. Hansen. Oct-23-1972. (Format: TXT=3894 bytes) (Updates RFC0387) + (Status: UNKNOWN) + +0402 ARPA Network Mailing Lists. J.B. North. Oct-26-1972. (Format: + TXT=28162 bytes) (Obsoletes RFC0363) (Status: UNKNOWN) + +0403 Desirability of a network 1108 service. G. Hicks. Jan-10-1973. + (Not online) (Status: UNKNOWN) + +0404 Host Address Changes Involving Rand and ISI. A.M. McKenzie. + Oct-05-1972. (Format: TXT=944 bytes) (Updated by RFC0405) (Status: + UNKNOWN) + +0405 Correction to RFC 404. A.M. McKenzie. Oct-10-1972. (Format: + TXT=1103 bytes) (Updates RFC0404) (Status: UNKNOWN) + +0406 Scheduled IMP Software Releases. J.M. McQuillan. Oct-10-1972. + (Format: TXT=2468 bytes) (Status: UNKNOWN) + +0407 Remote Job Entry Protocol. R.D. Bressler, R. Guida, A.M. + McKenzie. Oct-16-1972. (Format: TXT=47556 bytes) (Obsoletes RFC0360) + (Status: HISTORIC) + +0408 NETBANK. A.D. Owen, J. Postel. Oct-25-1972. (Format: TXT=1645 + bytes) (Status: UNKNOWN) + +0409 Tenex interface to UCSB's Simple-Minded File System. J.E. White. + Dec-08-1972. (Not online) (Status: UNKNOWN) + +0410 Removal of the 30-Second Delay When Hosts Come Up. J.M. + McQuillan. Nov-10-1972. (Format: TXT=3964 bytes) (Status: UNKNOWN) + +0411 New MULTICS Network Software Features. M.A. Padlipsky. + Nov-14-1972. (Format: TXT=3024 bytes) (Status: UNKNOWN) + +0412 User FTP Documentation. G. Hicks. Nov-27-1972. (Format: TXT=17510 + bytes) (Status: UNKNOWN) + +0413 Traffic statistics (October 1972). A.M. McKenzie. Nov-13-1972. + (Format: TXT=16145 bytes) (Status: UNKNOWN) + +0414 File Transfer Protocol (FTP) status and further comments. A.K. + Bhushan. Dec-29-1972. (Format: TXT=12845 bytes) (Updates RFC0385) + (Status: UNKNOWN) + +0415 Tenex bandwidth. H. Murray. Nov-29-1972. (Format: TXT=3456 bytes) + (Status: UNKNOWN) + +0416 ARC System Will Be Unavailable for Use During Thanksgiving Week. + J.C. Norton. Nov-07-1972. (Format: TXT=2205 bytes) (Status: UNKNOWN) + +0417 Link usage violation. J. Postel, C. Kline. Dec-06-1972. (Format: + TXT=901 bytes) (Status: UNKNOWN) + +0418 Server file transfer under TSS/360 at NASA Ames. W. Hathaway. + Nov-27-1972. (Not online) (Status: UNKNOWN) + +0419 To: Network liaisons and station agents. A. Vezza. Dec-12-1972. + (Format: TXT=1252 bytes) (Status: UNKNOWN) + +0420 CCA ICCC weather demo. H. Murray. Jan-04-1973. (Format: TXT=14752 + bytes) (Status: UNKNOWN) + +0421 Software Consulting Service for Network Users. A.M. McKenzie. + Nov-27-1972. (Format: TXT=2483 bytes) (Status: UNKNOWN) + +0422 Traffic statistics (November 1972). A.M. McKenzie. Dec-11-1972. + (Format: TXT=5494 bytes) (Status: UNKNOWN) + +0423 UCLA Campus Computing Network Liaison Staff for ARPANET. B. + Noble. Dec-12-1972. (Format: TXT=2890 bytes) (Obsoletes RFC0389) + (Status: UNKNOWN) + +0425 "But my NCP costs $500 a day". R.D. Bressler. Dec-19-1972. + (Format: TXT=1763 bytes) (Status: UNKNOWN) + +0426 Reconnection Protocol. R. Thomas. Jan-26-1973. (Format: TXT=26548 + bytes) (Status: UNKNOWN) + +0429 Character Generator Process. J. Postel. Dec-12-1972. (Format: + TXT=1319 bytes) (Status: UNKNOWN) + +0430 Comments on File Transfer Protocol. R.T. Braden. Feb-07-1973. + (Format: TXT=18696 bytes) (Status: UNKNOWN) + +0431 Update on SMFS Login and Logout. M. Krilanovich. Dec-15-1972. + (Format: TXT=4196 bytes) (Obsoletes RFC0399) (Updates RFC0122) + (Status: UNKNOWN) + +0432 Network logical map. N. Neigus. Dec-29-1972. (Format: TXT=1291, + PDF=148880, PS=1344571 bytes) (Status: UNKNOWN) + +0433 Socket number list. J. Postel. Dec-22-1972. (Format: TXT=6834 + bytes) (Obsoletes RFC0349) (Obsoleted by RFC0503) (Status: UNKNOWN) + +0434 IMP/TIP memory retrofit schedule. A.M. McKenzie. Jan-04-1973. + (Format: TXT=2242 bytes) (Obsoleted by RFC0447) (Status: UNKNOWN) + +0435 Telnet issues. B. Cosell, D.C. Walden. Jan-05-1973. (Format: + TXT=23019 bytes) (Updates RFC0318) (Status: UNKNOWN) + +0436 Announcement of RJS at UCSB. M. Krilanovich. Jan-10-1973. + (Format: TXT=2579 bytes) (Status: UNKNOWN) + +0437 Data Reconfiguration Service at UCSB. E. Faeh. Jun-30-1973. + (Format: TXT=21562 bytes) (Status: UNKNOWN) + +0438 FTP server-server interaction. R. Thomas, R. Clements. + Jan-15-1973. (Format: TXT=6514 bytes) (Status: UNKNOWN) + +0439 PARRY encounters the DOCTOR. V. Cerf. Jan-21-1973. (Format: + TXT=7066 bytes) (Status: UNKNOWN) + +0440 Scheduled network software maintenance. D.C. Walden. Jan-01-1973. + (Format: TXT=1870 bytes) (Status: UNKNOWN) + +0441 Inter-Entity Communication - an experiment. R.D. Bressler, R. + Thomas. Jan-19-1973. (Format: TXT=12876 bytes) (Status: UNKNOWN) + +0442 Current flow-control scheme for IMPSYS. V. Cerf. Jan-24-1973. + (Format: TXT=16315 bytes) (Updated by RFC0449) (Status: UNKNOWN) + +0443 Traffic statistics (December 1972). A.M. McKenzie. Jan-18-1973. + (Format: TXT=5664 bytes) (Status: UNKNOWN) + +0445 IMP/TIP preventive maintenance schedule. A.M. McKenzie. + Jan-22-1973. (Format: TXT=2668 bytes) (Status: UNKNOWN) + +0446 Proposal to consider a network program resource notebook. L.P. + Deutsch. Jan-25-1973. (Format: TXT=3053 bytes) (Status: UNKNOWN) + +0447 IMP/TIP memory retrofit schedule. A.M. McKenzie. Jan-29-1973. + (Format: TXT=2332 bytes) (Obsoletes RFC0434) (Obsoleted by RFC0476) + (Status: UNKNOWN) + +0448 Print files in FTP. R.T. Braden. Feb-27-1973. (Format: TXT=6838 + bytes) (Status: UNKNOWN) + +0449 Current flow-control scheme for IMPSYS. D.C. Walden. Jan-06-1973. + (Format: TXT=1662 bytes) (Updates RFC0442) (Status: UNKNOWN) + +0450 MULTICS sampling timeout change. M.A. Padlipsky. Feb-08-1973. + (Format: TXT=924 bytes) (Status: UNKNOWN) + +0451 Tentative proposal for a Unified User Level Protocol. M.A. + Padlipsky. Feb-22-1973. (Format: TXT=8114 bytes) (Status: UNKNOWN) + +0452 TELENET Command at Host LL. J. Winett. Feb-08-1973. (Not online) + (Status: UNKNOWN) + +0453 Meeting announcement to discuss a network mail system. M.D. + Kudlick. Feb-07-1973. (Format: TXT=4572 bytes) (Status: UNKNOWN) + +0454 File Transfer Protocol - meeting announcement and a new proposed + document. A.M. McKenzie. Feb-16-1973. (Format: TXT=78966 bytes) + (Updates RFC0354) (Status: UNKNOWN) + +0455 Traffic statistics (January 1973). A.M. McKenzie. Feb-12-1973. + (Format: TXT=5746 bytes) (Status: UNKNOWN) + +0456 Memorandum: Date change of mail meeting. M.D. Kudlick. + Feb-13-1973. (Format: TXT=950 bytes) (Status: UNKNOWN) + +0457 TIPUG. D.C. Walden. Feb-15-1973. (Format: TXT=845 bytes) (Status: + UNKNOWN) + +0458 Mail retrieval via FTP. R.D. Bressler, R. Thomas. Feb-20-1973. + (Format: TXT=2705 bytes) (Status: UNKNOWN) + +0459 Network questionnaires. W. Kantrowitz. Feb-26-1973. (Format: + TXT=1950 bytes) (Status: UNKNOWN) + +0460 NCP survey. C. Kline. Feb-13-1973. (Not online) (Status: UNKNOWN) + +0461 Telnet Protocol meeting announcement. A.M. McKenzie. Feb-14-1973. + (Format: TXT=1966 bytes) (Status: UNKNOWN) + +0462 Responding to user needs. J. Iseli, D. Crocker. Feb-22-1973. + (Format: TXT=2808 bytes) (Status: UNKNOWN) + +0463 FTP comments and response to RFC 430. A.K. Bhushan. Feb-21-1973. + (Format: TXT=5729 bytes) (Status: UNKNOWN) + +0464 Resource notebook framework. M.D. Kudlick. Feb-27-1973. (Format: + TXT=3684 bytes) (Status: UNKNOWN) + +0466 Telnet logger/server for host LL-67. J.M. Winett. Feb-27-1973. + (Not online) (Status: UNKNOWN) + +0467 Proposed change to Host-Host Protocol: Resynchronization of + connection status. J.D. Burchfiel, R.S. Tomlinson. Feb-20-1973. + (Format: TXT=14325 bytes) (Updated by RFC0492) (Status: UNKNOWN) + +0468 FTP data compression. R.T. Braden. Mar-08-1973. (Format: + TXT=14909 bytes) (Status: UNKNOWN) + +0469 Network mail meeting summary. M.D. Kudlick. Mar-08-1973. (Format: + TXT=17774 bytes) (Status: UNKNOWN) + +0470 Change in socket for TIP news facility. R. Thomas. Mar-13-1973. + (Format: TXT=1014 bytes) (Status: UNKNOWN) + +0471 Workshop on multi-site executive programs. R. Thomas. + Mar-13-1973. (Format: TXT=3339 bytes) (Status: UNKNOWN) + +0472 Illinois' reply to Maxwell's request for graphics information + (NIC 14925). S. Bunch. Mar-01-1973. (Format: TXT=4780 bytes) (Status: + UNKNOWN) + +0473 MIX and MIXAL?. D.C. Walden. Feb-28-1973. (Format: TXT=868 bytes) + (Status: UNKNOWN) + +0474 Announcement of NGWG meeting: Call for papers. S. Bunch. + Mar-01-1973. (Format: TXT=1170 bytes) (Updates RFC0396) (Status: + UNKNOWN) + +0475 FTP and network mail system. A.K. Bhushan. Mar-06-1973. (Not + online) (Status: UNKNOWN) + +0476 IMP/TIP memory retrofit schedule (rev 2). A.M. McKenzie. + Mar-07-1973. (Format: TXT=2281 bytes) (Obsoletes RFC0447) (Status: + UNKNOWN) + +0477 Remote Job Service at UCSB. M. Krilanovich. May-23-1973. (Format: + TXT=40535 bytes) (Status: UNKNOWN) + +0478 FTP server-server interaction - II. R.D. Bressler, R. Thomas. + Mar-26-1973. (Format: TXT=4199 bytes) (Status: UNKNOWN) + +0479 Use of FTP by the NIC Journal. J.E. White. Mar-08-1973. (Format: + TXT=11183 bytes) (Status: UNKNOWN) + +0480 Host-dependent FTP parameters. J.E. White. Mar-08-1973. (Format: + TXT=2084 bytes) (Status: UNKNOWN) + +0482 Traffic statistics (February 1973). A.M. McKenzie. Mar-12-1973. + (Format: TXT=6162 bytes) (Status: UNKNOWN) + +0483 Cancellation of the resource notebook framework meeting. M.D. + Kudlick. Mar-14-1973. (Format: TXT=1021 bytes) (Status: UNKNOWN) + +0485 MIX and MIXAL at UCSB. J.R. Pickens. Mar-19-1973. (Format: + TXT=2226 bytes) (Status: UNKNOWN) + +0486 Data transfer revisited. R.D. Bressler. Mar-20-1973. (Format: + TXT=4664 bytes) (Status: UNKNOWN) + +0487 Free file transfer. R.D. Bressler. Apr-06-1973. (Format: TXT=3249 + bytes) (Status: UNKNOWN) + +0488 NLS classes at network sites. M.F. Auerbach. Mar-23-1973. + (Format: TXT=3806 bytes) (Status: UNKNOWN) + +0489 Comment on resynchronization of connection status proposal. J. + Postel. Mar-26-1973. (Format: TXT=2010 bytes) (Status: UNKNOWN) + +0490 Surrogate RJS for UCLA-CCN. J.R. Pickens. Mar-06-1973. (Format: + TXT=9858 bytes) (Status: UNKNOWN) + +0491 What is "Free"?. M.A. Padlipsky. Apr-12-1973. (Format: TXT=5872 + bytes) (Status: UNKNOWN) + +0492 Response to RFC 467. E. Meyer. Apr-18-1973. (Format: TXT=18791 + bytes) (Updates RFC0467) (Status: UNKNOWN) + +0493 Graphics Protocol. J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. + Liddle, E. Meyer. Apr-26-1973. (Not online) (Status: UNKNOWN) + +0494 Availability of MIX and MIXAL in the Network. D.C. Walden. + Apr-20-1973. (Format: TXT=2007 bytes) (Status: UNKNOWN) + +0495 Telnet Protocol specifications. A.M. McKenzie. May-01-1973. + (Format: TXT=4260 bytes) (Obsoletes RFC0158) (Status: UNKNOWN) + +0496 TNLS quick reference card is available. M.F. Auerbach. + Apr-05-1973. (Format: TXT=1110 bytes) (Status: UNKNOWN) + +0497 Traffic statistics (March 1973). A.M. McKenzie. Apr-10-1973. (Not + online) (Status: UNKNOWN) + +0498 On mail service to CCN. R.T. Braden. Apr-17-1973. (Format: + TXT=5315 bytes) (Status: UNKNOWN) + +0499 Harvard's network RJE. B.R. Reussow. Apr-01-1973. (Format: + TXT=12584 bytes) (Status: UNKNOWN) + +0500 Integration of data management systems on a computer network. A. + Shoshani, I. Spiegler. Apr-16-1973. (Not online) (Status: UNKNOWN) + +0501 Un-muddling "free file transfer". K.T. Pogran. May-11-1973. + (Format: TXT=13177 bytes) (Status: UNKNOWN) + +0503 Socket number list. N. Neigus, J. Postel. Apr-12-1973. (Format: + TXT=8690 bytes) (Obsoletes RFC0433) (Obsoleted by RFC0739) (Status: + UNKNOWN) + +0504 Distributed resources workshop announcement. R. Thomas. + Apr-30-1973. (Format: TXT=9061 bytes) (Status: UNKNOWN) + +0505 Two solutions to a file transfer access problem. M.A. Padlipsky. + Jun-25-1973. (Format: TXT=7476 bytes) (Status: UNKNOWN) + +0506 FTP command naming problem. M.A. Padlipsky. Jun-26-1973. (Format: + TXT=1974 bytes) (Status: UNKNOWN) + +0508 Real-time data transmission on the ARPANET. L. Pfeifer, J. + McAfee. May-07-1973. (Not online) (Status: UNKNOWN) + +0509 Traffic statistics (April 1973). A.M. McKenzie. Apr-07-1973. + (Format: TXT=6538 bytes) (Status: UNKNOWN) + +0510 Request for network mailbox addresses. J.E. White. May-30-1973. + (Format: TXT=4150 bytes) (Status: UNKNOWN) + +0511 Enterprise phone service to NIC from ARPANET sites. J.B. North. + May-23-1973. (Format: TXT=4664 bytes) (Status: UNKNOWN) + +0512 More on lost message detection. W. Hathaway. May-23-1973. + (Format: TXT=3641 bytes) (Status: UNKNOWN) + +0513 Comments on the new Telnet specifications. W. Hathaway. + May-30-1973. (Format: TXT=7980 bytes) (Status: UNKNOWN) + +0514 Network make-work. W. Kantrowitz. Jun-05-1973. (Format: TXT=8734 + bytes) (Status: UNKNOWN) + +0515 Specifications for datalanguage: Version 0/9. R. Winter. + Jun-06-1973. (Not online) (Status: UNKNOWN) + +0516 Lost message detection. J. Postel. May-18-1973. (Format: TXT=4086 + bytes) (Status: UNKNOWN) + +0518 ARPANET accounts. N. Vaughan, E.J. Feinler. Jun-19-1973. (Format: + TXT=12880 bytes) (Status: UNKNOWN) + +0519 Resource evaluation. J.R. Pickens. Jun-01-1973. (Not online) + (Status: UNKNOWN) + +0520 Memo to FTP group: Proposal for File Access Protocol. J.D. Day. + Jun-25-1973. (Format: TXT=16825 bytes) (Status: UNKNOWN) + +0521 Restricted use of IMP DDT. A.M. McKenzie. May-30-1973. (Format: + TXT=3724 bytes) (Status: UNKNOWN) + +0522 Traffic statistics (May 1973). A.M. McKenzie. Jun-05-1973. (Not + online) (Status: UNKNOWN) + +0523 SURVEY is in operation again. A.K. Bhushan. Jun-05-1973. (Format: + TXT=2852 bytes) (Status: UNKNOWN) + +0524 Proposed Mail Protocol. J.E. White. Jun-13-1973. (Not online) + (Status: UNKNOWN) + +0525 MIT-MATHLAB meets UCSB-OLS -an example of resource sharing. W. + Parrish, J.R. Pickens. Jun-01-1973. (Not online) (Status: UNKNOWN) + +0526 Technical meeting: Digital image processing software systems. + W.K. Pratt. Jun-25-1973. (Format: TXT=4062 bytes) (Status: UNKNOWN) + +0527 ARPAWOCKY. D.L. Covill. May-01-1973. (Format: TXT=1857 bytes) + (Status: UNKNOWN) + +0528 Software checksumming in the IMP and network reliability. J.M. + McQuillan. Jun-20-1973. (Not online) (Status: UNKNOWN) + +0529 Note on protocol synch sequences. A.M. McKenzie, R. Thomas, R.S. + Tomlinson, K.T. Pogran. Jun-29-1973. (Format: TXT=9068 bytes) + (Status: UNKNOWN) + +0530 Report on the Survey project. A.K. Bhushan. Jun-22-1973. (Not + online) (Status: UNKNOWN) + +0531 Feast or famine? A response to two recent RFC's about network + information. M.A. Padlipsky. Jun-26-1973. (Format: TXT=5070 bytes) + (Status: UNKNOWN) + +0532 UCSD-CC Server-FTP facility. R.G. Merryman. Jul-12-1973. (Not + online) (Status: UNKNOWN) + +0533 Message-ID numbers. D.C. Walden. Jul-17-1973. (Format: TXT=2102 + bytes) (Status: UNKNOWN) + +0534 Lost message detection. D.C. Walden. Jul-17-1973. (Format: + TXT=3227 bytes) (Status: UNKNOWN) + +0535 Comments on File Access Protocol. R. Thomas. Jul-25-1973. (Not + online) (Status: UNKNOWN) + +0537 Announcement of NGG meeting July 16-17. S. Bunch. Jun-27-1973. + (Format: TXT=2695 bytes) (Status: UNKNOWN) + +0538 Traffic statistics (June 1973). A.M. McKenzie. Jul-05-1973. (Not + online) (Status: UNKNOWN) + +0539 Thoughts on the mail protocol proposed in RFC 524. D. Crocker, J. + Postel. Jul-07-1973. (Format: TXT=6213 bytes) (Status: UNKNOWN) + +0542 File Transfer Protocol. N. Neigus. Aug-12-1973. (Format: + TXT=100666 bytes) (Obsoletes RFC0354) (Obsoleted by RFC0765) (Updated + by RFC0614, RFC0640) (Also RFC0454, RFC0495) (Status: UNKNOWN) + +0543 Network journal submission and delivery. N.D. Meyer. Jul-24-1973. + (Not online) (Status: UNKNOWN) + +0544 Locating on-line documentation at SRI-ARC. N.D. Meyer, K. Kelley. + Jul-13-1973. (Format: TXT=1541 bytes) (Status: UNKNOWN) + +0545 Of what quality be the UCSB resources evaluators?. J.R. Pickens. + Jul-23-1973. (Not online) (Status: UNKNOWN) + +0546 Tenex load averages for July 1973. R. Thomas. Aug-10-1973. (Not + online) (Status: UNKNOWN) + +0547 Change to the Very Distant Host specification. D.C. Walden. + Aug-13-1973. (Not online) (Status: UNKNOWN) + +0548 Hosts using the IMP Going Down message. D.C. Walden. Aug-16-1973. + (Format: TXT=1435 bytes) (Status: UNKNOWN) + +0549 Minutes of Network Graphics Group meeting, 15-17 July 1973. J.C. + Michener. Jul-17-1973. (Not online) (Status: UNKNOWN) + +0550 NIC NCP experiment. L.P. Deutsch. Aug-24-1973. (Format: TXT=3688 + bytes) (Status: UNKNOWN) + +0552 Single access to standard protocols. A.D. Owen. Jul-13-1973. + (Format: TXT=1404 bytes) (Status: UNKNOWN) + +0553 Draft design for a text/graphics protocol. C.H. Irby, K. Victor. + Jul-14-1973. (Not online) (Status: UNKNOWN) + +0555 Responses to critiques of the proposed mail protocol. J.E. White. + Jul-30-1973. (Format: TXT=21521 bytes) (Status: UNKNOWN) + +0556 Traffic statistics (July 1973). A.M. McKenzie. Aug-13-1973. (Not + online) (Status: UNKNOWN) + +0557 Revelations in network host measurements. B.D. Wessler. + Aug-30-1973. (Not online) (Status: UNKNOWN) + +0559 Comments on The New Telnet Protocol and its Implementation. A.K. + Bhushan. Aug-15-1973. (Format: TXT=10643 bytes) (Status: UNKNOWN) + +0560 Remote Controlled Transmission and Echoing Telnet option. D. + Crocker, J. Postel. Aug-18-1973. (Not online) (Status: UNKNOWN) + +0561 Standardizing Network Mail Headers. A.K. Bhushan, K.T. Pogran, + R.S. Tomlinson, J.E. White. Sep-05-1973. (Format: TXT=6159 bytes) + (Updated by RFC0680) (Status: UNKNOWN) + +0562 Modifications to the Telnet specification. A.M. McKenzie. + Aug-28-1973. (Not online) (Status: UNKNOWN) + +0563 Comments on the RCTE Telnet option. J. Davidson. Aug-28-1973. + (Format: TXT=10788 bytes) (Status: UNKNOWN) + +0565 Storing network survey data at the datacomputer. D. Cantor. + Aug-28-1973. (Format: TXT=9307 bytes) (Status: UNKNOWN) + +0566 Traffic statistics (August 1973). A.M. McKenzie. Sep-04-1973. + (Not online) (Status: UNKNOWN) + +0567 Cross Country Network Bandwidth. L.P. Deutsch. Sep-06-1973. + (Format: TXT=1529 bytes) (Updated by RFC0568) (Status: UNKNOWN) + +0568 Response to RFC 567 - cross country network bandwidth. J.M. + McQuillan. Sep-18-1973. (Format: TXT=3244 bytes) (Updates RFC0567) + (Status: UNKNOWN) + +0569 NETED: A Common Editor for the ARPA Network. M.A. Padlipsky. + Oct-15-1973. (Format: TXT=17717 bytes) (Status: HISTORIC) + +0570 Experimental input mapping between NVT ASCII and UCSB On Line + System. J.R. Pickens. Oct-30-1973. (Not online) (Status: UNKNOWN) + +0571 Tenex FTP problem. R.T. Braden. Nov-15-1973. (Not online) + (Status: UNKNOWN) + +0573 Data and file transfer: Some measurement results. A.K. Bhushan. + Sep-14-1973. (Not online) (Status: UNKNOWN) + +0574 Announcement of a mail facility at UCSB. M. Krilanovich. + Sep-26-1973. (Not online) (Status: UNKNOWN) + +0576 Proposal for modifying linking. K. Victor. Sep-26-1973. (Not + online) (Status: UNKNOWN) + +0577 Mail priority. D. Crocker. Oct-18-1973. (Not online) (Status: + UNKNOWN) + +0578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle. A.K. Bhushan, N.D. + Ryan. Oct-29-1973. (Not online) (Status: UNKNOWN) + +0579 Traffic statistics (September 1973). A.M. McKenzie. Nov-26-1973. + (Not online) (Status: UNKNOWN) + +0580 Note to Protocol Designers and Implementers. J. Postel. + Oct-25-1973. (Format: TXT=1451 bytes) (Updated by RFC0582) (Status: + UNKNOWN) + +0581 Corrections to RFC 560: Remote Controlled Transmission and + Echoing Telnet Option. D. Crocker, J. Postel. Nov-02-1973. (Not + online) (Status: UNKNOWN) + +0582 Comments on RFC 580: Machine readable protocols. R. Clements. + Nov-05-1973. (Not online) (Updates RFC0580) (Status: UNKNOWN) + +0584 Charter for ARPANET Users Interest Working Group. J. Iseli, D. + Crocker, N. Neigus. Nov-06-1973. (Format: TXT=3461 bytes) (Status: + UNKNOWN) + +0585 ARPANET users interest working group meeting. D. Crocker, N. + Neigus, E.J. Feinler, J. Iseli. Nov-06-1973. (Format: TXT=18243 + bytes) (Status: UNKNOWN) + +0586 Traffic statistics (October 1973). A.M. McKenzie. Nov-08-1973. + (Not online) (Status: UNKNOWN) + +0587 Announcing new Telnet options. J. Postel. Nov-13-1973. (Not + online) (Status: UNKNOWN) + +0588 London node is now up. A.V. Stokes. Oct-29-1973. (Not online) + (Status: UNKNOWN) + +0589 CCN NETRJS server messages to remote user. R.T. Braden. + Nov-26-1973. (Format: TXT=7998 bytes) (Status: UNKNOWN) + +0590 MULTICS address change. M.A. Padlipsky. Nov-19-1973. (Not online) + (Status: UNKNOWN) + +0591 Addition to the Very Distant Host specifications. D.C. Walden. + Nov-29-1973. (Format: TXT=901 bytes) (Status: UNKNOWN) + +0592 Some thoughts on system design to facilitate resource sharing. + R.W. Watson. Nov-20-1973. (Not online) (Status: UNKNOWN) + +0593 Telnet and FTP implementation schedule change. A.M. McKenzie, J. + Postel. Nov-29-1973. (Format: TXT=2506 bytes) (Status: UNKNOWN) + +0594 Speedup of Host-IMP interface. J.D. Burchfiel. Dec-10-1973. (Not + online) (Status: UNKNOWN) + +0595 Second thoughts in defense of the Telnet Go-Ahead. W. Hathaway. + Dec-12-1973. (Format: TXT=13507 bytes) (Status: UNKNOWN) + +0596 Second thoughts on Telnet Go-Ahead. E.A. Taft. Dec-08-1973. + (Format: TXT=11919 bytes) (Status: UNKNOWN) + +0597 Host status. N. Neigus, E.J. Feinler. Dec-12-1973. (Format: + TXT=11678 bytes) (Updated by RFC0603) (Status: UNKNOWN) + +0598 RFC index - December 5, 1973. Network Information Center. + Stanford Research Institute. Dec-05-1973. (Not online) (Status: + UNKNOWN) + +0599 Update on NETRJS. R.T. Braden. Dec-13-1973. (Format: TXT=16590 + bytes) (Obsoletes RFC0189) (Obsoleted by RFC0740) (Status: UNKNOWN) + +0600 Interfacing an Illinois plasma terminal to the ARPANET. A. + Berggreen. Nov-26-1973. (Not online) (Status: UNKNOWN) + +0601 Traffic statistics (November 1973). A.M. McKenzie. Dec-14-1973. + (Format: TXT=9100 bytes) (Status: UNKNOWN) + +0602 "The stockings were hung by the chimney with care". R.M. + Metcalfe. Dec-27-1973. (Format: TXT=1988 bytes) (Status: UNKNOWN) + +0603 Response to RFC 597: Host status. J.D. Burchfiel. Dec-31-1973. + (Format: TXT=1482 bytes) (Updates RFC0597) (Updated by RFC0613) + (Status: UNKNOWN) + +0604 Assigned link numbers. J. Postel. Dec-26-1973. (Format: TXT=2758 + bytes) (Obsoletes RFC0317) (Obsoleted by RFC0739) (Status: UNKNOWN) + +0606 Host names on-line. L.P. Deutsch. Dec-29-1973. (Format: TXT=6855 + bytes) (Status: UNKNOWN) + +0607 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg. + Jan-07-1974. (Format: TXT=8652 bytes) (Obsoleted by RFC0624) (Updated + by RFC0614) (Status: UNKNOWN) + +0608 Host names on-line. M.D. Kudlick. Jan-10-1974. (Format: TXT=7010 + bytes) (Obsoleted by RFC0810) (Status: UNKNOWN) + +0609 Statement of upcoming move of NIC/NLS service. B. Ferguson. + Jan-10-1974. (Format: TXT=1260 bytes) (Status: UNKNOWN) + +0610 Further datalanguage design concepts. R. Winter, J. Hill, W. + Greiff. Dec-15-1973. (Format: TXT=198692 bytes) (Status: UNKNOWN) + +0611 Two changes to the IMP/Host Protocol to improve user/network + communications. D.C. Walden. Feb-14-1974. (Format: TXT=7481 bytes) + (Status: UNKNOWN) + +0612 Traffic statistics (December 1973). A.M. McKenzie. Jan-16-1974. + (Format: TXT=9667 bytes) (Status: UNKNOWN) + +0613 Network connectivity: A response to RFC 603. A.M. McKenzie. + Jan-21-1974. (Format: TXT=2557 bytes) (Updates RFC0603) (Status: + UNKNOWN) + +0614 Response to RFC 607: "Comments on the File Transfer Protocol". + K.T. Pogran, N. Neigus. Jan-28-1974. (Format: TXT=11409 bytes) + (Updates RFC0542, RFC0607) (Status: UNKNOWN) + +0615 Proposed Network Standard Data Pathname syntax. D. Crocker. + Mar-01-1974. (Format: TXT=9448 bytes) (Status: UNKNOWN) + +0616 Latest network maps. D.C. Walden. Feb-11-1973. (Not online) + (Status: UNKNOWN) + +0617 Note on socket number assignment. E.A. Taft. Feb-19-1974. + (Format: TXT=8062 bytes) (Status: UNKNOWN) + +0618 Few observations on NCP statistics. E.A. Taft. Feb-19-1974. + (Format: TXT=4929 bytes) (Status: UNKNOWN) + +0619 Mean round-trip times in the ARPANET. W. Naylor, H. Opderbeck. + Mar-07-1974. (Format: TXT=30946 bytes) (Status: UNKNOWN) + +0620 Request for monitor host table updates. B. Ferguson. Mar-01-1974. + (Format: TXT=1950 bytes) (Status: UNKNOWN) + +0621 NIC user directories at SRI ARC. M.D. Kudlick. Mar-06-1974. + (Format: TXT=1351 bytes) (Status: UNKNOWN) + +0622 Scheduling IMP/TIP down time. A.M. McKenzie. Mar-13-1974. + (Format: TXT=4367 bytes) (Status: UNKNOWN) + +0623 Comments on on-line host name service. M. Krilanovich. + Feb-22-1974. (Format: TXT=3740 bytes) (Status: UNKNOWN) + +0624 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg, + W. Hathaway, J.E. White. Feb-28-1974. (Format: TXT=10105 bytes) + (Obsoletes RFC0607) (Status: UNKNOWN) + +0625 On-line hostnames service. M.D. Kudlick, E.J. Feinler. + Mar-07-1974. (Format: TXT=2172 bytes) (Status: UNKNOWN) + +0626 On a possible lockup condition in IMP subnet due to message + sequencing. L. Kleinrock, H. Opderbeck. Mar-14-1974. (Format: + TXT=13150 bytes) (Status: UNKNOWN) + +0627 ASCII text file of hostnames. M.D. Kudlick, E.J. Feinler. + Mar-25-1974. (Format: TXT=2007 bytes) (Status: UNKNOWN) + +0628 Status of RFC numbers and a note on pre-assigned journal numbers. + M.L. Keeney. Mar-27-1974. (Format: TXT=1036 bytes) (Status: UNKNOWN) + +0629 Scenario for using the Network Journal. J.B. North. Mar-27-1974. + (Format: TXT=4504 bytes) (Status: UNKNOWN) + +0630 FTP error code usage for more reliable mail service. J. Sussmann. + Apr-10-1974. (Format: TXT=4070 bytes) (Status: UNKNOWN) + +0631 International meeting on minicomputers and data communication: + Call for papers. A. Danthine. Apr-17-1974. (Format: TXT=2707 bytes) + (Status: UNKNOWN) + +0632 Throughput degradations for single packet messages. H. Opderbeck. + May-20-1974. (Format: TXT=14563 bytes) (Status: UNKNOWN) + +0633 IMP/TIP preventive maintenance schedule. A.M. McKenzie. + Mar-18-1974. (Format: TXT=3733 bytes) (Obsoleted by RFC0638) (Status: + UNKNOWN) + +0634 Change in network address for Haskins Lab. A.M. McKenzie. + Apr-10-1974. (Format: TXT=1098 bytes) (Status: UNKNOWN) + +0635 Assessment of ARPANET protocols. V. Cerf. Apr-22-1974. (Not + online) (Status: UNKNOWN) + +0636 TIP/Tenex reliability improvements. J.D. Burchfiel, B. Cosell, + R.S. Tomlinson, D.C. Walden. Jun-10-1974. (Format: TXT=19914 bytes) + (Status: UNKNOWN) + +0637 Change of network address for SU-DSL. A.M. McKenzie. Apr-23-1974. + (Format: TXT=916 bytes) (Status: UNKNOWN) + +0638 IMP/TIP preventive maintenance schedule. A.M. McKenzie. + Apr-25-1974. (Format: TXT=4088 bytes) (Obsoletes RFC0633) (Status: + UNKNOWN) + +0640 Revised FTP reply codes. J. Postel. Jun-19-1974. (Format: + TXT=39670 bytes) (Updates RFC0542) (Status: UNKNOWN) + +0642 Ready line philosophy and implementation. J.D. Burchfiel. + Jul-05-1974. (Format: TXT=8414 bytes) (Status: UNKNOWN) + +0643 Network Debugging Protocol. E. Mader. Jul-01-1974. (Format: + TXT=12563 bytes) (Status: UNKNOWN) + +0644 On the problem of signature authentication for network mail. R. + Thomas. Jul-22-1974. (Format: TXT=9501 bytes) (Status: UNKNOWN) + +0645 Network Standard Data Specification syntax. D. Crocker. + Jun-26-1974. (Not online) (Status: UNKNOWN) + +0647 Proposed protocol for connecting host computers to ARPA-like + networks via front end processors. M.A. Padlipsky. Nov-12-1974. (Not + online) (Status: UNKNOWN) + +0651 Revised Telnet status option. D. Crocker. Oct-25-1974. (Format: + TXT=4360 bytes) (Obsoleted by RFC0859) (Status: UNKNOWN) + +0652 Telnet output carriage-return disposition option. D. Crocker. + Oct-25-1974. (Format: TXT=7003 bytes) (Status: HISTORIC) + +0653 Telnet output horizontal tabstops option. D. Crocker. + Oct-25-1974. (Format: TXT=4694 bytes) (Status: HISTORIC) + +0654 Telnet output horizontal tab disposition option. D. Crocker. + Oct-25-1974. (Format: TXT=6158 bytes) (Status: HISTORIC) + +0655 Telnet output formfeed disposition option. D. Crocker. + Oct-25-1974. (Format: TXT=5991 bytes) (Status: HISTORIC) + +0656 Telnet output vertical tabstops option. D. Crocker. Oct-25-1974. + (Format: TXT=4858 bytes) (Status: HISTORIC) + +0657 Telnet output vertical tab disposition option. D. Crocker. + Oct-25-1974. (Format: TXT=5759 bytes) (Status: HISTORIC) + +0658 Telnet output linefeed disposition. D. Crocker. Oct-25-1974. + (Format: TXT=6484 bytes) (Status: HISTORIC) + +0659 Announcing additional Telnet options. J. Postel. Oct-18-1974. + (Not online) (Status: UNKNOWN) + +0660 Some changes to the IMP and the IMP/Host interface. D.C. Walden. + Oct-23-1974. (Format: TXT=4991 bytes) (Status: UNKNOWN) + +0661 Protocol information. J. Postel. Nov-23-1974. (Not online) + (Status: UNKNOWN) + +0662 Performance improvement in ARPANET file transfers from Multics. + R. Kanodia. Nov-26-1974. (Format: TXT=8872 bytes) (Status: UNKNOWN) + +0663 Lost message detection and recovery protocol. R. Kanodia. + Nov-29-1974. (Format: TXT=44702 bytes) (Status: UNKNOWN) + +0666 Specification of the Unified User-Level Protocol. M.A. Padlipsky. + Nov-26-1974. (Not online) (Status: UNKNOWN) + +0667 BBN host ports. S.G. Chipman. Dec-17-1974. (Not online) (Status: + UNKNOWN) + +0669 November, 1974, survey of New-Protocol Telnet servers. D.W. + Dodds. Dec-04-1974. (Not online) (Status: UNKNOWN) + +0671 Note on Reconnection Protocol. R. Schantz. Dec-06-1974. (Not + online) (Status: UNKNOWN) + +0672 Multi-site data collection facility. R. Schantz. Dec-06-1974. + (Format: TXT=25736 bytes) (Status: UNKNOWN) + +0674 Procedure call documents: Version 2. J. Postel, J.E. White. + Dec-12-1974. (Format: TXT=12178 bytes) (Status: UNKNOWN) + +0675 Specification of Internet Transmission Control Program. V. Cerf, + Y. Dalal, C. Sunshine. Dec-01-1974. (Format: TXT=156874 bytes) + (Status: UNKNOWN) + +0677 Maintenance of duplicate databases. P.R. Johnson, R. Thomas. + Jan-27-1975. (Format: TXT=22990 bytes) (Status: UNKNOWN) + +0678 Standard file formats. J. Postel. Dec-19-1974. (Format: TXT=12393 + bytes) (Status: UNKNOWN) + +0679 February, 1975, survey of New-Protocol Telnet servers. D.W. + Dodds. Feb-21-1975. (Not online) (Status: UNKNOWN) + +0680 Message Transmission Protocol. T.H. Myer, D.A. Henderson. + Apr-30-1975. (Not online) (Updates RFC0561) (Status: UNKNOWN) + +0681 Network UNIX. S. Holmgren. Mar-18-1975. (Format: TXT=18874 bytes) + (Status: UNKNOWN) + +0683 FTPSRV - Tenex extension for paged files. R. Clements. + Apr-03-1975. (Format: TXT=8806 bytes) (Updates RFC0354) (Status: + UNKNOWN) + +0684 Commentary on procedure calling as a network protocol. R. + Schantz. Apr-15-1975. (Format: TXT=21164 bytes) (Status: UNKNOWN) + +0685 Response time in cross network debugging. M. Beeler. Apr-16-1975. + (Format: TXT=6914 bytes) (Status: UNKNOWN) + +0686 Leaving well enough alone. B. Harvey. May-10-1975. (Format: + TXT=24605 bytes) (Status: UNKNOWN) + +0687 IMP/Host and Host/IMP Protocol changes. D.C. Walden. Jun-02-1975. + (Format: TXT=6013 bytes) (Obsoleted by RFC0704) (Updated by RFC0690) + (Status: UNKNOWN) + +0688 Tentative schedule for the new Telnet implementation for the TIP. + D.C. Walden. Jun-04-1975. (Format: TXT=1593 bytes) (Status: UNKNOWN) + +0689 Tenex NCP finite state machine for connections. R. Clements. + May-23-1975. (Format: TXT=13101 bytes) (Status: UNKNOWN) + +0690 Comments on the proposed Host/IMP Protocol changes. J. Postel. + Jun-06-1975. (Format: TXT=7215 bytes) (Updates RFC0687) (Updated by + RFC0692) (Status: UNKNOWN) + +0691 One more try on the FTP. B. Harvey. Jun-06-1975. (Format: + TXT=32821 bytes) (Status: UNKNOWN) + +0692 Comments on IMP/Host Protocol changes (RFCs 687 and 690). S.M. + Wolfe. Jun-20-1975. (Format: TXT=2681 bytes) (Updates RFC0690) + (Status: UNKNOWN) + +0694 Protocol information. J. Postel. Jun-18-1975. (Not online) + (Status: UNKNOWN) + +0695 Official change in Host-Host Protocol. M. Krilanovich. + Jul-05-1975. (Format: TXT=3425 bytes) (Status: UNKNOWN) + +0696 Comments on the IMP/Host and Host/IMP Protocol changes. V.G. + Cerf. Jul-13-1975. (Not online) (Status: UNKNOWN) + +0697 CWD command of FTP. J. Lieb. Jul-14-1975. (Format: TXT=3047 + bytes) (Status: UNKNOWN) + +0698 Telnet extended ASCII option. T. Mock. Jul-23-1975. (Format: + TXT=5086 bytes) (Status: PROPOSED STANDARD) + +0699 Request For Comments summary notes: 600-699. J. Postel, J. + Vernon. Nov-01-1982. (Format: TXT=14688 bytes) (Status: + INFORMATIONAL) + +0700 Protocol experiment. E. Mader, W.W. Plummer, R.S. Tomlinson. + Aug-01-1974. (Format: TXT=14600 bytes) (Status: UNKNOWN) + +0701 August, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. + Aug-01-1974. (Format: TXT=3549 bytes) (Status: UNKNOWN) + +0702 September, 1974, survey of New-Protocol Telnet servers. D.W. + Dodds. Sep-25-1974. (Format: TXT=5386 bytes) (Status: UNKNOWN) + +0703 July, 1975, survey of New-Protocol Telnet Servers. D.W. Dodds. + Jul-11-1975. (Format: TXT=5691 bytes) (Status: UNKNOWN) + +0704 IMP/Host and Host/IMP Protocol change. P.J. Santos. Sep-15-1975. + (Format: TXT=7504 bytes) (Obsoletes RFC0687) (Status: UNKNOWN) + +0705 Front-end Protocol B6700 version. R.F. Bryan. Nov-05-1975. + (Format: TXT=70998 bytes) (Status: UNKNOWN) + +0706 On the junk mail problem. J. Postel. Nov-08-1975. (Format: + TXT=2085 bytes) (Status: UNKNOWN) + +0707 High-level framework for network-based resource sharing. J.E. + White. Dec-23-1975. (Format: TXT=57254 bytes) (Status: UNKNOWN) + +0708 Elements of a Distributed Programming System. J.E. White. + Jan-28-1976. (Format: TXT=57888 bytes) (Status: UNKNOWN) + +0709 Not Issued. + +0710 Not Issued. + +0711 Not Issued. + +0712 Distributed Capability Computing System (DCCS). J.E. Donnelley. + Feb-05-1976. (Not online) (Status: UNKNOWN) + +0713 MSDTP-Message Services Data Transmission Protocol. J. Haverty. + Apr-06-1976. (Format: TXT=41175 bytes) (Status: UNKNOWN) + +0714 Host-Host Protocol for an ARPANET-Type Network. A.M. McKenzie. + Apr-21-1976. (Not online) (Status: UNKNOWN) + +0715 Not Issued. + +0716 Interim Revision to Appendix F of BBN 1822. D.C. Walden, J. + Levin. May-24-1976. (Format: TXT=3345 bytes) (Status: UNKNOWN) + +0717 Assigned Network Numbers. J. Postel. Jul-01-1976. (Format: + TXT=2322 bytes) (Status: HISTORIC) + +0718 Comments on RCTE from the Tenex Implementation Experience. J. + Postel. Jun-30-1976. (Format: TXT=3829 bytes) (Status: UNKNOWN) + +0719 Discussion on RCTE. J. Postel. Jul-22-1976. (Format: TXT=4708 + bytes) (Status: UNKNOWN) + +0720 Address Specification Syntax for Network Mail. D. Crocker. + Aug-05-1976. (Format: TXT=6602 bytes) (Status: UNKNOWN) + +0721 Out-of-Band Control Signals in a Host-to-Host Protocol. L.L. + Garlick. Sep-01-1976. (Format: TXT=13566 bytes) (Status: UNKNOWN) + +0722 Thoughts on Interactions in Distributed Services. J. Haverty. + Sep-16-1976. (Format: TXT=29478 bytes) (Status: UNKNOWN) + +0723 Not Issued. + +0724 Proposed official standard for the format of ARPA Network + messages. D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson. + May-12-1977. (Format: TXT=75554 bytes) (Obsoleted by RFC0733) + (Status: UNKNOWN) + +0725 RJE protocol for a resource sharing network. J.D. Day, G.R. + Grossman. Mar-01-1977. (Format: TXT=44025 bytes) (Status: UNKNOWN) + +0726 Remote Controlled Transmission and Echoing Telnet option. J. + Postel, D. Crocker. Mar-08-1977. (Format: TXT=38651 bytes) (Status: + PROPOSED STANDARD) + +0727 Telnet logout option. M.R. Crispin. Apr-27-1977. (Format: + TXT=5674 bytes) (Status: PROPOSED STANDARD) + +0728 Minor pitfall in the Telnet Protocol. J.D. Day. Apr-27-1977. + (Format: TXT=2224 bytes) (Status: UNKNOWN) + +0729 Telnet byte macro option. D. Crocker. May-13-1977. (Format: + TXT=6509 bytes) (Obsoleted by RFC0735) (Status: UNKNOWN) + +0730 Extensible field addressing. J. Postel. May-20-1977. (Format: + TXT=9519 bytes) (Status: UNKNOWN) + +0731 Telnet Data Entry Terminal option. J.D. Day. Jun-27-1977. + (Format: TXT=61648 bytes) (Obsoleted by RFC0732) (Status: UNKNOWN) + +0732 Telnet Data Entry Terminal option. J.D. Day. Sep-12-1977. + (Format: TXT=57160 bytes) (Obsoletes RFC0731) (Updated by RFC1043) + (Status: UNKNOWN) + +0733 Standard for the format of ARPA network text messages. D. + Crocker, J. Vittal, K.T. Pogran, D.A. Henderson. Nov-21-1977. + (Format: TXT=73006 bytes) (Obsoletes RFC0724) (Obsoleted by RFC0822) + (Status: UNKNOWN) + +0734 SUPDUP Protocol. M.R. Crispin. Oct-07-1977. (Format: TXT=33256 + bytes) (Status: HISTORIC) + +0735 Revised Telnet byte macro option. D. Crocker, R.H. Gumpertz. + Nov-03-1977. (Format: TXT=10585 bytes) (Obsoletes RFC0729) (Status: + PROPOSED STANDARD) + +0736 Telnet SUPDUP option. M.R. Crispin. Oct-31-1977. (Format: + TXT=3081 bytes) (Status: PROPOSED STANDARD) + +0737 FTP extension: XSEN. K. Harrenstien. Oct-31-1977. (Format: + TXT=2127 bytes) (Status: UNKNOWN) + +0738 Time server. K. Harrenstien. Oct-31-1977. (Format: TXT=1851 + bytes) (Status: UNKNOWN) + +0739 Assigned numbers. J. Postel. Nov-11-1977. (Format: TXT=16346 + bytes) (Obsoletes RFC0604, RFC0503) (Obsoleted by RFC0750) (Status: + HISTORIC) + +0740 NETRJS Protocol. R.T. Braden. Nov-22-1977. (Format: TXT=38833 + bytes) (Obsoletes RFC0599) (Status: HISTORIC) + +0741 Specifications for the Network Voice Protocol (NVP). D. Cohen. + Nov-22-1977. (Format: TXT=57581 bytes) (Status: UNKNOWN) + +0742 NAME/FINGER Protocol. K. Harrenstien. Dec-30-1977. (Format: + TXT=12321 bytes) (Obsoleted by RFC1288, RFC1196, RFC1194) (Status: + UNKNOWN) + +0743 FTP extension: XRSQ/XRCP. K. Harrenstien. Dec-30-1977. (Format: + TXT=16249 bytes) (Status: UNKNOWN) + +0744 MARS - a Message Archiving and Retrieval Service. J. Sattley. + Jan-08-1978. (Format: TXT=10984 bytes) (Status: UNKNOWN) + +0745 JANUS interface specifications. M. Beeler. Mar-30-1978. (Format: + TXT=21453 bytes) (Status: UNKNOWN) + +0746 SUPDUP graphics extension. R. Stallman. Mar-17-1978. (Format: + TXT=30197 bytes) (Status: UNKNOWN) + +0747 Recent extensions to the SUPDUP Protocol. M.R. Crispin. + Mar-21-1978. (Format: TXT=2870 bytes) (Status: UNKNOWN) + +0748 Telnet randomly-lose option. M.R. Crispin. Apr-01-1978. (Format: + TXT=2741 bytes) (Status: UNKNOWN) + +0749 Telnet SUPDUP-Output option. B. Greenberg. Sep-18-1978. (Format: + TXT=8933 bytes) (Status: PROPOSED STANDARD) + +0750 Assigned numbers. J. Postel. Sep-26-1978. (Format: TXT=19979 + bytes) (Obsoletes RFC0739) (Obsoleted by RFC0755) (Status: HISTORIC) + +0751 Survey of FTP mail and MLFL. P.D. Lebling. Dec-10-1978. (Format: + TXT=10069 bytes) (Status: UNKNOWN) + +0752 Universal host table. M.R. Crispin. Jan-02-1979. (Format: + TXT=33793 bytes) (Status: UNKNOWN) + +0753 Internet Message Protocol. J. Postel. Mar-01-1979. (Format: + TXT=93363 bytes) (Status: UNKNOWN) + +0754 Out-of-net host addresses for mail. J. Postel. Apr-06-1979. + (Format: TXT=19212 bytes) (Status: UNKNOWN) + +0755 Assigned numbers. J. Postel. May-03-1979. (Format: TXT=22039 + bytes) (Obsoletes RFC0750) (Obsoleted by RFC0758) (Status: HISTORIC) + +0756 NIC name server - a datagram-based information utility. J.R. + Pickens, E.J. Feinler, J.E. Mathis. Jul-01-1979. (Format: TXT=23491 + bytes) (Status: UNKNOWN) + +0757 Suggested solution to the naming, addressing, and delivery + problem for ARPANET message systems. D.P. Deutsch. Sep-10-1979. + (Format: TXT=35618 bytes) (Status: UNKNOWN) + +0758 Assigned numbers. J. Postel. Aug-01-1979. (Format: TXT=22911 + bytes) (Obsoletes RFC0755) (Obsoleted by RFC0762) (Status: HISTORIC) + +0759 Internet Message Protocol. J. Postel. Aug-01-1980. (Format: + TXT=123606 bytes) (Status: HISTORIC) + +0760 DoD standard Internet Protocol. J. Postel. Jan-01-1980. (Format: + TXT=81507 bytes) (Obsoletes IEN 123) (Obsoleted by RFC0791) (Updated + by RFC0777) (Status: UNKNOWN) + +0761 DoD standard Transmission Control Protocol. J. Postel. + Jan-01-1980. (Format: TXT=167049 bytes) (Status: UNKNOWN) + +0762 Assigned numbers. J. Postel. Jan-01-1980. (Format: TXT=24668 + bytes) (Obsoletes RFC0758) (Obsoleted by RFC0770) (Status: HISTORIC) + +0763 Role mailboxes. M.D. Abrams. May-07-1980. (Format: TXT=942 bytes) + (Status: UNKNOWN) + +0764 Telnet Protocol specification. J. Postel. Jun-01-1980. (Format: + TXT=40005 bytes) (Obsoleted by RFC0854) (Status: UNKNOWN) + +0765 File Transfer Protocol specification. J. Postel. Jun-01-1980. + (Format: TXT=146641 bytes) (Obsoletes RFC0542) (Obsoleted by RFC0959) + (Status: UNKNOWN) + +0766 Internet Protocol Handbook: Table of contents. J. Postel. + Jul-01-1980. (Format: TXT=3465 bytes) (Obsoleted by RFC0774) (Status: + UNKNOWN) + +0767 Structured format for transmission of multi-media documents. J. + Postel. Aug-01-1980. (Format: TXT=59971 bytes) (Status: UNKNOWN) + +0768 User Datagram Protocol. J. Postel. Aug-28-1980. (Format: TXT=5896 + bytes) (Also STD0006) (Status: STANDARD) + +0769 Rapicom 450 facsimile file format. J. Postel. Sep-26-1980. + (Format: TXT=4079 bytes) (Status: UNKNOWN) + +0770 Assigned numbers. J. Postel. Sep-01-1980. (Format: TXT=26248 + bytes) (Obsoletes RFC0762) (Obsoleted by RFC0776) (Status: HISTORIC) + +0771 Mail transition plan. V.G. Cerf, J. Postel. Sep-01-1980. (Format: + TXT=18623 bytes) (Status: UNKNOWN) + +0772 Mail Transfer Protocol. S. Sluizer, J. Postel. Sep-01-1980. + (Format: TXT=61061 bytes) (Obsoleted by RFC0780) (Status: UNKNOWN) + +0773 Comments on NCP/TCP mail service transition strategy. V.G. Cerf. + Oct-01-1980. (Format: TXT=22181 bytes) (Status: UNKNOWN) + +0774 Internet Protocol Handbook: Table of contents. J. Postel. + Oct-01-1980. (Format: TXT=3452 bytes) (Obsoletes RFC0766) (Status: + UNKNOWN) + +0775 Directory oriented FTP commands. D. Mankins, D. Franklin, A.D. + Owen. Dec-01-1980. (Format: TXT=9511 bytes) (Status: UNKNOWN) + +0776 Assigned numbers. J. Postel. Jan-01-1981. (Format: TXT=30311 + bytes) (Obsoletes RFC0770) (Obsoleted by RFC0790) (Status: HISTORIC) + +0777 Internet Control Message Protocol. J. Postel. Apr-01-1981. + (Format: TXT=19407 bytes) (Obsoleted by RFC0792) (Updates RFC0760) + (Status: UNKNOWN) + +0778 DCNET Internet Clock Service. D.L. Mills. Apr-18-1981. (Format: + TXT=9464 bytes) (Status: HISTORIC) + +0779 Telnet send-location option. E. Killian. Apr-01-1981. (Format: + TXT=2564 bytes) (Status: PROPOSED STANDARD) + +0780 Mail Transfer Protocol. S. Sluizer, J. Postel. May-01-1981. + (Format: TXT=80352 bytes) (Obsoletes RFC0772) (Obsoleted by RFC0788) + (Status: UNKNOWN) + +0781 Specification of the Internet Protocol (IP) timestamp option. Z. + Su. May-01-1981. (Format: TXT=4002 bytes) (Status: UNKNOWN) + +0782 Virtual Terminal management model. J. Nabielsky, A.P. Skelton. + Jan-01-1981. (Format: TXT=43589 bytes) (Status: UNKNOWN) + +0783 TFTP Protocol (revision 2). K.R. Sollins. Jun-01-1981. (Format: + TXT=23522 bytes) (Obsoletes IEN 133) (Obsoleted by RFC1350) (Status: + UNKNOWN) + +0784 Mail Transfer Protocol: ISI TOPS20 implementation. S. Sluizer, J. + Postel. Jul-01-1981. (Format: TXT=5856 bytes) (Status: UNKNOWN) + +0785 Mail Transfer Protocol: ISI TOPS20 file definitions. S. Sluizer, + J. Postel. Jul-01-1981. (Format: TXT=7032 bytes) (Status: UNKNOWN) + +0786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface. S. + Sluizer, J. Postel. Jul-01-1981. (Format: TXT=3129 bytes) (Status: + UNKNOWN) + +0787 Connectionless data transmission survey/tutorial. A.L. Chapin. + Jul-01-1981. (Format: TXT=84265 bytes) (Status: UNKNOWN) + +0788 Simple Mail Transfer Protocol. J. Postel. Nov-01-1981. (Format: + TXT=109001 bytes) (Obsoletes RFC0780) (Obsoleted by RFC0821) (Status: + UNKNOWN) + +0789 Vulnerabilities of network control protocols: An example. E.C. + Rosen. Jul-01-1981. (Format: TXT=25541 bytes) (Status: UNKNOWN) + +0790 Assigned numbers. J. Postel. Sep-01-1981. (Format: TXT=35316 + bytes) (Obsoletes RFC0776) (Obsoleted by RFC0820) (Status: HISTORIC) + +0791 Internet Protocol. J. Postel. Sep-01-1981. (Format: TXT=97779 + bytes) (Obsoletes RFC0760) (Also STD0005) (Status: STANDARD) + +0792 Internet Control Message Protocol. J. Postel. Sep-01-1981. + (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950) + (Also STD0005) (Status: STANDARD) + +0793 Transmission Control Protocol. J. Postel. Sep-01-1981. (Format: + TXT=172710 bytes) (Also STD0007) (Status: STANDARD) + +0794 Pre-emption. V.G. Cerf. Sep-01-1981. (Format: TXT=5906 bytes) + (Updates IEN 125) (Status: UNKNOWN) + +0795 Service mappings. J. Postel. Sep-01-1981. (Format: TXT=5228 + bytes) (Status: UNKNOWN) + +0796 Address mappings. J. Postel. Sep-01-1981. (Format: TXT=11239 + bytes) (Obsoletes IEN 115) (Status: UNKNOWN) + +0797 Format for Bitmap files. A.R. Katz. Sep-01-1981. (Format: + TXT=3067 bytes) (Status: UNKNOWN) + +0798 Decoding facsimile data from the Rapicom 450. A.R. Katz. + Sep-01-1981. (Format: TXT=38867 bytes) (Status: UNKNOWN) + +0799 Internet name domains. D.L. Mills. Sep-01-1981. (Format: + TXT=13896 bytes) (Status: UNKNOWN) + +0800 Request For Comments summary notes: 700-799. J. Postel, J. + Vernon. Nov-01-1982. (Format: TXT=18354 bytes) (Status: + INFORMATIONAL) + +0801 NCP/TCP transition plan. J. Postel. Nov-01-1981. (Format: + TXT=42041 bytes) (Status: UNKNOWN) + +0802 ARPANET 1822L Host Access Protocol. A.G. Malis. Nov-01-1981. + (Format: TXT=62470 bytes) (Obsoleted by RFC0851) (Status: UNKNOWN) + +0803 Dacom 450/500 facsimile data transcoding. A. Agarwal, M.J. + O'Connor, D.L. Mills. Nov-02-1981. (Format: TXT=33826 bytes) (Status: + UNKNOWN) + +0804 CCITT draft recommendation T.4. International Telegraph and + Telephone Consultative Committee of the International + Telecommunication Union. Jan-01-1981. (Format: TXT=17025 bytes) + (Status: UNKNOWN) + +0805 Computer mail meeting notes. J. Postel. Feb-08-1982. (Format: + TXT=12522 bytes) (Status: UNKNOWN) + +0806 Proposed Federal Information Processing Standard: Specification + for message format for computer based message systems. National + Bureau of Standards. Sep-01-1981. (Format: TXT=216377 bytes) + (Obsoleted by RFC0841) (Status: UNKNOWN) + +0807 Multimedia mail meeting notes. J. Postel. Feb-09-1982. (Format: + TXT=11633 bytes) (Status: UNKNOWN) + +0808 Summary of computer mail services meeting held at BBN on 10 + January 1979. J. Postel. Mar-01-1982. (Format: TXT=15930 bytes) + (Status: UNKNOWN) + +0809 UCL facsimile system. T. Chang. Feb-01-1982. (Format: TXT=171153 + bytes) (Status: UNKNOWN) + +0810 DoD Internet host table specification. E.J. Feinler, K. + Harrenstien, Z. Su, V. White. Mar-01-1982. (Format: TXT=14196 bytes) + (Obsoletes RFC0608) (Obsoleted by RFC0952) (Status: UNKNOWN) + +0811 Hostnames Server. K. Harrenstien, V. White, E.J. Feinler. + Mar-01-1982. (Format: TXT=7771 bytes) (Obsoleted by RFC0953) (Status: + UNKNOWN) + +0812 NICNAME/WHOIS. K. Harrenstien, V. White. Mar-01-1982. (Format: + TXT=5389 bytes) (Obsoleted by RFC0954) (Status: UNKNOWN) + +0813 Window and Acknowledgement Strategy in TCP. D.D. Clark. + Jul-01-1982. (Format: TXT=38110 bytes) (Status: UNKNOWN) + +0814 Name, addresses, ports, and routes. D.D. Clark. Jul-01-1982. + (Format: TXT=24663 bytes) (Status: UNKNOWN) + +0815 IP datagram reassembly algorithms. D.D. Clark. Jul-01-1982. + (Format: TXT=14575 bytes) (Status: UNKNOWN) + +0816 Fault isolation and recovery. D.D. Clark. Jul-01-1982. (Format: + TXT=20106 bytes) (Status: UNKNOWN) + +0817 Modularity and efficiency in protocol implementation. D.D. Clark. + Jul-01-1982. (Format: TXT=45931 bytes) (Status: UNKNOWN) + +0818 Remote User Telnet service. J. Postel. Nov-01-1982. (Format: + TXT=3693 bytes) (Status: HISTORIC) + +0819 Domain naming convention for Internet user applications. Z. Su, + J. Postel. Aug-01-1982. (Format: TXT=35314 bytes) (Status: UNKNOWN) + +0820 Assigned numbers. J. Postel. Aug-14-1982. (Format: TXT=54213 + bytes) (Obsoletes RFC0790) (Obsoleted by RFC0870) (Status: HISTORIC) + +0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. (Format: + TXT=124482 bytes) (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also + STD0010) (Status: STANDARD) + +0822 Standard for the format of ARPA Internet text messages. D. + Crocker. Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733) + (Obsoleted by RFC2822) (Updated by RFC1123, RFC1138, RFC1148, + RFC1327, RFC2156) (Also STD0011) (Status: STANDARD) + +0823 DARPA Internet gateway. R.M. Hinden, A. Sheltzer. Sep-01-1982. + (Format: TXT=62620 bytes) (Updates IEN 109, IEN 30) (Status: + HISTORIC) + +0824 CRONUS Virtual Local Network. W.I. MacGregor, D.C. Tappan. + Aug-25-1982. (Format: TXT=58732 bytes) (Status: UNKNOWN) + +0825 Request for comments on Requests For Comments. J. Postel. + Nov-01-1982. (Format: TXT=4255 bytes) (Obsoleted by RFC1111, RFC1543, + RFC2223) (Status: UNKNOWN) + +0826 Ethernet Address Resolution Protocol: Or converting network + protocol addresses to 48.bit Ethernet address for transmission on + Ethernet hardware. D.C. Plummer. Nov-01-1982. (Format: TXT=22026 + bytes) (Also STD0037) (Status: STANDARD) + +0827 Exterior Gateway Protocol (EGP). E.C. Rosen. Oct-01-1982. + (Format: TXT=68436 bytes) (Updated by RFC0904) (Status: UNKNOWN) + +0828 Data communications: IFIP's international "network" of experts. + K. Owen. Aug-01-1982. (Format: TXT=29922 bytes) (Status: UNKNOWN) + +0829 Packet satellite technology reference sources. V.G. Cerf. + Nov-01-1982. (Format: TXT=10919 bytes) (Status: UNKNOWN) + +0830 Distributed system for Internet name service. Z. Su. Oct-01-1982. + (Format: TXT=31597 bytes) (Status: UNKNOWN) + +0831 Backup access to the European side of SATNET. R.T. Braden. + Dec-01-1982. (Format: TXT=11735 bytes) (Status: UNKNOWN) + +0832 Who talks TCP?. D. Smallberg. Dec-07-1982. (Format: TXT=42751 + bytes) (Obsoleted by RFC0833) (Status: UNKNOWN) + +0833 Who talks TCP?. D. Smallberg. Dec-14-1982. (Format: TXT=42973 + bytes) (Obsoletes RFC0832) (Obsoleted by RFC0834) (Status: UNKNOWN) + +0834 Who talks TCP?. D. Smallberg. Dec-22-1982. (Format: TXT=42764 + bytes) (Obsoletes RFC0833) (Obsoleted by RFC0835) (Status: UNKNOWN) + +0835 Who talks TCP?. D. Smallberg. Dec-29-1982. (Format: TXT=42959 + bytes) (Obsoletes RFC0834) (Obsoleted by RFC0836) (Status: UNKNOWN) + +0836 Who talks TCP?. D. Smallberg. Jan-05-1983. (Format: TXT=43643 + bytes) (Obsoletes RFC0835) (Obsoleted by RFC0837) (Status: UNKNOWN) + +0837 Who talks TCP?. D. Smallberg. Jan-12-1983. (Format: TXT=44864 + bytes) (Obsoletes RFC0836) (Obsoleted by RFC0838) (Status: UNKNOWN) + +0838 Who talks TCP?. D. Smallberg. Jan-20-1983. (Format: TXT=45033 + bytes) (Obsoletes RFC0837) (Obsoleted by RFC0839) (Status: UNKNOWN) + +0839 Who talks TCP?. D. Smallberg. Jan-26-1983. (Format: TXT=45175 + bytes) (Obsoletes RFC0838) (Obsoleted by RFC0842) (Status: UNKNOWN) + +0840 Official protocols. J. Postel. Apr-13-1983. (Format: TXT=33534 + bytes) (Obsoleted by RFC0880) (Status: HISTORIC) + +0841 Specification for message format for Computer Based Message + Systems. National Bureau of Standards. Jan-27-1983. (Format: + TXT=231871 bytes) (Obsoletes RFC0806) (Status: UNKNOWN) + +0842 Who talks TCP? - survey of 1 February 83. D. Smallberg. + Feb-03-1983. (Format: TXT=45962 bytes) (Obsoletes RFC0839) (Obsoleted + by RFC0843) (Status: UNKNOWN) + +0843 Who talks TCP? - survey of 8 February 83. D. Smallberg. + Feb-09-1983. (Format: TXT=46193 bytes) (Obsoletes RFC0842) (Obsoleted + by RFC0845) (Updated by RFC0844) (Status: UNKNOWN) + +0844 Who talks ICMP, too? - Survey of 18 February 1983. R. Clements. + Feb-18-1983. (Format: TXT=9078 bytes) (Updates RFC0843) (Status: + UNKNOWN) + +0845 Who talks TCP? - survey of 15 February 1983. D. Smallberg. + Feb-17-1983. (Format: TXT=45983 bytes) (Obsoletes RFC0843) (Obsoleted + by RFC0846) (Status: UNKNOWN) + +0846 Who talks TCP? - survey of 22 February 1983. D. Smallberg. + Feb-23-1983. (Format: TXT=45597 bytes) (Obsoletes RFC0845) (Obsoleted + by RFC0847) (Status: UNKNOWN) + +0847 Summary of Smallberg surveys. D. Smallberg, A. Westine, J. + Postel. Feb-01-1983. (Format: TXT=3789 bytes) (Obsoletes RFC0846) + (Status: UNKNOWN) + +0848 Who provides the "little" TCP services?. D. Smallberg. + Mar-14-1983. (Format: TXT=10985 bytes) (Status: UNKNOWN) + +0849 Suggestions for improved host table distribution. M.R. Crispin. + May-01-1983. (Format: TXT=5178 bytes) (Status: UNKNOWN) + +0850 Standard for interchange of USENET messages. M.R. Horton. + Jun-01-1983. (Format: TXT=43871 bytes) (Obsoleted by RFC1036) + (Status: UNKNOWN) + +0851 ARPANET 1822L Host Access Protocol. A.G. Malis. Apr-18-1983. + (Format: TXT=72042 bytes) (Obsoletes RFC0802) (Obsoleted by RFC0878) + (Status: UNKNOWN) + +0852 ARPANET short blocking feature. A.G. Malis. Apr-01-1983. (Format: + TXT=17151 bytes) (Status: UNKNOWN) + +0853 Not Issued. + +0854 Telnet Protocol Specification. J. Postel, J.K. Reynolds. + May-01-1983. (Format: TXT=39371 bytes) (Obsoletes RFC0764) (Also + STD0008) (Status: STANDARD) + +0855 Telnet Option Specifications. J. Postel, J.K. Reynolds. + May-01-1983. (Format: TXT=6218 bytes) (Obsoletes NIC 18640) (Also + STD0008) (Status: STANDARD) + +0856 Telnet Binary Transmission. J. Postel, J.K. Reynolds. + May-01-1983. (Format: TXT=9192 bytes) (Obsoletes NIC 15389) (Also + STD0027) (Status: STANDARD) + +0857 Telnet Echo Option. J. Postel, J.K. Reynolds. May-01-1983. + (Format: TXT=11143 bytes) (Obsoletes NIC 15390) (Also STD0028) + (Status: STANDARD) + +0858 Telnet Suppress Go Ahead Option. J. Postel, J.K. Reynolds. + May-01-1983. (Format: TXT=3825 bytes) (Obsoletes NIC 15392) (Also + STD0029) (Status: STANDARD) + +0859 Telnet Status Option. J. Postel, J.K. Reynolds. May-01-1983. + (Format: TXT=4443 bytes) (Obsoletes RFC0651) (Also STD0030) (Status: + STANDARD) + +0860 Telnet Timing Mark Option. J. Postel, J.K. Reynolds. May-01-1983. + (Format: TXT=8108 bytes) (Obsoletes NIC 16238) (Also STD0031) + (Status: STANDARD) + +0861 Telnet Extended Options: List Option. J. Postel, J.K. Reynolds. + May-01-1983. (Format: TXT=3181 bytes) (Obsoletes NIC 16239) (Also + STD0032) (Status: STANDARD) + +0862 Echo Protocol. J. Postel. May-01-1983. (Format: TXT=1294 bytes) + (Also STD0020) (Status: STANDARD) + +0863 Discard Protocol. J. Postel. May-01-1983. (Format: TXT=1297 + bytes) (Also STD0021) (Status: STANDARD) + +0864 Character Generator Protocol. J. Postel. May-01-1983. (Format: + TXT=7016 bytes) (Also STD0022) (Status: STANDARD) + +0865 Quote of the Day Protocol. J. Postel. May-01-1983. (Format: + TXT=1734 bytes) (Also STD0023) (Status: STANDARD) + +0866 Active users. J. Postel. May-01-1983. (Format: TXT=2087 bytes) + (Also STD0024) (Status: STANDARD) + +0867 Daytime Protocol. J. Postel. May-01-1983. (Format: TXT=2405 + bytes) (Also STD0025) (Status: STANDARD) + +0868 Time Protocol. J. Postel, K. Harrenstien. May-01-1983. (Format: + TXT=3140 bytes) (Also STD0026) (Status: STANDARD) + +0869 Host Monitoring Protocol. R. Hinden. Dec-01-1983. (Format: + TXT=94550 bytes) (Status: HISTORIC) + +0870 Assigned numbers. J.K. Reynolds, J. Postel. Oct-01-1983. (Format: + TXT=56055 bytes) (Obsoletes RFC0820) (Obsoleted by RFC0900) (Status: + HISTORIC) + +0871 Perspective on the ARPANET reference model. M.A. Padlipsky. + Sep-01-1982. (Format: TXT=74455 bytes) (Status: UNKNOWN) + +0872 TCP-on-a-LAN. M.A. Padlipsky. Sep-01-1982. (Format: TXT=22446 + bytes) (Status: UNKNOWN) + +0873 Illusion of vendor support. M.A. Padlipsky. Sep-01-1982. (Format: + TXT=23095 bytes) (Status: UNKNOWN) + +0874 Critique of X.25. M.A. Padlipsky. Sep-01-1982. (Format: TXT=36386 + bytes) (Status: UNKNOWN) + +0875 Gateways, architectures, and heffalumps. M.A. Padlipsky. + Sep-01-1982. (Format: TXT=22816 bytes) (Status: UNKNOWN) + +0876 Survey of SMTP implementations. D. Smallberg. Sep-01-1983. + (Format: TXT=37775 bytes) (Status: UNKNOWN) + +0877 Standard for the transmission of IP datagrams over public data + networks. J.T. Korb. Sep-01-1983. (Format: TXT=3272 bytes) (Obsoleted + by RFC1356) (Status: UNKNOWN) + +0878 ARPANET 1822L Host Access Protocol. A.G. Malis. Dec-01-1983. + (Format: TXT=74774 bytes) (Obsoletes RFC0851) (Status: UNKNOWN) + +0879 TCP maximum segment size and related topics. J. Postel. + Nov-01-1983. (Format: TXT=22024 bytes) (Status: UNKNOWN) + +0880 Official protocols. J.K. Reynolds, J. Postel. Oct-01-1983. + (Format: TXT=37332 bytes) (Obsoletes RFC0840) (Obsoleted by RFC0901) + (Status: HISTORIC) + +0881 Domain names plan and schedule. J. Postel. Nov-01-1983. (Format: + TXT=23490 bytes) (Updated by RFC0897) (Status: UNKNOWN) + +0882 Domain names: Concepts and facilities. P.V. Mockapetris. + Nov-01-1983. (Format: TXT=79776 bytes) (Obsoleted by RFC1034, + RFC1035) (Updated by RFC0973) (Status: UNKNOWN) + +0883 Domain names: Implementation specification. P.V. Mockapetris. + Nov-01-1983. (Format: TXT=175067 bytes) (Obsoleted by RFC1034, + RFC1035) (Updated by RFC0973) (Status: UNKNOWN) + +0884 Telnet terminal type option. M. Solomon, E. Wimmers. Dec-01-1983. + (Format: TXT=7881 bytes) (Obsoleted by RFC0930) (Status: UNKNOWN) + +0885 Telnet end of record option. J. Postel. Dec-01-1983. (Format: + TXT=3232 bytes) (Status: PROPOSED STANDARD) + +0886 Proposed standard for message header munging. M.T. Rose. + Dec-15-1983. (Format: TXT=30566 bytes) (Status: UNKNOWN) + +0887 Resource Location Protocol. M. Accetta. Dec-01-1983. (Format: + TXT=36770 bytes) (Status: EXPERIMENTAL) + +0888 "STUB" Exterior Gateway Protocol. L. Seamonson, E.C. Rosen. + Jan-01-1984. (Format: TXT=53227 bytes) (Updated by RFC0904) (Status: + UNKNOWN) + +0889 Internet delay experiments. D.L. Mills. Dec-01-1983. (Format: + TXT=27128 bytes) (Status: UNKNOWN) + +0890 Exterior Gateway Protocol implementation schedule. J. Postel. + Feb-01-1984. (Format: TXT=5899 bytes) (Status: UNKNOWN) + +0891 DCN local-network protocols. D.L. Mills. Dec-01-1983. (Format: + TXT=66769 bytes) (Also STD0044) (Status: STANDARD) + +0892 ISO Transport Protocol specification. International Organization + for Standardization. Dec-01-1983. (Format: TXT=158151 bytes) + (Obsoleted by RFC0905) (Status: UNKNOWN) + +0893 Trailer encapsulations. S. Leffler, M.J. Karels. Apr-01-1984. + (Format: TXT=13353 bytes) (Status: UNKNOWN) + +0894 Standard for the transmission of IP datagrams over Ethernet + networks. C. Hornig. Apr-01-1984. (Format: TXT=5697 bytes) (Also + STD0041) (Status: STANDARD) + +0895 Standard for the transmission of IP datagrams over experimental + Ethernet networks. J. Postel. Apr-01-1984. (Format: TXT=4985 bytes) + (Also STD0042) (Status: STANDARD) + +0896 Congestion control in IP/TCP internetworks. J. Nagle. + Jan-06-1984. (Format: TXT=26782 bytes) (Status: UNKNOWN) + +0897 Domain name system implementation schedule. J. Postel. + Feb-01-1984. (Format: TXT=15683 bytes) (Updates RFC0881) (Updated by + RFC0921) (Status: UNKNOWN) + +0898 Gateway special interest group meeting notes. R.M. Hinden, J. + Postel, M. Muuss, J.K. Reynolds. Apr-01-1984. (Format: TXT=42112 + bytes) (Status: UNKNOWN) + +0899 Request For Comments summary notes: 800-899. J. Postel, A. + Westine. May-01-1984. (Format: TXT=39996 bytes) (Status: + INFORMATIONAL) + +0900 Assigned Numbers. J.K. Reynolds, J. Postel. Jun-01-1984. (Format: + TXT=82116 bytes) (Obsoletes RFC0870) (Obsoleted by RFC0923) (Status: + HISTORIC) + +0901 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. + Jun-01-1984. (Format: TXT=41058 bytes) (Obsoletes RFC0880) (Obsoleted + by RFC0924) (Status: UNKNOWN) + +0902 ARPA Internet Protocol policy. J.K. Reynolds, J. Postel. + Jul-01-1984. (Format: TXT=11027 bytes) (Status: UNKNOWN) + +0903 Reverse Address Resolution Protocol. R. Finlayson, T. Mann, J.C. + Mogul, M. Theimer. Jun-01-1984. (Format: TXT=9345 bytes) (Also + STD0038) (Status: STANDARD) + +0904 Exterior Gateway Protocol formal specification. D.L. Mills. + Apr-01-1984. (Format: TXT=65226 bytes) (Updates RFC0827, RFC0888) + (Status: HISTORIC) + +0905 ISO Transport Protocol specification ISO DP 8073. A.M. McKenzie. + Apr-01-1984. (Format: TXT=249214 bytes) (Obsoletes RFC0892) (Status: + UNKNOWN) + +0906 Bootstrap loading using TFTP. R. Finlayson. Jun-01-1984. (Format: + TXT=10102 bytes) (Status: UNKNOWN) + +0907 Host Access Protocol specification. Bolt, Beranek and Newman, + Inc.. Jul-01-1984. (Format: TXT=129985 bytes) (Updated by RFC1221) + (Also STD0040) (Status: STANDARD) + +0908 Reliable Data Protocol. D. Velten, R.M. Hinden, J. Sax. + Jul-01-1984. (Format: TXT=97646 bytes) (Updated by RFC1151) (Status: + EXPERIMENTAL) + +0909 Loader Debugger Protocol. C. Welles, W. Milliken. Jul-01-1984. + (Format: TXT=209813 bytes) (Status: EXPERIMENTAL) + +0910 Multimedia mail meeting notes. H.C. Forsdick. Aug-01-1984. + (Format: TXT=24915 bytes) (Status: UNKNOWN) + +0911 EGP Gateway under Berkeley UNIX 4.2. P. Kirton. Aug-22-1984. + (Format: TXT=55908 bytes) (Status: UNKNOWN) + +0912 Authentication service. M. St. Johns. Sep-01-1984. (Format: + TXT=4544 bytes) (Obsoleted by RFC0931) (Status: UNKNOWN) + +0913 Simple File Transfer Protocol. M. Lottor. Sep-01-1984. (Format: + TXT=20929 bytes) (Status: HISTORIC) + +0914 Thinwire protocol for connecting personal computers to the + Internet. D.J. Farber, G. Delp, T.M. Conte. Sep-01-1984. (Format: + TXT=57288 bytes) (Status: HISTORIC) + +0915 Network mail path service. M.A. Elvy, R. Nedved. Dec-01-1984. + (Format: TXT=21635 bytes) (Status: UNKNOWN) + +0916 Reliable Asynchronous Transfer Protocol (RATP). G.G. Finn. + Oct-01-1984. (Format: TXT=110737 bytes) (Status: HISTORIC) + +0917 Internet subnets. J.C. Mogul. Oct-01-1984. (Format: TXT=47072 + bytes) (Status: UNKNOWN) + +0918 Post Office Protocol. J.K. Reynolds. Oct-01-1984. (Format: + TXT=9876 bytes) (Obsoleted by RFC0937) (Status: UNKNOWN) + +0919 Broadcasting Internet Datagrams. J.C. Mogul. Oct-01-1984. + (Format: TXT=16382 bytes) (Also STD0005) (Status: STANDARD) + +0920 Domain requirements. J. Postel, J.K. Reynolds. Oct-01-1984. + (Format: TXT=27823 bytes) (Status: UNKNOWN) + +0921 Domain name system implementation schedule - revised. J. Postel. + Oct-01-1984. (Format: TXT=23318 bytes) (Updates RFC0897) (Status: + UNKNOWN) + +0922 Broadcasting Internet datagrams in the presence of subnets. J.C. + Mogul. Oct-01-1984. (Format: TXT=24147 bytes) (Also STD0005) (Status: + STANDARD) + +0923 Assigned numbers. J.K. Reynolds, J. Postel. Oct-01-1984. (Format: + TXT=96467 bytes) (Obsoletes RFC0900) (Obsoleted by RFC0943) (Status: + HISTORIC) + +0924 Official ARPA-Internet protocols for connecting personal + computers to the Internet. J.K. Reynolds, J. Postel. Oct-01-1984. + (Format: TXT=48513 bytes) (Obsoletes RFC0901) (Obsoleted by RFC0944) + (Status: UNKNOWN) + +0925 Multi-LAN address resolution. J. Postel. Oct-01-1984. (Format: + TXT=31137 bytes) (Status: UNKNOWN) + +0926 Protocol for providing the connectionless mode network services. + International Organization for Standardization. Dec-01-1984. (Format: + TXT=165895 bytes) (Obsoleted by RFC0994) (Status: UNKNOWN) + +0927 TACACS user identification Telnet option. B.A. Anderson. + Dec-01-1984. (Format: TXT=5474 bytes) (Status: PROPOSED STANDARD) + +0928 Introduction to proposed DoD standard H-FP. M.A. Padlipsky. + Dec-01-1984. (Format: TXT=60461 bytes) (Status: UNKNOWN) + +0929 Proposed Host-Front End Protocol. J. Lilienkamp, R. Mandell, M.A. + Padlipsky. Dec-01-1984. (Format: TXT=135042 bytes) (Status: HISTORIC) + +0930 Telnet terminal type option. M. Solomon, E. Wimmers. Jan-01-1985. + (Format: TXT=6583 bytes) (Obsoletes RFC0884) (Obsoleted by RFC1091) + (Status: UNKNOWN) + +0931 Authentication server. M. St. Johns. Jan-01-1985. (Format: + TXT=8982 bytes) (Obsoletes RFC0912) (Obsoleted by RFC1413) (Status: + UNKNOWN) + +0932 Subnetwork addressing scheme. D.D. Clark. Jan-01-1985. (Format: + TXT=9283 bytes) (Status: UNKNOWN) + +0933 Output marking Telnet option. S. Silverman. Jan-01-1985. (Format: + TXT=6715 bytes) (Status: PROPOSED STANDARD) + +0934 Proposed standard for message encapsulation. M.T. Rose, E.A. + Stefferud. Jan-01-1985. (Format: TXT=21770 bytes) (Status: UNKNOWN) + +0935 Reliable link layer protocols. J.G. Robinson. Jan-01-1985. + (Format: TXT=31625 bytes) (Status: UNKNOWN) + +0936 Another Internet subnet addressing scheme. M.J. Karels. + Feb-01-1985. (Format: TXT=10179 bytes) (Status: UNKNOWN) + +0937 Post Office Protocol: Version 2. M. Butler, J. Postel, D. Chase, + J. Goldberger, J.K. Reynolds. Feb-01-1985. (Format: TXT=42370 bytes) + (Obsoletes RFC0918) (Status: HISTORIC) + +0938 Internet Reliable Transaction Protocol functional and interface + specification. T. Miller. Feb-01-1985. (Format: TXT=39478 bytes) + (Status: EXPERIMENTAL) + +0939 Executive summary of the NRC report on transport protocols for + Department of Defense data networks. National Research Council. + Feb-01-1985. (Format: TXT=42345 bytes) (Status: UNKNOWN) + +0940 Toward an Internet standard scheme for subnetting. Gateway + Algorithms and Data Structures Task Force. Apr-01-1985. (Format: + TXT=6881 bytes) (Status: UNKNOWN) + +0941 Addendum to the network service definition covering network layer + addressing. International Organization for Standardization. + Apr-01-1985. (Format: TXT=68733 bytes) (Status: UNKNOWN) + +0942 Transport protocols for Department of Defense data networks. + National Research Council. Feb-01-1985. (Format: TXT=217284 bytes) + (Status: UNKNOWN) + +0943 Assigned numbers. J.K. Reynolds, J. Postel. Apr-01-1985. (Format: + TXT=105234 bytes) (Obsoletes RFC0923) (Obsoleted by RFC0960) (Status: + HISTORIC) + +0944 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. + Apr-01-1985. (Format: TXT=61373 bytes) (Obsoletes RFC0924) (Obsoleted + by RFC0961) (Status: UNKNOWN) + +0945 DoD statement on the NRC report. J. Postel. May-01-1985. (Format: + TXT=5017 bytes) (Obsoleted by RFC1039) (Status: UNKNOWN) + +0946 Telnet terminal location number option. R. Nedved. May-01-1985. + (Format: TXT=6285 bytes) (Status: PROPOSED STANDARD) + +0947 Multi-network broadcasting within the Internet. K. Lebowitz, D. + Mankins. Jun-01-1985. (Format: TXT=12569 bytes) (Status: UNKNOWN) + +0948 Two methods for the transmission of IP datagrams over IEEE 802.3 + networks. I. Winston. Jun-01-1985. (Format: TXT=11495 bytes) + (Obsoleted by RFC1042) (Status: UNKNOWN) + +0949 FTP unique-named store command. M.A. Padlipsky. Jul-01-1985. + (Format: TXT=4017 bytes) (Status: UNKNOWN) + +0950 Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. + Aug-01-1985. (Format: TXT=37985 bytes) (Updates RFC0792) (Also + STD0005) (Status: STANDARD) + +0951 Bootstrap Protocol. W.J. Croft, J. Gilmore. Sep-01-1985. (Format: + TXT=28354 bytes) (Updated by RFC1395, RFC1497, RFC1532, RFC1542) + (Status: DRAFT STANDARD) + +0952 DoD Internet host table specification. K. Harrenstien, M.K. + Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=12388 bytes) + (Obsoletes RFC0810) (Status: UNKNOWN) + +0953 Hostname Server. K. Harrenstien, M.K. Stahl, E.J. Feinler. + Oct-01-1985. (Format: TXT=8305 bytes) (Obsoletes RFC0811) (Status: + HISTORIC) + +0954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. + Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Status: + DRAFT STANDARD) + +0955 Towards a transport service for transaction processing + applications. R.T. Braden. Sep-01-1985. (Format: TXT=22497 bytes) + (Status: UNKNOWN) + +0956 Algorithms for synchronizing network clocks. D.L. Mills. + Sep-01-1985. (Format: TXT=67387 bytes) (Status: UNKNOWN) + +0957 Experiments in network clock synchronization. D.L. Mills. + Sep-01-1985. (Format: TXT=68952 bytes) (Status: UNKNOWN) + +0958 Network Time Protocol (NTP). D.L. Mills. Sep-01-1985. (Format: + TXT=30723 bytes) (Obsoleted by RFC1059, RFC1119, RFC1305) (Status: + UNKNOWN) + +0959 File Transfer Protocol. J. Postel, J.K. Reynolds. Oct-01-1985. + (Format: TXT=151249 bytes) (Obsoletes RFC0765) (Updated by RFC2228, + RFC2640, RFC2773) (Also STD0009) (Status: STANDARD) + +0960 Assigned numbers. J.K. Reynolds, J. Postel. Dec-01-1985. (Format: + TXT=125814 bytes) (Obsoletes RFC0943) (Obsoleted by RFC0990) (Status: + HISTORIC) + +0961 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. + Dec-01-1985. (Format: TXT=52672 bytes) (Obsoletes RFC0944) (Obsoleted + by RFC0991) (Status: UNKNOWN) + +0962 TCP-4 prime. M.A. Padlipsky. Nov-01-1985. (Format: TXT=2773 + bytes) (Status: UNKNOWN) + +0963 Some problems with the specification of the Military Standard + Internet Protocol. D.P. Sidhu. Nov-01-1985. (Format: TXT=44019 bytes) + (Status: UNKNOWN) + +0964 Some problems with the specification of the Military Standard + Transmission Control Protocol. D.P. Sidhu. Nov-01-1985. (Format: + TXT=20972 bytes) (Status: UNKNOWN) + +0965 Format for a graphical communication protocol. L. Aguilar. + Dec-01-1985. (Format: TXT=105456 bytes) (Status: UNKNOWN) + +0966 Host groups: A multicast extension to the Internet Protocol. S.E. + Deering, D.R. Cheriton. Dec-01-1985. (Format: TXT=59469 bytes) + (Obsoleted by RFC0988) (Status: UNKNOWN) + +0967 All victims together. M.A. Padlipsky. Dec-01-1985. (Format: + TXT=4706 bytes) (Status: UNKNOWN) + +0968 Twas the night before start-up. V.G. Cerf. Dec-01-1985. (Format: + TXT=2459 bytes) (Status: UNKNOWN) + +0969 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert, + L. Zhang. Dec-01-1985. (Format: TXT=40040 bytes) (Obsoleted by + RFC0998) (Status: UNKNOWN) + +0970 On packet switches with infinite storage. J. Nagle. Dec-01-1985. + (Format: TXT=35316 bytes) (Status: UNKNOWN) + +0971 Survey of data representation standards. A.L. DeSchon. + Jan-01-1986. (Format: TXT=22883 bytes) (Status: UNKNOWN) + +0972 Password Generator Protocol. F.J. Wancho. Jan-01-1986. (Format: + TXT=3890 bytes) (Status: UNKNOWN) + +0973 Domain system changes and observations. P.V. Mockapetris. + Jan-01-1986. (Format: TXT=22364 bytes) (Obsoleted by RFC1034, + RFC1035) (Updates RFC0882, RFC0883) (Status: UNKNOWN) + +0974 Mail routing and the domain system. C. Partridge. Jan-01-1986. + (Format: TXT=18581 bytes) (Obsoleted by RFC2821) (Status: HISTORIC) + +0975 Autonomous confederations. D.L. Mills. Feb-01-1986. (Format: + TXT=28010 bytes) (Status: UNKNOWN) + +0976 UUCP mail interchange format standard. M.R. Horton. Feb-01-1986. + (Format: TXT=26814 bytes) (Updated by RFC1137) (Status: UNKNOWN) + +0977 Network News Transfer Protocol. B. Kantor, P. Lapsley. + Feb-01-1986. (Format: TXT=55062 bytes) (Status: PROPOSED STANDARD) + +0978 Voice File Interchange Protocol (VFIP). J.K. Reynolds, R. + Gillman, W.A. Brackenridge, A. Witkowski, J. Postel. Feb-01-1986. + (Format: TXT=9223 bytes) (Status: UNKNOWN) + +0979 PSN End-to-End functional specification. A.G. Malis. Mar-01-1986. + (Format: TXT=39472 bytes) (Status: UNKNOWN) + +0980 Protocol document order information. O.J. Jacobsen, J. Postel. + Mar-01-1986. (Format: TXT=24416 bytes) (Status: UNKNOWN) + +0981 Experimental multiple-path routing algorithm. D.L. Mills. + Mar-01-1986. (Format: TXT=59069 bytes) (Status: UNKNOWN) + +0982 Guidelines for the specification of the structure of the Domain + Specific Part (DSP) of the ISO standard NSAP address. H.W. Braun. + Apr-01-1986. (Format: TXT=22595 bytes) (Status: UNKNOWN) + +0983 ISO transport arrives on top of the TCP. D.E. Cass, M.T. Rose. + Apr-01-1986. (Format: TXT=59819 bytes) (Obsoleted by RFC1006) + (Status: UNKNOWN) + +0984 PCMAIL: A distributed mail system for personal computers. D.D. + Clark, M.L. Lambert. May-01-1986. (Format: TXT=69333 bytes) + (Obsoleted by RFC0993) (Status: UNKNOWN) + +0985 Requirements for Internet gateways - draft. National Science + Foundation, Network Technical Advisory Group. May-01-1986. (Format: + TXT=59221 bytes) (Obsoleted by RFC1009) (Status: UNKNOWN) + +0986 Guidelines for the use of Internet-IP addresses in the ISO + Connectionless-Mode Network Protocol. R.W. Callon, H.W. Braun. + Jun-01-1986. (Format: TXT=13950 bytes) (Obsoleted by RFC1069) + (Status: UNKNOWN) + +0987 Mapping between X.400 and RFC 822. S.E. Kille. Jun-01-1986. + (Format: TXT=127540 bytes) (Obsoleted by RFC1327, RFC2156) (Updated + by RFC1026, RFC1138, RFC1148) (Status: UNKNOWN) + +0988 Host extensions for IP multicasting. S.E. Deering. Jul-01-1986. + (Format: TXT=45220 bytes) (Obsoletes RFC0966) (Obsoleted by RFC1054, + RFC1112) (Status: UNKNOWN) + +0989 Privacy enhancement for Internet electronic mail: Part I: Message + encipherment and authentication procedures. J. Linn. Feb-01-1987. + (Format: TXT=63934 bytes) (Obsoleted by RFC1040, RFC1113) (Status: + UNKNOWN) + +0990 Assigned numbers. J.K. Reynolds, J. Postel. Nov-01-1986. (Format: + TXT=174784 bytes) (Obsoletes RFC0960) (Obsoleted by RFC1010) (Updated + by RFC0997) (Status: HISTORIC) + +0991 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. + Nov-01-1986. (Format: TXT=65205 bytes) (Obsoletes RFC0961) (Obsoleted + by RFC1011) (Status: UNKNOWN) + +0992 On communication support for fault tolerant process groups. K.P. + Birman, T.A. Joseph. Nov-01-1986. (Format: TXT=52313 bytes) (Status: + UNKNOWN) + +0993 PCMAIL: A distributed mail system for personal computers. D.D. + Clark, M.L. Lambert. Dec-01-1986. (Format: TXT=71725 bytes) + (Obsoletes RFC0984) (Obsoleted by RFC1056) (Status: UNKNOWN) + +0994 Final text of DIS 8473, Protocol for Providing the + Connectionless-mode Network Service. International Organization for + Standardization. Mar-01-1986. (Format: TXT=129006 bytes) (Obsoletes + RFC0926) (Status: UNKNOWN) + +0995 End System to Intermediate System Routing Exchange Protocol for + use in conjunction with ISO 8473. International Organization for + Standardization. Apr-01-1986. (Format: TXT=94069 bytes) (Status: + UNKNOWN) + +0996 Statistics server. D.L. Mills. Feb-01-1987. (Format: TXT=6127 + bytes) (Status: HISTORIC) + +0997 Internet numbers. J.K. Reynolds, J. Postel. Mar-01-1987. (Format: + TXT=123919 bytes) (Obsoleted by RFC1020, RFC1117) (Updates RFC0990) + (Status: UNKNOWN) + +0998 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert, + L. Zhang. Mar-01-1987. (Format: TXT=57147 bytes) (Obsoletes RFC0969) + (Status: EXPERIMENTAL) + +0999 Requests For Comments summary notes: 900-999. A. Westine, J. + Postel. Apr-01-1987. (Format: TXT=62877 bytes) (Obsoletes RFC0160) + (Obsoleted by RFC1000) (Status: UNKNOWN) + +1000 Request For Comments reference guide. J.K. Reynolds, J. Postel. + Aug-01-1987. (Format: TXT=323960 bytes) (Obsoletes RFC0999) (Status: + UNKNOWN) + +1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: + Concepts and methods. NetBIOS Working Group in the Defense Advanced + Research Projects Agency, Internet Activities Board, End-to-End + Services Task Force. Mar-01-1987. (Format: TXT=158437 bytes) (Also + STD0019) (Status: STANDARD) + +1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: + Detailed specifications. NetBIOS Working Group in the Defense + Advanced Research Projects Agency, Internet Activities Board, + End-to-End Services Task Force. Mar-01-1987. (Format: TXT=170262 + bytes) (Also STD0019) (Status: STANDARD) + +1003 Issues in defining an equations representation standard. A.R. + Katz. Mar-01-1987. (Format: TXT=19816 bytes) (Status: UNKNOWN) + +1004 Distributed-protocol authentication scheme. D.L. Mills. + Apr-01-1987. (Format: TXT=21402 bytes) (Status: EXPERIMENTAL) + +1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP). A. Khanna, + A.G. Malis. May-01-1987. (Format: TXT=69957 bytes) (Status: UNKNOWN) + +1006 ISO transport services on top of the TCP: Version 3. M.T. Rose, + D.E. Cass. May-01-1987. (Format: TXT=31935 bytes) (Obsoletes RFC0983) + (Updated by RFC2126) (Also STD0035) (Status: STANDARD) + +1007 Military supplement to the ISO Transport Protocol. W. McCoy. + Jun-01-1987. (Format: TXT=51280 bytes) (Status: UNKNOWN) + +1008 Implementation guide for the ISO Transport Protocol. W. McCoy. + Jun-01-1987. (Format: TXT=204664 bytes) (Status: UNKNOWN) + +1009 Requirements for Internet gateways. R.T. Braden, J. Postel. + Jun-01-1987. (Format: TXT=128173 bytes) (Obsoletes RFC0985) + (Obsoleted by RFC1812) (Status: HISTORIC) + +1010 Assigned numbers. J.K. Reynolds, J. Postel. May-01-1987. (Format: + TXT=78179 bytes) (Obsoletes RFC0990) (Obsoleted by RFC1060) (Status: + HISTORIC) + +1011 Official Internet protocols. J.K. Reynolds, J. Postel. + May-01-1987. (Format: TXT=74593 bytes) (Obsoletes RFC0991) (Status: + UNKNOWN) + +1012 Bibliography of Request For Comments 1 through 999. J.K. + Reynolds, J. Postel. Jun-01-1987. (Format: TXT=129194 bytes) (Status: + INFORMATIONAL) + +1013 X Window System Protocol, version 11: Alpha update April 1987. + R.W. Scheifler. Jun-01-1987. (Format: TXT=244905 bytes) (Status: + UNKNOWN) + +1014 XDR: External Data Representation standard. Sun Microsystems. + Jun-01-1987. (Format: TXT=39316 bytes) (Status: UNKNOWN) + +1015 Implementation plan for interagency research Internet. B.M. + Leiner. Jul-01-1987. (Format: TXT=63159 bytes) (Status: UNKNOWN) + +1016 Something a host could do with source quench: The Source Quench + Introduced Delay (SQuID). W. Prue, J. Postel. Jul-01-1987. (Format: + TXT=47922 bytes) (Status: UNKNOWN) + +1017 Network requirements for scientific research: Internet task force + on scientific computing. B.M. Leiner. Aug-01-1987. (Format: TXT=49512 + bytes) (Status: UNKNOWN) + +1018 Some comments on SQuID. A.M. McKenzie. Aug-01-1987. (Format: + TXT=7931 bytes) (Status: UNKNOWN) + +1019 Report of the Workshop on Environments for Computational + Mathematics. D. Arnon. Sep-01-1987. (Format: TXT=21151 bytes) + (Status: UNKNOWN) + +1020 Internet numbers. S. Romano, M.K. Stahl. Nov-01-1987. (Format: + TXT=146864 bytes) (Obsoletes RFC0997) (Obsoleted by RFC1062, RFC1117, + RFC1166) (Status: UNKNOWN) + +1021 High-level Entity Management System (HEMS). C. Partridge, G. + Trewitt. Oct-01-1987. (Format: TXT=12993 bytes) (Status: HISTORIC) + +1022 High-level Entity Management Protocol (HEMP). C. Partridge, G. + Trewitt. Oct-01-1987. (Format: TXT=25348 bytes) (Status: UNKNOWN) + +1023 HEMS monitoring and control language. G. Trewitt, C. Partridge. + Oct-01-1987. (Format: TXT=40992 bytes) (Obsoleted by RFC1076) + (Status: UNKNOWN) + +1024 HEMS variable definitions. C. Partridge, G. Trewitt. Oct-01-1987. + (Format: TXT=126536 bytes) (Status: UNKNOWN) + +1025 TCP and IP bake off. J. Postel. Sep-01-1987. (Format: TXT=11648 + bytes) (Status: UNKNOWN) + +1026 Addendum to RFC 987: (Mapping between X.400 and RFC-822). S.E. + Kille. Sep-01-1987. (Format: TXT=7117 bytes) (Obsoleted by RFC1327, + RFC2156) (Updates RFC0987) (Updated by RFC1138, RFC1148) (Status: + UNKNOWN) + +1027 Using ARP to implement transparent subnet gateways. S. + Carl-Mitchell, J.S. Quarterman. Oct-01-1987. (Format: TXT=21297 + bytes) (Status: UNKNOWN) + +1028 Simple Gateway Monitoring Protocol. J. Davin, J.D. Case, M. + Fedor, M.L. Schoffstall. Nov-01-1987. (Format: TXT=82440 bytes) + (Status: HISTORIC) + +1029 More fault tolerant approach to address resolution for a + Multi-LAN system of Ethernets. G. Parr. May-01-1988. (Format: + TXT=44019 bytes) (Status: UNKNOWN) + +1030 On testing the NETBLT Protocol over divers networks. M.L. + Lambert. Nov-01-1987. (Format: TXT=40964 bytes) (Status: UNKNOWN) + +1031 MILNET name domain transition. W.D. Lazear. Nov-01-1987. (Format: + TXT=20137 bytes) (Status: UNKNOWN) + +1032 Domain administrators guide. M.K. Stahl. Nov-01-1987. (Format: + TXT=29454 bytes) (Status: UNKNOWN) + +1033 Domain administrators operations guide. M. Lottor. Nov-01-1987. + (Format: TXT=37263 bytes) (Status: UNKNOWN) + +1034 Domain names - concepts and facilities. P.V. Mockapetris. + Nov-01-1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, + RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, + RFC2065, RFC2181, RFC2308, RFC2535) (Also STD0013) (Status: STANDARD) + +1035 Domain names - implementation and specification. P.V. + Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes + RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, + RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, + RFC2137, RFC2308, RFC2535, RFC2845) (Also STD0013) (Status: STANDARD) + +1036 Standard for interchange of USENET messages. M.R. Horton, R. + Adams. Dec-01-1987. (Format: TXT=46891 bytes) (Obsoletes RFC0850) + (Status: UNKNOWN) + +1037 NFILE - a file access protocol. B. Greenberg, S. Keene. + Dec-01-1987. (Format: TXT=197312 bytes) (Status: HISTORIC) + +1038 Draft revised IP security option. M. St. Johns. Jan-01-1988. + (Format: TXT=15879 bytes) (Obsoleted by RFC1108) (Status: UNKNOWN) + +1039 DoD statement on Open Systems Interconnection protocols. D. + Latham. Jan-01-1988. (Format: TXT=6194 bytes) (Obsoletes RFC0945) + (Status: UNKNOWN) + +1040 Privacy enhancement for Internet electronic mail: Part I: Message + encipherment and authentication procedures. J. Linn. Jan-01-1988. + (Format: TXT=76276 bytes) (Obsoletes RFC0989) (Obsoleted by RFC1113) + (Status: UNKNOWN) + +1041 Telnet 3270 regime option. Y. Rekhter. Jan-01-1988. (Format: + TXT=11608 bytes) (Status: PROPOSED STANDARD) + +1042 Standard for the transmission of IP datagrams over IEEE 802 + networks. J. Postel, J.K. Reynolds. Feb-01-1988. (Format: TXT=34359 + bytes) (Obsoletes RFC0948) (Also STD0043) (Status: STANDARD) + +1043 Telnet Data Entry Terminal option: DODIIS implementation. A. + Yasuda, T. Thompson. Feb-01-1988. (Format: TXT=59478 bytes) (Updates + RFC0732) (Status: PROPOSED STANDARD) + +1044 Internet Protocol on Network System's HYPERchannel: Protocol + specification. K. Hardwick, J. Lekashman. Feb-01-1988. (Format: + TXT=103241 bytes) (Also STD0045) (Status: STANDARD) + +1045 VMTP: Versatile Message Transaction Protocol: Protocol + specification. D.R. Cheriton. Feb-01-1988. (Format: TXT=272058 bytes) + (Status: EXPERIMENTAL) + +1046 Queuing algorithm to provide type-of-service for IP links. W. + Prue, J. Postel. Feb-01-1988. (Format: TXT=30106 bytes) (Status: + UNKNOWN) + +1047 Duplicate messages and SMTP. C. Partridge. Feb-01-1988. (Format: + TXT=5888 bytes) (Status: UNKNOWN) + +1048 BOOTP vendor information extensions. P.A. Prindeville. + Feb-01-1988. (Format: TXT=15423 bytes) (Obsoleted by RFC1084, + RFC1395, RFC1497, RFC1533) (Status: UNKNOWN) + +1049 Content-type header field for Internet messages. M.A. Sirbu. + Mar-01-1988. (Format: TXT=18923 bytes) (Status: HISTORIC) + +1050 RPC: Remote Procedure Call Protocol specification. Sun + Microsystems. Apr-01-1988. (Format: TXT=51540 bytes) (Obsoleted by + RFC1057) (Status: HISTORIC) + +1051 Standard for the transmission of IP datagrams and ARP packets + over ARCNET networks. P.A. Prindeville. Mar-01-1988. (Format: + TXT=7779 bytes) (Obsoleted by RFC1201) (Status: HISTORIC) + +1052 IAB recommendations for the development of Internet network + management standards. V.G. Cerf. Apr-01-1988. (Format: TXT=30569 + bytes) (Status: UNKNOWN) + +1053 Telnet X.3 PAD option. S. Levy, T. Jacobson. Apr-01-1988. + (Format: TXT=48952 bytes) (Status: PROPOSED STANDARD) + +1054 Host extensions for IP multicasting. S.E. Deering. May-01-1988. + (Format: TXT=45465 bytes) (Obsoletes RFC0988) (Obsoleted by RFC1112) + (Status: UNKNOWN) + +1055 Nonstandard for transmission of IP datagrams over serial lines: + SLIP. J.L. Romkey. Jun-01-1988. (Format: TXT=12911 bytes) (Also + STD0047) (Status: STANDARD) + +1056 PCMAIL: A distributed mail system for personal computers. M.L. + Lambert. Jun-01-1988. (Format: TXT=85368 bytes) (Obsoletes RFC0993) + (Status: INFORMATIONAL) + +1057 RPC: Remote Procedure Call Protocol specification: Version 2. Sun + Microsystems. Jun-01-1988. (Format: TXT=52462 bytes) (Obsoletes + RFC1050) (Status: INFORMATIONAL) + +1058 Routing Information Protocol. C.L. Hedrick. Jun-01-1988. (Format: + TXT=93285 bytes) (Updated by RFC1388, RFC1723) (Status: HISTORIC) + +1059 Network Time Protocol (version 1) specification and + implementation. D.L. Mills. Jul-01-1988. (Format: TXT=140890 bytes) + (Obsoletes RFC0958) (Obsoleted by RFC1119, RFC1305) (Status: UNKNOWN) + +1060 Assigned numbers. J.K. Reynolds, J. Postel. Mar-01-1990. (Format: + TXT=177923 bytes) (Obsoletes RFC1010) (Obsoleted by RFC1340) (Status: + HISTORIC) + +1061 Not Issued. + +1062 Internet numbers. S. Romano, M.K. Stahl, M. Recker. Aug-01-1988. + (Format: TXT=198729 bytes) (Obsoletes RFC1020) (Obsoleted by RFC1117, + RFC1166) (Status: UNKNOWN) + +1063 IP MTU discovery options. J.C. Mogul, C.A. Kent, C. Partridge, K. + McCloghrie. Jul-01-1988. (Format: TXT=27121 bytes) (Obsoleted by + RFC1191) (Status: UNKNOWN) + +1064 Interactive Mail Access Protocol: Version 2. M.R. Crispin. + Jul-01-1988. (Format: TXT=57813 bytes) (Obsoleted by RFC1176, + RFC1203) (Status: UNKNOWN) + +1065 Structure and identification of management information for + TCP/IP-based internets. K. McCloghrie, M.T. Rose. Aug-01-1988. + (Format: TXT=38858 bytes) (Obsoleted by RFC1155) (Status: STANDARD) + +1066 Management Information Base for network management of + TCP/IP-based internets. K. McCloghrie, M.T. Rose. Aug-01-1988. + (Format: TXT=135177 bytes) (Obsoleted by RFC1156) (Status: UNKNOWN) + +1067 Simple Network Management Protocol. J.D. Case, M. Fedor, M.L. + Schoffstall, J. Davin. Aug-01-1988. (Format: TXT=69592 bytes) + (Obsoleted by RFC1098) (Status: UNKNOWN) + +1068 Background File Transfer Program (BFTP). A.L. DeSchon, R.T. + Braden. Aug-01-1988. (Format: TXT=51004 bytes) (Status: UNKNOWN) + +1069 Guidelines for the use of Internet-IP addresses in the ISO + Connectionless-Mode Network Protocol. R.W. Callon, H.W. Braun. + Feb-01-1989. (Format: TXT=24268 bytes) (Obsoletes RFC0986) (Status: + UNKNOWN) + +1070 Use of the Internet as a subnetwork for experimentation with the + OSI network layer. R.A. Hagens, N.E. Hall, M.T. Rose. Feb-01-1989. + (Format: TXT=37354 bytes) (Status: UNKNOWN) + +1071 Computing the Internet checksum. R.T. Braden, D.A. Borman, C. + Partridge. Sep-01-1988. (Format: TXT=54941 bytes) (Updated by + RFC1141) (Status: UNKNOWN) + +1072 TCP extensions for long-delay paths. V. Jacobson, R.T. Braden. + Oct-01-1988. (Format: TXT=36000 bytes) (Obsoleted by RFC1323, + RFC2018) (Status: UNKNOWN) + +1073 Telnet window size option. D. Waitzman. Oct-01-1988. (Format: + TXT=7639 bytes) (Status: PROPOSED STANDARD) + +1074 NSFNET backbone SPF based Interior Gateway Protocol. J. Rekhter. + Oct-01-1988. (Format: TXT=10872 bytes) (Status: UNKNOWN) + +1075 Distance Vector Multicast Routing Protocol. D. Waitzman, C. + Partridge, S.E. Deering. Nov-01-1988. (Format: TXT=54731 bytes) + (Status: EXPERIMENTAL) + +1076 HEMS monitoring and control language. G. Trewitt, C. Partridge. + Nov-01-1988. (Format: TXT=98774 bytes) (Obsoletes RFC1023) (Status: + UNKNOWN) + +1077 Critical issues in high bandwidth networking. B.M. Leiner. + Nov-01-1988. (Format: TXT=116464 bytes) (Status: UNKNOWN) + +1078 TCP port service Multiplexer (TCPMUX). M. Lottor. Nov-01-1988. + (Format: TXT=3248 bytes) (Status: UNKNOWN) + +1079 Telnet terminal speed option. C.L. Hedrick. Dec-01-1988. (Format: + TXT=4942 bytes) (Status: PROPOSED STANDARD) + +1080 Telnet remote flow control option. C.L. Hedrick. Nov-01-1988. + (Format: TXT=6688 bytes) (Obsoleted by RFC1372) (Status: UNKNOWN) + +1081 Post Office Protocol: Version 3. M.T. Rose. Nov-01-1988. (Format: + TXT=37009 bytes) (Obsoleted by RFC1225) (Status: UNKNOWN) + +1082 Post Office Protocol: Version 3: Extended service offerings. M.T. + Rose. Nov-01-1988. (Format: TXT=25423 bytes) (Status: UNKNOWN) + +1083 IAB official protocol standards. Defense Advanced Research + Projects Agency, Internet Activities Board. Dec-01-1988. (Format: + TXT=27128 bytes) (Obsoleted by RFC1100) (Status: HISTORIC) + +1084 BOOTP vendor information extensions. J.K. Reynolds. Dec-01-1988. + (Format: TXT=16327 bytes) (Obsoletes RFC1048) (Obsoleted by RFC1395, + RFC1497, RFC1533) (Status: UNKNOWN) + +1085 ISO presentation services on top of TCP/IP based internets. M.T. + Rose. Dec-01-1988. (Format: TXT=64643 bytes) (Status: UNKNOWN) + +1086 ISO-TP0 bridge between TCP and X.25. J.P. Onions, M.T. Rose. + Dec-01-1988. (Format: TXT=19934 bytes) (Status: UNKNOWN) + +1087 Ethics and the Internet. Defense Advanced Research Projects + Agency, Internet Activities Board. Jan-01-1989. (Format: TXT=4582 + bytes) (Status: UNKNOWN) + +1088 Standard for the transmission of IP datagrams over NetBIOS + networks. L.J. McLaughlin. Feb-01-1989. (Format: TXT=5749 bytes) + (Also STD0048) (Status: STANDARD) + +1089 SNMP over Ethernet. M.L. Schoffstall, C. Davin, M. Fedor, J.D. + Case. Feb-01-1989. (Format: TXT=4458 bytes) (Status: UNKNOWN) + +1090 SMTP on X.25. R. Ullmann. Feb-01-1989. (Format: TXT=6141 bytes) + (Status: UNKNOWN) + +1091 Telnet terminal-type option. J. VanBokkelen. Feb-01-1989. + (Format: TXT=13439 bytes) (Obsoletes RFC0930) (Status: PROPOSED + STANDARD) + +1092 EGP and policy based routing in the new NSFNET backbone. J. + Rekhter. Feb-01-1989. (Format: TXT=11865 bytes) (Status: UNKNOWN) + +1093 NSFNET routing architecture. H.W. Braun. Feb-01-1989. (Format: + TXT=20629 bytes) (Status: UNKNOWN) + +1094 NFS: Network File System Protocol specification. Sun + Microsystems. Mar-01-1989. (Format: TXT=51454 bytes) (Obsoleted by + RFC3010) (Also RFC1813) (Status: INFORMATIONAL) + +1095 Common Management Information Services and Protocol over TCP/IP + (CMOT). U.S. Warrier, L. Besaw. Apr-01-1989. (Format: TXT=157506 + bytes) (Obsoleted by RFC1189) (Status: UNKNOWN) + +1096 Telnet X display location option. G.A. Marcy. Mar-01-1989. + (Format: TXT=4634 bytes) (Status: PROPOSED STANDARD) + +1097 Telnet subliminal-message option. B. Miller. Apr-01-1989. + (Format: TXT=5490 bytes) (Status: UNKNOWN) + +1098 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, + M.L. Schoffstall, C. Davin. April 1989. (Format: TXT=71563 bytes) + (Obsoletes RFC1067) (Obsoleted by RFC1157) (Status: UNKNOWN) + +1099 Request for Comments Summary: RFC Numbers 1000-1099. J. Reynolds. + December 1991. (Format: TXT=49108 bytes) (Status: INFORMATIONAL) + +1100 IAB official protocol standards. Defense Advanced Research + Projects Agency, Internet Activities Board. Apr-01-1989. (Format: + TXT=30101 bytes) (Obsoletes RFC1083) (Obsoleted by RFC1130) (Status: + HISTORIC) + +1101 DNS encoding of network names and other types. P.V. Mockapetris. + Apr-01-1989. (Format: TXT=28677 bytes) (Updates RFC1034, RFC1035) + (Status: UNKNOWN) + +1102 Policy routing in Internet protocols. D.D. Clark. May-01-1989. + (Format: TXT=59664 bytes) (Status: UNKNOWN) + +1103 Proposed standard for the transmission of IP datagrams over FDDI + Networks. D. Katz. Jun-01-1989. (Format: TXT=19439 bytes) (Obsoleted + by RFC1188) (Status: UNKNOWN) + +1104 Models of policy based routing. H.W. Braun. Jun-01-1989. (Format: + TXT=25468 bytes) (Status: UNKNOWN) + +1105 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. + Jun-01-1989. (Format: TXT=37644 bytes) (Obsoleted by RFC1163) + (Status: EXPERIMENTAL) + +1106 TCP big window and NAK options. R. Fox. Jun-01-1989. (Format: + TXT=37105 bytes) (Status: UNKNOWN) + +1107 Plan for Internet directory services. K.R. Sollins. Jul-01-1989. + (Format: TXT=51773 bytes) (Status: INFORMATIONAL) + +1108 U.S. Department of Defense Security Options for the Internet + Protocol. S. Kent. November 1991. (Format: TXT=41791 bytes) + (Obsoletes RFC1038) (Status: HISTORIC) + +1109 Report of the second Ad Hoc Network Management Review Group. V.G. + Cerf. Aug-01-1989. (Format: TXT=20642 bytes) (Status: UNKNOWN) + +1110 Problem with the TCP big window option. A.M. McKenzie. + Aug-01-1989. (Format: TXT=5778 bytes) (Status: UNKNOWN) + +1111 Request for comments on Request for Comments: Instructions to RFC + authors. J. Postel. Aug-01-1989. (Format: TXT=11793 bytes) (Obsoletes + RFC0825) (Obsoleted by RFC1543, RFC2223) (Status: INFORMATIONAL) + +1112 Host extensions for IP multicasting. S.E. Deering. Aug-01-1989. + (Format: TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by + RFC2236) (Also STD0005) (Status: STANDARD) + +1113 Privacy enhancement for Internet electronic mail: Part I - + message encipherment and authentication procedures. J. Linn. + Aug-01-1989. (Format: TXT=89293 bytes) (Obsoletes RFC0989, RFC1040) + (Obsoleted by RFC1421) (Status: HISTORIC) + +1114 Privacy enhancement for Internet electronic mail: Part II - + certificate-based key management. S.T. Kent, J. Linn. Aug-01-1989. + (Format: TXT=69661 bytes) (Obsoleted by RFC1422) (Status: HISTORIC) + +1115 Privacy enhancement for Internet electronic mail: Part III - + algorithms, modes, and identifiers. J. Linn. Aug-01-1989. (Format: + TXT=18226 bytes) (Obsoleted by RFC1423) (Status: HISTORIC) + +1116 Telnet Linemode option. D.A. Borman. Aug-01-1989. (Format: + TXT=47473 bytes) (Obsoleted by RFC1184) (Status: PROPOSED STANDARD) + +1117 Internet numbers. S. Romano, M.K. Stahl, M. Recker. Aug-01-1989. + (Format: TXT=324666 bytes) (Obsoletes RFC1062, RFC1020, RFC0997) + (Obsoleted by RFC1166) (Status: INFORMATIONAL) + +1118 Hitchhikers guide to the Internet. E. Krol. Sep-01-1989. (Format: + TXT=62757 bytes) (Status: INFORMATIONAL) + +1119 Network Time Protocol (version 2) specification and + implementation. D.L. Mills. Sep-01-1989. (Format: TXT=143, PS=518020, + PDF=187940 bytes) (Obsoletes RFC0958, RFC1059) (Obsoleted by RFC1305) + (Also STD0012) (Status: STANDARD) + +1120 Internet Activities Board. V. Cerf. Sep-01-1989. (Format: + TXT=26123 bytes) (Obsoleted by RFC1160) (Status: INFORMATIONAL) + +1121 Act one - the poems. J. Postel, L. Kleinrock, V.G. Cerf, B. + Boehm. Sep-01-1989. (Format: TXT=10644 bytes) (Status: INFORMATIONAL) + +1122 Requirements for Internet Hosts - Communication Layers. R. + Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Also STD0003) + (Status: STANDARD) + +1123 Requirements for Internet Hosts - Application and Support. R. + Braden, Ed.. October 1989. (Format: TXT=245503 bytes) (Updates + RFC0822) (Updated by RFC2181) (Also STD0003) (Status: STANDARD) + +1124 Policy issues in interconnecting networks. B.M. Leiner. + Sep-01-1989. (Format: TXT=118, PS=315692, PDF=143819 bytes) (Status: + UNKNOWN) + +1125 Policy requirements for inter Administrative Domain routing. D. + Estrin. Nov-01-1989. (Format: TXT=55248, PS=282123, PDF=289862 bytes) + (Status: UNKNOWN) + +1126 Goals and functional requirements for inter-autonomous system + routing. M. Little. Oct-01-1989. (Format: TXT=62725 bytes) (Status: + UNKNOWN) + +1127 Perspective on the Host Requirements RFCs. R.T. Braden. + Oct-01-1989. (Format: TXT=41267 bytes) (Status: INFORMATIONAL) + +1128 Measured performance of the Network Time Protocol in the Internet + system. D.L. Mills. Oct-01-1989. (Format: TXT=314, PS=633742, + PDF=197897 bytes) (Status: UNKNOWN) + +1129 Internet Time Synchronization: The Network Time Protocol. D.L. + Mills. Oct-01-1989. (Format: TXT=298, PS=551697, PDF=197036 bytes) + (Also RFC1119) (Status: INFORMATIONAL) + +1130 IAB official protocol standards. Defense Advanced Research + Projects Agency, Internet Activities Board. Oct-01-1989. (Format: + TXT=33858 bytes) (Obsoletes RFC1100) (Obsoleted by RFC1140) (Status: + HISTORIC) + +1131 OSPF specification. J. Moy. Oct-01-1989. (Format: TXT=268, + PS=857280, PDF=398863 bytes) (Obsoleted by RFC1247) (Status: PROPOSED + STANDARD) + +1132 Standard for the transmission of 802.2 packets over IPX networks. + L.J. McLaughlin. Nov-01-1989. (Format: TXT=8128 bytes) (Also STD0049) + (Status: STANDARD) + +1133 Routing between the NSFNET and the DDN. J.Y. Yu, H.W. Braun. + Nov-01-1989. (Format: TXT=23169 bytes) (Status: INFORMATIONAL) + +1134 Point-to-Point Protocol: A proposal for multi-protocol + transmission of datagrams over Point-to-Point links. D. Perkins. + Nov-01-1989. (Format: TXT=87352 bytes) (Obsoleted by RFC1171) + (Status: PROPOSED STANDARD) + +1135 Helminthiasis of the Internet. J.K. Reynolds. Dec-01-1989. + (Format: TXT=77033 bytes) (Status: INFORMATIONAL) + +1136 Administrative Domains and Routing Domains: A model for routing + in the Internet. S. Hares, D. Katz. Dec-01-1989. (Format: TXT=22158 + bytes) (Status: INFORMATIONAL) + +1137 Mapping between full RFC 822 and RFC 822 with restricted + encoding. S. Kille. Dec-01-1989. (Format: TXT=6266 bytes) (Updates + RFC0976) (Status: HISTORIC) + +1138 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.E. Kille. + Dec-01-1989. (Format: TXT=191029 bytes) (Obsoleted by RFC1327, + RFC2156) (Updates RFC0822, RFC0987, RFC1026) (Updated by RFC1148) + (Status: EXPERIMENTAL) + +1139 Echo function for ISO 8473. R.A. Hagens. Jan-01-1990. (Format: + TXT=14229 bytes) (Obsoleted by RFC1574, RFC1575) (Status: PROPOSED + STANDARD) + +1140 IAB official protocol standards. Defense Advanced Research + Projects Agency, Internet Activities Board. May-01-1990. (Format: + TXT=60501 bytes) (Obsoletes RFC1130) (Obsoleted by RFC1200) (Status: + HISTORIC) + +1141 Incremental updating of the Internet checksum. T. Mallory, A. + Kullberg. Jan-01-1990. (Format: TXT=3587 bytes) (Updates RFC1071) + (Updated by RFC1624) (Status: INFORMATIONAL) + +1142 OSI IS-IS Intra-domain Routing Protocol. D. Oran. Feb-01-1990. + (Format: TXT=425379, PS=1440951, PDF=490300 bytes) (Status: + INFORMATIONAL) + +1143 The Q Method of Implementing TELNET Option Negotiation. D.J. + Bernstein. Feb-01-1990. (Format: TXT=23331 bytes) (Status: + EXPERIMENTAL) + +1144 Compressing TCP/IP headers for low-speed serial links. V. + Jacobson. Feb-01-1990. (Format: TXT=120959, PS=534729, PDF=255616 + bytes) (Status: PROPOSED STANDARD) + +1145 TCP alternate checksum options. J. Zweig, C. Partridge. + Feb-01-1990. (Format: TXT=11052 bytes) (Obsoleted by RFC1146) + (Status: EXPERIMENTAL) + +1146 TCP alternate checksum options. J. Zweig, C. Partridge. + Mar-01-1990. (Format: TXT=10955 bytes) (Obsoletes RFC1145) (Status: + EXPERIMENTAL) + +1147 FYI on a Network Management Tool Catalog: Tools for Monitoring + and Debugging TCP/IP Internets and Interconnected Devices. R.H. + Stine. Apr-01-1990. (Format: TXT=336906, PS=555225, PDF=308602 bytes) + (Obsoleted by RFC1470) (Status: INFORMATIONAL) + +1148 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.E. Kille. + Mar-01-1990. (Format: TXT=194292 bytes) (Obsoleted by RFC1327, + RFC2156) (Updates RFC0822, RFC0987, RFC1026, RFC1138) (Status: + EXPERIMENTAL) + +1149 Standard for the transmission of IP datagrams on avian carriers. + D. Waitzman. Apr-01-1990. (Format: TXT=3329 bytes) (Updated by + RFC2549) (Status: EXPERIMENTAL) + +1150 FYI on FYI: Introduction to the FYI Notes. G.S. Malkin, J.K. + Reynolds. Mar-01-1990. (Format: TXT=7867 bytes) (Also FYI0001) + (Status: INFORMATIONAL) + +1151 Version 2 of the Reliable Data Protocol (RDP). C. Partridge, R.M. + Hinden. Apr-01-1990. (Format: TXT=8293 bytes) (Updates RFC0908) + (Status: EXPERIMENTAL) + +1152 Workshop report: Internet research steering group workshop on + very-high-speed networks. C. Partridge. Apr-01-1990. (Format: + TXT=64003 bytes) (Status: INFORMATIONAL) + +1153 Digest message format. F.J. Wancho. Apr-01-1990. (Format: + TXT=6632 bytes) (Status: EXPERIMENTAL) + +1154 Encoding header field for internet messages. D. Robinson, R. + Ullmann. Apr-01-1990. (Format: TXT=12214 bytes) (Obsoleted by + RFC1505) (Status: EXPERIMENTAL) + +1155 Structure and identification of management information for + TCP/IP-based internets. M.T. Rose, K. McCloghrie. May-01-1990. + (Format: TXT=40927 bytes) (Obsoletes RFC1065) (Also STD0016) (Status: + STANDARD) + +1156 Management Information Base for network management of + TCP/IP-based internets. K. McCloghrie, M.T. Rose. May-01-1990. + (Format: TXT=138781 bytes) (Obsoletes RFC1066) (Status: HISTORIC) + +1157 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, + M.L. Schoffstall, C. Davin. May-01-1990. (Format: TXT=74894 bytes) + (Obsoletes RFC1098) (Also STD0015) (Status: STANDARD) + +1158 Management Information Base for network management of + TCP/IP-based internets: MIB-II. M.T. Rose. May-01-1990. (Format: + TXT=212152 bytes) (Obsoleted by RFC1213) (Status: PROPOSED STANDARD) + +1159 Message Send Protocol. R. Nelson. Jun-01-1990. (Format: TXT=3957 + bytes) (Obsoleted by RFC1312) (Status: EXPERIMENTAL) + +1160 Internet Activities Board. V. Cerf. May-01-1990. (Format: + TXT=28182 bytes) (Obsoletes RFC1120) (Status: INFORMATIONAL) + +1161 SNMP over OSI. M.T. Rose. Jun-01-1990. (Format: TXT=16036 bytes) + (Obsoleted by RFC1418) (Status: EXPERIMENTAL) + +1162 Connectionless Network Protocol (ISO 8473) and End System to + Intermediate System (ISO 9542) Management Information Base. G. Satz. + Jun-01-1990. (Format: TXT=109893 bytes) (Obsoleted by RFC1238) + (Status: EXPERIMENTAL) + +1163 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. + Jun-01-1990. (Format: TXT=69404 bytes) (Obsoletes RFC1105) (Obsoleted + by RFC1267) (Status: HISTORIC) + +1164 Application of the Border Gateway Protocol in the Internet. J.C. + Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu. Jun-01-1990. (Format: + TXT=56278 bytes) (Obsoleted by RFC1268) (Status: HISTORIC) + +1165 Network Time Protocol (NTP) over the OSI Remote Operations + Service. J. Crowcroft, J.P. Onions. Jun-01-1990. (Format: TXT=18277 + bytes) (Status: EXPERIMENTAL) + +1166 Internet numbers. S. Kirkpatrick, M.K. Stahl, M. Recker. + Jul-01-1990. (Format: TXT=566778 bytes) (Obsoletes RFC1117, RFC1062, + RFC1020) (Status: INFORMATIONAL) + +1167 Thoughts on the National Research and Education Network. V.G. + Cerf. Jul-01-1990. (Format: TXT=20682 bytes) (Status: INFORMATIONAL) + +1168 Intermail and Commercial Mail Relay services. A. Westine, A.L. + DeSchon, J. Postel, C.E. Ward. Jul-01-1990. (Format: TXT=40306, + PS=149816, PDF=55890 bytes) (Status: INFORMATIONAL) + +1169 Explaining the role of GOSIP. V.G. Cerf, K.L. Mills. Aug-01-1990. + (Format: TXT=30255 bytes) (Status: INFORMATIONAL) + +1170 Public key standards and licenses. R.B. Fougner. Jan-01-1991. + (Format: TXT=3144 bytes) (Status: INFORMATIONAL) + +1171 Point-to-Point Protocol for the transmission of multi-protocol + datagrams over Point-to-Point links. D. Perkins. Jul-01-1990. + (Format: TXT=92321 bytes) (Obsoletes RFC1134) (Obsoleted by RFC1331) + (Status: DRAFT STANDARD) + +1172 Point-to-Point Protocol (PPP) initial configuration options. D. + Perkins, R. Hobby. Jul-01-1990. (Format: TXT=76132 bytes) (Obsoleted + by RFC1331, RFC1332) (Status: PROPOSED STANDARD) + +1173 Responsibilities of host and network managers: A summary of the + "oral tradition" of the Internet. J. VanBokkelen. Aug-01-1990. + (Format: TXT=12527 bytes) (Status: INFORMATIONAL) + +1174 IAB recommended policy on distributing internet identifier + assignment and IAB recommended policy change to internet "connected" + status. V.G. Cerf. Aug-01-1990. (Format: TXT=21321 bytes) (Status: + INFORMATIONAL) + +1175 FYI on where to start: A bibliography of internetworking + information. K.L. Bowers, T.L. LaQuey, J.K. Reynolds, K. Roubicek, + M.K. Stahl, A. Yuan. Aug-01-1990. (Format: TXT=67330 bytes) (Also + FYI0003) (Status: INFORMATIONAL) + +1176 Interactive Mail Access Protocol: Version 2. M.R. Crispin. + Aug-01-1990. (Format: TXT=67330 bytes) (Obsoletes RFC1064) (Status: + EXPERIMENTAL) + +1177 FYI on Questions and Answers: Answers to commonly asked "new + internet user" questions. G.S. Malkin, A.N. Marine, J.K. Reynolds. + Aug-01-1990. (Format: TXT=52852 bytes) (Obsoleted by RFC1206) + (Status: INFORMATIONAL) + +1178 Choosing a name for your computer. D. Libes. Aug-01-1990. + (Format: TXT=18472 bytes) (Also FYI0005) (Status: INFORMATIONAL) + +1179 Line printer daemon protocol. L. McLaughlin. Aug-01-1990. + (Format: TXT=24324 bytes) (Status: INFORMATIONAL) + +1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. Jan-01-1991. + (Format: TXT=65494 bytes) (Status: INFORMATIONAL) + +1181 RIPE Terms of Reference. R. Blokzijl. Sep-01-1990. (Format: + TXT=2523 bytes) (Status: INFORMATIONAL) + +1182 Not Issued. + +1183 New DNS RR Definitions. C.F. Everhart, L.A. Mamakos, R. Ullmann, + P.V. Mockapetris. Oct-01-1990. (Format: TXT=23788 bytes) (Updates + RFC1034, RFC1035) (Status: EXPERIMENTAL) + +1184 Telnet Linemode Option. D.A. Borman. Oct-01-1990. (Format: + TXT=53085 bytes) (Obsoletes RFC1116) (Status: DRAFT STANDARD) + +1185 TCP Extension for High-Speed Paths. V. Jacobson, R.T. Braden, L. + Zhang. Oct-01-1990. (Format: TXT=49508 bytes) (Obsoleted by RFC1323) + (Status: EXPERIMENTAL) + +1186 MD4 Message Digest Algorithm. R.L. Rivest. Oct-01-1990. (Format: + TXT=35391 bytes) (Obsoleted by RFC1320) (Status: INFORMATIONAL) + +1187 Bulk Table Retrieval with the SNMP. M.T. Rose, K. McCloghrie, + J.R. Davin. Oct-01-1990. (Format: TXT=27220 bytes) (Status: + EXPERIMENTAL) + +1188 Proposed Standard for the Transmission of IP Datagrams over FDDI + Networks. D. Katz. Oct-01-1990. (Format: TXT=22424 bytes) (Obsoletes + RFC1103) (Status: DRAFT STANDARD) + +1189 Common Management Information Services and Protocols for the + Internet (CMOT and CMIP). U.S. Warrier, L. Besaw, L. LaBarre, B.D. + Handspicker. Oct-01-1990. (Format: TXT=32928 bytes) (Obsoletes + RFC1095) (Status: HISTORIC) + +1190 Experimental Internet Stream Protocol: Version 2 (ST-II). C. + Topolcic. Oct-01-1990. (Format: TXT=386909 bytes) (Obsoletes IEN 119) + (Obsoleted by RFC1819) (Status: EXPERIMENTAL) + +1191 Path MTU discovery. J.C. Mogul, S.E. Deering. Nov-01-1990. + (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT + STANDARD) + +1192 Commercialization of the Internet summary report. B. Kahin. + Nov-01-1990. (Format: TXT=35253 bytes) (Status: INFORMATIONAL) + +1193 Client requirements for real-time communication services. D. + Ferrari. Nov-01-1990. (Format: TXT=61540 bytes) (Status: + INFORMATIONAL) + +1194 Finger User Information Protocol. D.P. Zimmerman. Nov-01-1990. + (Format: TXT=24626 bytes) (Obsoletes RFC0742) (Obsoleted by RFC1196, + RFC1288) (Status: DRAFT STANDARD) + +1195 Use of OSI IS-IS for routing in TCP/IP and dual environments. + R.W. Callon. Dec-01-1990. (Format: TXT=187866, PS=362052 bytes) + (Status: PROPOSED STANDARD) + +1196 Finger User Information Protocol. D.P. Zimmerman. Dec-01-1990. + (Format: TXT=24799 bytes) (Obsoletes RFC1194, RFC0742) (Obsoleted by + RFC1288) (Status: DRAFT STANDARD) + +1197 Using ODA for translating multimedia information. M. Sherman. + Dec-01-1990. (Format: TXT=3620 bytes) (Status: INFORMATIONAL) + +1198 FYI on the X window system. R.W. Scheifler. Jan-01-1991. (Format: + TXT=3629 bytes) (Also FYI0006) (Status: INFORMATIONAL) + +1199 Request for Comments Summary Notes: 1100-1199. J. Reynolds. + Dec-01-1991. (Format: TXT=46443 bytes) (Status: INFORMATIONAL) + +1200 IAB official protocol standards. Defense Advanced Research + Projects Agency, Internet Activities Board. Apr-01-1991. (Format: + TXT=67069 bytes) (Obsoletes RFC1140) (Obsoleted by RFC1250) (Status: + HISTORIC) + +1201 Transmitting IP traffic over ARCNET networks. D. Provan. + Feb-01-1991. (Format: TXT=16959 bytes) (Obsoletes RFC1051) (Also + STD0046) (Status: STANDARD) + +1202 Directory Assistance service. M.T. Rose. Feb-01-1991. (Format: + TXT=21645 bytes) (Status: INFORMATIONAL) + +1203 Interactive Mail Access Protocol: Version 3. J. Rice. + Feb-01-1991. (Format: TXT=123325 bytes) (Obsoletes RFC1064) (Status: + HISTORIC) + +1204 Message Posting Protocol (MPP). S. Yeh, D. Lee. Feb-01-1991. + (Format: TXT=11371 bytes) (Status: EXPERIMENTAL) + +1205 5250 Telnet interface. P. Chmielewski. Feb-01-1991. (Format: + TXT=27179 bytes) (Updated by RFC2877) (Status: INFORMATIONAL) + +1206 FYI on Questions and Answers: Answers to commonly asked "new + Internet user" questions. G.S. Malkin, A.N. Marine. Feb-01-1991. + (Format: TXT=72479 bytes) (Obsoletes RFC1177) (Obsoleted by RFC1325) + (Status: INFORMATIONAL) + +1207 FYI on Questions and Answers: Answers to commonly asked + "experienced Internet user" questions. G.S. Malkin, A.N. Marine, J.K. + Reynolds. Feb-01-1991. (Format: TXT=33385 bytes) (Also FYI0007) + (Status: INFORMATIONAL) + +1208 Glossary of networking terms. O.J. Jacobsen, D.C. Lynch. + Mar-01-1991. (Format: TXT=41156 bytes) (Status: INFORMATIONAL) + +1209 Transmission of IP datagrams over the SMDS Service. D.M. + Piscitello, J. Lawrence. Mar-01-1991. (Format: TXT=25280 bytes) (Also + STD0052) (Status: STANDARD) + +1210 Network and infrastructure user requirements for transatlantic + research collaboration: Brussels, July 16-18, and Washington July + 24-25, 1990. V.G. Cerf, P.T. Kirstein, B. Randell. Mar-01-1991. + (Format: TXT=79048 bytes) (Status: INFORMATIONAL) + +1211 Problems with the maintenance of large mailing lists. A. Westine, + J. Postel. Mar-01-1991. (Format: TXT=96167 bytes) (Status: + INFORMATIONAL) + +1212 Concise MIB definitions. M.T. Rose, K. McCloghrie. Mar-01-1991. + (Format: TXT=43579 bytes) (Also STD0016) (Status: STANDARD) + +1213 Management Information Base for Network Management of + TCP/IP-based internets:MIB-II. K. McCloghrie, M.T. Rose. Mar-01-1991. + (Format: TXT=146080 bytes) (Obsoletes RFC1158) (Updated by RFC2011, + RFC2012, RFC2013) (Also STD0017) (Status: STANDARD) + +1214 OSI internet management: Management Information Base. L. LaBarre. + Apr-01-1991. (Format: TXT=172564 bytes) (Status: HISTORIC) + +1215 Convention for defining traps for use with the SNMP. M.T. Rose. + Mar-01-1991. (Format: TXT=19336 bytes) (Status: INFORMATIONAL) + +1216 Gigabit network economics and paradigm shifts. P. Richard, P. + Kynikos. Apr-01-1991. (Format: TXT=8130 bytes) (Status: + INFORMATIONAL) + +1217 Memo from the Consortium for Slow Commotion Research (CSCR). V.G. + Cerf. Apr-01-1991. (Format: TXT=11079 bytes) (Status: INFORMATIONAL) + +1218 Naming scheme for c=US. North American Directory Forum. + Apr-01-1991. (Format: TXT=42698 bytes) (Obsoleted by RFC1255, + RFC1417) (Status: INFORMATIONAL) + +1219 On the assignment of subnet numbers. P.F. Tsuchiya. Apr-01-1991. + (Format: TXT=30609 bytes) (Status: INFORMATIONAL) + +1220 Point-to-Point Protocol extensions for bridging. F. Baker. + Apr-01-1991. (Format: TXT=38165 bytes) (Obsoleted by RFC1638) + (Status: PROPOSED STANDARD) + +1221 Host Access Protocol (HAP) specification: Version 2. W. Edmond. + Apr-01-1991. (Format: TXT=152740 bytes) (Updates RFC0907) (Status: + INFORMATIONAL) + +1222 Advancing the NSFNET routing architecture. H.W. Braun, Y. + Rekhter. May-01-1991. (Format: TXT=15067 bytes) (Status: + INFORMATIONAL) + +1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel. J.M. + Halpern. May-01-1991. (Format: TXT=29601 bytes) (Status: + INFORMATIONAL) + +1224 Techniques for managing asynchronously generated alerts. L. + Steinberg. May-01-1991. (Format: TXT=54303 bytes) (Status: + EXPERIMENTAL) + +1225 Post Office Protocol: Version 3. M.T. Rose. May-01-1991. (Format: + TXT=37340 bytes) (Obsoletes RFC1081) (Obsoleted by RFC1460) (Status: + DRAFT STANDARD) + +1226 Internet protocol encapsulation of AX.25 frames. B. Kantor. + May-01-1991. (Format: TXT=2573 bytes) (Status: EXPERIMENTAL) + +1227 SNMP MUX protocol and MIB. M.T. Rose. May-01-1991. (Format: + TXT=25868 bytes) (Status: HISTORIC) + +1228 SNMP-DPI: Simple Network Management Protocol Distributed Program + Interface. G. Carpenter, B. Wijnen. May-01-1991. (Format: TXT=96972 + bytes) (Obsoleted by RFC1592) (Status: EXPERIMENTAL) + +1229 Extensions to the generic-interface MIB. K. McCloghrie. + May-01-1991. (Format: TXT=36022 bytes) (Obsoleted by RFC1573) + (Updated by RFC1239) (Status: PROPOSED STANDARD) + +1230 IEEE 802.4 Token Bus MIB. K. McCloghrie, R. Fox. May-01-1991. + (Format: TXT=53100 bytes) (Updated by RFC1239) (Status: HISTORIC) + +1231 IEEE 802.5 Token Ring MIB. K. McCloghrie, R. Fox, E. Decker. + May-01-1991. (Format: TXT=53542 bytes) (Obsoleted by RFC1743, + RFC1748) (Updated by RFC1239) (Status: PROPOSED STANDARD) + +1232 Definitions of managed objects for the DS1 Interface type. F. + Baker, C.P. Kolb. May-01-1991. (Format: TXT=60757 bytes) (Obsoleted + by RFC1406) (Updated by RFC1239) (Status: PROPOSED STANDARD) + +1233 Definitions of managed objects for the DS3 Interface type. T.A. + Cox, K. Tesink. May-01-1991. (Format: TXT=49559 bytes) (Obsoleted by + RFC1407) (Updated by RFC1239) (Status: PROPOSED STANDARD) + +1234 Tunneling IPX traffic through IP networks. D. Provan. + Jun-01-1991. (Format: TXT=12333 bytes) (Status: PROPOSED STANDARD) + +1235 Coherent File Distribution Protocol. J. Ioannidis, G. Maguire. + Jun-01-1991. (Format: TXT=29345 bytes) (Status: EXPERIMENTAL) + +1236 IP to X.121 address mapping for DDN. L. Morales, P. Hasse. + Jun-01-1991. (Format: TXT=12626 bytes) (Status: INFORMATIONAL) + +1237 Guidelines for OSI NSAP Allocation in the Internet. R. Collela, + E.P. Gardner, R.W. Callon. Jul-01-1991. (Format: TXT=116989, + PS=160478, PDF=171423 bytes) (Obsoleted by RFC1629) (Status: PROPOSED + STANDARD) + +1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) + and End System to Intermediate System (ISO 9542). G. Satz. + Jun-01-1991. (Format: TXT=65159 bytes) (Obsoletes RFC1162) (Status: + EXPERIMENTAL) + +1239 Reassignment of experimental MIBs to standard MIBs. J.K. + Reynolds. Jun-01-1991. (Format: TXT=3656 bytes) (Updates RFC1229, + RFC1230, RFC1231, RFC1232, RFC1233) (Status: PROPOSED STANDARD) + +1240 OSI connectionless transport services on top of UDP: Version 1. + C. Shue, W. Haggerty, K. Dobbins. Jun-01-1991. (Format: TXT=18140 + bytes) (Status: HISTORIC) + +1241 Scheme for an internet encapsulation protocol: Version 1. R.A. + Woodburn, D.L. Mills. Jul-01-1991. (Format: TXT=42468, PS=128921, + PDF=44593 bytes) (Status: EXPERIMENTAL) + +1242 Benchmarking terminology for network interconnection devices. S. + Bradner. Jul-01-1991. (Format: TXT=22817 bytes) (Status: + INFORMATIONAL) + +1243 AppleTalk Management Information Base. S. Waldbusser. + Jul-01-1991. (Format: TXT=61985 bytes) (Obsoleted by RFC1742) + (Status: PROPOSED STANDARD) + +1244 Site Security Handbook. J.P. Holbrook, J.K. Reynolds. + Jul-01-1991. (Format: TXT=259129 bytes) (Obsoleted by RFC2196) + (Status: INFORMATIONAL) + +1245 OSPF Protocol Analysis. J. Moy. Jul-01-1991. (Format: TXT=26160, + PS=33546, PDF=31723 bytes) (Also RFC1247, RFC1246) (Status: + INFORMATIONAL) + +1246 Experience with the OSPF Protocol. J. Moy. Jul-01-1991. (Format: + TXT=70441, PS=141924, PDF=84633 bytes) (Also RFC1247, RFC1245) + (Status: INFORMATIONAL) + +1247 OSPF Version 2. J. Moy. Jul-01-1991. (Format: TXT=433332, + PS=989724, PDF=490300 bytes) (Obsoletes RFC1131) (Obsoleted by + RFC1583) (Also RFC1246, RFC1245) (Status: DRAFT STANDARD) + +1248 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. + Jul-01-1991. (Format: TXT=74347 bytes) (Obsoleted by RFC1252) + (Status: PROPOSED STANDARD) + +1249 DIXIE Protocol Specification. T. Howes, M. Smith, B. Beecher. + Aug-01-1991. (Format: TXT=20028 bytes) (Also RFC1202) (Status: + INFORMATIONAL) + +1250 IAB Official Protocol Standards. J. Postel. Aug-01-1991. (Format: + TXT=62555 bytes) (Obsoletes RFC1200) (Obsoleted by RFC2200, RFC1280) + (Status: HISTORIC) + +1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG + Members. G. Malkin. Aug-01-1991. (Format: TXT=70383 bytes) (Obsoleted + by RFC1336) (Status: INFORMATIONAL) + +1252 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. + Aug-01-1991. (Format: TXT=74471 bytes) (Obsoletes RFC1248) (Obsoleted + by RFC1253) (Also RFC1247, RFC1245) (Status: PROPOSED STANDARD) + +1253 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. + Aug-01-1991. (Format: TXT=74453 bytes) (Obsoletes RFC1252) (Obsoleted + by RFC1850) (Also RFC1247, RFC1245, RFC1246) (Status: PROPOSED + STANDARD) + +1254 Gateway Congestion Control Survey. A. Mankin, K. Ramakrishnan. + Aug-01-1991. (Format: TXT=67609 bytes) (Status: INFORMATIONAL) + +1255 A Naming Scheme for c=US. The North American Directory Forum. + Sep-01-1991. (Format: TXT=51103 bytes) (Obsoletes RFC1218) (Obsoleted + by RFC1417) (Status: INFORMATIONAL) + +1256 ICMP Router Discovery Messages. S. Deering. Sep-01-1991. (Format: + TXT=43059 bytes) (Also RFC0792) (Status: PROPOSED STANDARD) + +1257 Isochronous applications do not require jitter-controlled + networks. C. Partridge. Sep-01-1991. (Format: TXT=11075 bytes) + (Status: INFORMATIONAL) + +1258 BSD Rlogin. B. Kantor. Sep-01-1991. (Format: TXT=10763 bytes) + (Status: INFORMATIONAL) + +1259 Building the open road: The NREN as test-bed for the national + public network. M. Kapor. Sep-01-1991. (Format: TXT=61654 bytes) + (Status: INFORMATIONAL) + +1260 Not Issued. + +1261 Transition of Nic Services. S. Williamson, L. Nobile. + Sep-01-1991. (Format: TXT=4244 bytes) (Status: INFORMATIONAL) + +1262 Guidelines for Internet Measurement Activities. V.G. Cerf. + Oct-01-1991. (Format: TXT=6381 bytes) (Status: INFORMATIONAL) + +1263 TCP Extensions Considered Harmful. S. O'Malley, L.L. Peterson. + Oct-01-1991. (Format: TXT=54078 bytes) (Status: INFORMATIONAL) + +1264 Internet Engineering Task Force Internet Routing Protocol + Standardization Criteria. R.M. Hinden. Oct-01-1991. (Format: + TXT=17016 bytes) (Status: INFORMATIONAL) + +1265 BGP Protocol Analysis. Y. Rekhter. Oct-01-1991. (Format: + TXT=20728 bytes) (Status: INFORMATIONAL) + +1266 Experience with the BGP Protocol. Y. Rekhter. Oct-01-1991. + (Format: TXT=21938 bytes) (Status: INFORMATIONAL) + +1267 Border Gateway Protocol 3 (BGP-3). K. Lougheed, Y. Rekhter. + Oct-01-1991. (Format: TXT=80724 bytes) (Obsoletes RFC1163) (Status: + HISTORIC) + +1268 Application of the Border Gateway Protocol in the Internet. Y. + Rekhter, P. Gross. Oct-01-1991. (Format: TXT=31102 bytes) (Obsoletes + RFC1164) (Obsoleted by RFC1655) (Status: HISTORIC) + +1269 Definitions of Managed Objects for the Border Gateway Protocol: + Version 3. S. Willis, J.W. Burruss. Oct-01-1991. (Format: TXT=25717 + bytes) (Status: PROPOSED STANDARD) + +1270 SNMP Communications Services. F. Kastenholz. Oct-01-1991. + (Format: TXT=26167 bytes) (Status: INFORMATIONAL) + +1271 Remote Network Monitoring Management Information Base. S. + Waldbusser. Nov-01-1991. (Format: TXT=184111 bytes) (Obsoleted by + RFC1757) (Updated by RFC1513) (Status: PROPOSED STANDARD) + +1272 Internet Accounting: Background. C. Mills, D. Hirsh, G.R. Ruth. + Nov-01-1991. (Format: TXT=46562 bytes) (Status: INFORMATIONAL) + +1273 Measurement Study of Changes in Service-Level Reachability in the + Global TCP/IP Internet: Goals, Experimental Design, Implementation, + and Policy Considerations. M.F. Schwartz. Nov-01-1991. (Format: + TXT=19949 bytes) (Status: INFORMATIONAL) + +1274 The COSINE and Internet X.500 Schema. P. Barker, S. Kille. + November 1991. (Format: TXT=92827 bytes) (Status: PROPOSED STANDARD) + +1275 Replication Requirements to provide an Internet Directory using + X.500. S.E. Hardcastle-Kille. November 1991. (Format: TXT=4616, + PS=83736, PDF=62498 bytes) (Status: INFORMATIONAL) + +1276 Replication and Distributed Operations extensions to provide an + Internet Directory using X.500. S.E. Hardcastle-Kille. November 1991. + (Format: TXT=33731, PS=217170 bytes) (Status: PROPOSED STANDARD) + +1277 Encoding Network Addresses to Support Operation over Non-OSI + Lower Layers. S.E. Hardcastle-Kille. November 1991. (Format: + TXT=22254, PS=176169 bytes) (Status: PROPOSED STANDARD) + +1278 A string encoding of Presentation Address. S.E. Hardcastle-Kille. + November 1991. (Format: TXT=10256, PS=128696 bytes) (Status: + INFORMATIONAL) + +1279 X.500 and Domains. S.E. Hardcastle-Kille. November 1991. (Format: + TXT=26669, PS=170029 bytes) (Status: EXPERIMENTAL) + +1280 IAB Official Protocol Standards. J. Postel. March 1992. (Format: + TXT=70458 bytes) (Obsoletes RFC1250) (Obsoleted by RFC1360) (Status: + HISTORIC) + +1281 Guidelines for the Secure Operation of the Internet. R. Pethia, + S. Crocker, B. Fraser. November 1991. (Format: TXT=22618 bytes) + (Status: INFORMATIONAL) + +1282 BSD Rlogin. B. Kantor. December 1991. (Format: TXT=10704 bytes) + (Status: INFORMATIONAL) + +1283 SNMP over OSI. M. Rose. December 1991. (Format: TXT=16857 bytes) + (Obsoleted by RFC1418) (Status: EXPERIMENTAL) + +1284 Definitions of Managed Objects for the Ethernet-like Interface + Types. J. Cook. December 1991. (Format: TXT=43225 bytes) (Obsoleted + by RFC1398) (Status: PROPOSED STANDARD) + +1285 FDDI Management Information Base. J. Case. January 1992. (Format: + TXT=99747 bytes) (Updated by RFC1512) (Status: PROPOSED STANDARD) + +1286 Definitions of Managed Objects for Bridges. E. Decker, P. + Langille, A. Rijsinghani, K. McCloghrie. December 1991. (Format: + TXT=79104 bytes) (Obsoleted by RFC1493, RFC1525) (Status: PROPOSED + STANDARD) + +1287 Towards the Future Internet Architecture. D. Clark, L. Chapin, V. + Cerf, R. Braden, R. Hobby. December 1991. (Format: TXT=59812 bytes) + (Status: INFORMATIONAL) + +1288 The Finger User Information Protocol. D. Zimmerman. December + 1991. (Format: TXT=25161 bytes) (Obsoletes RFC1196, RFC1194, RFC0742) + (Status: DRAFT STANDARD) + +1289 DECnet Phase IV MIB Extensions. J. Saperia. December 1991. + (Format: TXT=122272 bytes) (Obsoleted by RFC1559) (Status: PROPOSED + STANDARD) + +1290 There's Gold in them thar Networks! or Searching for Treasure in + all the Wrong Places. J. Martin. December 1991. (Format: TXT=46997 + bytes) (Obsoleted by RFC1402) (Status: INFORMATIONAL) + +1291 Mid-Level Networks Potential Technical Services. V. Aggarwal. + December 1991. (Format: TXT=24314, PS=218918 bytes) (Status: + INFORMATIONAL) + +1292 A Catalog of Available X.500 Implementations. R. Lang, R. Wright. + January 1992. (Format: TXT=129468 bytes) (Obsoleted by RFC1632) + (Status: INFORMATIONAL) + +1293 Inverse Address Resolution Protocol. T. Bradley, C. Brown. + January 1992. (Format: TXT=11368 bytes) (Obsoleted by RFC2390) + (Status: PROPOSED STANDARD) + +1294 Multiprotocol Interconnect over Frame Relay. T. Bradley, C. + Brown, A. Malis. January 1992. (Format: TXT=54992 bytes) (Obsoleted + by RFC1490, RFC2427) (Status: PROPOSED STANDARD) + +1295 User Bill of Rights for entries and listings in the Public + Directory. The North American Directory Forum. January 1992. (Format: + TXT=3502 bytes) (Obsoleted by RFC1417) (Status: INFORMATIONAL) + +1296 Internet Growth (1981-1991). M. Lottor. January 1992. (Format: + TXT=20103 bytes) (Status: INFORMATIONAL) + +1297 NOC Internal Integrated Trouble Ticket System Functional + Specification Wishlist ("NOC TT REQUIREMENTS"). D. Johnson. January + 1992. (Format: TXT=32964 bytes) (Status: INFORMATIONAL) + +1298 SNMP over IPX. R. Wormley, S. Bostock. February 1992. (Format: + TXT=7878 bytes) (Obsoleted by RFC1420) (Status: INFORMATIONAL) + +1299 Summary of 1200-1299. M. Kennedy. January 1997. (Format: + TXT=36594 bytes) (Status: INFORMATIONAL) + +1300 Remembrances of Things Past. S. Greenfield. February 1992. + (Format: TXT=4963 bytes) (Status: INFORMATIONAL) + +1301 Multicast Transport Protocol. S. Armstrong, A. Freier, K. + Marzullo. February 1992. (Format: TXT=91976 bytes) (Status: + INFORMATIONAL) + +1302 Building a Network Information Services Infrastructure. D. + Sitzler, P. Smith, A. Marine. February 1992. (Format: TXT=29135 + bytes) (Also FYI0012) (Status: INFORMATIONAL) + +1303 A Convention for Describing SNMP-based Agents. K. McCloghrie, M. + Rose. February 1992. (Format: TXT=22915 bytes) (Also RFC1155, + RFC1212, RFC1213, RFC1157) (Status: INFORMATIONAL) + +1304 Definitions of Managed Objects for the SIP Interface Type. T. + Cox, K. Tesink, Editors. February 1992. (Format: TXT=52491 bytes) + (Obsoleted by RFC1694) (Status: PROPOSED STANDARD) + +1305 Network Time Protocol (Version 3) Specification, Implementation. + David L. Mills. March 1992. (Format: TXT=307085, PDF=442493 bytes) + (Obsoletes RFC0958, RFC1059, RFC1119) (Status: DRAFT STANDARD) + +1306 Experiences Supporting By-Request Circuit-Switched T3 Networks. + A. Nicholson, J. Young. March 1992. (Format: TXT=25788 bytes) + (Status: INFORMATIONAL) + +1307 Dynamically Switched Link Control Protocol. J. Young, A. + Nicholson. March 1992. (Format: TXT=24145 bytes) (Status: + EXPERIMENTAL) + +1308 Executive Introduction to Directory Services Using the X.500 + Protocol. C. Weider, J. Reynolds. March 1992. (Format: TXT=9392 + bytes) (Also FYI0013) (Status: INFORMATIONAL) + +1309 Technical Overview of Directory Services Using the X.500 + Protocol. C. Weider, J. Reynolds, S. Heker. March 1992. (Format: + TXT=35694 bytes) (Also FYI0014) (Status: INFORMATIONAL) + +1310 The Internet Standards Process. L. Chapin. March 1992. (Format: + TXT=54738 bytes) (Obsoleted by RFC1602) (Status: INFORMATIONAL) + +1311 Introduction to the STD Notes. J. Postel. March 1992. (Format: + TXT=11308 bytes) (Status: INFORMATIONAL) + +1312 Message Send Protocol 2. R. Nelson, G. Arnold. April 1992. + (Format: TXT=18037 bytes) (Obsoletes RFC1159) (Status: EXPERIMENTAL) + +1313 Today's Programming for KRFC AM 1313 Internet Talk Radio. C. + Partridge. Apr-01-1992. (Format: TXT=5444 bytes) (Status: + INFORMATIONAL) + +1314 A File Format for the Exchange of Images in the Internet. A. + Katz, D. Cohen. April 1992. (Format: TXT=54072 bytes) (Status: + PROPOSED STANDARD) + +1315 Management Information Base for Frame Relay DTEs. C. Brown, F. + Baker, C. Carvalho. April 1992. (Format: TXT=33825 bytes) (Obsoleted + by RFC2115) (Status: PROPOSED STANDARD) + +1316 Definitions of Managed Objects for Character Stream Devices. B. + Stewart. April 1992. (Format: TXT=35143 bytes) (Obsoleted by RFC1658) + (Status: PROPOSED STANDARD) + +1317 Definitions of Managed Objects for RS-232-like Hardware Devices. + B. Stewart. April 1992. (Format: TXT=30442 bytes) (Obsoleted by + RFC1659) (Status: PROPOSED STANDARD) + +1318 Definitions of Managed Objects for Parallel-printer-like Hardware + Devices. B. Stewart. April 1992. (Format: TXT=19570 bytes) (Obsoleted + by RFC1660) (Status: PROPOSED STANDARD) + +1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992. + (Format: TXT=25661 bytes) (Status: INFORMATIONAL) + +1320 The MD4 Message-Digest Algorithm. R. Rivest. April 1992. (Format: + TXT=32407 bytes) (Obsoletes RFC1186) (Status: INFORMATIONAL) + +1321 The MD5 Message-Digest Algorithm. R. Rivest. April 1992. (Format: + TXT=35222 bytes) (Status: INFORMATIONAL) + +1322 A Unified Approach to Inter-Domain Routing. D. Estrin, Y. + Rekhter, S. Hotz. May 1992. (Format: TXT=96934 bytes) (Status: + INFORMATIONAL) + +1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, D. + Borman. May 1992. (Format: TXT=84558 bytes) (Obsoletes RFC1072, + RFC1185) (Status: PROPOSED STANDARD) + +1324 A Discussion on Computer Network Conferencing. D. Reed. May 1992. + (Format: TXT=24988 bytes) (Status: INFORMATIONAL) + +1325 FYI on Questions and Answers Answers to Commonly asked "New + Internet User" Questions. G. Malkin, A. Marine. May 1992. (Format: + TXT=91884 bytes) (Obsoletes RFC1206) (Obsoleted by RFC1594) (Status: + INFORMATIONAL) + +1326 Mutual Encapsulation Considered Dangerous. P. Tsuchiya. May 1992. + (Format: TXT=11277 bytes) (Status: INFORMATIONAL) + +1327 Mapping between X.400(1988) / ISO 10021 and RFC 822. S. + Hardcastle-Kille. May 1992. (Format: TXT=228598 bytes) (Obsoletes + RFC0987, RFC1026, RFC1138, RFC1148) (Obsoleted by RFC2156) (Updates + RFC0822) (Updated by RFC1495) (Status: PROPOSED STANDARD) + +1328 X.400 1988 to 1984 downgrading. S. Hardcastle-Kille. May 1992. + (Format: TXT=10006 bytes) (Status: PROPOSED STANDARD) + +1329 Thoughts on Address Resolution for Dual MAC FDDI Networks. P. + Kuehn. May 1992. (Format: TXT=58150 bytes) (Status: INFORMATIONAL) + +1330 Recommendations for the Phase I Deployment of OSI Directory + Services (X.500) and OSI Message Handling Services (X.400) within the + ESNET Community. ESCC X.500/X.400 Task Force, ESnet Site Coordinating + Committee (ESCC). May 1992. (Format: TXT=192925 bytes) (Status: + INFORMATIONAL) + +1331 The Point-to-Point Protocol (PPP) for the Transmission of + Multi-protocol Datagrams over Point-to-Point Links. W. Simpson. May + 1992. (Format: TXT=129892 bytes) (Obsoletes RFC1171, RFC1172) + (Obsoleted by RFC1548) (Status: PROPOSED STANDARD) + +1332 The PPP Internet Protocol Control Protocol (IPCP). G. McGregor. + May 1992. (Format: TXT=17613 bytes) (Obsoletes RFC1172) (Status: + PROPOSED STANDARD) + +1333 PPP Link Quality Monitoring. W. Simpson. May 1992. (Format: + TXT=29965 bytes) (Obsoleted by RFC1989) (Status: PROPOSED STANDARD) + +1334 PPP Authentication Protocols. B. Lloyd, W. Simpson. October 1992. + (Format: TXT=33248 bytes) (Obsoleted by RFC1994) (Status: PROPOSED + STANDARD) + +1335 A Two-Tier Address Structure for the Internet: A Solution to the + Problem of Address Space Exhaustion. Z. Wang, J. Crowcroft. May 1992. + (Format: TXT=15418 bytes) (Status: INFORMATIONAL) + +1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG + Members. G. Malkin. May 1992. (Format: TXT=92119 bytes) (Obsoletes + RFC1251) (Also FYI0009) (Status: INFORMATIONAL) + +1337 TIME-WAIT Assassination Hazards in TCP. R. Braden. May 1992. + (Format: TXT=22887 bytes) (Status: INFORMATIONAL) + +1338 Supernetting: an Address Assignment and Aggregation Strategy. V. + Fuller, T. Li, J. Yu, K. Varadhan. June 1992. (Format: TXT=47975 + bytes) (Obsoleted by RFC1519) (Status: INFORMATIONAL) + +1339 Remote Mail Checking Protocol. S. Dorner, P. Resnick. June 1992. + (Format: TXT=13115 bytes) (Status: EXPERIMENTAL) + +1340 Assigned Numbers. J. Reynolds, J. Postel. July 1992. (Format: + TXT=232974 bytes) (Obsoletes RFC1060) (Obsoleted by RFC1700) (Status: + HISTORIC) + +1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for + Specifying and Describing the Format of Internet Message Bodies. N. + Borenstein, N. Freed. June 1992. (Format: TXT=211117, PS=347082, + PDF=192244 bytes) (Obsoleted by RFC1521) (Status: PROPOSED STANDARD) + +1342 Representation of Non-ASCII Text in Internet Message Headers. K. + Moore. June 1992. (Format: TXT=15845 bytes) (Obsoleted by RFC1522) + (Status: PROPOSED STANDARD) + +1343 A User Agent Configuration Mechanism for Multimedia Mail Format + Information. N. Borenstein. June 1992. (Format: TXT=29295, PS=59978, + PDF=28495 bytes) (Status: INFORMATIONAL) + +1344 Implications of MIME for Internet Mail Gateways. N. Borenstein. + June 1992. (Format: TXT=25872, PS=51812, PDF=24430 bytes) (Status: + INFORMATIONAL) + +1345 Character Mnemonics and Character Sets. K. Simonsen. June 1992. + (Format: TXT=249737 bytes) (Status: INFORMATIONAL) + +1346 Resource Allocation, Control, and Accounting for the Use of + Network Resources. P. Jones. June 1992. (Format: TXT=13084 bytes) + (Status: INFORMATIONAL) + +1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for + Internet Addressing and Routing. R. Callon. June 1992. (Format: + TXT=26563, PS=42398, PDF=22398 bytes) (Status: INFORMATIONAL) + +1348 DNS NSAP RRs. B. Manning. July 1992. (Format: TXT=6871 bytes) + (Obsoleted by RFC1637) (Updates RFC1034, RFC1035) (Status: + EXPERIMENTAL) + +1349 Type of Service in the Internet Protocol Suite. P. Almquist. July + 1992. (Format: TXT=68949 bytes) (Obsoleted by RFC2474) (Status: + PROPOSED STANDARD) + +1350 The TFTP Protocol (Revision 2). K. Sollins. July 1992. (Format: + TXT=24599 bytes) (Obsoletes RFC0783) (Updated by RFC1782, RFC1783, + RFC1784, RFC1785, RFC2347, RFC2348, RFC2349) (Also STD0033) (Status: + STANDARD) + +1351 SNMP Administrative Model. J. Davin, J. Galvin, K. McCloghrie. + July 1992. (Format: TXT=80721 bytes) (Status: HISTORIC) + +1352 SNMP Security Protocols. J. Galvin, K. McCloghrie, J. Davin. July + 1992. (Format: TXT=95732 bytes) (Status: HISTORIC) + +1353 Definitions of Managed Objects for Administration of SNMP + Parties. K. McCloghrie, J. Davin, J. Galvin. July 1992. (Format: + TXT=59556 bytes) (Status: HISTORIC) + +1354 IP Forwarding Table MIB. F. Baker. July 1992. (Format: TXT=24905 + bytes) (Obsoleted by RFC2096) (Status: PROPOSED STANDARD) + +1355 Privacy and Accuracy Issues in Network Information Center + Databases. J. Curran, A. Marine. August 1992. (Format: TXT=8858 + bytes) (Also FYI0015) (Status: INFORMATIONAL) + +1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode. + A. Malis, D. Robinson, R. Ullmann. August 1992. (Format: TXT=32043 + bytes) (Obsoletes RFC0877) (Status: DRAFT STANDARD) + +1357 A Format for E-mailing Bibliographic Records. D. Cohen. July + 1992. (Format: TXT=25021 bytes) (Obsoleted by RFC1807) (Status: + INFORMATIONAL) + +1358 Charter of the Internet Architecture Board (IAB). L. Chapin. + August 1992. (Format: TXT=11328 bytes) (Obsoleted by RFC1601) + (Status: INFORMATIONAL) + +1359 Connecting to the Internet - What Connecting Institutions Should + Anticipate. ACM SIGUCCS. August 1992. (Format: TXT=53449 bytes) (Also + FYI0016) (Status: INFORMATIONAL) + +1360 IAB Official Protocol Standards. J. Postel. September 1992. + (Format: TXT=71860 bytes) (Obsoletes RFC1280) (Obsoleted by RFC1410) + (Status: HISTORIC) + +1361 Simple Network Time Protocol (SNTP). D. Mills. August 1992. + (Format: TXT=23812 bytes) (Obsoleted by RFC1769) (Also RFC1305) + (Status: INFORMATIONAL) + +1362 Novell IPX over Various WAN Media (IPXWAN). M. Allen. September + 1992. (Format: TXT=30219 bytes) (Obsoleted by RFC1634) (Status: + INFORMATIONAL) + +1363 A Proposed Flow Specification. C. Partridge. September 1992. + (Format: TXT=59214 bytes) (Status: INFORMATIONAL) + +1364 BGP OSPF Interaction. K. Varadhan. September 1992. (Format: + TXT=32121 bytes) (Obsoleted by RFC1403) (Also RFC1247, RFC1267) + (Status: PROPOSED STANDARD) + +1365 An IP Address Extension Proposal. K. Siyan. September 1992. + (Format: TXT=12790 bytes) (Status: INFORMATIONAL) + +1366 Guidelines for Management of IP Address Space. E. Gerich. October + 1992. (Format: TXT=17793 bytes) (Obsoleted by RFC1466) (Status: + INFORMATIONAL) + +1367 Schedule for IP Address Space Management Guidelines. C. Topolcic. + October 1992. (Format: TXT=4780 bytes) (Obsoleted by RFC1467) + (Status: INFORMATIONAL) + +1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices. D. + McMaster, K. McCloghrie. October 1992. (Format: TXT=83905 bytes) + (Obsoleted by RFC1516) (Status: PROPOSED STANDARD) + +1369 Implementation Notes and Experience for the Internet Ethernet + MIB. F. Kastenholz. October 1992. (Format: TXT=13961 bytes) (Status: + INFORMATIONAL) + +1370 Applicability Statement for OSPF. Internet Architecture Board, L. + Chapin. October 1992. (Format: TXT=4303 bytes) (Status: PROPOSED + STANDARD) + +1371 Choosing a Common IGP for the IP Internet. P. Gross. October + 1992. (Format: TXT=18168 bytes) (Status: INFORMATIONAL) + +1372 Telnet Remote Flow Control Option. C. Hedrick, D. Borman. October + 1992. (Format: TXT=11098 bytes) (Obsoletes RFC1080) (Status: PROPOSED + STANDARD) + +1373 Portable DUAs. T. Tignor. October 1992. (Format: TXT=19931 bytes) + (Status: INFORMATIONAL) + +1374 IP and ARP on HIPPI. J. Renwick, A. Nicholson. October 1992. + (Format: TXT=100903 bytes) (Obsoleted by RFC2834) (Status: PROPOSED + STANDARD) + +1375 Suggestion for New Classes of IP Addresses. P. Robinson. October + 1992. (Format: TXT=16990 bytes) (Status: INFORMATIONAL) + +1376 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. + November 1992. (Format: TXT=12448 bytes) (Obsoleted by RFC1762) + (Status: PROPOSED STANDARD) + +1377 The PPP OSI Network Layer Control Protocol (OSINLCP). D. Katz. + November 1992. (Format: TXT=22109 bytes) (Status: PROPOSED STANDARD) + +1378 The PPP AppleTalk Control Protocol (ATCP). B. Parker. November + 1992. (Format: TXT=28496 bytes) (Status: PROPOSED STANDARD) + +1379 Extending TCP for Transactions -- Concepts. R. Braden. November + 1992. (Format: TXT=91353 bytes) (Updated by RFC1644) (Status: + INFORMATIONAL) + +1380 IESG Deliberations on Routing and Addressing. P. Gross, P. + Almquist. November 1992. (Format: TXT=49415 bytes) (Status: + INFORMATIONAL) + +1381 SNMP MIB Extension for X.25 LAPB. D. Throop, F. Baker. November + 1992. (Format: TXT=71253 bytes) (Status: PROPOSED STANDARD) + +1382 SNMP MIB Extension for the X.25 Packet Layer. D. Throop. November + 1992. (Format: TXT=153877 bytes) (Status: PROPOSED STANDARD) + +1383 An Experiment in DNS Based IP Routing. C. Huitema. December 1992. + (Format: TXT=32680 bytes) (Status: EXPERIMENTAL) + +1384 Naming Guidelines for Directory Pilots. P. Barker, S.E. + Hardcastle-Kille. January 1993. (Format: TXT=25870, PS=175044, + PDF=134487 bytes) (Obsoleted by RFC1617, RTR0011) (Status: + INFORMATIONAL) + +1385 EIP: The Extended Internet Protocol. Z. Wang. November 1992. + (Format: TXT=39123 bytes) (Status: INFORMATIONAL) + +1386 The US Domain. A. Cooper, J. Postel. December 1992. (Format: + TXT=62310 bytes) (Obsoleted by RFC1480) (Status: INFORMATIONAL) + +1387 RIP Version 2 Protocol Analysis. G. Malkin. January 1993. + (Format: TXT=5598 bytes) (Obsoleted by RFC1721) (Status: + INFORMATIONAL) + +1388 RIP Version 2 Carrying Additional Information. G. Malkin. January + 1993. (Format: TXT=16227 bytes) (Obsoleted by RFC1723) (Updates + RFC1058) (Status: PROPOSED STANDARD) + +1389 RIP Version 2 MIB Extensions. G. Malkin, F. Baker. January 1993. + (Format: TXT=23569 bytes) (Obsoleted by RFC1724) (Status: PROPOSED + STANDARD) + +1390 Transmission of IP and ARP over FDDI Networks. D. Katz. January + 1993. (Format: TXT=22077 bytes) (Also STD0036) (Status: STANDARD) + +1391 The Tao of the IETF: A Guide for New Attendees of the Internet + Engineering Task Force. G. Malkin. January 1993. (Format: TXT=41892 + bytes) (Obsoleted by RFC1539) (Status: INFORMATIONAL) + +1392 Internet Users' Glossary. G. Malkin, T. LaQuey Parker. January + 1993. (Format: TXT=104624 bytes) (Obsoleted by RFC1983) (Status: + INFORMATIONAL) + +1393 Traceroute Using an IP Option. G. Malkin. January 1993. (Format: + TXT=13140 bytes) (Status: EXPERIMENTAL) + +1394 Relationship of Telex Answerback Codes to Internet Domains. P. + Robinson. January 1993. (Format: TXT=43776 bytes) (Status: + INFORMATIONAL) + +1395 BOOTP Vendor Information Extensions. J. Reynolds. January 1993. + (Format: TXT=16314 bytes) (Obsoletes RFC1084, RFC1048) (Obsoleted by + RFC1497, RFC1533) (Updates RFC0951) (Status: DRAFT STANDARD) + +1396 The Process for Organization of Internet Standards Working Group + (POISED). S. Crocker. January 1993. (Format: TXT=22096 bytes) + (Status: INFORMATIONAL) + +1397 Default Route Advertisement In BGP2 and BGP3 Version of The + Border Gateway Protocol. D. Haskin. January 1993. (Format: TXT=4124 + bytes) (Status: PROPOSED STANDARD) + +1398 Definitions of Managed Objects for the Ethernet-Like Interface + Types. F. Kastenholz. January 1993. (Format: TXT=36684 bytes) + (Obsoletes RFC1284) (Obsoleted by RFC1623) (Status: DRAFT STANDARD) + +1399 Summary of 1300-1399. J. Elliott. January 1997. (Format: + TXT=43662 bytes) (Status: INFORMATIONAL) + +1400 Transition and Modernization of the Internet Registration + Service. S. Williamson. March 1993. (Format: TXT=13008 bytes) + (Status: INFORMATIONAL) + +1401 Correspondence between the IAB and DISA on the use of DNS. + Internet Architecture Board. January 1993. (Format: TXT=12528 bytes) + (Status: INFORMATIONAL) + +1402 There's Gold in them thar Networks! or Searching for Treasure in + all the Wrong Places. J. Martin. January 1993. (Format: TXT=71176 + bytes) (Obsoletes RFC1290) (Also FYI0010) (Status: INFORMATIONAL) + +1403 BGP OSPF Interaction. K. Varadhan. January 1993. (Format: + TXT=36173 bytes) (Obsoletes RFC1364) (Status: HISTORIC) + +1404 A Model for Common Operational Statistics. B. Stockman. January + 1993. (Format: TXT=52814 bytes) (Obsoleted by RFC1857) (Status: + INFORMATIONAL) + +1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail). C. + Allocchio. January 1993. (Format: TXT=33885 bytes) (Obsoleted by + RFC2162) (Status: EXPERIMENTAL) + +1406 Definitions of Managed Objects for the DS1 and E1 Interface + Types. F. Baker, J. Watt, Editors. January 1993. (Format: TXT=97559 + bytes) (Obsoletes RFC1232) (Obsoleted by RFC2495) (Status: PROPOSED + STANDARD) + +1407 Definitions of Managed Objects for the DS3/E3 Interface Type. T. + Cox, K. Tesink. January 1993. (Format: TXT=90682 bytes) (Obsoletes + RFC1233) (Obsoleted by RFC2496) (Status: PROPOSED STANDARD) + +1408 Telnet Environment Option. D. Borman, Editor. January 1993. + (Format: TXT=13936 bytes) (Updated by RFC1571) (Status: HISTORIC) + +1409 Telnet Authentication Option. D. Borman, Editor. January 1993. + (Format: TXT=13119 bytes) (Obsoleted by RFC1416) (Status: + EXPERIMENTAL) + +1410 IAB Official Protocol Standards. J. Postel, Editor. March 1993. + (Format: TXT=76524 bytes) (Obsoletes RFC1360) (Obsoleted by RFC1500) + (Status: HISTORIC) + +1411 Telnet Authentication: Kerberos Version 4. D. Borman, Editor. + January 1993. (Format: TXT=7967 bytes) (Status: EXPERIMENTAL) + +1412 Telnet Authentication: SPX. K. Alagappan. January 1993. (Format: + TXT=6952 bytes) (Status: EXPERIMENTAL) + +1413 Identification Protocol. M. St. Johns. February 1993. (Format: + TXT=16291 bytes) (Obsoletes RFC0931) (Status: PROPOSED STANDARD) + +1414 Identification MIB. M. St. Johns, M. Rose. February 1993. + (Format: TXT=14165 bytes) (Status: PROPOSED STANDARD) + +1415 FTP-FTAM Gateway Specification. J. Mindel, R. Slaski. January + 1993. (Format: TXT=128261 bytes) (Status: PROPOSED STANDARD) + +1416 Telnet Authentication Option. D. Borman, Editor. February 1993. + (Format: TXT=13270 bytes) (Obsoletes RFC1409) (Obsoleted by RFC2941) + (Status: EXPERIMENTAL) + +1417 NADF Standing Documents: A Brief Overview. The North American + Directory Forum. February 1993. (Format: TXT=7270 bytes) (Obsoletes + RFC1295, RFC1255, RFC1218) (Obsoleted by RFC1758) (Status: + INFORMATIONAL) + +1418 SNMP over OSI. M. Rose. March 1993. (Format: TXT=7721 bytes) + (Obsoletes RFC1161, RFC1283) (Status: PROPOSED STANDARD) + +1419 SNMP over AppleTalk. G. Minshall, M. Ritter. March 1993. (Format: + TXT=16470 bytes) (Status: PROPOSED STANDARD) + +1420 SNMP over IPX. S. Bostock. March 1993. (Format: TXT=6762 bytes) + (Obsoletes RFC1298) (Status: PROPOSED STANDARD) + +1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message + Encryption and Authentication Procedures. J. Linn. February 1993. + (Format: TXT=103894 bytes) (Obsoletes RFC1113) (Status: PROPOSED + STANDARD) + +1422 Privacy Enhancement for Internet Electronic Mail: Part II: + Certificate-Based Key Management. S. Kent. February 1993. (Format: + TXT=86085 bytes) (Obsoletes RFC1114) (Status: PROPOSED STANDARD) + +1423 Privacy Enhancement for Internet Electronic Mail: Part III: + Algorithms, Modes, and Identifiers. D. Balenson. February 1993. + (Format: TXT=33277 bytes) (Obsoletes RFC1115) (Status: PROPOSED + STANDARD) + +1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key + Certification and Related Services. B. Kaliski. February 1993. + (Format: TXT=17537 bytes) (Status: PROPOSED STANDARD) + +1425 SMTP Service Extensions. J. Klensin, WG Chair, N. Freed, Editor, + M. Rose, E. Stefferud, D. Crocker. February 1993. (Format: TXT=20932 + bytes) (Obsoleted by RFC1651) (Status: PROPOSED STANDARD) + +1426 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, WG + Chair, N. Freed, Editor, M. Rose, E. Stefferud, D. Crocker. February + 1993. (Format: TXT=11661 bytes) (Obsoleted by RFC1652) (Status: + PROPOSED STANDARD) + +1427 SMTP Service Extension for Message Size Declaration. J. Klensin, + WG Chair, N. Freed, Editor, K. Moore. February 1993. (Format: + TXT=17856 bytes) (Obsoleted by RFC1653) (Status: PROPOSED STANDARD) + +1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. + G. Vaudreuil. February 1993. (Format: TXT=12064 bytes) (Status: + INFORMATIONAL) + +1429 Listserv Distribute Protocol. E. Thomas. February 1993. (Format: + TXT=17759 bytes) (Status: INFORMATIONAL) + +1430 A Strategic Plan for Deploying an Internet X.500 Directory + Service. S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent. + February 1993. (Format: TXT=47587 bytes) (Status: INFORMATIONAL) + +1431 DUA Metrics (OSI-DS 33 (v2)). P. Barker. February 1993. (Format: + TXT=42240 bytes) (Status: INFORMATIONAL) + +1432 Recent Internet Books. J. Quarterman. March 1993. (Format: + TXT=27089 bytes) (Status: INFORMATIONAL) + +1433 Directed ARP. J. Garrett, J. Hagan, J. Wong. March 1993. (Format: + TXT=41028 bytes) (Status: EXPERIMENTAL) + +1434 Data Link Switching: Switch-to-Switch Protocol. R. Dixon, D. + Kushi. March 1993. (Format: TXT=80182, PS=292006, PDF=181839 bytes) + (Obsoleted by RFC1795) (Status: INFORMATIONAL) + +1435 IESG Advice from Experience with Path MTU Discovery. S. Knowles. + March 1993. (Format: TXT=2708 bytes) (Status: INFORMATIONAL) + +1436 The Internet Gopher Protocol (a distributed document search and + retrieval protocol). F. Anklesaria, M. McCahill, P. Lindner, D. + Johnson, D. Torrey, B. Albert. March 1993. (Format: TXT=36493 bytes) + (Status: INFORMATIONAL) + +1437 The Extension of MIME Content-Types to a New Medium. N. + Borenstein, M. Linimon. Apr-01-1993. (Format: TXT=13356 bytes) + (Status: INFORMATIONAL) + +1438 Internet Engineering Task Force Statements Of Boredom (SOBs). A. + Lyman Chapin, C. Huitema. Apr-01-1993. (Format: TXT=3044 bytes) + (Status: INFORMATIONAL) + +1439 The Uniqueness of Unique Identifiers. C. Finseth. March 1993. + (Format: TXT=20477 bytes) (Status: INFORMATIONAL) + +1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer. R. Troth. + July 1993. (Format: TXT=17366 bytes) (Status: EXPERIMENTAL) + +1441 Introduction to version 2 of the Internet-standard Network + Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. + April 1993. (Format: TXT=25386 bytes) (Status: PROPOSED STANDARD) + +1442 Structure of Management Information for version 2 of the Simple + Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. + Rose, S. Waldbusser. April 1993. (Format: TXT=95779 bytes) (Obsoleted + by RFC1902) (Status: PROPOSED STANDARD) + +1443 Textual Conventions for version 2 of the Simple Network + Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. + Waldbusser. April 1993. (Format: TXT=60947 bytes) (Obsoleted by + RFC1903) (Status: PROPOSED STANDARD) + +1444 Conformance Statements for version 2 of the Simple Network + Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. + Waldbusser. April 1993. (Format: TXT=57744 bytes) (Obsoleted by + RFC1904) (Status: PROPOSED STANDARD) + +1445 Administrative Model for version 2 of the Simple Network + Management Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993. + (Format: TXT=99443 bytes) (Status: HISTORIC) + +1446 Security Protocols for version 2 of the Simple Network Management + Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993. (Format: + TXT=108733 bytes) (Status: HISTORIC) + +1447 Party MIB for version 2 of the Simple Network Management Protocol + (SNMPv2). K. McCloghrie, J. Galvin. April 1993. (Format: TXT=80762 + bytes) (Status: HISTORIC) + +1448 Protocol Operations for version 2 of the Simple Network + Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. + Waldbusser. April 1993. (Format: TXT=74224 bytes) (Obsoleted by + RFC1905) (Status: PROPOSED STANDARD) + +1449 Transport Mappings for version 2 of the Simple Network Management + Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. + April 1993. (Format: TXT=41161 bytes) (Obsoleted by RFC1906) (Status: + PROPOSED STANDARD) + +1450 Management Information Base for version 2 of the Simple Network + Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. + Waldbusser. April 1993. (Format: TXT=42172 bytes) (Obsoleted by + RFC1907) (Status: PROPOSED STANDARD) + +1451 Manager-to-Manager Management Information Base. J. Case, K. + McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=62935 + bytes) (Status: HISTORIC) + +1452 Coexistence between version 1 and version 2 of the + Internet-standard Network Management Framework. J. Case, K. + McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT=32176 + bytes) (Obsoleted by RFC1908) (Status: PROPOSED STANDARD) + +1453 A Comment on Packet Video Remote Conferencing and the + Transport/Network Layers. W. Chimiak. April 1993. (Format: TXT=23563 + bytes) (Status: INFORMATIONAL) + +1454 Comparison of Proposals for Next Version of IP. T. Dixon. May + 1993. (Format: TXT=35064 bytes) (Status: INFORMATIONAL) + +1455 Physical Link Security Type of Service. D. Eastlake. May 1993. + (Format: TXT=12391 bytes) (Obsoleted by RFC2474) (Status: + EXPERIMENTAL) + +1456 Conventions for Encoding the Vietnamese Language VISCII: + VIetnamese Standard Code for Information Interchange VIQR: VIetnamese + Quoted-Readable Specification. Vietnamese Standardization Working + Group. May 1993. (Format: TXT=14775 bytes) (Status: INFORMATIONAL) + +1457 Security Label Framework for the Internet. R. Housley. May 1993. + (Format: TXT=35802 bytes) (Status: INFORMATIONAL) + +1458 Requirements for Multicast Protocols. R. Braudes, S. Zabele. May + 1993. (Format: TXT=48106 bytes) (Status: INFORMATIONAL) + +1459 Internet Relay Chat Protocol. J. Oikarinen, D. Reed. May 1993. + (Format: TXT=138964 bytes) (Updated by RFC2810, RFC2811, RFC2812, + RFC2813) (Status: EXPERIMENTAL) + +1460 Post Office Protocol - Version 3. M. Rose. June 1993. (Format: + TXT=38827 bytes) (Obsoletes RFC1225) (Obsoleted by RFC1725) (Status: + DRAFT STANDARD) + +1461 SNMP MIB extension for Multiprotocol Interconnect over X.25. D. + Throop. May 1993. (Format: TXT=47945 bytes) (Status: PROPOSED + STANDARD) + +1462 FYI on "What is the Internet?". E. Krol, E. Hoffman. May 1993. + (Format: TXT=27811 bytes) (Also FYI0020) (Status: INFORMATIONAL) + +1463 FYI on Introducing the Internet-- A Short Bibliography of + Introductory Internetworking Readings. E. Hoffman, L. Jackson. May + 1993. (Format: TXT=7116 bytes) (Also FYI0019) (Status: INFORMATIONAL) + +1464 Using the Domain Name System To Store Arbitrary String + Attributes. R. Rosenbaum. May 1993. (Format: TXT=7953 bytes) (Status: + EXPERIMENTAL) + +1465 Routing Coordination for X.400 MHS Services Within a Multi + Protocol / Multi Network Environment Table Format V3 for Static + Routing. D. Eppenberger. May 1993. (Format: TXT=66833 bytes) (Status: + EXPERIMENTAL) + +1466 Guidelines for Management of IP Address Space. E. Gerich. May + 1993. (Format: TXT=22262 bytes) (Obsoletes RFC1366) (Obsoleted by + RFC2050) (Status: INFORMATIONAL) + +1467 Status of CIDR Deployment in the Internet. C. Topolcic. August + 1993. (Format: TXT=20720 bytes) (Obsoletes RFC1367) (Status: + INFORMATIONAL) + +1468 Japanese Character Encoding for Internet Messages. J. Murai, M. + Crispin, E. van der Poel. June 1993. (Format: TXT=10970 bytes) + (Status: INFORMATIONAL) + +1469 IP Multicast over Token-Ring Local Area Networks. T. Pusateri. + June 1993. (Format: TXT=8189 bytes) (Status: PROPOSED STANDARD) + +1470 FYI on a Network Management Tool Catalog: Tools for Monitoring + and Debugging TCP/IP Internets and Interconnected Devices. R. Enger, + J. Reynolds. June 1993. (Format: TXT=308528 bytes) (Obsoletes + RFC1147) (Also FYI0002) (Status: INFORMATIONAL) + +1471 The Definitions of Managed Objects for the Link Control Protocol + of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: + TXT=53558 bytes) (Status: PROPOSED STANDARD) + +1472 The Definitions of Managed Objects for the Security Protocols of + the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: + TXT=27152 bytes) (Status: PROPOSED STANDARD) + +1473 The Definitions of Managed Objects for the IP Network Control + Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. + (Format: TXT=20484 bytes) (Status: PROPOSED STANDARD) + +1474 The Definitions of Managed Objects for the Bridge Network Control + Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. + (Format: TXT=31846 bytes) (Status: PROPOSED STANDARD) + +1475 TP/IX: The Next Internet. R. Ullmann. June 1993. (Format: + TXT=77854 bytes) (Status: EXPERIMENTAL) + +1476 RAP: Internet Route Access Protocol. R. Ullmann. June 1993. + (Format: TXT=45560 bytes) (Status: EXPERIMENTAL) + +1477 IDPR as a Proposed Standard. M. Steenstrup. July 1993. (Format: + TXT=32238 bytes) (Status: INFORMATIONAL) + +1478 An Architecture for Inter-Domain Policy Routing. M. Steenstrup. + June 1993. (Format: TXT=90673 bytes) (Status: PROPOSED STANDARD) + +1479 Inter-Domain Policy Routing Protocol Specification: Version 1. M. + Steenstrup. July 1993. (Format: TXT=275823 bytes) (Status: PROPOSED + STANDARD) + +1480 The US Domain. A. Cooper, J. Postel. June 1993. (Format: + TXT=100556 bytes) (Obsoletes RFC1386) (Status: INFORMATIONAL) + +1481 IAB Recommendation for an Intermediate Strategy to Address the + Issue of Scaling. C. Huitema. July 1993. (Format: TXT=3502 bytes) + (Status: INFORMATIONAL) + +1482 Aggregation Support in the NSFNET Policy-Based Routing Database. + M. Knopper, S. Richardson. June 1993. (Format: TXT=25330 bytes) + (Status: INFORMATIONAL) + +1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5. Juha + Heinanen. July 1993. (Format: TXT=35192 bytes) (Obsoleted by RFC2684) + (Status: PROPOSED STANDARD) + +1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS + 24 (v1.2)). S. Hardcastle-Kille. July 1993. (Format: TXT=48974 bytes) + (Obsoleted by RFC1781) (Status: EXPERIMENTAL) + +1485 A String Representation of Distinguished Names (OSI-DS 23 (v5)). + S. Hardcastle-Kille. July 1993. (Format: TXT=11158 bytes) (Obsoleted + by RFC1779) (Status: PROPOSED STANDARD) + +1486 An Experiment in Remote Printing. M. Rose, C. Malamud. July 1993. + (Format: TXT=26373 bytes) (Obsoleted by RFC1528, RFC1529) (Status: + EXPERIMENTAL) + +1487 X.500 Lightweight Directory Access Protocol. W. Yeong, T. Howes, + S. Kille. July 1993. (Format: TXT=44947 bytes) (Obsoleted by RFC1777) + (Status: PROPOSED STANDARD) + +1488 The X.500 String Representation of Standard Attribute Syntaxes. + T. Howes, S. Kille, W. Yeong, C. Robbins. July 1993. (Format: + TXT=17182 bytes) (Obsoleted by RFC1778) (Status: PROPOSED STANDARD) + +1489 Registration of a Cyrillic Character Set. A. Chernov. July 1993. + (Format: TXT=7798 bytes) (Status: INFORMATIONAL) + +1490 Multiprotocol Interconnect over Frame Relay. T. Bradley, C. + Brown, A. Malis. July 1993. (Format: TXT=75206 bytes) (Obsoletes + RFC1294) (Obsoleted by RFC2427) (Status: DRAFT STANDARD) + +1491 A Survey of Advanced Usages of X.500. C. Weider, R. Wright. July + 1993. (Format: TXT=34883 bytes) (Also FYI0021) (Status: + INFORMATIONAL) + +1492 An Access Control Protocol, Sometimes Called TACACS. C. Finseth. + July 1993. (Format: TXT=41880 bytes) (Status: INFORMATIONAL) + +1493 Definitions of Managed Objects for Bridges. E. Decker, P. + Langille, A. Rijsinghani, K. McCloghrie. July 1993. (Format: + TXT=74493 bytes) (Obsoletes RFC1286) (Status: DRAFT STANDARD) + +1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies. H. + Alvestrand, S. Thompson. August 1993. (Format: TXT=37273 bytes) + (Status: PROPOSED STANDARD) + +1495 Mapping between X.400 and RFC-822 Message Bodies. H. Alvestrand, + S. Kille, R. Miles, M. Rose, S. Thompson. August 1993. (Format: + TXT=20071 bytes) (Obsoleted by RFC2156) (Updates RFC1327) (Status: + PROPOSED STANDARD) + +1496 Rules for downgrading messages from X.400/88 to X.400/84 when + MIME content-types are present in the messages. H. Alvestrand, J. + Romaguera, K. Jordan. August 1993. (Format: TXT=8411 bytes) (Status: + PROPOSED STANDARD) + +1497 BOOTP Vendor Information Extensions. J. Reynolds. August 1993. + (Format: TXT=16805 bytes) (Obsoletes RFC1395, RFC1084, RFC1048) + (Obsoleted by RFC1533) (Updates RFC0951) (Status: DRAFT STANDARD) + +1498 On the Naming and Binding of Network Destinations. J. Saltzer. + August 1993. (Format: TXT=24698 bytes) (Status: INFORMATIONAL) + +1499 Summary of 1400-1499. J. Elliott. January 1997. (Format: + TXT=40923 bytes) (Status: INFORMATIONAL) + +1500 Internet Official Protocol Standards. J. Postel. August 1993. + (Format: TXT=79557 bytes) (Obsoletes RFC1410) (Obsoleted by RFC1540) + (Status: HISTORIC) + +1501 OS/2 User Group. E. Brunsen. August 1993. (Format: TXT=3636 + bytes) (Status: INFORMATIONAL) + +1502 X.400 Use of Extended Character Sets. H. Alvestrand. August 1993. + (Format: TXT=27976 bytes) (Status: PROPOSED STANDARD) + +1503 Algorithms for Automating Administration in SNMPv2 Managers. K. + McCloghrie, M. Rose. August 1993. (Format: TXT=33542 bytes) (Status: + INFORMATIONAL) + +1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk + Routing. A. Oppenheimer. August 1993. (Format: TXT=201553 bytes) + (Status: INFORMATIONAL) + +1505 Encoding Header Field for Internet Messages. A. Costanzo, D. + Robinson, R. Ullmann. August 1993. (Format: TXT=63796 bytes) + (Obsoletes RFC1154) (Status: EXPERIMENTAL) + +1506 A Tutorial on Gatewaying between X.400 and Internet Mail. J. + Houttuin. August 1993. (Format: TXT=85550 bytes) (Status: + INFORMATIONAL) + +1507 DASS - Distributed Authentication Security Service. C. Kaufman. + September 1993. (Format: TXT=287809 bytes) (Status: EXPERIMENTAL) + +1508 Generic Security Service Application Program Interface. J. Linn. + September 1993. (Format: TXT=111228 bytes) (Obsoleted by RFC2078) + (Status: PROPOSED STANDARD) + +1509 Generic Security Service API : C-bindings. J. Wray. September + 1993. (Format: TXT=99608 bytes) (Obsoleted by RFC2744) (Status: + PROPOSED STANDARD) + +1510 The Kerberos Network Authentication Service (V5). J. Kohl, C. + Neuman. September 1993. (Format: TXT=275395 bytes) (Status: PROPOSED + STANDARD) + +1511 Common Authentication Technology Overview. J. Linn. September + 1993. (Format: TXT=4185 bytes) (Status: INFORMATIONAL) + +1512 FDDI Management Information Base. J. Case, A. Rijsinghani. + September 1993. (Format: TXT=108589 bytes) (Updates RFC1285) (Status: + PROPOSED STANDARD) + +1513 Token Ring Extensions to the Remote Network Monitoring MIB. S. + Waldbusser. September 1993. (Format: TXT=121974 bytes) (Updates + RFC1271) (Status: PROPOSED STANDARD) + +1514 Host Resources MIB. P. Grillo, S. Waldbusser. September 1993. + (Format: TXT=63775 bytes) (Obsoleted by RFC2790) (Status: PROPOSED + STANDARD) + +1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment + Units (MAUs). D. McMaster, K. McCloghrie, S. Roberts. September 1993. + (Format: TXT=52828 bytes) (Status: PROPOSED STANDARD) + +1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices. + D. McMaster, K. McCloghrie. September 1993. (Format: TXT=82918 bytes) + (Obsoletes RFC1368) (Obsoleted by RFC2108) (Status: DRAFT STANDARD) + +1517 Applicability Statement for the Implementation of Classless + Inter-Domain Routing (CIDR). Internet Engineering Steering Group, R. + Hinden. September 1993. (Format: TXT=7357 bytes) (Status: PROPOSED + STANDARD) + +1518 An Architecture for IP Address Allocation with CIDR. Y. Rekhter, + T. Li. September 1993. (Format: TXT=72609 bytes) (Status: PROPOSED + STANDARD) + +1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and + Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September + 1993. (Format: TXT=59998 bytes) (Obsoletes RFC1338) (Status: PROPOSED + STANDARD) + +1520 Exchanging Routing Information Across Provider Boundaries in the + CIDR Environment. Y. Rekhter, C. Topolcic. September 1993. (Format: + TXT=20389 bytes) (Status: INFORMATIONAL) + +1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms + for Specifying and Describing the Format of Internet Message Bodies. + N. Borenstein, N. Freed. September 1993. (Format: TXT=187424, + PS=393670, PDF=205091 bytes) (Obsoletes RFC1341) (Obsoleted by + RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Updated by RFC1590) + (Status: DRAFT STANDARD) + +1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message + Header Extensions for Non-ASCII Text. K. Moore. September 1993. + (Format: TXT=22502 bytes) (Obsoletes RFC1342) (Obsoleted by RFC2045, + RFC2046, RFC2047, RFC2048, RFC2049) (Status: DRAFT STANDARD) + +1523 The text/enriched MIME Content-type. N. Borenstein. September + 1993. (Format: TXT=32691 bytes) (Obsoleted by RFC1563, RFC1896) + (Status: INFORMATIONAL) + +1524 A User Agent Configuration Mechanism For Multimedia Mail Format + Information. N. Borenstein. September 1993. (Format: TXT=26464 bytes) + (Status: INFORMATIONAL) + +1525 Definitions of Managed Objects for Source Routing Bridges. E. + Decker, K. McCloghrie, P. Langille, A. Rijsinghani. September 1993. + (Format: TXT=38100 bytes) (Obsoletes RFC1286) (Status: PROPOSED + STANDARD) + +1526 Assignment of System Identifiers for TUBA/CLNP Hosts. D. + Piscitello. September 1993. (Format: TXT=16848 bytes) (Status: + INFORMATIONAL) + +1527 What Should We Plan Given the Dilemma of the Network?. G. Cook. + September 1993. (Format: TXT=46935 bytes) (Status: INFORMATIONAL) + +1528 Principles of Operation for the TPC.INT Subdomain: Remote + Printing -- Technical Procedures. C. Malamud, M. Rose. October 1993. + (Format: TXT=18576 bytes) (Obsoletes RFC1486) (Status: EXPERIMENTAL) + +1529 Principles of Operation for the TPC.INT Subdomain: Remote + Printing -- Administrative Policies. C. Malamud, M. Rose. October + 1993. (Format: TXT=11142 bytes) (Obsoletes RFC1486) (Status: + INFORMATIONAL) + +1530 Principles of Operation for the TPC.INT Subdomain: General + Principles and Policy. C. Malamud, M. Rose. October 1993. (Format: + TXT=15031 bytes) (Status: INFORMATIONAL) + +1531 Dynamic Host Configuration Protocol. R. Droms. October 1993. + (Format: TXT=96192 bytes) (Obsoleted by RFC1541) (Status: PROPOSED + STANDARD) + +1532 Clarifications and Extensions for the Bootstrap Protocol. W. + Wimer. October 1993. (Format: TXT=51545 bytes) (Obsoleted by RFC1542) + (Updates RFC0951) (Status: PROPOSED STANDARD) + +1533 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms. + October 1993. (Format: TXT=50919 bytes) (Obsoletes RFC1497, RFC1395, + RFC1084, RFC1048) (Obsoleted by RFC2132) (Status: PROPOSED STANDARD) + +1534 Interoperation Between DHCP and BOOTP. R. Droms. October 1993. + (Format: TXT=6966 bytes) (Status: DRAFT STANDARD) + +1535 A Security Problem and Proposed Correction With Widely Deployed + DNS Software. E. Gavron. October 1993. (Format: TXT=9722 bytes) + (Status: INFORMATIONAL) + +1536 Common DNS Implementation Errors and Suggested Fixes. A. Kumar, + J. Postel, C. Neuman, P. Danzig, S. Miller. October 1993. (Format: + TXT=25476 bytes) (Status: INFORMATIONAL) + +1537 Common DNS Data File Configuration Errors. P. Beertema. October + 1993. (Format: TXT=19825 bytes) (Obsoleted by RFC1912) (Status: + INFORMATIONAL) + +1538 Advanced SNA/IP : A Simple SNA Transport Protocol. W. Behl, B. + Sterling, W. Teskey. October 1993. (Format: TXT=21217 bytes) (Status: + INFORMATIONAL) + +1539 The Tao of IETF - A Guide for New Attendees of the Internet + Engineering Task Force. G. Malkin. October 1993. (Format: TXT=48199 + bytes) (Obsoletes RFC1391) (Obsoleted by RFC1718) (Status: + INFORMATIONAL) + +1540 Internet Official Protocol Standards. J. Postel. October 1993. + (Format: TXT=75496 bytes) (Obsoletes RFC1500) (Obsoleted by RFC1600) + (Status: HISTORIC) + +1541 Dynamic Host Configuration Protocol. R. Droms. October 1993. + (Format: TXT=96950 bytes) (Obsoletes RFC1531) (Obsoleted by RFC2131) + (Status: PROPOSED STANDARD) + +1542 Clarifications and Extensions for the Bootstrap Protocol. W. + Wimer. October 1993. (Format: TXT=52948 bytes) (Obsoletes RFC1532) + (Updates RFC0951) (Status: DRAFT STANDARD) + +1543 Instructions to RFC Authors. J. Postel. October 1993. (Format: + TXT=31383 bytes) (Obsoletes RFC1111, RFC0825) (Obsoleted by RFC2223) + (Status: INFORMATIONAL) + +1544 The Content-MD5 Header Field. M. Rose. November 1993. (Format: + TXT=6478 bytes) (Obsoleted by RFC1864) (Status: PROPOSED STANDARD) + +1545 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. + November 1993. (Format: TXT=8985 bytes) (Obsoleted by RFC1639) + (Status: EXPERIMENTAL) + +1546 Host Anycasting Service. C. Partridge, T. Mendez, W. Milliken. + November 1993. (Format: TXT=22263 bytes) (Status: INFORMATIONAL) + +1547 Requirements for an Internet Standard Point-to-Point Protocol. D. + Perkins. December 1993. (Format: TXT=49810 bytes) (Status: + INFORMATIONAL) + +1548 The Point-to-Point Protocol (PPP). W. Simpson. December 1993. + (Format: TXT=111638 bytes) (Obsoletes RFC1331) (Obsoleted by RFC1661) + (Updated by RFC1570) (Status: DRAFT STANDARD) + +1549 PPP in HDLC Framing. W. Simpson. December 1993. (Format: + TXT=36352 bytes) (Obsoleted by RFC1662) (Status: DRAFT STANDARD) + +1550 IP: Next Generation (IPng) White Paper Solicitation. S. Bradner, + A. Mankin. December 1993. (Format: TXT=12472 bytes) (Status: + INFORMATIONAL) + +1551 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. December + 1993. (Format: TXT=54210 bytes) (Obsoleted by RFC1634) (Status: + INFORMATIONAL) + +1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP). + W. Simpson. December 1993. (Format: TXT=29173 bytes) (Status: + PROPOSED STANDARD) + +1553 Compressing IPX Headers Over WAN Media (CIPX). S. Mathur, M. + Lewis. December 1993. (Format: TXT=47450 bytes) (Status: PROPOSED + STANDARD) + +1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP. M. Ohta, K. + Handa. December 1993. (Format: TXT=11449 bytes) (Status: + INFORMATIONAL) + +1555 Hebrew Character Encoding for Internet Messages. H. Nussbacher, + Y. Bourvine. December 1993. (Format: TXT=9273 bytes) (Status: + INFORMATIONAL) + +1556 Handling of Bi-directional Texts in MIME. H. Nussbacher. December + 1993. (Format: TXT=5602 bytes) (Status: INFORMATIONAL) + +1557 Korean Character Encoding for Internet Messages. U. Choi, K. + Chon, H. Park. December 1993. (Format: TXT=8736 bytes) (Status: + INFORMATIONAL) + +1558 A String Representation of LDAP Search Filters. T. Howes. + December 1993. (Format: TXT=5239 bytes) (Obsoleted by RFC1960) + (Status: INFORMATIONAL) + +1559 DECnet Phase IV MIB Extensions. J. Saperia. December 1993. + (Format: TXT=125427 bytes) (Obsoletes RFC1289) (Status: DRAFT + STANDARD) + +1560 The MultiProtocol Internet. B. Leiner, Y. Rekhter. December 1993. + (Format: TXT=16651 bytes) (Status: INFORMATIONAL) + +1561 Use of ISO CLNP in TUBA Environments. D. Piscitello. December + 1993. (Format: TXT=55902 bytes) (Status: EXPERIMENTAL) + +1562 Naming Guidelines for the AARNet X.500 Directory Service. G. + Michaelson, M. Prior. December 1993. (Format: TXT=6884 bytes) + (Status: INFORMATIONAL) + +1563 The text/enriched MIME Content-type. N. Borenstein. January 1994. + (Format: TXT=32913, PS=73543, PDF=37459 bytes) (Obsoletes RFC1523) + (Obsoleted by RFC1896) (Status: INFORMATIONAL) + +1564 DSA Metrics (OSI-DS 34 (v3)). P. Barker, R. Hedberg. January + 1994. (Format: TXT=46205 bytes) (Status: INFORMATIONAL) + +1565 Network Services Monitoring MIB. S. Kille, N. Freed. January + 1994. (Format: TXT=29761 bytes) (Obsoleted by RFC2248) (Status: + PROPOSED STANDARD) + +1566 Mail Monitoring MIB. S. Kille, N. Freed. January 1994. (Format: + TXT=33136 bytes) (Obsoleted by RFC2249, RFC2789) (Status: PROPOSED + STANDARD) + +1567 X.500 Directory Monitoring MIB. G. Mansfield, S. Kille. January + 1994. (Format: TXT=33527 bytes) (Obsoleted by RFC2605) (Status: + PROPOSED STANDARD) + +1568 Simple Network Paging Protocol - Version 1(b). A. Gwinn. January + 1994. (Format: TXT=16558 bytes) (Obsoleted by RFC1645) (Status: + INFORMATIONAL) + +1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging + -- Technical Procedures. M. Rose. January 1994. (Format: TXT=12597 + bytes) (Obsoleted by RFC1703) (Status: INFORMATIONAL) + +1570 PPP LCP Extensions. W. Simpson. January 1994. (Format: TXT=35719 + bytes) (Updates RFC1548) (Updated by RFC2484) (Status: PROPOSED + STANDARD) + +1571 Telnet Environment Option Interoperability Issues. D. Borman. + January 1994. (Format: TXT=8117 bytes) (Updates RFC1408) (Status: + INFORMATIONAL) + +1572 Telnet Environment Option. S. Alexander. January 1994. (Format: + TXT=14676 bytes) (Status: PROPOSED STANDARD) + +1573 Evolution of the Interfaces Group of MIB-II. K. McCloghrie, F. + Kastenholz. January 1994. (Format: TXT=123057 bytes) (Obsoletes + RFC1229) (Obsoleted by RFC2233) (Status: PROPOSED STANDARD) + +1574 Essential Tools for the OSI Internet. S. Hares, C. Wittbrodt. + February 1994. (Format: TXT=27735 bytes) (Obsoletes RFC1139) (Status: + INFORMATIONAL) + +1575 An Echo Function for CLNP (ISO 8473). S. Hares, C. Wittbrodt. + February 1994. (Format: TXT=22479 bytes) (Obsoletes RFC1139) (Status: + DRAFT STANDARD) + +1576 TN3270 Current Practices. J. Penner. January 1994. (Format: + TXT=24477 bytes) (Status: INFORMATIONAL) + +1577 Classical IP and ARP over ATM. M. Laubach. January 1994. (Format: + TXT=41239 bytes) (Obsoleted by RFC2225) (Status: PROPOSED STANDARD) + +1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary + and Secondary School Internet User" Questions. J. Sellers. February + 1994. (Format: TXT=113646 bytes) (Obsoleted by RFC1941) (Status: + INFORMATIONAL) + +1579 Firewall-Friendly FTP. S. Bellovin. February 1994. (Format: + TXT=8806 bytes) (Status: INFORMATIONAL) + +1580 Guide to Network Resource Tools. EARN Staff. March 1994. (Format: + TXT=235112 bytes) (Also FYI0023) (Status: INFORMATIONAL) + +1581 Protocol Analysis for Extensions to RIP to Support Demand + Circuits. G. Meyer. February 1994. (Format: TXT=7536 bytes) (Status: + INFORMATIONAL) + +1582 Extensions to RIP to Support Demand Circuits. G. Meyer. February + 1994. (Format: TXT=63271 bytes) (Status: PROPOSED STANDARD) + +1583 OSPF Version 2. J. Moy. March 1994. (Format: TXT=532636, + PS=990794, PDF=465711 bytes) (Obsoletes RFC1247) (Obsoleted by + RFC2178) (Status: DRAFT STANDARD) + +1584 Multicast Extensions to OSPF. J. Moy. March 1994. (Format: + TXT=262463, PS=426358, PDF=243185 bytes) (Status: PROPOSED STANDARD) + +1585 MOSPF: Analysis and Experience. J. Moy. March 1994. (Format: + TXT=29754 bytes) (Status: INFORMATIONAL) + +1586 Guidelines for Running OSPF Over Frame Relay Networks. O. + deSouza, M. Rodrigues. March 1994. (Format: TXT=14968 bytes) (Status: + INFORMATIONAL) + +1587 The OSPF NSSA Option. R. Coltun, V. Fuller. March 1994. (Format: + TXT=37412 bytes) (Status: PROPOSED STANDARD) + +1588 White Pages Meeting Report. J. Postel, C. Anderson. February + 1994. (Format: TXT=77945 bytes) (Status: INFORMATIONAL) + +1589 A Kernel Model for Precision Timekeeping. D. Mills. March 1994. + (Format: TXT=88129 bytes) (Status: INFORMATIONAL) + +1590 Media Type Registration Procedure. J. Postel. March 1994. + (Format: TXT=13044 bytes) (Obsoleted by RFC2045, RFC2046, RFC2047, + RFC2048, RFC2049) (Updates RFC1521) (Status: INFORMATIONAL) + +1591 Domain Name System Structure and Delegation. J. Postel. March + 1994. (Format: TXT=16481 bytes) (Status: INFORMATIONAL) + +1592 Simple Network Management Protocol Distributed Protocol Interface + Version 2.0. B. Wijnen, G. Carpenter, K. Curran, A. Sehgal, G. + Waters. March 1994. (Format: TXT=135259 bytes) (Obsoletes RFC1228) + (Status: EXPERIMENTAL) + +1593 SNA APPN Node MIB. W. McKenzie, J. Cheng. March 1994. (Format: + TXT=207882 bytes) (Status: INFORMATIONAL) + +1594 FYI on Questions and Answers - Answers to Commonly asked "New + Internet User" Questions. A. Marine, J. Reynolds, G. Malkin. March + 1994. (Format: TXT=98753 bytes) (Obsoletes RFC1325) (Obsoleted by + RFC2664) (Status: INFORMATIONAL) + +1595 Definitions of Managed Objects for the SONET/SDH Interface Type. + T. Brown, K. Tesink. March 1994. (Format: TXT=121937 bytes) + (Obsoleted by RFC2558) (Status: PROPOSED STANDARD) + +1596 Definitions of Managed Objects for Frame Relay Service. T. Brown, + Editor. March 1994. (Format: TXT=88795 bytes) (Obsoleted by RFC1604) + (Status: PROPOSED STANDARD) + +1597 Address Allocation for Private Internets. Y. Rekhter, B. + Moskowitz, D. Karrenberg, G. de Groot. March 1994. (Format: TXT=17430 + bytes) (Obsoleted by RFC1918) (Status: INFORMATIONAL) + +1598 PPP in X.25. W. Simpson. March 1994. (Format: TXT=13835 bytes) + (Status: PROPOSED STANDARD) + +1599 Summary of 1500-1599. M. Kennedy. January 1997. (Format: + TXT=43761 bytes) (Status: INFORMATIONAL) + +1600 Internet Official Protocol Standards. J. Postel. March 1994. + (Format: TXT=80958 bytes) (Obsoletes RFC1540) (Obsoleted by RFC1610) + (Status: HISTORIC) + +1601 Charter of the Internet Architecture Board (IAB). C. Huitema. + March 1994. (Format: TXT=12424 bytes) (Obsoletes RFC1358) (Obsoleted + by RFC2850) (Status: INFORMATIONAL) + +1602 The Internet Standards Process -- Revision 2. Internet + Architecture Board and Internet Engineering Steering Group. March + 1994. (Format: TXT=88465 bytes) (Obsoletes RFC1310) (Obsoleted by + RFC2026) (Updated by RFC1871) (Status: INFORMATIONAL) + +1603 IETF Working Group Guidelines and Procedures. E. Huizer, D. + Crocker. March 1994. (Format: TXT=63900 bytes) (Obsoleted by RFC2418) + (Updated by RFC1871) (Status: INFORMATIONAL) + +1604 Definitions of Managed Objects for Frame Relay Service. T. Brown, + Editor. March 1994. (Format: TXT=88770 bytes) (Obsoletes RFC1596) + (Obsoleted by RFC2954) (Status: PROPOSED STANDARD) + +1605 SONET to Sonnet Translation. W. Shakespeare. Apr-01-1994. + (Format: TXT=4451 bytes) (Status: INFORMATIONAL) + +1606 A Historical Perspective On The Usage Of IP Version 9. J. Onions. + Apr-01-1994. (Format: TXT=8398 bytes) (Status: INFORMATIONAL) + +1607 A VIEW FROM THE 21ST CENTURY. V. Cerf. Apr-01-1994. (Format: + TXT=28165 bytes) (Status: INFORMATIONAL) + +1608 Representing IP Information in the X.500 Directory. T. Johannsen, + G. Mansfield, M. Kosters, S. Sataluri. March 1994. (Format: TXT=40269 + bytes) (Status: EXPERIMENTAL) + +1609 Charting Networks in the X.500 Directory. G. Mansfield, T. + Johannsen, M. Knopper. March 1994. (Format: TXT=30044 bytes) (Status: + EXPERIMENTAL) + +1610 Internet Official Protocol Standards. J. Postel. July 1994. + (Format: TXT=81346 bytes) (Obsoletes RFC1600) (Obsoleted by RFC1720) + (Status: HISTORIC) + +1611 DNS Server MIB Extensions. R. Austein, J. Saperia. May 1994. + (Format: TXT=58700 bytes) (Status: PROPOSED STANDARD) + +1612 DNS Resolver MIB Extensions. R. Austein, J. Saperia. May 1994. + (Format: TXT=61382 bytes) (Status: PROPOSED STANDARD) + +1613 cisco Systems X.25 over TCP (XOT). J. Forster, G. Satz, G. Glick, + R. Day. May 1994. (Format: TXT=29267 bytes) (Status: INFORMATIONAL) + +1614 Network Access to Multimedia Information. C. Adie. May 1994. + (Format: TXT=187253 bytes) (Status: INFORMATIONAL) + +1615 Migrating from X.400(84) to X.400(88). J. Houttuin, J. Craigie. + May 1994. (Format: TXT=39693 bytes) (Status: INFORMATIONAL) + +1616 X.400(1988) for the Academic and Research Community in Europe. + RARE WG-MSG Task Force 88, E. Huizer, J. Romaguera, Editors. May + 1994. (Format: TXT=107432 bytes) (Status: INFORMATIONAL) + +1617 Naming and Structuring Guidelines for X.500 Directory Pilots. P. + Barker, S. Kille, T. Lenggenhager. May 1994. (Format: TXT=56739 + bytes) (Obsoletes RFC1384) (Status: INFORMATIONAL) + +1618 PPP over ISDN. W. Simpson. May 1994. (Format: TXT=14896 bytes) + (Status: PROPOSED STANDARD) + +1619 PPP over SONET/SDH. W. Simpson. May 1994. (Format: TXT=8893 + bytes) (Obsoleted by RFC2615) (Status: PROPOSED STANDARD) + +1620 Internet Architecture Extensions for Shared Media. B. Braden, J. + Postel, Y. Rekhter. May 1994. (Format: TXT=44999 bytes) (Status: + INFORMATIONAL) + +1621 Pip Near-term Architecture. P. Francis. May 1994. (Format: + TXT=128905 bytes) (Status: INFORMATIONAL) + +1622 Pip Header Processing. P. Francis. May 1994. (Format: TXT=34837 + bytes) (Status: INFORMATIONAL) + +1623 Definitions of Managed Objects for the Ethernet-like Interface + Types. F. Kastenholz. May 1994. (Format: TXT=38745 bytes) (Obsoletes + RFC1398) (Obsoleted by RFC1643) (Status: HISTORIC) + +1624 Computation of the Internet Checksum via Incremental Update. A. + Rijsinghani, Editor. May 1994. (Format: TXT=9836 bytes) (Updates + RFC1141) (Status: INFORMATIONAL) + +1625 WAIS over Z39.50-1988. M. St. Pierre, J. Fullton, K. Gamiel, J. + Goldman, B. Kahle, J. Kunze, H. Morris, F. Schiettecatte. June 1994. + (Format: TXT=14694 bytes) (Status: INFORMATIONAL) + +1626 Default IP MTU for use over ATM AAL5. R. Atkinson. May 1994. + (Format: TXT=11841 bytes) (Obsoleted by RFC2225) (Status: PROPOSED + STANDARD) + +1627 Network 10 Considered Harmful (Some Practices Shouldn't be + Codified). E. Lear, E. Fair, D. Crocker, T. Kessler. July 1994. + (Format: TXT=18823 bytes) (Obsoleted by RFC1918) (Status: + INFORMATIONAL) + +1628 UPS Management Information Base. J. Case. May 1994. (Format: + TXT=83439 bytes) (Status: PROPOSED STANDARD) + +1629 Guidelines for OSI NSAP Allocation in the Internet. R. Colella, + R. Callon, E. Gardner, Y. Rekhter. May 1994. (Format: TXT=131640 + bytes) (Obsoletes RFC1237) (Status: DRAFT STANDARD) + +1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the + Expression of Names and Addresses of Objects on the Network as used + in the World-Wide Web. T. Berners-Lee. June 1994. (Format: TXT=57601 + bytes) (Status: INFORMATIONAL) + +1631 The IP Network Address Translator (NAT). K. Egevang, P. Francis. + May 1994. (Format: TXT=22714 bytes) (Obsoleted by RFC3022) (Status: + INFORMATIONAL) + +1632 A Revised Catalog of Available X.500 Implementations. A. + Getchell, S. Sataluri, Editors. May 1994. (Format: TXT=124111 bytes) + (Obsoletes RFC1292) (Obsoleted by RFC2116) (Status: INFORMATIONAL) + +1633 Integrated Services in the Internet Architecture: an Overview. R. + Braden, D. Clark, S. Shenker. June 1994. (Format: TXT=89691, + PS=207016, PDF=201858 bytes) (Status: INFORMATIONAL) + +1634 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. May 1994. + (Format: TXT=55347 bytes) (Obsoletes RFC1551, RFC1362) (Status: + INFORMATIONAL) + +1635 How to Use Anonymous FTP. P. Deutsch, A. Emtage, A. Marine. May + 1994. (Format: TXT=27258 bytes) (Also FYI0024) (Status: + INFORMATIONAL) + +1636 Report of IAB Workshop on Security in the Internet Architecture - + February 8-10, 1994. R. Braden, D. Clark, S. Crocker, C. Huitema. + June 1994. (Format: TXT=130761 bytes) (Status: INFORMATIONAL) + +1637 DNS NSAP Resource Records. B. Manning, R. Colella. June 1994. + (Format: TXT=21768 bytes) (Obsoletes RFC1348) (Obsoleted by RFC1706) + (Status: EXPERIMENTAL) + +1638 PPP Bridging Control Protocol (BCP). F. Baker, R. Bowen. June + 1994. (Format: TXT=58477 bytes) (Obsoletes RFC1220) (Obsoleted by + RFC2878) (Status: PROPOSED STANDARD) + +1639 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. + June 1994. (Format: TXT=10055 bytes) (Obsoletes RFC1545) (Status: + EXPERIMENTAL) + +1640 The Process for Organization of Internet Standards Working Group + (POISED). S. Crocker. June 1994. (Format: TXT=21780 bytes) (Status: + INFORMATIONAL) + +1641 Using Unicode with MIME. D. Goldsmith, M. Davis. July 1994. + (Format: TXT=11258, PS=20451, PDF=11658 bytes) (Status: EXPERIMENTAL) + +1642 UTF-7 - A Mail-Safe Transformation Format of Unicode. D. + Goldsmith, M. Davis. July 1994. (Format: TXT=27770, PS=50907, + PDF=29573 bytes) (Obsoleted by RFC2152) (Status: EXPERIMENTAL) + +1643 Definitions of Managed Objects for the Ethernet-like Interface + Types. F. Kastenholz. July 1994. (Format: TXT=39008 bytes) (Obsoletes + RFC1623) (Also STD0050) (Status: STANDARD) + +1644 T/TCP -- TCP Extensions for Transactions Functional + Specification. R. Braden. July 1994. (Format: TXT=87362 bytes) + (Updates RFC1379) (Status: EXPERIMENTAL) + +1645 Simple Network Paging Protocol - Version 2. A. Gwinn. July 1994. + (Format: TXT=31243 bytes) (Obsoletes RFC1568) (Obsoleted by RFC1861) + (Status: INFORMATIONAL) + +1646 TN3270 Extensions for LUname and Printer Selection. C. Graves, T. + Butts, M. Angel. July 1994. (Format: TXT=27564 bytes) (Status: + INFORMATIONAL) + +1647 TN3270 Enhancements. B. Kelly. July 1994. (Format: TXT=84420 + bytes) (Obsoleted by RFC2355) (Status: PROPOSED STANDARD) + +1648 Postmaster Convention for X.400 Operations. A. Cargille. July + 1994. (Format: TXT=8761 bytes) (Status: PROPOSED STANDARD) + +1649 Operational Requirements for X.400 Management Domains in the + GO-MHS Community. R. Hagens, A. Hansen. July 1994. (Format: TXT=28138 + bytes) (Status: INFORMATIONAL) + +1650 Definitions of Managed Objects for the Ethernet-like Interface + Types using SMIv2. F. Kastenholz. August 1994. (Format: TXT=40484 + bytes) (Obsoleted by RFC2358) (Status: PROPOSED STANDARD) + +1651 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. + Stefferud, D. Crocker. July 1994. (Format: TXT=22153 bytes) + (Obsoletes RFC1425) (Obsoleted by RFC1869) (Status: DRAFT STANDARD) + +1652 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. + Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. (Format: + TXT=11842 bytes) (Obsoletes RFC1426) (Status: DRAFT STANDARD) + +1653 SMTP Service Extension for Message Size Declaration. J. Klensin, + N. Freed, K. Moore. July 1994. (Format: TXT=17883 bytes) (Obsoletes + RFC1427) (Obsoleted by RFC1870) (Status: DRAFT STANDARD) + +1654 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li, Editors. + July 1994. (Format: TXT=130118 bytes) (Obsoleted by RFC1771) (Status: + PROPOSED STANDARD) + +1655 Application of the Border Gateway Protocol in the Internet. Y. + Rekhter, P. Gross, Editors. July 1994. (Format: TXT=43664 bytes) + (Obsoletes RFC1268) (Obsoleted by RFC1772) (Status: PROPOSED + STANDARD) + +1656 BGP-4 Protocol Document Roadmap and Implementation Experience. P. + Traina. July 1994. (Format: TXT=7705 bytes) (Obsoleted by RFC1773) + (Status: INFORMATIONAL) + +1657 Definitions of Managed Objects for the Fourth Version of the + Border Gateway Protocol (BGP-4) using SMIv2. S. Willis, J. Burruss, + J. Chu, Editor. July 1994. (Format: TXT=45505 bytes) (Status: DRAFT + STANDARD) + +1658 Definitions of Managed Objects for Character Stream Devices using + SMIv2. B. Stewart. July 1994. (Format: TXT=32579 bytes) (Obsoletes + RFC1316) (Status: DRAFT STANDARD) + +1659 Definitions of Managed Objects for RS-232-like Hardware Devices + using SMIv2. B. Stewart. July 1994. (Format: TXT=36479 bytes) + (Obsoletes RFC1317) (Status: DRAFT STANDARD) + +1660 Definitions of Managed Objects for Parallel-printer-like Hardware + Devices using SMIv2. B. Stewart. July 1994. (Format: TXT=16784 bytes) + (Obsoletes RFC1318) (Status: DRAFT STANDARD) + +1661 The Point-to-Point Protocol (PPP). W. Simpson, Editor. July 1994. + (Format: TXT=103026 bytes) (Obsoletes RFC1548) (Updated by RFC2153) + (Also STD0051) (Status: STANDARD) + +1662 PPP in HDLC-like Framing. W. Simpson, Editor. July 1994. (Format: + TXT=48058 bytes) (Obsoletes RFC1549) (Also STD0051) (Status: + STANDARD) + +1663 PPP Reliable Transmission. D. Rand. July 1994. (Format: TXT=17281 + bytes) (Status: PROPOSED STANDARD) + +1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping + Tables. C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens. + August 1994. (Format: TXT=50783 bytes) (Obsoleted by RFC2163) + (Status: EXPERIMENTAL) + +1665 Definitions of Managed Objects for SNA NAUs using SMIv2. Z. + Kielczewski, D. Kostick, K. Shih, Editors. July 1994. (Format: + TXT=133381 bytes) (Obsoleted by RFC1666) (Status: PROPOSED STANDARD) + +1666 Definitions of Managed Objects for SNA NAUs using SMIv2. Z. + Kielczewski, D. Kostick, K. Shih, Editors. August 1994. (Format: + TXT=134385 bytes) (Obsoletes RFC1665) (Status: PROPOSED STANDARD) + +1667 Modeling and Simulation Requirements for IPng. S. Symington, D. + Wood, M. Pullen. August 1994. (Format: TXT=17291 bytes) (Status: + INFORMATIONAL) + +1668 Unified Routing Requirements for IPng. D. Estrin, T. Li, Y. + Rekhter. August 1994. (Format: TXT=5106 bytes) (Status: + INFORMATIONAL) + +1669 Market Viability as a IPng Criteria. J. Curran. August 1994. + (Format: TXT=8099 bytes) (Status: INFORMATIONAL) + +1670 Input to IPng Engineering Considerations. D. Heagerty. August + 1994. (Format: TXT=5350 bytes) (Status: INFORMATIONAL) + +1671 IPng White Paper on Transition and Other Considerations. B. + Carpenter. August 1994. (Format: TXT=17631 bytes) (Status: + INFORMATIONAL) + +1672 Accounting Requirements for IPng. N. Brownlee. August 1994. + (Format: TXT=6185 bytes) (Status: INFORMATIONAL) + +1673 Electric Power Research Institute Comments on IPng. R. Skelton. + August 1994. (Format: TXT=7476 bytes) (Status: INFORMATIONAL) + +1674 A Cellular Industry View of IPng. M. Taylor. August 1994. + (Format: TXT=6157 bytes) (Status: INFORMATIONAL) + +1675 Security Concerns for IPng. S. Bellovin. August 1994. (Format: + TXT=8290 bytes) (Status: INFORMATIONAL) + +1676 INFN Requirements for an IPng. A. Ghiselli, D. Salomoni, C. + Vistoli. August 1994. (Format: TXT=8493 bytes) (Status: + INFORMATIONAL) + +1677 Tactical Radio Frequency Communication Requirements for IPng. B. + Adamson. August 1994. (Format: TXT=24065 bytes) (Status: + INFORMATIONAL) + +1678 IPng Requirements of Large Corporate Networks. E. Britton, J. + Tavs. August 1994. (Format: TXT=18650 bytes) (Status: INFORMATIONAL) + +1679 HPN Working Group Input to the IPng Requirements Solicitation. D. + Green, P. Irey, D. Marlow, K. O'Donoghue. August 1994. (Format: + TXT=22974 bytes) (Status: INFORMATIONAL) + +1680 IPng Support for ATM Services. C. Brazdziunas. August 1994. + (Format: TXT=17846 bytes) (Status: INFORMATIONAL) + +1681 On Many Addresses per Host. S. Bellovin. August 1994. (Format: + TXT=11964 bytes) (Status: INFORMATIONAL) + +1682 IPng BSD Host Implementation Analysis. J. Bound. August 1994. + (Format: TXT=22295 bytes) (Status: INFORMATIONAL) + +1683 Multiprotocol Interoperability In IPng. R. Clark, M. Ammar, K. + Calvert. August 1994. (Format: TXT=28201 bytes) (Status: + INFORMATIONAL) + +1684 Introduction to White Pages Services based on X.500. P. Jurg. + August 1994. (Format: TXT=22985 bytes) (Status: INFORMATIONAL) + +1685 Writing X.400 O/R Names. H. Alvestrand. August 1994. (Format: + TXT=21242 bytes) (Also RTR0012) (Status: INFORMATIONAL) + +1686 IPng Requirements: A Cable Television Industry Viewpoint. M. + Vecchi. August 1994. (Format: TXT=39052 bytes) (Status: + INFORMATIONAL) + +1687 A Large Corporate User's View of IPng. E. Fleischman. August + 1994. (Format: TXT=34120 bytes) (Status: INFORMATIONAL) + +1688 IPng Mobility Considerations. W. Simpson. August 1994. (Format: + TXT=19151 bytes) (Status: INFORMATIONAL) + +1689 A Status Report on Networked Information Retrieval: Tools and + Groups. J. Foster. August 1994. (Format: TXT=375469 bytes) (Also + FYI0025) (Status: INFORMATIONAL) + +1690 Introducing the Internet Engineering and Planning Group (IEPG). + G. Huston. August 1994. (Format: TXT=3013 bytes) (Status: + INFORMATIONAL) + +1691 The Document Architecture for the Cornell Digital Library. W. + Turner. August 1994. (Format: TXT=20438 bytes) (Status: + INFORMATIONAL) + +1692 Transport Multiplexing Protocol (TMux). P. Cameron, D. Crocker, + D. Cohen, J. Postel. August 1994. (Format: TXT=26163 bytes) (Status: + PROPOSED STANDARD) + +1693 An Extension to TCP : Partial Order Service. T. Connolly, P. + Amer, P. Conrad. November 1994. (Format: TXT=90100 bytes) (Status: + EXPERIMENTAL) + +1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2. + T. Brown, K. Tesink, Editors. August 1994. (Format: TXT=70856 bytes) + (Obsoletes RFC1304) (Status: DRAFT STANDARD) + +1695 Definitions of Managed Objects for ATM Management Version 8.0 + using SMIv2. M. Ahmed, K. Tesink, Editors. August 1994. (Format: + TXT=175461 bytes) (Obsoleted by RFC2515) (Status: PROPOSED STANDARD) + +1696 Modem Management Information Base (MIB) using SMIv2. J. Barnes, + L. Brown, R. Royston, S. Waldbusser. August 1994. (Format: TXT=54054 + bytes) (Status: PROPOSED STANDARD) + +1697 Relational Database Management System (RDBMS) Management + Information Base (MIB) using SMIv2. D. Brower, Editor, B. Purvy, + RDBMSMIB Working Group Chair, A. Daniel, M. Sinykin, J. Smith. August + 1994. (Format: TXT=76202 bytes) (Status: PROPOSED STANDARD) + +1698 Octet Sequences for Upper-Layer OSI to Support Basic + Communications Applications. P. Furniss. October 1994. (Format: + TXT=67433 bytes) (Status: INFORMATIONAL) + +1699 Summary of 1600-1699. J. Elliott. January 1997. (Format: + TXT=40674 bytes) (Status: INFORMATIONAL) + +1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format: + TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status: + STANDARD) + +1701 Generic Routing Encapsulation (GRE). S. Hanks, T. Li, D. + Farinacci, P. Traina. October 1994. (Format: TXT=15460 bytes) + (Status: INFORMATIONAL) + +1702 Generic Routing Encapsulation over IPv4 networks. S. Hanks, T. + Li, D. Farinacci, P. Traina. October 1994. (Format: TXT=7288 bytes) + (Status: INFORMATIONAL) + +1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging + -- Technical Procedures. M. Rose. October 1994. (Format: TXT=17985 + bytes) (Obsoletes RFC1569) (Status: INFORMATIONAL) + +1704 On Internet Authentication. N. Haller, R. Atkinson. October 1994. + (Format: TXT=42269 bytes) (Status: INFORMATIONAL) + +1705 Six Virtual Inches to the Left: The Problem with IPng. R. + Carlson, D. Ficarella. October 1994. (Format: TXT=65222 bytes) + (Status: INFORMATIONAL) + +1706 DNS NSAP Resource Records. B. Manning, R. Colella. October 1994. + (Format: TXT=19721 bytes) (Obsoletes RFC1637) (Status: INFORMATIONAL) + +1707 CATNIP: Common Architecture for the Internet. M. McGovern, R. + Ullmann. October 1994. (Format: TXT=37568 bytes) (Status: + INFORMATIONAL) + +1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3. D. + Gowin. October 1994. (Format: TXT=26523 bytes) (Status: + INFORMATIONAL) + +1709 K-12 Internetworking Guidelines. J. Gargano, D. Wasley. November + 1994. (Format: TXT=66659, PS=662030, PDF=134065 bytes) (Also FYI0026) + (Status: INFORMATIONAL) + +1710 Simple Internet Protocol Plus White Paper. R. Hinden. October + 1994. (Format: TXT=56910 bytes) (Status: INFORMATIONAL) + +1711 Classifications in E-mail Routing. J. Houttuin. October 1994. + (Format: TXT=47584 bytes) (Status: INFORMATIONAL) + +1712 DNS Encoding of Geographical Location. C. Farrell, M. Schulze, S. + Pleitner, D. Baldoni. November 1994. (Format: TXT=13237 bytes) + (Status: EXPERIMENTAL) + +1713 Tools for DNS debugging. A. Romao. November 1994. (Format: + TXT=33500 bytes) (Also FYI0027) (Status: INFORMATIONAL) + +1714 Referral Whois Protocol (RWhois). S. Williamson, M. Kosters. + November 1994. (Format: TXT=85395, PS=204207, PDF=85556 bytes) + (Obsoleted by RFC2167) (Status: INFORMATIONAL) + +1715 The H Ratio for Address Assignment Efficiency. C. Huitema. + November 1994. (Format: TXT=7392 bytes) (Status: INFORMATIONAL) + +1716 Towards Requirements for IP Routers. P. Almquist, F. Kastenholz. + November 1994. (Format: TXT=432330 bytes) (Obsoleted by RFC1812) + (Status: INFORMATIONAL) + +1717 The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. + McGregor, D. Carr. November 1994. (Format: TXT=46264 bytes) + (Obsoleted by RFC1990) (Status: PROPOSED STANDARD) + +1718 The Tao of IETF - A Guide for New Attendees of the Internet + Engineering Task Force. IETF Secretariat, G. Malkin. November 1994. + (Format: TXT=50458 bytes) (Obsoletes RFC1539) (Obsoleted by RFC3160) + (Status: INFORMATIONAL) + +1719 A Direction for IPng. P. Gross. December 1994. (Format: TXT=11118 + bytes) (Status: INFORMATIONAL) + +1720 Internet Official Protocol Standards. J. Postel. November 1994. + (Format: TXT=89063 bytes) (Obsoletes RFC1610) (Obsoleted by RFC1780) + (Status: HISTORIC) + +1721 RIP Version 2 Protocol Analysis. G. Malkin. November 1994. + (Format: TXT=6680 bytes) (Obsoletes RFC1387) (Status: INFORMATIONAL) + +1722 RIP Version 2 Protocol Applicability Statement. G. Malkin. + November 1994. (Format: TXT=10236 bytes) (Also STD0057) (Status: + STANDARD) + +1723 RIP Version 2 - Carrying Additional Information. G. Malkin. + November 1994. (Format: TXT=18597 bytes) (Obsoletes RFC1388) + (Obsoleted by RFC2453) (Updates RFC1058) (Also STD0056) (Status: + STANDARD) + +1724 RIP Version 2 MIB Extension. G. Malkin, F. Baker. November 1994. + (Format: TXT=29645 bytes) (Obsoletes RFC1389) (Status: DRAFT + STANDARD) + +1725 Post Office Protocol - Version 3. J. Myers, M. Rose. November + 1994. (Format: TXT=35058 bytes) (Obsoletes RFC1460) (Obsoleted by + RFC1939) (Also STD0053) (Status: STANDARD) + +1726 Technical Criteria for Choosing IP The Next Generation (IPng). C. + Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes) + (Status: INFORMATIONAL) + +1727 A Vision of an Integrated Internet Information Service. C. + Weider, P. Deutsch. December 1994. (Format: TXT=28468 bytes) (Status: + INFORMATIONAL) + +1728 Resource Transponders. C. Weider. December 1994. (Format: + TXT=12092 bytes) (Status: INFORMATIONAL) + +1729 Using the Z39.50 Information Retrieval Protocol. C. Lynch. + December 1994. (Format: TXT=20927 bytes) (Status: INFORMATIONAL) + +1730 Internet Message Access Protocol - Version 4. M. Crispin. + December 1994. (Format: TXT=156660 bytes) (Obsoleted by RFC2060, + RFC2061) (Status: PROPOSED STANDARD) + +1731 IMAP4 Authentication Mechanisms. J. Myers. December 1994. + (Format: TXT=11433 bytes) (Status: PROPOSED STANDARD) + +1732 IMAP4 Compatibility with IMAP2 and IMAP2bis. M. Crispin. December + 1994. (Format: TXT=9276 bytes) (Status: INFORMATIONAL) + +1733 Distributed Electronic Mail Models in IMAP4. M. Crispin. December + 1994. (Format: TXT=6205 bytes) (Status: INFORMATIONAL) + +1734 POP3 AUTHentication command. J. Myers. December 1994. (Format: + TXT=8499 bytes) (Status: PROPOSED STANDARD) + +1735 NBMA Address Resolution Protocol (NARP). J. Heinanen, R. + Govindan. December 1994. (Format: TXT=24485 bytes) (Status: + EXPERIMENTAL) + +1736 Functional Recommendations for Internet Resource Locators. J. + Kunze. February 1995. (Format: TXT=22415 bytes) (Status: + INFORMATIONAL) + +1737 Functional Requirements for Uniform Resource Names. K. Sollins, + L. Masinter. December 1994. (Format: TXT=16337 bytes) (Status: + INFORMATIONAL) + +1738 Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. + McCahill. December 1994. (Format: TXT=51348 bytes) (Updated by + RFC1808, RFC2368, RFC2396) (Status: PROPOSED STANDARD) + +1739 A Primer On Internet and TCP/IP Tools. G. Kessler, S. Shepard. + December 1994. (Format: TXT=102676 bytes) (Obsoleted by RFC2151) + (Status: INFORMATIONAL) + +1740 MIME Encapsulation of Macintosh Files - MacMIME. P. Faltstrom, D. + Crocker, E. Fair. December 1994. (Format: TXT=31297 bytes) (Status: + PROPOSED STANDARD) + +1741 MIME Content Type for BinHex Encoded Files. P. Faltstrom, D. + Crocker, E. Fair. December 1994. (Format: TXT=10155 bytes) (Status: + INFORMATIONAL) + +1742 AppleTalk Management Information Base II. S. Waldbusser, K. + Frisa. January 1995. (Format: TXT=168306 bytes) (Obsoletes RFC1243) + (Status: PROPOSED STANDARD) + +1743 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December + 1994. (Format: TXT=43224 bytes) (Obsoletes RFC1231) (Obsoleted by + RFC1748) (Status: DRAFT STANDARD) + +1744 Observations on the Management of the Internet Address Space. G. + Huston. December 1994. (Format: TXT=32411 bytes) (Status: + INFORMATIONAL) + +1745 BGP4/IDRP for IP---OSPF Interaction. K. Varadhan, S. Hares, Y. + Rekhter. December 1994. (Format: TXT=43675 bytes) (Status: HISTORIC) + +1746 Ways to Define User Expectations. B. Manning, D. Perkins. + December 1994. (Format: TXT=46164 bytes) (Status: INFORMATIONAL) + +1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) + using SMIv2. J. Hilgeman, Chair, S. Nix, A. Bartky, W. Clark, Editor. + January 1995. (Format: TXT=147388 bytes) (Status: PROPOSED STANDARD) + +1748 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December + 1994. (Format: TXT=43224 bytes) (Obsoletes RFC1743, RFC1231) (Updated + by RFC1749) (Status: DRAFT STANDARD) + +1749 IEEE 802.5 Station Source Routing MIB using SMIv2. K. McCloghrie, + F. Baker, E. Decker. December 1994. (Format: TXT=17563 bytes) + (Updates RFC1748) (Status: PROPOSED STANDARD) + +1750 Randomness Recommendations for Security. D. Eastlake, S. Crocker, + J. Schiller. December 1994. (Format: TXT=73842 bytes) (Status: + INFORMATIONAL) + +1751 A Convention for Human-Readable 128-bit Keys. D. McDonald. + December 1994. (Format: TXT=31428 bytes) (Status: INFORMATIONAL) + +1752 The Recommendation for the IP Next Generation Protocol. S. + Bradner, A. Mankin. January 1995. (Format: TXT=127784 bytes) (Status: + PROPOSED STANDARD) + +1753 IPng Technical Requirements Of the Nimrod Routing and Addressing + Architecture. N. Chiappa. December 1994. (Format: TXT=46586 bytes) + (Status: INFORMATIONAL) + +1754 IP over ATM Working Group's Recommendations for the ATM Forum's + Multiprotocol BOF Version 1. M. Laubach. January 1995. (Format: + TXT=13483 bytes) (Status: INFORMATIONAL) + +1755 ATM Signaling Support for IP over ATM. M. Perez, F. Liaw, D. + Grossman, A. Mankin, E. Hoffman, A. Malis. February 1995. (Format: + TXT=55209 bytes) (Status: PROPOSED STANDARD) + +1756 Remote Write Protocol - Version 1.0. T. Rinne. January 1995. + (Format: TXT=22078 bytes) (Status: EXPERIMENTAL) + +1757 Remote Network Monitoring Management Information Base. S. + Waldbusser. February 1995. (Format: TXT=208117 bytes) (Obsoletes + RFC1271) (Obsoleted by RFC2819) (Status: DRAFT STANDARD) + +1758 NADF Standing Documents: A Brief Overview. The North American + Directory Forum. February 1995. (Format: TXT=7294 bytes) (Obsoletes + RFC1417) (Status: INFORMATIONAL) + +1759 Printer MIB. R. Smith, F. Wright, T. Hastings, S. Zilles, J. + Gyllenskog. March 1995. (Format: TXT=239228 bytes) (Status: PROPOSED + STANDARD) + +1760 The S/KEY One-Time Password System. N. Haller. February 1995. + (Format: TXT=31124 bytes) (Status: INFORMATIONAL) + +1761 Snoop Version 2 Packet Capture File Format. B. Callaghan, R. + Gilligan. February 1995. (Format: TXT=10761 bytes) (Status: + INFORMATIONAL) + +1762 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. March + 1995. (Format: TXT=12709 bytes) (Obsoletes RFC1376) (Status: DRAFT + STANDARD) + +1763 The PPP Banyan Vines Control Protocol (BVCP). S. Senum. March + 1995. (Format: TXT=17817 bytes) (Status: PROPOSED STANDARD) + +1764 The PPP XNS IDP Control Protocol (XNSCP). S. Senum. March 1995. + (Format: TXT=9525 bytes) (Status: PROPOSED STANDARD) + +1765 OSPF Database Overflow. J. Moy. March 1995. (Format: TXT=21613 + bytes) (Status: EXPERIMENTAL) + +1766 Tags for the Identification of Languages. H. Alvestrand. March + 1995. (Format: TXT=16966 bytes) (Obsoleted by RFC3066) (Status: + PROPOSED STANDARD) + +1767 MIME Encapsulation of EDI Objects. D. Crocker. March 1995. + (Format: TXT=15293 bytes) (Status: PROPOSED STANDARD) + +1768 Host Group Extensions for CLNP Multicasting. D. Marlow. March + 1995. (Format: TXT=111499 bytes) (Status: EXPERIMENTAL) + +1769 Simple Network Time Protocol (SNTP). D. Mills. March 1995. + (Format: TXT=34454 bytes) (Obsoletes RFC1361) (Obsoleted by RFC2030) + (Status: INFORMATIONAL) + +1770 IPv4 Option for Sender Directed Multi-Destination Delivery. C. + Graff. March 1995. (Format: TXT=11606 bytes) (Status: INFORMATIONAL) + +1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March + 1995. (Format: TXT=131903 bytes) (Obsoletes RFC1654) (Status: DRAFT + STANDARD) + +1772 Application of the Border Gateway Protocol in the Internet. Y. + Rekhter, P. Gross. March 1995. (Format: TXT=43916 bytes) (Obsoletes + RFC1655) (Status: DRAFT STANDARD) + +1773 Experience with the BGP-4 protocol. P. Traina. March 1995. + (Format: TXT=19936 bytes) (Obsoletes RFC1656) (Status: INFORMATIONAL) + +1774 BGP-4 Protocol Analysis. P. Traina, Editor. March 1995. (Format: + TXT=23823 bytes) (Status: INFORMATIONAL) + +1775 To Be "On" the Internet. D. Crocker. March 1995. (Format: + TXT=8454 bytes) (Status: INFORMATIONAL) + +1776 The Address is the Message. S. Crocker. Apr-01-1995. (Format: + TXT=2051 bytes) (Status: INFORMATIONAL) + +1777 Lightweight Directory Access Protocol. W. Yeong, T. Howes, S. + Kille. March 1995. (Format: TXT=45459 bytes) (Obsoletes RFC1487) + (Status: DRAFT STANDARD) + +1778 The String Representation of Standard Attribute Syntaxes. T. + Howes, S. Kille, W. Yeong, C. Robbins. March 1995. (Format: TXT=19053 + bytes) (Obsoletes RFC1488) (Updated by RFC2559) (Status: DRAFT + STANDARD) + +1779 A String Representation of Distinguished Names. S. Kille. March + 1995. (Format: TXT=12429 bytes) (Obsoletes RFC1485) (Obsoleted by + RFC2253) (Status: DRAFT STANDARD) + +1780 Internet Official Protocol Standards. J. Postel, Editor. March + 1995. (Format: TXT=86594 bytes) (Obsoletes RFC1720) (Obsoleted by + RFC1800) (Status: HISTORIC) + +1781 Using the OSI Directory to Achieve User Friendly Naming. S. + Kille. March 1995. (Format: TXT=47129 bytes) (Obsoletes RFC1484) + (Status: PROPOSED STANDARD) + +1782 TFTP Option Extension. G. Malkin, A. Harkin. March 1995. (Format: + TXT=11508 bytes) (Obsoleted by RFC2347) (Updates RFC1350) (Status: + PROPOSED STANDARD) + +1783 TFTP Blocksize Option. G. Malkin, A. Harkin. March 1995. (Format: + TXT=7814 bytes) (Obsoleted by RFC2348) (Updates RFC1350) (Status: + PROPOSED STANDARD) + +1784 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. + Harkin. March 1995. (Format: TXT=6106 bytes) (Obsoleted by RFC2349) + (Updates RFC1350) (Status: PROPOSED STANDARD) + +1785 TFTP Option Negotiation Analysis. G. Malkin, A. Harkin. March + 1995. (Format: TXT=3354 bytes) (Updates RFC1350) (Status: + INFORMATIONAL) + +1786 Representation of IP Routing Policies in a Routing Registry + (ripe-81++). T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. + Karrenberg, M. Terpstra, J. Yu. March 1995. (Format: TXT=133643 + bytes) (Status: INFORMATIONAL) + +1787 Routing in a Multi-provider Internet. Y. Rekhter. April 1995. + (Format: TXT=20754 bytes) (Status: INFORMATIONAL) + +1788 ICMP Domain Name Messages. W. Simpson. April 1995. (Format: + TXT=11722 bytes) (Status: EXPERIMENTAL) + +1789 INETPhone: Telephone Services and Servers on Internet. C. Yang. + April 1995. (Format: TXT=14186 bytes) (Status: INFORMATIONAL) + +1790 An Agreement between the Internet Society and Sun Microsystems, + Inc. in the Matter of ONC RPC and XDR Protocols. V. Cerf. April 1995. + (Format: TXT=8226 bytes) (Status: INFORMATIONAL) + +1791 TCP And UDP Over IPX Networks With Fixed Path MTU. T. Sung. April + 1995. (Format: TXT=22347 bytes) (Status: EXPERIMENTAL) + +1792 TCP/IPX Connection Mib Specification. T. Sung. April 1995. + (Format: TXT=16389 bytes) (Status: EXPERIMENTAL) + +1793 Extending OSPF to Support Demand Circuits. J. Moy. April 1995. + (Format: TXT=78728 bytes) (Status: PROPOSED STANDARD) + +1794 DNS Support for Load Balancing. T. Brisco. April 1995. (Format: + TXT=15494 bytes) (Status: INFORMATIONAL) + +1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw + Closed Pages, DLSw Standard Version 1. L. Wells, Chair, A. Bartky, + Editor. April 1995. (Format: TXT=214848 bytes) (Obsoletes RFC1434) + (Status: INFORMATIONAL) + +1796 Not All RFCs are Standards. C. Huitema, J. Postel, S. Crocker. + April 1995. (Format: TXT=7049 bytes) (Status: INFORMATIONAL) + +1797 Class A Subnet Experiment. Internet Assigned Numbers Authority + (IANA). April 1995. (Format: TXT=6779 bytes) (Status: EXPERIMENTAL) + +1798 Connection-less Lightweight X.500 Directory Access Protocol. A. + Young. June 1995. (Format: TXT=18548 bytes) (Status: PROPOSED + STANDARD) + +1799 Request for Comments Summary RFC Numbers 1700-1799. M. Kennedy. + January 1997. (Format: TXT=42038 bytes) (Status: INFORMATIONAL) + +1800 Internet Official Protocol Standards. J. Postel, Editor. July + 1995. (Format: TXT=83649 bytes) (Obsoletes RFC1780) (Obsoleted by + RFC1880) (Status: HISTORIC) + +1801 MHS use of the X.500 Directory to support MHS Routing. S. Kille. + June 1995. (Format: TXT=156462 bytes) (Status: EXPERIMENTAL) + +1802 Introducing Project Long Bud: Internet Pilot Project for the + Deployment of X.500 Directory Information in Support of X.400 + Routing. H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera. June + 1995. (Format: TXT=24637 bytes) (Status: INFORMATIONAL) + +1803 Recommendations for an X.500 Production Directory Service. R. + Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. Yeong. June + 1995. (Format: TXT=14721 bytes) (Status: INFORMATIONAL) + +1804 Schema Publishing in X.500 Directory. G. Mansfield, P. Rajeev, S. + Raghavan, T. Howes. June 1995. (Format: TXT=18268 bytes) (Status: + EXPERIMENTAL) + +1805 Location-Independent Data/Software Integrity Protocol. A. Rubin. + June 1995. (Format: TXT=13352 bytes) (Status: INFORMATIONAL) + +1806 Communicating Presentation Information in Internet Messages: The + Content-Disposition Header. R. Troost, S. Dorner. June 1995. (Format: + TXT=15548 bytes) (Updated by RFC2183) (Status: EXPERIMENTAL) + +1807 A Format for Bibliographic Records. R. Lasher, D. Cohen. June + 1995. (Format: TXT=29417 bytes) (Obsoletes RFC1357) (Status: + INFORMATIONAL) + +1808 Relative Uniform Resource Locators. R. Fielding. June 1995. + (Format: TXT=34950 bytes) (Updates RFC1738) (Updated by RFC2368, + RFC2396) (Status: PROPOSED STANDARD) + +1809 Using the Flow Label Field in IPv6. C. Partridge. June 1995. + (Format: TXT=13591 bytes) (Status: INFORMATIONAL) + +1810 Report on MD5 Performance. J. Touch. June 1995. (Format: + TXT=16607 bytes) (Status: INFORMATIONAL) + +1811 U.S. Government Internet Domain Names. Federal Networking + Council. June 1995. (Format: TXT=6641 bytes) (Obsoleted by RFC1816) + (Status: INFORMATIONAL) + +1812 Requirements for IP Version 4 Routers. F. Baker. June 1995. + (Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated by + RFC2644) (Status: PROPOSED STANDARD) + +1813 NFS Version 3 Protocol Specification. B. Callaghan, B. Pawlowski, + P. Staubach. June 1995. (Format: TXT=229793 bytes) (Obsoleted by + RFC3010) (Also RFC1094) (Status: INFORMATIONAL) + +1814 Unique Addresses are Good. E. Gerich. June 1995. (Format: + TXT=5936 bytes) (Status: INFORMATIONAL) + +1815 Character Sets ISO-10646 and ISO-10646-J-1. M. Ohta. July 1995. + (Format: TXT=11823 bytes) (Status: INFORMATIONAL) + +1816 U.S. Government Internet Domain Names. Federal Networking + Council. August 1995. (Format: TXT=17979 bytes) (Obsoletes RFC1811) + (Obsoleted by RFC2146) (Status: INFORMATIONAL) + +1817 CIDR and Classful Routing. Y. Rekhter. August 1995. (Format: + TXT=3416 bytes) (Status: INFORMATIONAL) + +1818 Best Current Practices. J. Postel, T. Li, Y. Rekhter. August + 1995. (Format: TXT=4114 bytes) (Also BCP0001) (Status: BEST CURRENT + PRACTICE) + +1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - + Version ST2+. L. Delgrossi, L. Berger, Editors. August 1995. (Format: + TXT=266875 bytes) (Obsoletes RFC1190, IEN 119) (Status: EXPERIMENTAL) + +1820 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August + 1995. (Format: TXT=14672 bytes) (Obsoleted by RFC1844) (Status: + INFORMATIONAL) + +1821 Integration of Real-time Services in an IP-ATM Network + Architecture. M. Borden, E. Crawley, B. Davie, S. Batsell. August + 1995. (Format: TXT=64466 bytes) (Status: INFORMATIONAL) + +1822 A Grant of Rights to Use a Specific IBM patent with Photuris. J. + Lowe. August 1995. (Format: TXT=2664 bytes) (Status: INFORMATIONAL) + +1823 The LDAP Application Program Interface. T. Howes, M. Smith. + August 1995. (Format: TXT=41081 bytes) (Status: INFORMATIONAL) + +1824 The Exponential Security System TESS: An Identity-Based + Cryptographic Protocol for Authenticated Key-Exchange + (E.I.S.S.-Report 1995/4). H. Danisch. August 1995. (Format: TXT=45540 + bytes) (Status: INFORMATIONAL) + +1825 Security Architecture for the Internet Protocol. R. Atkinson. + August 1995. (Format: TXT=56772 bytes) (Obsoleted by RFC2401) + (Status: PROPOSED STANDARD) + +1826 IP Authentication Header. R. Atkinson. August 1995. (Format: + TXT=27583 bytes) (Obsoleted by RFC2402) (Status: PROPOSED STANDARD) + +1827 IP Encapsulating Security Payload (ESP). R. Atkinson. August + 1995. (Format: TXT=30278 bytes) (Obsoleted by RFC2406) (Status: + PROPOSED STANDARD) + +1828 IP Authentication using Keyed MD5. P. Metzger, W. Simpson. August + 1995. (Format: TXT=9800 bytes) (Status: PROPOSED STANDARD) + +1829 The ESP DES-CBC Transform. P. Karn, P. Metzger, W. Simpson. + August 1995. (Format: TXT=19291 bytes) (Status: PROPOSED STANDARD) + +1830 SMTP Service Extensions for Transmission of Large and Binary MIME + Messages. G. Vaudreuil. August 1995. (Format: TXT=16555 bytes) + (Obsoleted by RFC3030) (Status: EXPERIMENTAL) + +1831 RPC: Remote Procedure Call Protocol Specification Version 2. R. + Srinivasan. August 1995. (Format: TXT=37798 bytes) (Status: PROPOSED + STANDARD) + +1832 XDR: External Data Representation Standard. R. Srinivasan. August + 1995. (Format: TXT=47418 bytes) (Status: DRAFT STANDARD) + +1833 Binding Protocols for ONC RPC Version 2. R. Srinivasan. August + 1995. (Format: TXT=24449 bytes) (Status: PROPOSED STANDARD) + +1834 Whois and Network Information Lookup Service, Whois++. J. + Gargano, K. Weiss. August 1995. (Format: TXT=14429 bytes) (Status: + INFORMATIONAL) + +1835 Architecture of the WHOIS++ service. P. Deutsch, R. Schoultz, P. + Faltstrom, C. Weider. August 1995. (Format: TXT=80581 bytes) (Status: + PROPOSED STANDARD) + +1836 Representing the O/R Address hierarchy in the X.500 Directory + Information Tree. S. Kille. August 1995. (Format: TXT=20175 bytes) + (Obsoleted by RFC2294) (Status: EXPERIMENTAL) + +1837 Representing Tables and Subtrees in the X.500 Directory. S. + Kille. August 1995. (Format: TXT=10924 bytes) (Obsoleted by RFC2293) + (Status: EXPERIMENTAL) + +1838 Use of the X.500 Directory to support mapping between X.400 and + RFC 822 Addresses. S. Kille. August 1995. (Format: TXT=12216 bytes) + (Obsoleted by RFC2164) (Status: EXPERIMENTAL) + +1841 PPP Network Control Protocol for LAN Extension. J. Chapman, D. + Coli, A. Harvey, B. Jensen, K. Rowett. September 1995. (Format: + TXT=146206 bytes) (Status: INFORMATIONAL) + +1842 ASCII Printable Characters-Based Chinese Character Encoding for + Internet Messages. Y. Wei, Y. Zhang, J. Li, J. Ding, Y. Jiang. August + 1995. (Format: TXT=24143 bytes) (Status: INFORMATIONAL) + +1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed + Chinese and ASCII characters. F. Lee. August 1995. (Format: TXT=8787 + bytes) (Status: INFORMATIONAL) + +1844 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August + 1995. (Format: TXT=15072 bytes) (Obsoletes RFC1820) (Status: + INFORMATIONAL) + +1845 SMTP Service Extension for Checkpoint/Restart. D. Crocker, N. + Freed, A. Cargille. September 1995. (Format: TXT=15399 bytes) + (Status: EXPERIMENTAL) + +1846 SMTP 521 Reply Code. A. Durand, F. Dupont. September 1995. + (Format: TXT=6558 bytes) (Status: EXPERIMENTAL) + +1847 Security Multiparts for MIME: Multipart/Signed and + Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker, N. Freed. + October 1995. (Format: TXT=23679 bytes) (Status: PROPOSED STANDARD) + +1848 MIME Object Security Services. S. Crocker, N. Freed, J. Galvin, + S. Murphy. October 1995. (Format: TXT=95010 bytes) (Status: PROPOSED + STANDARD) + +1850 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. + November 1995. (Format: TXT=140255 bytes) (Obsoletes RFC1253) + (Status: DRAFT STANDARD) + +1851 The ESP Triple DES Transform. P. Karn, P. Metzger, W. Simpson. + September 1995. (Format: TXT=20000 bytes) (Status: EXPERIMENTAL) + +1852 IP Authentication using Keyed SHA. P. Metzger, W. Simpson. + September 1995. (Format: TXT=9367 bytes) (Obsoleted by RFC2841) + (Status: EXPERIMENTAL) + +1853 IP in IP Tunneling. W. Simpson. October 1995. (Format: TXT=14803 + bytes) (Status: INFORMATIONAL) + +1854 SMTP Service Extension for Command Pipelining. N. Freed. October + 1995. (Format: TXT=14097 bytes) (Obsoleted by RFC2197) (Status: + PROPOSED STANDARD) + +1855 Netiquette Guidelines. S. Hambridge. October 1995. (Format: + TXT=46185 bytes) (Also FYI0028) (Status: INFORMATIONAL) + +1856 The Opstat Client-Server Model for Statistics Retrieval. H. + Clark. September 1995. (Format: TXT=29954 bytes) (Status: + INFORMATIONAL) + +1857 A Model for Common Operational Statistics. M. Lambert. October + 1995. (Format: TXT=55314 bytes) (Obsoletes RFC1404) (Status: + INFORMATIONAL) + +1858 Security Considerations for IP Fragment Filtering. G. Ziemba, D. + Reed, P. Traina. October 1995. (Format: TXT=20468 bytes) (Status: + INFORMATIONAL) + +1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP + RFC1006 extension. Y. Pouffary. October 1995. (Format: TXT=14572 + bytes) (Status: INFORMATIONAL) + +1860 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. + October 1995. (Format: TXT=5694 bytes) (Obsoleted by RFC1878) + (Status: INFORMATIONAL) + +1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced. A. + Gwinn. October 1995. (Format: TXT=49181 bytes) (Obsoletes RFC1645) + (Status: INFORMATIONAL) + +1862 Report of the IAB Workshop on Internet Information + Infrastructure, October 12-14, 1994. M. McCahill, J. Romkey, M. + Schwartz, K. Sollins, T. Verschuren, C. Weider. November 1995. + (Format: TXT=62483 bytes) (Status: INFORMATIONAL) + +1863 A BGP/IDRP Route Server alternative to a full mesh routing. D. + Haskin. October 1995. (Format: TXT=37426 bytes) (Status: + EXPERIMENTAL) + +1864 The Content-MD5 Header Field. J. Myers, M. Rose. October 1995. + (Format: TXT=7216 bytes) (Obsoletes RFC1544) (Status: DRAFT STANDARD) + +1865 EDI Meets the Internet Frequently Asked Questions about + Electronic Data Interchange (EDI) on the Internet. W. Houser, J. + Griffin, C. Hage. January 1996. (Format: TXT=98361 bytes) (Status: + INFORMATIONAL) + +1866 Hypertext Markup Language - 2.0. T. Berners-Lee, D. Connolly. + November 1995. (Format: TXT=146904 bytes) (Obsoleted by RFC2854) + (Status: HISTORIC) + +1867 Form-based File Upload in HTML. E. Nebel, L. Masinter. November + 1995. (Format: TXT=26183 bytes) (Obsoleted by RFC2854) (Status: + HISTORIC) + +1868 ARP Extension - UNARP. G. Malkin. November 1995. (Format: + TXT=7681 bytes) (Status: EXPERIMENTAL) + +1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. + Stefferud, D. Crocker. November 1995. (Format: TXT=23299 bytes) + (Obsoletes RFC1651) (Obsoleted by RFC2821) (Also STD0010) (Status: + STANDARD) + +1870 SMTP Service Extension for Message Size Declaration. J. Klensin, + N. Freed, K. Moore. November 1995. (Format: TXT=18226 bytes) + (Obsoletes RFC1653) (Also STD0010) (Status: STANDARD) + +1871 Addendum to RFC 1602 -- Variance Procedure. J. Postel. November + 1995. (Format: TXT=7747 bytes) (Updates RFC1602, RFC1603) (Also + BCP0002) (Status: BEST CURRENT PRACTICE) + +1872 The MIME Multipart/Related Content-type. E. Levinson. December + 1995. (Format: TXT=15565 bytes) (Obsoleted by RFC2112) (Status: + EXPERIMENTAL) + +1873 Message/External-Body Content-ID Access Type. E. Levinson. + December 1995. (Format: TXT=5878 bytes) (Status: EXPERIMENTAL) + +1874 SGML Media Types. E. Levinson. December 1995. (Format: TXT=12515 + bytes) (Status: EXPERIMENTAL) + +1875 UNINETT PCA Policy Statements. N. Berge. December 1995. (Format: + TXT=19089 bytes) (Status: INFORMATIONAL) + +1876 A Means for Expressing Location Information in the Domain Name + System. C. Davis, P. Vixie, T. Goodwin, I. Dickinson. January 1996. + (Format: TXT=29631 bytes) (Updates RFC1034, RFC1035) (Status: + EXPERIMENTAL) + +1877 PPP Internet Protocol Control Protocol Extensions for Name Server + Addresses. S. Cobb. December 1995. (Format: TXT=10591 bytes) (Status: + INFORMATIONAL) + +1878 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. + December 1995. (Format: TXT=19414 bytes) (Obsoletes RFC1860) (Status: + INFORMATIONAL) + +1879 Class A Subnet Experiment Results and Recommendations. B. + Manning. January 1996. (Format: TXT=10589 bytes) (Status: + INFORMATIONAL) + +1880 Internet Official Protocol Standards. J. Postel, Editor. November + 1995. (Format: TXT=89153 bytes) (Obsoletes RFC1800) (Obsoleted by + RFC1920) (Status: HISTORIC) + +1881 IPv6 Address Allocation Management. IAB, IESG. December 1995. + (Format: TXT=3215 bytes) (Status: INFORMATIONAL) + +1882 The 12-Days of Technology Before Christmas. B. Hancock. December + 1995. (Format: TXT=9130 bytes) (Status: INFORMATIONAL) + +1883 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. + Hinden. December 1995. (Format: TXT=82089 bytes) (Obsoleted by + RFC2460) (Status: PROPOSED STANDARD) + +1884 IP Version 6 Addressing Architecture. R. Hinden, S. Deering, + Editors. December 1995. (Format: TXT=37860 bytes) (Obsoleted by + RFC2373) (Status: HISTORIC) + +1885 Internet Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6). A. Conta, S. Deering. December 1995. + (Format: TXT=32214 bytes) (Obsoleted by RFC2463) (Status: PROPOSED + STANDARD) + +1886 DNS Extensions to support IP version 6. S. Thomson, C. Huitema. + December 1995. (Format: TXT=6424 bytes) (Updated by RFC3152) (Status: + PROPOSED STANDARD) + +1887 An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter, + T. Li, Editors. December 1995. (Format: TXT=66066 bytes) (Status: + INFORMATIONAL) + +1888 OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J. + Houldsworth, A. Lloyd. August 1996. (Format: TXT=36469 bytes) + (Status: EXPERIMENTAL) + +1889 RTP: A Transport Protocol for Real-Time Applications. Audio-Video + Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. + Jacobson. January 1996. (Format: TXT=188544 bytes) (Status: PROPOSED + STANDARD) + +1890 RTP Profile for Audio and Video Conferences with Minimal Control. + Audio-Video Transport Working Group, H. Schulzrinne. January 1996. + (Format: TXT=37509 bytes) (Status: PROPOSED STANDARD) + +1891 SMTP Service Extension for Delivery Status Notifications. K. + Moore. January 1996. (Format: TXT=65192 bytes) (Status: PROPOSED + STANDARD) + +1892 The Multipart/Report Content Type for the Reporting of Mail + System Administrative Messages. G. Vaudreuil. January 1996. (Format: + TXT=7800 bytes) (Status: PROPOSED STANDARD) + +1893 Enhanced Mail System Status Codes. G. Vaudreuil. January 1996. + (Format: TXT=28218 bytes) (Status: PROPOSED STANDARD) + +1894 An Extensible Message Format for Delivery Status Notifications. + K. Moore, G. Vaudreuil. January 1996. (Format: TXT=77462 bytes) + (Updated by RFC2852) (Status: PROPOSED STANDARD) + +1895 The Application/CALS-1840 Content-type. E. Levinson. February + 1996. (Format: TXT=10576 bytes) (Status: INFORMATIONAL) + +1896 The text/enriched MIME Content-type. P. Resnick, A. Walker. + February 1996. (Format: TXT=45926, PS=81217 bytes) (Obsoletes + RFC1523, RFC1563) (Status: INFORMATIONAL) + +1897 IPv6 Testing Address Allocation. R. Hinden, J. Postel. January + 1996. (Format: TXT=6643 bytes) (Obsoleted by RFC2471) (Status: + EXPERIMENTAL) + +1898 CyberCash Credit Card Protocol Version 0.8. D. Eastlake, B. + Boesch, S. Crocker, M. Yesil. February 1996. (Format: TXT=113633 + bytes) (Status: INFORMATIONAL) + +1899 Request for Comments Summary RFC Numbers 1800-1899. J. Elliott. + January 1997. (Format: TXT=37984 bytes) (Status: INFORMATIONAL) + +1900 Renumbering Needs Work. B. Carpenter, Y. Rekhter. February 1996. + (Format: TXT=9528 bytes) (Status: INFORMATIONAL) + +1901 Introduction to Community-based SNMPv2. SNMPv2 Working Group, J. + Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: + TXT=15903 bytes) (Status: EXPERIMENTAL) + +1902 Structure of Management Information for Version 2 of the Simple + Network Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case, + K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: + TXT=77453 bytes) (Obsoletes RFC1442) (Obsoleted by RFC2578) (Status: + DRAFT STANDARD) + +1903 Textual Conventions for Version 2 of the Simple Network + Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K. + McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=52652 + bytes) (Obsoletes RFC1443) (Obsoleted by RFC2579) (Status: DRAFT + STANDARD) + +1904 Conformance Statements for Version 2 of the Simple Network + Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K. + McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=47083 + bytes) (Obsoletes RFC1444) (Obsoleted by RFC2580) (Status: DRAFT + STANDARD) + +1905 Protocol Operations for Version 2 of the Simple Network + Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K. + McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=55526 + bytes) (Obsoletes RFC1448) (Status: DRAFT STANDARD) + +1906 Transport Mappings for Version 2 of the Simple Network Management + Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K. McCloghrie, M. + Rose, S. Waldbusser. January 1996. (Format: TXT=27465 bytes) + (Obsoletes RFC1449) (Status: DRAFT STANDARD) + +1907 Management Information Base for Version 2 of the Simple Network + Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K. + McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=34881 + bytes) (Obsoletes RFC1450) (Status: DRAFT STANDARD) + +1908 Coexistence between Version 1 and Version 2 of the + Internet-standard Network Management Framework. SNMPv2 Working Group, + J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. + (Format: TXT=21463 bytes) (Obsoletes RFC1452) (Obsoleted by RFC2576) + (Status: DRAFT STANDARD) + +1909 An Administrative Infrastructure for SNMPv2. K. McCloghrie. + February 1996. (Format: TXT=45773 bytes) (Status: EXPERIMENTAL) + +1910 User-based Security Model for SNMPv2. G. Waters. February 1996. + (Format: TXT=98252 bytes) (Status: EXPERIMENTAL) + +1911 Voice Profile for Internet Mail. G. Vaudreuil. February 1996. + (Format: TXT=50242 bytes) (Obsoleted by RFC2421, RFC2422, RFC2423) + (Status: EXPERIMENTAL) + +1912 Common DNS Operational and Configuration Errors. D. Barr. + February 1996. (Format: TXT=38252 bytes) (Obsoletes RFC1537) (Status: + INFORMATIONAL) + +1913 Architecture of the Whois++ Index Service. C. Weider, J. Fullton, + S. Spero. February 1996. (Format: TXT=33743 bytes) (Status: PROPOSED + STANDARD) + +1914 How to Interact with a Whois++ Mesh. P. Faltstrom, R. Schoultz, + C. Weider. February 1996. (Format: TXT=17842 bytes) (Status: PROPOSED + STANDARD) + +1915 Variance for The PPP Connection Control Protocol and The PPP + Encryption Control Protocol. F. Kastenholz. February 1996. (Format: + TXT=14347 bytes) (Also BCP0003) (Status: BEST CURRENT PRACTICE) + +1916 Enterprise Renumbering: Experience and Information Solicitation. + H. Berkowitz, P. Ferguson, W. Leland, P. Nesser. February 1996. + (Format: TXT=16117 bytes) (Status: INFORMATIONAL) + +1917 An Appeal to the Internet Community to Return Unused IP Networks + (Prefixes) to the IANA. P. Nesser II. February 1996. (Format: + TXT=23623 bytes) (Also BCP0004) (Status: BEST CURRENT PRACTICE) + +1918 Address Allocation for Private Internets. Y. Rekhter, B. + Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. + (Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) + (Status: BEST CURRENT PRACTICE) + +1919 Classical versus Transparent IP Proxies. M. Chatel. March 1996. + (Format: TXT=87374 bytes) (Status: INFORMATIONAL) + +1920 Internet Official Protocol Standards. J. Postel. March 1996. + (Format: TXT=91936 bytes) (Obsoletes RFC1880) (Obsoleted by RFC2000) + (Status: HISTORIC) + +1921 TNVIP Protocol. J. Dujonc. March 1996. (Format: TXT=57475 bytes) + (Status: INFORMATIONAL) + +1922 Chinese Character Encoding for Internet Messages. HF. Zhu, DY. + Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin. March 1996. (Format: + TXT=50995 bytes) (Status: INFORMATIONAL) + +1923 RIPv1 Applicability Statement for Historic Status. J. Halpern, S. + Bradner. March 1996. (Format: TXT=5560 bytes) (Status: INFORMATIONAL) + +1924 A Compact Representation of IPv6 Addresses. R. Elz. Apr-01-1996. + (Format: TXT=10409 bytes) (Status: INFORMATIONAL) + +1925 The Twelve Networking Truths. R. Callon. Apr-01-1996. (Format: + TXT=4294 bytes) (Status: INFORMATIONAL) + +1926 An Experimental Encapsulation of IP Datagrams on Top of ATM. J. + Eriksson. Apr-01-1996. (Format: TXT=2969 bytes) (Status: + INFORMATIONAL) + +1927 Suggested Additional MIME Types for Associating Documents. C. + Rogers. Apr-01-1996. (Format: TXT=5254 bytes) (Status: INFORMATIONAL) + +1928 SOCKS Protocol Version 5. M. Leech, M. Ganis, Y. Lee, R. Kuris, + D. Koblas, L. Jones. March 1996. (Format: TXT=19741 bytes) (Status: + PROPOSED STANDARD) + +1929 Username/Password Authentication for SOCKS V5. M. Leech. March + 1996. (Format: TXT=3568 bytes) (Status: PROPOSED STANDARD) + +1930 Guidelines for creation, selection, and registration of an + Autonomous System (AS). J. Hawkinson, T. Bates. March 1996. (Format: + TXT=22073 bytes) (Also BCP0006) (Status: BEST CURRENT PRACTICE) + +1931 Dynamic RARP Extensions for Automatic Network Address + Acquisition. D. Brownell. April 1996. (Format: TXT=27544 bytes) + (Status: INFORMATIONAL) + +1932 IP over ATM: A Framework Document. R. Cole, D. Shur,, C. + Villamizar. April 1996. (Format: TXT=68031 bytes) (Status: + INFORMATIONAL) + +1933 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. + Nordmark. April 1996. (Format: TXT=47005 bytes) (Obsoleted by + RFC2893) (Status: PROPOSED STANDARD) + +1934 Ascend's Multilink Protocol Plus (MP+). K. Smith. April 1996. + (Format: TXT=87072 bytes) (Status: INFORMATIONAL) + +1935 What is the Internet, Anyway?. J. Quarterman, S. Carl-Mitchell. + April 1996. (Format: TXT=30369 bytes) (Status: INFORMATIONAL) + +1936 Implementing the Internet Checksum in Hardware. J. Touch, B. + Parham. April 1996. (Format: TXT=36618 bytes) (Status: INFORMATIONAL) + +1937 "Local/Remote" Forwarding Decision in Switched Data Link + Subnetworks. Y. Rekhter, D. Kandlur. May 1996. (Format: TXT=18302 + bytes) (Status: INFORMATIONAL) + +1938 A One-Time Password System. N. Haller, C. Metz. May 1996. + (Format: TXT=44844 bytes) (Obsoleted by RFC2289) (Status: PROPOSED + STANDARD) + +1939 Post Office Protocol - Version 3. J. Myers, M. Rose. May 1996. + (Format: TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957, + RFC2449) (Also STD0053) (Status: STANDARD) + +1940 Source Demand Routing: Packet Format and Forwarding Specification + (Version 1). D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala. + May 1996. (Format: TXT=60858 bytes) (Status: INFORMATIONAL) + +1941 Frequently Asked Questions for Schools. J. Sellers, J. Robichaux. + May 1996. (Format: TXT=150980 bytes) (Obsoletes RFC1578) (Also + FYI0022) (Status: INFORMATIONAL) + +1942 HTML Tables. D. Raggett. May 1996. (Format: TXT=68705 bytes) + (Obsoleted by RFC2854) (Status: HISTORIC) + +1943 Building an X.500 Directory Service in the US. B. Jennings. May + 1996. (Format: TXT=51266 bytes) (Status: INFORMATIONAL) + +1944 Benchmarking Methodology for Network Interconnect Devices. S. + Bradner, J. McQuaid. May 1996. (Format: TXT=66061 bytes) (Obsoleted + by RFC2544) (Status: INFORMATIONAL) + +1945 Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. + Fielding, H. Frystyk. May 1996. (Format: TXT=137582 bytes) (Status: + INFORMATIONAL) + +1946 Native ATM Support for ST2+. S. Jackowski. May 1996. (Format: + TXT=50430 bytes) (Status: INFORMATIONAL) + +1947 Greek Character Encoding for Electronic Mail Messages. D. + Spinellis. May 1996. (Format: TXT=14428 bytes) (Status: + INFORMATIONAL) + +1948 Defending Against Sequence Number Attacks. S. Bellovin. May 1996. + (Format: TXT=13074 bytes) (Status: INFORMATIONAL) + +1949 Scalable Multicast Key Distribution. A. Ballardie. May 1996. + (Format: TXT=41853 bytes) (Status: EXPERIMENTAL) + +1950 ZLIB Compressed Data Format Specification version 3.3. P. + Deutsch, J-L. Gailly. May 1996. (Format: TXT=20502, PS=37768, + PDF=36393 bytes) (Status: INFORMATIONAL) + +1951 DEFLATE Compressed Data Format Specification version 1.3. P. + Deutsch. May 1996. (Format: TXT=36944, PS=57408, PDF=56620 bytes) + (Status: INFORMATIONAL) + +1952 GZIP file format specification version 4.3. P. Deutsch. May 1996. + (Format: TXT=25036, PS=43337, PDF=43211 bytes) (Status: + INFORMATIONAL) + +1953 Ipsilon Flow Management Protocol Specification for IPv4 Version + 1.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. + Lyon, G. Minshall. May 1996. (Format: TXT=43749 bytes) (Status: + INFORMATIONAL) + +1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon + Version 1.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching + Liaw, T. Lyon, G. Minshall. May 1996. (Format: TXT=16075 bytes) + (Status: INFORMATIONAL) + +1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG. + R. Hinden. June 1996. (Format: TXT=10115 bytes) (Status: + INFORMATIONAL) + +1956 Registration in the MIL Domain. D. Engebretson, R. Plzak. June + 1996. (Format: TXT=2923 bytes) (Status: INFORMATIONAL) + +1957 Some Observations on Implementations of the Post Office Protocol + (POP3). R. Nelson. June 1996. (Format: TXT=2325 bytes) (Updates + RFC1939) (Status: INFORMATIONAL) + +1958 Architectural Principles of the Internet. B. Carpenter. June + 1996. (Format: TXT=17345 bytes) (Status: INFORMATIONAL) + +1959 An LDAP URL Format. T. Howes, M. Smith. June 1996. (Format: + TXT=7243 bytes) (Obsoleted by RFC2255) (Status: PROPOSED STANDARD) + +1960 A String Representation of LDAP Search Filters. T. Howes. June + 1996. (Format: TXT=5288 bytes) (Obsoletes RFC1558) (Obsoleted by + RFC2254) (Status: PROPOSED STANDARD) + +1961 GSS-API Authentication Method for SOCKS Version 5. P. McMahon. + June 1996. (Format: TXT=16036 bytes) (Status: PROPOSED STANDARD) + +1962 The PPP Compression Control Protocol (CCP). D. Rand. June 1996. + (Format: TXT=18005 bytes) (Updated by RFC2153) (Status: PROPOSED + STANDARD) + +1963 PPP Serial Data Transport Protocol (SDTP). K. Schneider, S. + Venters. August 1996. (Format: TXT=38185 bytes) (Status: + INFORMATIONAL) + +1964 The Kerberos Version 5 GSS-API Mechanism. J. Linn. June 1996. + (Format: TXT=47413 bytes) (Status: PROPOSED STANDARD) + +1965 Autonomous System Confederations for BGP. P. Traina. June 1996. + (Format: TXT=13575 bytes) (Obsoleted by RFC3065) (Status: + EXPERIMENTAL) + +1966 BGP Route Reflection An alternative to full mesh IBGP. T. Bates, + R. Chandrasekeran. June 1996. (Format: TXT=14320 bytes) (Updated by + RFC2796) (Status: EXPERIMENTAL) + +1967 PPP LZS-DCP Compression Protocol (LZS-DCP). K. Schneider, R. + Friend. August 1996. (Format: TXT=40039 bytes) (Status: + INFORMATIONAL) + +1968 The PPP Encryption Control Protocol (ECP). G. Meyer. June 1996. + (Format: TXT=20781 bytes) (Status: PROPOSED STANDARD) + +1969 The PPP DES Encryption Protocol (DESE). K. Sklower, G. Meyer. + June 1996. (Format: TXT=20383 bytes) (Obsoleted by RFC2419) (Status: + INFORMATIONAL) + +1970 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. + Nordmark, W. Simpson. August 1996. (Format: TXT=197632 bytes) + (Obsoleted by RFC2461) (Status: PROPOSED STANDARD) + +1971 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. + August 1996. (Format: TXT=56890 bytes) (Obsoleted by RFC2462) + (Status: PROPOSED STANDARD) + +1972 A Method for the Transmission of IPv6 Packets over Ethernet + Networks. M. Crawford. August 1996. (Format: TXT=6353 bytes) + (Obsoleted by RFC2464) (Status: PROPOSED STANDARD) + +1973 PPP in Frame Relay. W. Simpson. June 1996. (Format: TXT=14780 + bytes) (Status: PROPOSED STANDARD) + +1974 PPP Stac LZS Compression Protocol. R. Friend, W. Simpson. August + 1996. (Format: TXT=45267 bytes) (Status: INFORMATIONAL) + +1975 PPP Magnalink Variable Resource Compression. D. Schremp, J. + Black, J. Weiss. August 1996. (Format: TXT=8655 bytes) (Status: + INFORMATIONAL) + +1976 PPP for Data Compression in Data Circuit-Terminating Equipment + (DCE). K. Schneider, S. Venters. August 1996. (Format: TXT=19781 + bytes) (Status: INFORMATIONAL) + +1977 PPP BSD Compression Protocol. V. Schryver. August 1996. (Format: + TXT=50747 bytes) (Status: INFORMATIONAL) + +1978 PPP Predictor Compression Protocol. D. Rand. August 1996. + (Format: TXT=17424 bytes) (Status: INFORMATIONAL) + +1979 PPP Deflate Protocol. J. Woods. August 1996. (Format: TXT=18803 + bytes) (Status: INFORMATIONAL) + +1980 A Proposed Extension to HTML : Client-Side Image Maps. J. + Seidman. August 1996. (Format: TXT=13448 bytes) (Obsoleted by + RFC2854) (Status: HISTORIC) + +1981 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. + Mogul. August 1996. (Format: TXT=34088 bytes) (Status: PROPOSED + STANDARD) + +1982 Serial Number Arithmetic. R. Elz, R. Bush. August 1996. (Format: + TXT=14440 bytes) (Updates RFC1034, RFC1035) (Status: PROPOSED + STANDARD) + +1983 Internet Users' Glossary. G. Malkin. August 1996. (Format: + TXT=123008 bytes) (Obsoletes RFC1392) (Also FYI0018) (Status: + INFORMATIONAL) + +1984 IAB and IESG Statement on Cryptographic Technology and the + Internet. IAB, IESG. August 1996. (Format: TXT=10738 bytes) (Status: + INFORMATIONAL) + +1985 SMTP Service Extension for Remote Message Queue Starting. J. De + Winter. August 1996. (Format: TXT=14815 bytes) (Status: PROPOSED + STANDARD) + +1986 Experiments with a Simple File Transfer Protocol for Radio Links + using Enhanced Trivial File Transfer Protocol (ETFTP). W. Polites, W. + Wollman, D. Woo, R. Langan. August 1996. (Format: TXT=49772 bytes) + (Status: EXPERIMENTAL) + +1987 Ipsilon's General Switch Management Protocol Specification + Version 1.1. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching + Liaw, T. Lyon, G. Minshall. August 1996. (Format: TXT=105821 bytes) + (Updated by RFC2297) (Status: INFORMATIONAL) + +1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents + In Conjunction With the Internet Engineering Task Force's + Internet-Standard Network Management Framework. G. McAnally, D. + Gilbert, J. Flick. August 1996. (Format: TXT=3821 bytes) (Status: + INFORMATIONAL) + +1989 PPP Link Quality Monitoring. W. Simpson. August 1996. (Format: + TXT=29289 bytes) (Obsoletes RFC1333) (Status: DRAFT STANDARD) + +1990 The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. + McGregor, D. Carr, T. Coradetti. August 1996. (Format: TXT=53271 + bytes) (Obsoletes RFC1717) (Status: DRAFT STANDARD) + +1991 PGP Message Exchange Formats. D. Atkins, W. Stallings, P. + Zimmermann. August 1996. (Format: TXT=46255 bytes) (Status: + INFORMATIONAL) + +1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M. + Steenstrup. August 1996. (Format: TXT=59848 bytes) (Status: + INFORMATIONAL) + +1993 PPP Gandalf FZA Compression Protocol. A. Barbir, D. Carr, W. + Simpson. August 1996. (Format: TXT=9811 bytes) (Status: + INFORMATIONAL) + +1994 PPP Challenge Handshake Authentication Protocol (CHAP). W. + Simpson. August 1996. (Format: TXT=24094 bytes) (Obsoletes RFC1334) + (Updated by RFC2484) (Status: DRAFT STANDARD) + +1995 Incremental Zone Transfer in DNS. M. Ohta. August 1996. (Format: + TXT=16810 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD) + +1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). + P. Vixie. August 1996. (Format: TXT=15247 bytes) (Updates RFC1035) + (Status: PROPOSED STANDARD) + +1997 BGP Communities Attribute. R. Chandra, P. Traina, T. Li. August + 1996. (Format: TXT=8275 bytes) (Status: PROPOSED STANDARD) + +1998 An Application of the BGP Community Attribute in Multi-home + Routing. E. Chen, T. Bates. August 1996. (Format: TXT=16953 bytes) + (Status: INFORMATIONAL) + +1999 Request for Comments Summary RFC Numbers 1900-1999. J. Elliott. + January 1997. (Format: TXT=39819 bytes) (Status: INFORMATIONAL) + +2000 Internet Official Protocol Standards. J. Postel, Editor. February + 1997. (Format: TXT=121356 bytes) (Obsoletes RFC1920) (Obsoleted by + RFC2200) (Status: HISTORIC) + +2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast + Recovery Algorithms. W. Stevens. January 1997. (Format: TXT=12981 + bytes) (Obsoleted by RFC2581) (Status: PROPOSED STANDARD) + +2002 IP Mobility Support. C. Perkins. October 1996. (Format: + TXT=193103 bytes) (Updated by RFC2290) (Status: PROPOSED STANDARD) + +2003 IP Encapsulation within IP. C. Perkins. October 1996. (Format: + TXT=30291 bytes) (Status: PROPOSED STANDARD) + +2004 Minimal Encapsulation within IP. C. Perkins. October 1996. + (Format: TXT=12202 bytes) (Status: PROPOSED STANDARD) + +2005 Applicability Statement for IP Mobility Support. J. Solomon. + October 1996. (Format: TXT=10509 bytes) (Status: PROPOSED STANDARD) + +2006 The Definitions of Managed Objects for IP Mobility Support using + SMIv2. D. Cong, M. Hamlen, C. Perkins. October 1996. (Format: + TXT=95030 bytes) (Status: PROPOSED STANDARD) + +2007 Catalogue of Network Training Materials. J. Foster, M. Isaacs, M. + Prior. October 1996. (Format: TXT=78941 bytes) (Also FYI0029) + (Status: INFORMATIONAL) + +2008 Implications of Various Address Allocation Policies for Internet + Routing. Y. Rekhter, T. Li. October 1996. (Format: TXT=34717 bytes) + (Also BCP0007) (Status: BEST CURRENT PRACTICE) + +2009 GPS-Based Addressing and Routing. T. Imielinski, J. Navas. + November 1996. (Format: TXT=66229 bytes) (Status: EXPERIMENTAL) + +2010 Operational Criteria for Root Name Servers. B. Manning, P. Vixie. + October 1996. (Format: TXT=14870 bytes) (Obsoleted by RFC2870) + (Status: INFORMATIONAL) + +2011 SNMPv2 Management Information Base for the Internet Protocol + using SMIv2. K. McCloghrie. November 1996. (Format: TXT=31168 bytes) + (Updates RFC1213) (Status: PROPOSED STANDARD) + +2012 SNMPv2 Management Information Base for the Transmission Control + Protocol using SMIv2. K. McCloghrie. November 1996. (Format: + TXT=16792 bytes) (Updates RFC1213) (Status: PROPOSED STANDARD) + +2013 SNMPv2 Management Information Base for the User Datagram Protocol + using SMIv2. K. McCloghrie. November 1996. (Format: TXT=9333 bytes) + (Updates RFC1213) (Status: PROPOSED STANDARD) + +2014 IRTF Research Group Guidelines and Procedures. A. Weinrib, J. + Postel. October 1996. (Format: TXT=27507 bytes) (Also BCP0008) + (Status: BEST CURRENT PRACTICE) + +2015 MIME Security with Pretty Good Privacy (PGP). M. Elkins. October + 1996. (Format: TXT=14223 bytes) (Updated by RFC3156) (Status: + PROPOSED STANDARD) + +2016 Uniform Resource Agents (URAs). L. Daigle, P. Deutsch, B. Heelan, + C. Alpaugh, M. Maclachlan. October 1996. (Format: TXT=38355 bytes) + (Status: EXPERIMENTAL) + +2017 Definition of the URL MIME External-Body Access-Type. N. Freed, + K. Moore, A. Cargille. October 1996. (Format: TXT=9000 bytes) + (Status: PROPOSED STANDARD) + +2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. + Floyd, A. Romanow. October 1996. (Format: TXT=25671 bytes) (Obsoletes + RFC1072) (Status: PROPOSED STANDARD) + +2019 Transmission of IPv6 Packets Over FDDI. M. Crawford. October + 1996. (Format: TXT=12344 bytes) (Obsoleted by RFC2467) (Status: + PROPOSED STANDARD) + +2020 IEEE 802.12 Interface MIB. J. Flick. October 1996. (Format: + TXT=72135 bytes) (Status: PROPOSED STANDARD) + +2021 Remote Network Monitoring Management Information Base Version 2 + using SMIv2. S. Waldbusser. January 1997. (Format: TXT=262223 bytes) + (Status: PROPOSED STANDARD) + +2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks. G. + Armitage. November 1996. (Format: TXT=189219 bytes) (Status: PROPOSED + STANDARD) + +2023 IP Version 6 over PPP. D. Haskin, E. Allen. October 1996. + (Format: TXT=20275 bytes) (Obsoleted by RFC2472) (Status: PROPOSED + STANDARD) + +2024 Definitions of Managed Objects for Data Link Switching using + SMIv2. D. Chen, P. Gayek, S. Nix. October 1996. (Format: TXT=173952 + bytes) (Status: PROPOSED STANDARD) + +2025 The Simple Public-Key GSS-API Mechanism (SPKM). C. Adams. October + 1996. (Format: TXT=101692 bytes) (Status: PROPOSED STANDARD) + +2026 The Internet Standards Process -- Revision 3. S. Bradner. October + 1996. (Format: TXT=86731 bytes) (Obsoletes RFC1602) (Also BCP0009) + (Status: BEST CURRENT PRACTICE) + +2027 IAB and IESG Selection, Confirmation, and Recall Process: + Operation of the Nominating and Recall Committees. J. Galvin. October + 1996. (Format: TXT=24207 bytes) (Obsoleted by RFC2282) (Status: + INFORMATIONAL) + +2028 The Organizations Involved in the IETF Standards Process. R. + Hovey, S. Bradner. October 1996. (Format: TXT=13865 bytes) (Also + BCP0011) (Status: BEST CURRENT PRACTICE) + +2029 RTP Payload Format of Sun's CellB Video Encoding. M. Speer, D. + Hoffman. October 1996. (Format: TXT=11216 bytes) (Status: PROPOSED + STANDARD) + +2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and + OSI. D. Mills. October 1996. (Format: TXT=48620 bytes) (Obsoletes + RFC1769) (Status: INFORMATIONAL) + +2031 IETF-ISOC relationship. E. Huizer. October 1996. (Format: + TXT=8816 bytes) (Status: INFORMATIONAL) + +2032 RTP Payload Format for H.261 Video Streams. T. Turletti, C. + Huitema. October 1996. (Format: TXT=27488 bytes) (Status: PROPOSED + STANDARD) + +2033 Local Mail Transfer Protocol. J. Myers. October 1996. (Format: + TXT=14711 bytes) (Status: INFORMATIONAL) + +2034 SMTP Service Extension for Returning Enhanced Error Codes. N. + Freed. October 1996. (Format: TXT=10460 bytes) (Status: PROPOSED + STANDARD) + +2035 RTP Payload Format for JPEG-compressed Video. L. Berc, W. Fenner, + R. Frederick, S. McCanne. October 1996. (Format: TXT=30079 bytes) + (Obsoleted by RFC2435) (Status: PROPOSED STANDARD) + +2036 Observations on the use of Components of the Class A Address + Space within the Internet. G. Huston. October 1996. (Format: + TXT=20743 bytes) (Status: INFORMATIONAL) + +2037 Entity MIB using SMIv2. K. McCloghrie, A. Bierman. October 1996. + (Format: TXT=74362 bytes) (Obsoleted by RFC2737) (Status: PROPOSED + STANDARD) + +2038 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G. + Fernando, V. Goyal. October 1996. (Format: TXT=23266 bytes) + (Obsoleted by RFC2250) (Status: PROPOSED STANDARD) + +2039 Applicability of Standards Track MIBs to Management of World Wide + Web Servers. C. Kalbfleisch. November 1996. (Format: TXT=31966 bytes) + (Status: INFORMATIONAL) + +2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms. R. + Baldwin, R. Rivest. October 1996. (Format: TXT=54598 bytes) (Status: + INFORMATIONAL) + +2041 Mobile Network Tracing. B. Noble, G. Nguyen, M. Satyanarayanan, + R. Katz. October 1996. (Format: TXT=64688 bytes) (Status: + INFORMATIONAL) + +2042 Registering New BGP Attribute Types. B. Manning. January 1997. + (Format: TXT=4001 bytes) (Status: INFORMATIONAL) + +2043 The PPP SNA Control Protocol (SNACP). A. Fuqua. October 1996. + (Format: TXT=13719 bytes) (Status: PROPOSED STANDARD) + +2044 UTF-8, a transformation format of Unicode and ISO 10646. F. + Yergeau. October 1996. (Format: TXT=11932 bytes) (Obsoleted by + RFC2279) (Status: INFORMATIONAL) + +2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of + Internet Message Bodies. N. Freed, N. Borenstein. November 1996. + (Format: TXT=72932 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) + (Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD) + +2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media + Types. N. Freed, N. Borenstein. November 1996. (Format: TXT=105854 + bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2646) + (Status: DRAFT STANDARD) + +2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message + Header Extensions for Non-ASCII Text. K. Moore. November 1996. + (Format: TXT=33262 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) + (Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD) + +2048 Multipurpose Internet Mail Extensions (MIME) Part Four: + Registration Procedures. N. Freed, J. Klensin, J. Postel. November + 1996. (Format: TXT=45033 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) + (Updated by RFC3023) (Also BCP0013) (Status: BEST CURRENT PRACTICE) + +2049 Multipurpose Internet Mail Extensions (MIME) Part Five: + Conformance Criteria and Examples. N. Freed, N. Borenstein. November + 1996. (Format: TXT=51207 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) + (Status: DRAFT STANDARD) + +2050 Internet Registry IP Allocation Guidelines. K. Hubbard, M. + Kosters, D. Conrad, D. Karrenberg, J. Postel. November 1996. (Format: + TXT=28975 bytes) (Obsoletes RFC1466) (Also BCP0012) (Status: BEST + CURRENT PRACTICE) + +2051 Definitions of Managed Objects for APPC using SMIv2. M. Allen, B. + Clouston, Z. Kielczewski, W. Kwan, B. Moore. October 1996. (Format: + TXT=239359 bytes) (Status: PROPOSED STANDARD) + +2052 A DNS RR for specifying the location of services (DNS SRV). A. + Gulbrandsen, P. Vixie. October 1996. (Format: TXT=19257 bytes) + (Obsoleted by RFC2782) (Status: EXPERIMENTAL) + +2053 The AM (Armenia) Domain. E. Der-Danieliantz. October 1996. + (Format: TXT=4128 bytes) (Status: INFORMATIONAL) + +2054 WebNFS Client Specification. B. Callaghan. October 1996. (Format: + TXT=36354 bytes) (Status: INFORMATIONAL) + +2055 WebNFS Server Specification. B. Callaghan. October 1996. (Format: + TXT=20498 bytes) (Status: INFORMATIONAL) + +2056 Uniform Resource Locators for Z39.50. R. Denenberg, J. Kunze, D. + Lynch. November 1996. (Format: TXT=14204 bytes) (Status: PROPOSED + STANDARD) + +2057 Source Directed Access Control on the Internet. S. Bradner. + November 1996. (Format: TXT=56664 bytes) (Status: INFORMATIONAL) + +2058 Remote Authentication Dial In User Service (RADIUS). C. Rigney, + A. Rubens, W. Simpson, S. Willens. January 1997. (Format: TXT=118880 + bytes) (Obsoleted by RFC2138) (Status: PROPOSED STANDARD) + +2059 RADIUS Accounting. C. Rigney. January 1997. (Format: TXT=44237 + bytes) (Obsoleted by RFC2139) (Status: INFORMATIONAL) + +2060 Internet Message Access Protocol - Version 4rev1. M. Crispin. + December 1996. (Format: TXT=166513 bytes) (Obsoletes RFC1730) + (Status: PROPOSED STANDARD) + +2061 IMAP4 Compatibility with IMAP2bis. M. Crispin. December 1996. + (Format: TXT=5867 bytes) (Obsoletes RFC1730) (Status: INFORMATIONAL) + +2062 Internet Message Access Protocol - Obsolete Syntax. M. Crispin. + December 1996. (Format: TXT=14222 bytes) (Status: INFORMATIONAL) + +2063 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. + Ruth. January 1997. (Format: TXT=89092 bytes) (Obsoleted by RFC2722) + (Status: EXPERIMENTAL) + +2064 Traffic Flow Measurement: Meter MIB. N. Brownlee. January 1997. + (Format: TXT=67520 bytes) (Obsoleted by RFC2720) (Status: + EXPERIMENTAL) + +2065 Domain Name System Security Extensions. D. Eastlake, C. Kaufman. + January 1997. (Format: TXT=97718 bytes) (Obsoleted by RFC2535) + (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) + +2066 TELNET CHARSET Option. R. Gellens. January 1997. (Format: + TXT=26088 bytes) (Status: EXPERIMENTAL) + +2067 IP over HIPPI. J. Renwick. January 1997. (Format: TXT=66702 + bytes) (Status: DRAFT STANDARD) + +2068 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, + J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. (Format: + TXT=378114 bytes) (Obsoleted by RFC2616) (Status: PROPOSED STANDARD) + +2069 An Extension to HTTP : Digest Access Authentication. J. Franks, + P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. + Stewart. January 1997. (Format: TXT=41733 bytes) (Obsoleted by + RFC2617) (Status: PROPOSED STANDARD) + +2070 Internationalization of the Hypertext Markup Language. F. + Yergeau, G. Nicol, G. Adams, M. Duerst. January 1997. (Format: + TXT=91887 bytes) (Obsoleted by RFC2854) (Status: HISTORIC) + +2071 Network Renumbering Overview: Why would I want it and what is it + anyway?. P. Ferguson, H. Berkowitz. January 1997. (Format: TXT=33218 + bytes) (Status: INFORMATIONAL) + +2072 Router Renumbering Guide. H. Berkowitz. January 1997. (Format: + TXT=110591 bytes) (Status: INFORMATIONAL) + +2073 An IPv6 Provider-Based Unicast Address Format. Y. Rekhter, P. + Lothberg, R. Hinden, S. Deering, J. Postel. January 1997. (Format: + TXT=15549 bytes) (Obsoleted by RFC2374) (Status: PROPOSED STANDARD) + +2074 Remote Network Monitoring MIB Protocol Identifiers. A. Bierman, + R. Iddon. January 1997. (Format: TXT=81262 bytes) (Obsoleted by + RFC2895) (Status: PROPOSED STANDARD) + +2075 IP Echo Host Service. C. Partridge. January 1997. (Format: + TXT=12536 bytes) (Status: EXPERIMENTAL) + +2076 Common Internet Message Headers. J. Palme. February 1997. + (Format: TXT=47639 bytes) (Status: INFORMATIONAL) + +2077 The Model Primary Content Type for Multipurpose Internet Mail + Extensions. S. Nelson, C. Parks, Mitra. January 1997. (Format: + TXT=30158 bytes) (Status: PROPOSED STANDARD) + +2078 Generic Security Service Application Program Interface, Version + 2. J. Linn. January 1997. (Format: TXT=185990 bytes) (Obsoletes + RFC1508) (Obsoleted by RFC2743) (Status: PROPOSED STANDARD) + +2079 Definition of an X.500 Attribute Type and an Object Class to Hold + Uniform Resource Identifiers (URIs). M. Smith. January 1997. (Format: + TXT=8757 bytes) (Status: PROPOSED STANDARD) + +2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: + TXT=47534 bytes) (Status: PROPOSED STANDARD) + +2081 RIPng Protocol Applicability Statement. G. Malkin. January 1997. + (Format: TXT=6821 bytes) (Status: INFORMATIONAL) + +2082 RIP-2 MD5 Authentication. F. Baker, R. Atkinson. January 1997. + (Format: TXT=25436 bytes) (Status: PROPOSED STANDARD) + +2083 PNG (Portable Network Graphics) Specification Version 1.0. T. + Boutell. March 1997. (Format: TXT=242528 bytes) (Status: + INFORMATIONAL) + +2084 Considerations for Web Transaction Security. G. Bossert, S. + Cooper, W. Drummond. January 1997. (Format: TXT=9022 bytes) (Status: + INFORMATIONAL) + +2085 HMAC-MD5 IP Authentication with Replay Prevention. M. Oehler, R. + Glenn. February 1997. (Format: TXT=13399 bytes) (Status: PROPOSED + STANDARD) + +2086 IMAP4 ACL extension. J. Myers. January 1997. (Format: TXT=13925 + bytes) (Status: PROPOSED STANDARD) + +2087 IMAP4 QUOTA extension. J. Myers. January 1997. (Format: TXT=8542 + bytes) (Status: PROPOSED STANDARD) + +2088 IMAP4 non-synchronizing literals. J. Myers. January 1997. + (Format: TXT=4052 bytes) (Status: PROPOSED STANDARD) + +2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent. + B. Wijnen, D. Levi. January 1997. (Format: TXT=23814 bytes) + (Obsoleted by RFC2576) (Status: INFORMATIONAL) + +2090 TFTP Multicast Option. A. Emberson. February 1997. (Format: + TXT=11857 bytes) (Status: EXPERIMENTAL) + +2091 Triggered Extensions to RIP to Support Demand Circuits. G. Meyer, + S. Sherry. January 1997. (Format: TXT=44835 bytes) (Status: PROPOSED + STANDARD) + +2092 Protocol Analysis for Triggered RIP. S. Sherry, G. Meyer. January + 1997. (Format: TXT=10865 bytes) (Status: INFORMATIONAL) + +2093 Group Key Management Protocol (GKMP) Specification. H. Harney, C. + Muckenhirn. July 1997. (Format: TXT=48678 bytes) (Status: + EXPERIMENTAL) + +2094 Group Key Management Protocol (GKMP) Architecture. H. Harney, C. + Muckenhirn. July 1997. (Format: TXT=53097 bytes) (Status: + EXPERIMENTAL) + +2095 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. + Klensin, R. Catoe, P. Krumviede. January 1997. (Format: TXT=10446 + bytes) (Obsoleted by RFC2195) (Status: PROPOSED STANDARD) + +2096 IP Forwarding Table MIB. F. Baker. January 1997. (Format: + TXT=35930 bytes) (Obsoletes RFC1354) (Status: PROPOSED STANDARD) + +2097 The PPP NetBIOS Frames Control Protocol (NBFCP). G. Pall. January + 1997. (Format: TXT=27104 bytes) (Status: PROPOSED STANDARD) + +2098 Toshiba's Router Architecture Extensions for ATM : Overview. Y. + Katsube, K. Nagami, H. Esaki. February 1997. (Format: TXT=43622 + bytes) (Status: INFORMATIONAL) + +2099 Request for Comments Summary RFC Numbers 2000-2099. J. Elliott. + March 1997. (Format: TXT=40763 bytes) (Status: INFORMATIONAL) + +2100 The Naming of Hosts. J. Ashworth. Apr-01-1997. (Format: TXT=4077 + bytes) (Status: INFORMATIONAL) + +2101 IPv4 Address Behaviour Today. B. Carpenter, J. Crowcroft, Y. + Rekhter. February 1997. (Format: TXT=31407 bytes) (Status: + INFORMATIONAL) + +2102 Multicast Support for Nimrod : Requirements and Solution + Approaches. R. Ramanathan. February 1997. (Format: TXT=50963 bytes) + (Status: INFORMATIONAL) + +2103 Mobility Support for Nimrod : Challenges and Solution Approaches. + R. Ramanathan. February 1997. (Format: TXT=41352 bytes) (Status: + INFORMATIONAL) + +2104 HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. + Bellare, R. Canetti. February 1997. (Format: TXT=22297 bytes) + (Status: INFORMATIONAL) + +2105 Cisco Systems' Tag Switching Architecture Overview. Y. Rekhter, + B. Davie, D. Katz, E. Rosen, G. Swallow. February 1997. (Format: + TXT=33013 bytes) (Status: INFORMATIONAL) + +2106 Data Link Switching Remote Access Protocol. S. Chiang, J. Lee, H. + Yasuda. February 1997. (Format: TXT=40819 bytes) (Obsoleted by + RFC2114) (Status: INFORMATIONAL) + +2107 Ascend Tunnel Management Protocol - ATMP. K. Hamzeh. February + 1997. (Format: TXT=44300 bytes) (Status: INFORMATIONAL) + +2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices + using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie. + February 1997. (Format: TXT=166336 bytes) (Obsoletes RFC1516) + (Status: PROPOSED STANDARD) + +2109 HTTP State Management Mechanism. D. Kristol, L. Montulli. + February 1997. (Format: TXT=43469 bytes) (Obsoleted by RFC2965) + (Status: PROPOSED STANDARD) + +2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML + (MHTML). J. Palme, A. Hopmann. March 1997. (Format: TXT=41961 bytes) + (Obsoleted by RFC2557) (Status: PROPOSED STANDARD) + +2111 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. + March 1997. (Format: TXT=9099 bytes) (Obsoleted by RFC2392) (Status: + PROPOSED STANDARD) + +2112 The MIME Multipart/Related Content-type. E. Levinson. March 1997. + (Format: TXT=17052 bytes) (Obsoletes RFC1872) (Obsoleted by RFC2387) + (Status: PROPOSED STANDARD) + +2113 IP Router Alert Option. D. Katz. February 1997. (Format: TXT=7924 + bytes) (Status: PROPOSED STANDARD) + +2114 Data Link Switching Client Access Protocol. S. Chiang, J. Lee, H. + Yasuda. February 1997. (Format: TXT=50872 bytes) (Obsoletes RFC2106) + (Status: INFORMATIONAL) + +2115 Management Information Base for Frame Relay DTEs Using SMIv2. C. + Brown, F. Baker. September 1997. (Format: TXT=59950 bytes) (Obsoletes + RFC1315) (Status: DRAFT STANDARD) + +2116 X.500 Implementations Catalog-96. C. Apple, K. Rossen. April + 1997. (Format: TXT=243994 bytes) (Obsoletes RFC1632) (Also FYI0011) + (Status: INFORMATIONAL) + +2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol + Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. + Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June + 1997. (Format: TXT=151886 bytes) (Obsoleted by RFC2362) (Status: + EXPERIMENTAL) + +2118 Microsoft Point-To-Point Compression (MPPC) Protocol. G. Pall. + March 1997. (Format: TXT=17443 bytes) (Status: INFORMATIONAL) + +2119 Key words for use in RFCs to Indicate Requirement Levels. S. + Bradner. March 1997. (Format: TXT=4723 bytes) (Also BCP0014) (Status: + BEST CURRENT PRACTICE) + +2120 Managing the X.500 Root Naming Context. D. Chadwick. March 1997. + (Format: TXT=30773 bytes) (Status: EXPERIMENTAL) + +2121 Issues affecting MARS Cluster Size. G. Armitage. March 1997. + (Format: TXT=26781 bytes) (Status: INFORMATIONAL) + +2122 VEMMI URL Specification. D. Mavrakis, H. Layec, K. Kartmann. + March 1997. (Format: TXT=25043 bytes) (Status: PROPOSED STANDARD) + +2123 Traffic Flow Measurement: Experiences with NeTraMet. N. Brownlee. + March 1997. (Format: TXT=81874 bytes) (Status: INFORMATIONAL) + +2124 Cabletron's Light-weight Flow Admission Protocol Specification + Version 1.0. P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons. + March 1997. (Format: TXT=47912 bytes) (Status: INFORMATIONAL) + +2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth + Allocation Control Protocol (BACP). C. Richards, K. Smith. March + 1997. (Format: TXT=49213 bytes) (Status: PROPOSED STANDARD) + +2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. + Young. March 1997. (Format: TXT=51032 bytes) (Updates RFC1006) + (Status: PROPOSED STANDARD) + +2127 ISDN Management Information Base using SMIv2. G. Roeck. March + 1997. (Format: TXT=95994 bytes) (Status: PROPOSED STANDARD) + +2128 Dial Control Management Information Base using SMIv2. G. Roeck. + March 1997. (Format: TXT=66153 bytes) (Status: PROPOSED STANDARD) + +2129 Toshiba's Flow Attribute Notification Protocol (FANP) + Specification. K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. + Matsuzawa, T. Jinmei, H. Esaki. April 1997. (Format: TXT=41137 bytes) + (Status: INFORMATIONAL) + +2130 The Report of the IAB Character Set Workshop held 29 February - 1 + March, 1996. C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. + Atkinson, M. Crispin, P. Svanberg. April 1997. (Format: TXT=63443 + bytes) (Status: INFORMATIONAL) + +2131 Dynamic Host Configuration Protocol. R. Droms. March 1997. + (Format: TXT=113738 bytes) (Obsoletes RFC1541) (Status: DRAFT + STANDARD) + +2132 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms. + March 1997. (Format: TXT=63670 bytes) (Obsoletes RFC1533) (Status: + DRAFT STANDARD) + +2133 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. + Thomson, J. Bound, W. Stevens. April 1997. (Format: TXT=69737 bytes) + (Obsoleted by RFC2553) (Status: INFORMATIONAL) + +2134 Articles of Incorporation of Internet Society. ISOC Board of + Trustees. April 1997. (Format: TXT=9131 bytes) (Status: + INFORMATIONAL) + +2135 Internet Society By-Laws. ISOC Board of Trustees. April 1997. + (Format: TXT=20467 bytes) (Status: INFORMATIONAL) + +2136 Dynamic Updates in the Domain Name System (DNS UPDATE). P. Vixie, + Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. (Format: TXT=56354 + bytes) (Updates RFC1035) (Updated by RFC3007) (Status: PROPOSED + STANDARD) + +2137 Secure Domain Name System Dynamic Update. D. Eastlake. April + 1997. (Format: TXT=24824 bytes) (Obsoleted by RFC3007) (Updates + RFC1035) (Status: PROPOSED STANDARD) + +2138 Remote Authentication Dial In User Service (RADIUS). C. Rigney, + A. Rubens, W. Simpson, S. Willens. April 1997. (Format: TXT=120407 + bytes) (Obsoletes RFC2058) (Obsoleted by RFC2865) (Status: PROPOSED + STANDARD) + +2139 RADIUS Accounting. C. Rigney. April 1997. (Format: TXT=44919 + bytes) (Obsoletes RFC2059) (Obsoleted by RFC2866) (Status: + INFORMATIONAL) + +2140 TCP Control Block Interdependence. J. Touch. April 1997. (Format: + TXT=26032 bytes) (Status: INFORMATIONAL) + +2141 URN Syntax. R. Moats. May 1997. (Format: TXT=14077 bytes) + (Status: PROPOSED STANDARD) + +2142 Mailbox Names for Common Services, Roles and Functions. D. + Crocker. May 1997. (Format: TXT=12195 bytes) (Status: PROPOSED + STANDARD) + +2143 Encapsulating IP with the Small Computer System Interface. B. + Elliston. May 1997. (Format: TXT=10749 bytes) (Status: EXPERIMENTAL) + +2144 The CAST-128 Encryption Algorithm. C. Adams. May 1997. (Format: + TXT=37532 bytes) (Status: INFORMATIONAL) + +2145 Use and Interpretation of HTTP Version Numbers. J. C. Mogul, R. + Fielding, J. Gettys, H. Frystyk. May 1997. (Format: TXT=13659 bytes) + (Status: INFORMATIONAL) + +2146 U.S. Government Internet Domain Names. Federal Networking + Council. May 1997. (Format: TXT=26564 bytes) (Obsoletes RFC1816) + (Status: INFORMATIONAL) + +2147 TCP and UDP over IPv6 Jumbograms. D. Borman. May 1997. (Format: + TXT=1883 bytes) (Obsoleted by RFC2675) (Status: PROPOSED STANDARD) + +2148 Deployment of the Internet White Pages Service. H. Alvestrand, P. + Jurg. September 1997. (Format: TXT=31539 bytes) (Also BCP0015) + (Status: BEST CURRENT PRACTICE) + +2149 Multicast Server Architectures for MARS-based ATM multicasting. + R. Talpade, M. Ammar. May 1997. (Format: TXT=42007 bytes) (Status: + INFORMATIONAL) + +2150 Humanities and Arts: Sharing Center Stage on the Internet. J. + Max, W. Stickle. October 1997. (Format: TXT=154037 bytes) (Also + FYI0031) (Status: INFORMATIONAL) + +2151 A Primer On Internet and TCP/IP Tools and Utilities. G. Kessler, + S. Shepard. June 1997. (Format: TXT=114130 bytes) (Obsoletes RFC1739) + (Also FYI0030) (Status: INFORMATIONAL) + +2152 UTF-7 A Mail-Safe Transformation Format of Unicode. D. Goldsmith, + M. Davis. May 1997. (Format: TXT=28065 bytes) (Obsoletes RFC1642) + (Status: INFORMATIONAL) + +2153 PPP Vendor Extensions. W. Simpson. May 1997. (Format: TXT=10780 + bytes) (Updates RFC1661, RFC1962) (Status: INFORMATIONAL) + +2154 OSPF with Digital Signatures. S. Murphy, M. Badger, B. + Wellington. June 1997. (Format: TXT=72701 bytes) (Status: + EXPERIMENTAL) + +2155 Definitions of Managed Objects for APPN using SMIv2. B. Clouston, + B. Moore. June 1997. (Format: TXT=213809 bytes) (Obsoleted by + RFC2455) (Status: PROPOSED STANDARD) + +2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 + and RFC 822/MIME. S. Kille. January 1998. (Format: TXT=280385 bytes) + (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148, RFC1327, RFC1495) + (Updates RFC0822) (Status: PROPOSED STANDARD) + +2157 Mapping between X.400 and RFC-822/MIME Message Bodies. H. + Alvestrand. January 1998. (Format: TXT=92554 bytes) (Status: PROPOSED + STANDARD) + +2158 X.400 Image Body Parts. H. Alvestrand. January 1998. (Format: + TXT=5547 bytes) (Status: PROPOSED STANDARD) + +2159 A MIME Body Part for FAX. H. Alvestrand. January 1998. (Format: + TXT=11471 bytes) (Status: PROPOSED STANDARD) + +2160 Carrying PostScript in X.400 and MIME. H. Alvestrand. January + 1998. (Format: TXT=7059 bytes) (Status: PROPOSED STANDARD) + +2161 A MIME Body Part for ODA. H. Alvestrand. January 1998. (Format: + TXT=8009 bytes) (Status: EXPERIMENTAL) + +2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 + mail. C. Allocchio. January 1998. (Format: TXT=58553 bytes) + (Obsoletes RFC1405) (Status: EXPERIMENTAL) + +2163 Using the Internet DNS to Distribute MIXER Conformant Global + Address Mapping (MCGAM). C. Allocchio. January 1998. (Format: + TXT=58789 bytes) (Obsoletes RFC1664) (Status: PROPOSED STANDARD) + +2164 Use of an X.500/LDAP directory to support MIXER address mapping. + S. Kille. January 1998. (Format: TXT=16701 bytes) (Obsoletes RFC1838) + (Status: PROPOSED STANDARD) + +2165 Service Location Protocol. J. Veizades, E. Guttman, C. Perkins, + S. Kaplan. June 1997. (Format: TXT=169889 bytes) (Updated by RFC2608, + RFC2609) (Status: PROPOSED STANDARD) + +2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 + Enhancements. D. Bryant, P. Brittain. June 1997. (Format: TXT=75527 + bytes) (Status: INFORMATIONAL) + +2167 Referral Whois (RWhois) Protocol V1.5. S. Williamson, M. Kosters, + D. Blacka, J. Singh, K. Zeilstra. June 1997. (Format: TXT=136355 + bytes) (Obsoletes RFC1714) (Status: INFORMATIONAL) + +2168 Resolution of Uniform Resource Identifiers using the Domain Name + System. R. Danie1, M. Mealling. June 1997. (Format: TXT=46528 bytes) + (Updated by RFC2915) (Status: EXPERIMENTAL) + +2169 A Trivial Convention for using HTTP in URN Resolution. R. Danie1. + June 1997. (Format: TXT=17763 bytes) (Status: EXPERIMENTAL) + +2170 Application REQuested IP over ATM (AREQUIPA). W. Almesberger, J. + Le Boudec, P. Oechslin. July 1997. (Format: TXT=22874 bytes) (Status: + INFORMATIONAL) + +2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1. K. + Murakami, M. Maruyama. June 1997. (Format: TXT=17480 bytes) (Status: + INFORMATIONAL) + +2172 MAPOS Version 1 Assigned Numbers. M. Maruyama, K. Murakami. June + 1997. (Format: TXT=4857 bytes) (Status: INFORMATIONAL) + +2173 A MAPOS version 1 Extension - Node Switch Protocol. K. Murakami, + M. Maruyama. June 1997. (Format: TXT=12251 bytes) (Status: + INFORMATIONAL) + +2174 A MAPOS version 1 Extension - Switch-Switch Protocol. K. + Murakami, M. Maruyama. June 1997. (Format: TXT=47967 bytes) (Status: + INFORMATIONAL) + +2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit + Addressing. K. Murakami, M. Maruyama. June 1997. (Format: TXT=11677 + bytes) (Status: INFORMATIONAL) + +2176 IPv4 over MAPOS Version 1. K. Murakami, M. Maruyama. June 1997. + (Format: TXT=12305 bytes) (Status: INFORMATIONAL) + +2177 IMAP4 IDLE command. B. Leiba. June 1997. (Format: TXT=6770 bytes) + (Status: PROPOSED STANDARD) + +2178 OSPF Version 2. J. Moy. July 1997. (Format: TXT=495866 bytes) + (Obsoletes RFC1583) (Obsoleted by RFC2328) (Status: DRAFT STANDARD) + +2179 Network Security For Trade Shows. A. Gwinn. July 1997. (Format: + TXT=20690 bytes) (Status: INFORMATIONAL) + +2180 IMAP4 Multi-Accessed Mailbox Practice. M. Gahrns. July 1997. + (Format: TXT=24750 bytes) (Status: INFORMATIONAL) + +2181 Clarifications to the DNS Specification. R. Elz, R. Bush. July + 1997. (Format: TXT=36989 bytes) (Updates RFC1034, RFC1035, RFC1123) + (Updated by RFC2535) (Status: PROPOSED STANDARD) + +2182 Selection and Operation of Secondary DNS Servers. R. Elz, R. + Bush, S. Bradner, M. Patton. July 1997. (Format: TXT=27456 bytes) + (Also BCP0016) (Status: BEST CURRENT PRACTICE) + +2183 Communicating Presentation Information in Internet Messages: The + Content-Disposition Header Field. R. Troost, S. Dorner, K. Moore. + August 1997. (Format: TXT=23150 bytes) (Updates RFC1806) (Updated by + RFC2184, RFC2231) (Status: PROPOSED STANDARD) + +2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, + Languages, and Continuations. N. Freed, K. Moore. August 1997. + (Format: TXT=17635 bytes) (Obsoleted by RFC2231) (Updates RFC2045, + RFC2047, RFC2183) (Status: PROPOSED STANDARD) + +2185 Routing Aspects of IPv6 Transition. R. Callon, D. Haskin. + September 1997. (Format: TXT=31281 bytes) (Status: INFORMATIONAL) + +2186 Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. + September 1997. (Format: TXT=18808 bytes) (Status: INFORMATIONAL) + +2187 Application of Internet Cache Protocol (ICP), version 2. D. + Wessels, K. Claffy. September 1997. (Format: TXT=51662 bytes) + (Status: INFORMATIONAL) + +2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol + Specification Version 1.2. M. Banan, M. Taylor, and J. Cheng. + September 1997. (Format: TXT=118374 bytes) (Status: INFORMATIONAL) + +2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol + Specification --. A. Ballardie. September 1997. (Format: TXT=52043 + bytes) (Status: EXPERIMENTAL) + +2190 RTP Payload Format for H.263 Video Streams. C. Zhu. September + 1997. (Format: TXT=26409 bytes) (Status: PROPOSED STANDARD) + +2191 VENUS - Very Extensive Non-Unicast Service. G. Armitage. + September 1997. (Format: TXT=31316 bytes) (Status: INFORMATIONAL) + +2192 IMAP URL Scheme. C. Newman. September 1997. (Format: TXT=31426 + bytes) (Status: PROPOSED STANDARD) + +2193 IMAP4 Mailbox Referrals. M. Gahrns. September 1997. (Format: + TXT=16248 bytes) (Status: PROPOSED STANDARD) + +2194 Review of Roaming Implementations. B. Aboba, J. Lu, J. Alsop, J. + Ding, W. Wang. September 1997. (Format: TXT=81533 bytes) (Status: + INFORMATIONAL) + +2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. + Klensin, R. Catoe, P. Krumviede. September 1997. (Format: TXT=10468 + bytes) (Obsoletes RFC2095) (Status: PROPOSED STANDARD) + +2196 Site Security Handbook. B. Fraser. September 1997. (Format: + TXT=191772 bytes) (Obsoletes RFC1244) (Also FYI0008) (Status: + INFORMATIONAL) + +2197 SMTP Service Extension for Command Pipelining. N. Freed. + September 1997. (Format: TXT=15003 bytes) (Obsoletes RFC1854) + (Obsoleted by RFC2920) (Status: DRAFT STANDARD) + +2198 RTP Payload for Redundant Audio Data. C. Perkins, I. Kouvelas, O. + Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. + Fosse-Parisis. September 1997. (Format: TXT=25166 bytes) (Status: + PROPOSED STANDARD) + +2199 Request for Comments Summary RFC Numbers 2100-2199. A. Ramos. + January 1998. (Format: TXT=47664 bytes) (Status: INFORMATIONAL) + +2200 Internet Official Protocol Standards. J. Postel. June 1997. + (Format: TXT=94506 bytes) (Obsoletes RFC1250, RFC2000) (Obsoleted by + RFC2300) (Status: HISTORIC) + +2201 Core Based Trees (CBT) Multicast Routing Architecture. A. + Ballardie. September 1997. (Format: TXT=38040 bytes) (Status: + EXPERIMENTAL) + +2202 Test Cases for HMAC-MD5 and HMAC-SHA-1. P. Cheng, R. Glenn. + September 1997. (Format: TXT=11945 bytes) (Status: INFORMATIONAL) + +2203 RPCSEC_GSS Protocol Specification. M. Eisler, A. Chiu, L. Ling. + September 1997. (Format: TXT=50937 bytes) (Status: PROPOSED STANDARD) + +2204 ODETTE File Transfer Protocol. D. Nash. September 1997. (Format: + TXT=151857 bytes) (Status: INFORMATIONAL) + +2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional + Specification. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. + Jamin. September 1997. (Format: TXT=223974 bytes) (Updated by + RFC2750) (Status: PROPOSED STANDARD) + +2206 RSVP Management Information Base using SMIv2. F. Baker, J. + Krawczyk, A. Sastry. September 1997. (Format: TXT=112937 bytes) + (Status: PROPOSED STANDARD) + +2207 RSVP Extensions for IPSEC Data Flows. L. Berger, T. O'Malley. + September 1997. (Format: TXT=30473 bytes) (Status: PROPOSED STANDARD) + +2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability + Statement Some Guidelines on Deployment. A. Mankin, Ed., F. Baker, B. + Braden, S. Bradner, M. O`Dell, A. Romanow, A. Weinrib, L. Zhang. + September 1997. (Format: TXT=14289 bytes) (Status: INFORMATIONAL) + +2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message + Processing Rules. R. Braden, L. Zhang. September 1997. (Format: + TXT=51690 bytes) (Status: INFORMATIONAL) + +2210 The Use of RSVP with IETF Integrated Services. J. Wroclawski. + September 1997. (Format: TXT=77613 bytes) (Status: PROPOSED STANDARD) + +2211 Specification of the Controlled-Load Network Element Service. J. + Wroclawski. September 1997. (Format: TXT=46523 bytes) (Status: + PROPOSED STANDARD) + +2212 Specification of Guaranteed Quality of Service. S. Shenker, C. + Partridge, R. Guerin. September 1997. (Format: TXT=52330 bytes) + (Status: PROPOSED STANDARD) + +2213 Integrated Services Management Information Base using SMIv2. F. + Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT=36147 + bytes) (Status: PROPOSED STANDARD) + +2214 Integrated Services Management Information Base Guaranteed + Service Extensions using SMIv2. F. Baker, J. Krawczyk, A. Sastry. + September 1997. (Format: TXT=15971 bytes) (Status: PROPOSED STANDARD) + +2215 General Characterization Parameters for Integrated Service + Network Elements. S. Shenker, J. Wroclawski. September 1997. (Format: + TXT=39552 bytes) (Status: PROPOSED STANDARD) + +2216 Network Element Service Specification Template. S. Shenker, J. + Wroclawski. September 1997. (Format: TXT=53655 bytes) (Status: + INFORMATIONAL) + +2217 Telnet Com Port Control Option. G. Clark. October 1997. (Format: + TXT=31664 bytes) (Status: EXPERIMENTAL) + +2218 A Common Schema for the Internet White Pages Service. T. + Genovese, B. Jennings. October 1997. (Format: TXT=16258 bytes) + (Status: PROPOSED STANDARD) + +2219 Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. + October 1997. (Format: TXT=17858 bytes) (Also BCP0017) (Status: BEST + CURRENT PRACTICE) + +2220 The Application/MARC Content-type. R. Guenther. October 1997. + (Format: TXT=7025 bytes) (Status: INFORMATIONAL) + +2221 IMAP4 Login Referrals. M. Gahrns. October 1997. (Format: TXT=9251 + bytes) (Status: PROPOSED STANDARD) + +2222 Simple Authentication and Security Layer (SASL). J. Myers. + October 1997. (Format: TXT=35010 bytes) (Updated by RFC2444) (Status: + PROPOSED STANDARD) + +2223 Instructions to RFC Authors. J. Postel, J. Reynolds. October + 1997. (Format: TXT=37948 bytes) (Obsoletes RFC1543, RFC1111, RFC0825) + (Status: INFORMATIONAL) + +2224 NFS URL Scheme. B. Callaghan. October 1997. (Format: TXT=22726 + bytes) (Status: INFORMATIONAL) + +2225 Classical IP and ARP over ATM. M. Laubach, J. Halpern. April + 1998. (Format: TXT=65779 bytes) (Obsoletes RFC1626, RFC1577) (Status: + PROPOSED STANDARD) + +2226 IP Broadcast over ATM Networks. T. Smith, G. Armitage. October + 1997. (Format: TXT=30661 bytes) (Status: PROPOSED STANDARD) + +2227 Simple Hit-Metering and Usage-Limiting for HTTP. J. Mogul, P. + Leach. October 1997. (Format: TXT=85127 bytes) (Status: PROPOSED + STANDARD) + +2228 FTP Security Extensions. M. Horowitz, S. Lunt. October 1997. + (Format: TXT=58733 bytes) (Updates RFC0959) (Status: PROPOSED + STANDARD) + +2229 A Dictionary Server Protocol. R. Faith, B. Martin. October 1997. + (Format: TXT=59551 bytes) (Status: INFORMATIONAL) + +2230 Key Exchange Delegation Record for the DNS. R. Atkinson. November + 1997. (Format: TXT=25563 bytes) (Status: INFORMATIONAL) + +2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, + Languages, and Continuations. N. Freed, K. Moore. November 1997. + (Format: TXT=19280 bytes) (Obsoletes RFC2184) (Updates RFC2045, + RFC2047, RFC2183) (Status: PROPOSED STANDARD) + +2232 Definitions of Managed Objects for DLUR using SMIv2. B. Clouston, + B. Moore. November 1997. (Format: TXT=37955 bytes) (Status: PROPOSED + STANDARD) + +2233 The Interfaces Group MIB using SMIv2. K. McCloghrie, F. + Kastenholz. November 1997. (Format: TXT=148033 bytes) (Obsoletes + RFC1573) (Obsoleted by RFC2863) (Status: PROPOSED STANDARD) + +2234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., + P. Overell. November 1997. (Format: TXT=24265 bytes) (Status: + PROPOSED STANDARD) + +2235 Hobbes' Internet Timeline. R. Zakon. November 1997. (Format: + TXT=43060 bytes) (Also FYI0032) (Status: INFORMATIONAL) + +2236 Internet Group Management Protocol, Version 2. W. Fenner. + November 1997. (Format: TXT=51048 bytes) (Updates RFC1112) (Status: + PROPOSED STANDARD) + +2237 Japanese Character Encoding for Internet Messages. K. Tamaru. + November 1997. (Format: TXT=11628 bytes) (Status: INFORMATIONAL) + +2238 Definitions of Managed Objects for HPR using SMIv2. B. Clouston, + B. Moore. November 1997. (Format: TXT=65498 bytes) (Status: PROPOSED + STANDARD) + +2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment + Units (MAUs) using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K. + McCloghrie, S. Roberts. November 1997. (Format: TXT=80651 bytes) + (Obsoleted by RFC2668) (Status: PROPOSED STANDARD) + +2240 A Legal Basis for Domain Name Allocation. O. Vaughan. November + 1997. (Format: TXT=13602 bytes) (Obsoleted by RFC2352) (Status: + INFORMATIONAL) + +2241 DHCP Options for Novell Directory Services. D. Provan. November + 1997. (Format: TXT=8419 bytes) (Status: PROPOSED STANDARD) + +2242 NetWare/IP Domain Name and Information. R. Droms, K. Fong. + November 1997. (Format: TXT=10653 bytes) (Status: PROPOSED STANDARD) + +2243 OTP Extended Responses. C. Metz. November 1997. (Format: + TXT=19730 bytes) (Status: PROPOSED STANDARD) + +2244 ACAP -- Application Configuration Access Protocol. C. Newman, J. + G. Myers. November 1997. (Format: TXT=154610 bytes) (Status: PROPOSED + STANDARD) + +2245 Anonymous SASL Mechanism. C. Newman. November 1997. (Format: + TXT=9974 bytes) (Status: PROPOSED STANDARD) + +2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. + (Format: TXT=170401 bytes) (Status: PROPOSED STANDARD) + +2247 Using Domains in LDAP/X.500 Distinguished Names. S. Kille, M. + Wahl, A. Grimstad, R. Huber, S. Sataluri. January 1998. (Format: + TXT=12411 bytes) (Status: PROPOSED STANDARD) + +2248 Network Services Monitoring MIB. N. Freed, S. Kille. January + 1998. (Format: TXT=34106 bytes) (Obsoletes RFC1565) (Obsoleted by + RFC2788) (Status: PROPOSED STANDARD) + +2249 Mail Monitoring MIB. N. Freed, S. Kille. January 1998. (Format: + TXT=52334 bytes) (Obsoletes RFC1566) (Obsoleted by RFC2789) (Status: + PROPOSED STANDARD) + +2250 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G. + Fernando, V. Goyal, M. Civanlar. January 1998. (Format: TXT=34293 + bytes) (Obsoletes RFC2038) (Status: PROPOSED STANDARD) + +2251 Lightweight Directory Access Protocol (v3). M. Wahl, T. Howes, S. + Kille. December 1997. (Format: TXT=114488 bytes) (Status: PROPOSED + STANDARD) + +2252 Lightweight Directory Access Protocol (v3): Attribute Syntax + Definitions. M. Wahl, A. Coulbeck, T. Howes, S. Kille. December 1997. + (Format: TXT=60204 bytes) (Status: PROPOSED STANDARD) + +2253 Lightweight Directory Access Protocol (v3): UTF-8 String + Representation of Distinguished Names. M. Wahl, S. Kille, T. Howes. + December 1997. (Format: TXT=18226 bytes) (Obsoletes RFC1779) (Status: + PROPOSED STANDARD) + +2254 The String Representation of LDAP Search Filters. T. Howes. + December 1997. (Format: TXT=13511 bytes) (Obsoletes RFC1960) (Status: + PROPOSED STANDARD) + +2255 The LDAP URL Format. T. Howes, M. Smith. December 1997. (Format: + TXT=20685 bytes) (Obsoletes RFC1959) (Status: PROPOSED STANDARD) + +2256 A Summary of the X.500(96) User Schema for use with LDAPv3. M. + Wahl. December 1997. (Format: TXT=32377 bytes) (Status: PROPOSED + STANDARD) + +2257 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B. + Wijnen, D. Francisco. January 1998. (Format: TXT=177452 bytes) + (Obsoleted by RFC2741) (Status: PROPOSED STANDARD) + +2258 Internet Nomenclator Project. J. Ordille. January 1998. (Format: + TXT=34871 bytes) (Status: INFORMATIONAL) + +2259 Simple Nomenclator Query Protocol (SNQP). J. Elliott, J. Ordille. + January 1998. (Format: TXT=58508 bytes) (Status: INFORMATIONAL) + +2260 Scalable Support for Multi-homed Multi-provider Connectivity. T. + Bates, Y. Rekhter. January 1998. (Format: TXT=28085 bytes) (Status: + INFORMATIONAL) + +2261 An Architecture for Describing SNMP Management Frameworks. D. + Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT=128036 + bytes) (Obsoleted by RFC2271) (Status: PROPOSED STANDARD) + +2262 Message Processing and Dispatching for the Simple Network + Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. + Wijnen. January 1998. (Format: TXT=88254 bytes) (Obsoleted by + RFC2272) (Status: PROPOSED STANDARD) + +2263 SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. January 1998. + (Format: TXT=143493 bytes) (Obsoleted by RFC2273) (Status: PROPOSED + STANDARD) + +2264 User-based Security Model (USM) for version 3 of the Simple + Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. + January 1998. (Format: TXT=168759 bytes) (Obsoleted by RFC2274) + (Status: PROPOSED STANDARD) + +2265 View-based Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. + January 1998. (Format: TXT=77807 bytes) (Obsoleted by RFC2275) + (Status: PROPOSED STANDARD) + +2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices. + J. Flick. January 1998. (Format: TXT=134027 bytes) (Status: PROPOSED + STANDARD) + +2267 Network Ingress Filtering: Defeating Denial of Service Attacks + which employ IP Source Address Spoofing. P. Ferguson, D. Senie. + January 1998. (Format: TXT=21032 bytes) (Obsoleted by RFC2827) + (Status: INFORMATIONAL) + +2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest. + March 1998. (Format: TXT=19048 bytes) (Status: INFORMATIONAL) + +2269 Using the MARS Model in non-ATM NBMA Networks. G. Armitage. + January 1998. (Format: TXT=12094 bytes) (Status: INFORMATIONAL) + +2270 Using a Dedicated AS for Sites Homed to a Single Provider. J. + Stewart, T. Bates, R. Chandra, E. Chen. January 1998. (Format: + TXT=12063 bytes) (Status: INFORMATIONAL) + +2271 An Architecture for Describing SNMP Management Frameworks. D. + Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT=128227 + bytes) (Obsoletes RFC2261) (Obsoleted by RFC2571) (Status: PROPOSED + STANDARD) + +2272 Message Processing and Dispatching for the Simple Network + Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. + Wijnen. January 1998. (Format: TXT=88445 bytes) (Obsoletes RFC2262) + (Obsoleted by RFC2572) (Status: PROPOSED STANDARD) + +2273 SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. January 1998. + (Format: TXT=143754 bytes) (Obsoletes RFC2263) (Obsoleted by RFC2573) + (Status: PROPOSED STANDARD) + +2274 User-based Security Model (USM) for version 3 of the Simple + Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. + January 1998. (Format: TXT=168950 bytes) (Obsoletes RFC2264) + (Obsoleted by RFC2574) (Status: PROPOSED STANDARD) + +2275 View-based Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. + January 1998. (Format: TXT=77998 bytes) (Obsoletes RFC2265) + (Obsoleted by RFC2575) (Status: PROPOSED STANDARD) + +2276 Architectural Principles of Uniform Resource Name Resolution. K. + Sollins. January 1998. (Format: TXT=64811 bytes) (Status: + INFORMATIONAL) + +2277 IETF Policy on Character Sets and Languages. H. Alvestrand. + January 1998. (Format: TXT=16622 bytes) (Also BCP0018) (Status: BEST + CURRENT PRACTICE) + +2278 IANA Charset Registration Procedures. N. Freed, J. Postel. + January 1998. (Format: TXT=18881 bytes) (Obsoleted by RFC2978) + (Status: INFORMATIONAL) + +2279 UTF-8, a transformation format of ISO 10646. F. Yergeau. January + 1998. (Format: TXT=21634 bytes) (Obsoletes RFC2044) (Status: DRAFT + STANDARD) + +2280 Routing Policy Specification Language (RPSL). C. Alaettinoglu, T. + Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. + Villamizar. January 1998. (Format: TXT=114985 bytes) (Obsoleted by + RFC2622) (Status: PROPOSED STANDARD) + +2281 Cisco Hot Standby Router Protocol (HSRP). T. Li, B. Cole, P. + Morton, D. Li. March 1998. (Format: TXT=35161 bytes) (Status: + INFORMATIONAL) + +2282 IAB and IESG Selection, Confirmation, and Recall Process: + Operation of the Nominating and Recall Committees. J. Galvin. + February 1998. (Format: TXT=29852 bytes) (Obsoletes RFC2027) + (Obsoleted by RFC2727) (Status: INFORMATIONAL) + +2283 Multiprotocol Extensions for BGP-4. T. Bates, R. Chandra, D. + Katz, Y. Rekhter. February 1998. (Format: TXT=18946 bytes) (Obsoleted + by RFC2858) (Status: PROPOSED STANDARD) + +2284 PPP Extensible Authentication Protocol (EAP). L. Blunk, J. + Vollbrecht. March 1998. (Format: TXT=29452 bytes) (Updated by + RFC2484) (Status: PROPOSED STANDARD) + +2285 Benchmarking Terminology for LAN Switching Devices. R. + Mandeville. February 1998. (Format: TXT=43130 bytes) (Status: + INFORMATIONAL) + +2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. J. Kapp. + February 1998. (Format: TXT=11849 bytes) (Status: INFORMATIONAL) + +2287 Definitions of System-Level Managed Objects for Applications. C. + Krupczak, J. Saperia. February 1998. (Format: TXT=98210 bytes) + (Status: PROPOSED STANDARD) + +2288 Using Existing Bibliographic Identifiers as Uniform Resource + Names. C. Lynch, C. Preston, R. Daniel. February 1998. (Format: + TXT=21628 bytes) (Status: INFORMATIONAL) + +2289 A One-Time Password System. N. Haller, C. Metz, P. Nesser, M. + Straw. February 1998. (Format: TXT=56495 bytes) (Obsoletes RFC1938) + (Also STD0061) (Status: STANDARD) + +2290 Mobile-IPv4 Configuration Option for PPP IPCP. J. Solomon, S. + Glass. February 1998. (Format: TXT=39421 bytes) (Updates RFC2002) + (Updated by RFC2794) (Status: PROPOSED STANDARD) + +2291 Requirements for a Distributed Authoring and Versioning Protocol + for the World Wide Web. J. Slein, F. Vitali, E. Whitehead, D. Durand. + February 1998. (Format: TXT=44036 bytes) (Status: INFORMATIONAL) + +2292 Advanced Sockets API for IPv6. W. Stevens, M. Thomas. February + 1998. (Format: TXT=152077 bytes) (Status: INFORMATIONAL) + +2293 Representing Tables and Subtrees in the X.500 Directory. S. + Kille. March 1998. (Format: TXT=12539 bytes) (Obsoletes RFC1837) + (Status: PROPOSED STANDARD) + +2294 Representing the O/R Address hierarchy in the X.500 Directory + Information Tree. S. Kille. March 1998. (Format: TXT=22059 bytes) + (Obsoletes RFC1836) (Status: PROPOSED STANDARD) + +2295 Transparent Content Negotiation in HTTP. K. Holtman, A. Mutz. + March 1998. (Format: TXT=125130 bytes) (Status: EXPERIMENTAL) + +2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0. K. Holtman, + A. Mutz. March 1998. (Format: TXT=26932 bytes) (Status: EXPERIMENTAL) + +2297 Ipsilon's General Switch Management Protocol Specification + Version 2.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching + Liaw, T. Lyon, G. Minshall. March 1998. (Format: TXT=280484 bytes) + (Updates RFC1987) (Status: INFORMATIONAL) + +2298 An Extensible Message Format for Message Disposition + Notifications. R. Fajman. March 1998. (Format: TXT=62059 bytes) + (Status: PROPOSED STANDARD) + +2299 Request for Comments Summary. A. Ramos. January 1999. (Format: + TXT=51234 bytes) (Status: INFORMATIONAL) + +2300 Internet Official Protocol Standards. J. Postel. May 1998. + (Format: TXT=128322 bytes) (Obsoletes RFC2200) (Obsoleted by RFC2400) + (Status: HISTORIC) + +2301 File Format for Internet Fax. L. McIntyre, S. Zilles, R. Buckley, + D. Venable, G. Parsons, J. Rafferty. March 1998. (Format: TXT=200525 + bytes) (Status: PROPOSED STANDARD) + +2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type + Registration. G. Parsons, J. Rafferty, S. Zilles. March 1998. + (Format: TXT=14375 bytes) (Status: PROPOSED STANDARD) + +2303 Minimal PSTN address format in Internet Mail. C. Allocchio. March + 1998. (Format: TXT=14625 bytes) (Status: PROPOSED STANDARD) + +2304 Minimal FAX address format in Internet Mail. C. Allocchio. March + 1998. (Format: TXT=13236 bytes) (Status: PROPOSED STANDARD) + +2305 A Simple Mode of Facsimile Using Internet Mail. K. Toyoda, H. + Ohno, J. Murai, D. Wing. March 1998. (Format: TXT=24624 bytes) + (Status: PROPOSED STANDARD) + +2306 Tag Image File Format (TIFF) - F Profile for Facsimile. G. + Parsons, J. Rafferty. March 1998. (Format: TXT=59358 bytes) (Status: + INFORMATIONAL) + +2307 An Approach for Using LDAP as a Network Information Service. L. + Howard. March 1998. (Format: TXT=41396 bytes) (Status: EXPERIMENTAL) + +2308 Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March + 1998. (Format: TXT=41428 bytes) (Updates RFC1034, RFC1035) (Status: + PROPOSED STANDARD) + +2309 Recommendations on Queue Management and Congestion Avoidance in + the Internet. B. Braden, D. Clark, J. Crowcroft, B. Davie, S. + Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, + L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. + April 1998. (Format: TXT=38079 bytes) (Status: INFORMATIONAL) + +2310 The Safe Response Header Field. K. Holtman. April 1998. (Format: + TXT=8091 bytes) (Status: EXPERIMENTAL) + +2311 S/MIME Version 2 Message Specification. S. Dusse, P. Hoffman, B. + Ramsdell, L. Lundblade, L. Repka. March 1998. (Format: TXT=70901 + bytes) (Status: INFORMATIONAL) + +2312 S/MIME Version 2 Certificate Handling. S. Dusse, P. Hoffman, B. + Ramsdell, J. Weinstein. March 1998. (Format: TXT=39829 bytes) + (Status: INFORMATIONAL) + +2313 PKCS #1: RSA Encryption Version 1.5. B. Kaliski. March 1998. + (Format: TXT=37777 bytes) (Obsoleted by RFC2437) (Status: + INFORMATIONAL) + +2314 PKCS #10: Certification Request Syntax Version 1.5. B. Kaliski. + March 1998. (Format: TXT=15814 bytes) (Obsoleted by RFC2986) (Status: + INFORMATIONAL) + +2315 PKCS #7: Cryptographic Message Syntax Version 1.5. B. Kaliski. + March 1998. (Format: TXT=69679 bytes) (Status: INFORMATIONAL) + +2316 Report of the IAB Security Architecture Workshop. S. Bellovin. + April 1998. (Format: TXT=19733 bytes) (Status: INFORMATIONAL) + +2317 Classless IN-ADDR.ARPA delegation. H. Eidnes, G. de Groot, P. + Vixie. March 1998. (Format: TXT=17744 bytes) (Also BCP0020) (Status: + BEST CURRENT PRACTICE) + +2318 The text/css Media Type. H. Lie, B. Bos, C. Lilley. March 1998. + (Format: TXT=7819 bytes) (Status: INFORMATIONAL) + +2319 Ukrainian Character Set KOI8-U. KOI8-U Working Group. April 1998. + (Format: TXT=18042 bytes) (Status: INFORMATIONAL) + +2320 Definitions of Managed Objects for Classical IP and ARP Over ATM + Using SMIv2 (IPOA-MIB). M. Greene, J. Luciani, K. White, T. Kuo. + April 1998. (Format: TXT=102116 bytes) (Status: PROPOSED STANDARD) + +2321 RITA -- The Reliable Internetwork Troubleshooting Agent. A. + Bressen. Apr-01-1998. (Format: TXT=12302 bytes) (Status: + INFORMATIONAL) + +2322 Management of IP numbers by peg-dhcp. K. van den Hout, A. Koopal, + R. van Mook. Apr-01-1998. (Format: TXT=12665 bytes) (Status: + INFORMATIONAL) + +2323 IETF Identification and Security Guidelines. A. Ramos. + Apr-01-1998. (Format: TXT=9257 bytes) (Status: INFORMATIONAL) + +2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). L. Masinter. + Apr-01-1998. (Format: TXT=19610 bytes) (Status: INFORMATIONAL) + +2325 Definitions of Managed Objects for Drip-Type Heated Beverage + Hardware Devices using SMIv2. M. Slavitch. Apr-01-1998. (Format: + TXT=12726 bytes) (Status: INFORMATIONAL) + +2326 Real Time Streaming Protocol (RTSP). H. Schulzrinne, A. Rao, R. + Lanphier. April 1998. (Format: TXT=195010 bytes) (Status: PROPOSED + STANDARD) + +2327 SDP: Session Description Protocol. M. Handley, V. Jacobson. April + 1998. (Format: TXT=87096 bytes) (Status: PROPOSED STANDARD) + +2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT=447367 bytes) + (Obsoletes RFC2178) (Also STD0054) (Status: STANDARD) + +2329 OSPF Standardization Report. J. Moy. April 1998. (Format: + TXT=15130 bytes) (Status: INFORMATIONAL) + +2330 Framework for IP Performance Metrics. V. Paxson, G. Almes, J. + Mahdavi, M. Mathis. May 1998. (Format: TXT=94387 bytes) (Status: + INFORMATIONAL) + +2331 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 + Update. M. Maher. April 1998. (Format: TXT=61119 bytes) (Status: + PROPOSED STANDARD) + +2332 NBMA Next Hop Resolution Protocol (NHRP). J. Luciani, D. Katz, D. + Piscitello, B. Cole, N. Doraswamy. April 1998. (Format: TXT=126978 + bytes) (Status: PROPOSED STANDARD) + +2333 NHRP Protocol Applicability Statement. D. Cansever. April 1998. + (Format: TXT=20164 bytes) (Status: PROPOSED STANDARD) + +2334 Server Cache Synchronization Protocol (SCSP). J. Luciani, G. + Armitage, J. Halpern, N. Doraswamy. April 1998. (Format: TXT=98161 + bytes) (Status: PROPOSED STANDARD) + +2335 A Distributed NHRP Service Using SCSP. J. Luciani. April 1998. + (Format: TXT=14007 bytes) (Status: PROPOSED STANDARD) + +2336 Classical IP to NHRP Transition. J. Luciani. July 1998. (Format: + TXT=10500 bytes) (Status: INFORMATIONAL) + +2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode + PIM. D. Farinacci, D. Meyer, Y. Rekhter. April 1998. (Format: + TXT=16357 bytes) (Status: EXPERIMENTAL) + +2338 Virtual Router Redundancy Protocol. S. Knight, D. Weaver, D. + Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. + Lindem. April 1998. (Format: TXT=59871 bytes) (Status: PROPOSED + STANDARD) + +2339 An Agreement Between the Internet Society, the IETF, and Sun + Microsystems, Inc. in the matter of NFS V.4 Protocols. The Internet + Society, Sun Microsystems. May 1998. (Format: TXT=10745 bytes) + (Status: INFORMATIONAL) + +2340 Nortel's Virtual Network Switching (VNS) Overview. B. Jamoussi, + D. Jamieson, D. Williston, S. Gabe. May 1998. (Format: TXT=30731 + bytes) (Status: INFORMATIONAL) + +2341 Cisco Layer Two Forwarding (Protocol) "L2F". A. Valencia, M. + Littlewood, T. Kolar. May 1998. (Format: TXT=66592 bytes) (Status: + HISTORIC) + +2342 IMAP4 Namespace. M. Gahrns, C. Newman. May 1998. (Format: + TXT=19489 bytes) (Status: PROPOSED STANDARD) + +2343 RTP Payload Format for Bundled MPEG. M. Civanlar, G. Cash, B. + Haskell. May 1998. (Format: TXT=16557 bytes) (Status: EXPERIMENTAL) + +2344 Reverse Tunneling for Mobile IP. G. Montenegro. May 1998. + (Format: TXT=39468 bytes) (Obsoleted by RFC3024) (Status: PROPOSED + STANDARD) + +2345 Domain Names and Company Name Retrieval. J. Klensin, T. Wolf, G. + Oglesby. May 1998. (Format: TXT=29707 bytes) (Status: EXPERIMENTAL) + +2346 Making Postscript and PDF International. J. Palme. May 1998. + (Format: TXT=12382 bytes) (Status: INFORMATIONAL) + +2347 TFTP Option Extension. G. Malkin, A. Harkin. May 1998. (Format: + TXT=13060 bytes) (Obsoletes RFC1782) (Updates RFC1350) (Status: DRAFT + STANDARD) + +2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998. (Format: + TXT=9515 bytes) (Obsoletes RFC1783) (Updates RFC1350) (Status: DRAFT + STANDARD) + +2349 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. + Harkin. May 1998. (Format: TXT=7848 bytes) (Obsoletes RFC1784) + (Updates RFC1350) (Status: DRAFT STANDARD) + +2350 Expectations for Computer Security Incident Response. N. + Brownlee, E. Guttman. June 1998. (Format: TXT=86545 bytes) (Also + BCP0021) (Status: BEST CURRENT PRACTICE) + +2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic + over IP. A. Rober. May 1998. (Format: TXT=43440 bytes) (Status: + INFORMATIONAL) + +2352 A Convention For Using Legal Names as Domain Names. O. Vaughan. + May 1998. (Format: TXT=16354 bytes) (Obsoletes RFC2240) (Status: + INFORMATIONAL) + +2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages + Document. G. Dudley. May 1998. (Format: TXT=116972 bytes) (Status: + INFORMATIONAL) + +2354 Options for Repair of Streaming Media. C. Perkins, O. Hodson. + June 1998. (Format: TXT=28876 bytes) (Status: INFORMATIONAL) + +2355 TN3270 Enhancements. B. Kelly. June 1998. (Format: TXT=89394 + bytes) (Obsoletes RFC1647) (Status: DRAFT STANDARD) + +2356 Sun's SKIP Firewall Traversal for Mobile IP. G. Montenegro, V. + Gupta. June 1998. (Format: TXT=53198 bytes) (Status: INFORMATIONAL) + +2357 IETF Criteria for Evaluating Reliable Multicast Transport and + Application Protocols. A. Mankin, A. Romanow, S. Bradner, V. Paxson. + June 1998. (Format: TXT=24130 bytes) (Status: INFORMATIONAL) + +2358 Definitions of Managed Objects for the Ethernet-like Interface + Types. J. Flick, J. Johnson. June 1998. (Format: TXT=87891 bytes) + (Obsoletes RFC1650) (Obsoleted by RFC2665) (Status: PROPOSED + STANDARD) + +2359 IMAP4 UIDPLUS extension. J. Myers. June 1998. (Format: TXT=10862 + bytes) (Status: PROPOSED STANDARD) + +2360 Guide for Internet Standards Writers. G. Scott. June 1998. + (Format: TXT=47280 bytes) (Also BCP0022) (Status: BEST CURRENT + PRACTICE) + +2361 WAVE and AVI Codec Registries. E. Fleischman. June 1998. (Format: + TXT=97796 bytes) (Status: INFORMATIONAL) + +2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol + Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. + Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June + 1998. (Format: TXT=159833 bytes) (Obsoletes RFC2117) (Status: + EXPERIMENTAL) + +2363 PPP Over FUNI. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. + July 1998. (Format: TXT=22576 bytes) (Status: PROPOSED STANDARD) + +2364 PPP Over AAL5. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. + July 1998. (Format: TXT=23539 bytes) (Status: PROPOSED STANDARD) + +2365 Administratively Scoped IP Multicast. D. Meyer. July 1998. + (Format: TXT=17770 bytes) (Also BCP0023) (Status: BEST CURRENT + PRACTICE) + +2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 + based ATM Networks. C. Chung, M. Greene. July 1998. (Format: + TXT=134312 bytes) (Obsoleted by RFC2417) (Status: PROPOSED STANDARD) + +2367 PF_KEY Key Management API, Version 2. D. McDonald, C. Metz, B. + Phan. July 1998. (Format: TXT=146754 bytes) (Status: INFORMATIONAL) + +2368 The mailto URL scheme. P. Hoffman, L. Masinter, J. Zawinski. July + 1998. (Format: TXT=16502 bytes) (Updates RFC1738, RFC1808) (Status: + PROPOSED STANDARD) + +2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and + their Transport through Message Header Fields. G. Neufeld, J. Baer. + July 1998. (Format: TXT=30853 bytes) (Status: PROPOSED STANDARD) + +2370 The OSPF Opaque LSA Option. R. Coltun. July 1998. (Format: + TXT=33789 bytes) (Also RFC2328) (Status: PROPOSED STANDARD) + +2371 Transaction Internet Protocol Version 3.0. J. Lyon, K. Evans, J. + Klein. July 1998. (Format: TXT=71399 bytes) (Status: PROPOSED + STANDARD) + +2372 Transaction Internet Protocol - Requirements and Supplemental + Information. K. Evans, J. Klein, J. Lyon. July 1998. (Format: + TXT=53699 bytes) (Status: INFORMATIONAL) + +2373 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. July + 1998. (Format: TXT=52526 bytes) (Obsoletes RFC1884) (Status: PROPOSED + STANDARD) + +2374 An IPv6 Aggregatable Global Unicast Address Format. R. Hinden, M. + O'Dell, S. Deering. July 1998. (Format: TXT=25068 bytes) (Obsoletes + RFC2073) (Status: PROPOSED STANDARD) + +2375 IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July + 1998. (Format: TXT=14356 bytes) (Status: INFORMATIONAL) + +2376 XML Media Types. E. Whitehead, M. Murata. July 1998. (Format: + TXT=32143 bytes) (Obsoleted by RFC3023) (Status: INFORMATIONAL) + +2377 Naming Plan for Internet Directory-Enabled Applications. A. + Grimstad, R. Huber, S. Sataluri, M. Wahl. September 1998. (Format: + TXT=38274 bytes) (Status: INFORMATIONAL) + +2378 The CCSO Nameserver (Ph) Architecture. R. Hedberg, P. Pomes. + September 1998. (Format: TXT=38960 bytes) (Status: INFORMATIONAL) + +2379 RSVP over ATM Implementation Guidelines. L. Berger. August 1998. + (Format: TXT=15174 bytes) (Also BCP0024) (Status: BEST CURRENT + PRACTICE) + +2380 RSVP over ATM Implementation Requirements. L. Berger. August + 1998. (Format: TXT=31234 bytes) (Status: PROPOSED STANDARD) + +2381 Interoperation of Controlled-Load Service and Guaranteed Service + with ATM. M. Garrett, M. Borden. August 1998. (Format: TXT=107299 + bytes) (Status: PROPOSED STANDARD) + +2382 A Framework for Integrated Services and RSVP over ATM. E. + Crawley, L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. + August 1998. (Format: TXT=73865 bytes) (Status: INFORMATIONAL) + +2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version. M. + Suzuki. August 1998. (Format: TXT=99889 bytes) (Status: + INFORMATIONAL) + +2384 POP URL Scheme. R. Gellens. August 1998. (Format: TXT=13649 + bytes) (Status: PROPOSED STANDARD) + +2385 Protection of BGP Sessions via the TCP MD5 Signature Option. A. + Heffernan. August 1998. (Format: TXT=12315 bytes) (Status: PROPOSED + STANDARD) + +2386 A Framework for QoS-based Routing in the Internet. E. Crawley, R. + Nair, B. Rajagopalan, H. Sandick. August 1998. (Format: TXT=93459 + bytes) (Status: INFORMATIONAL) + +2387 The MIME Multipart/Related Content-type. E. Levinson. August + 1998. (Format: TXT=18864 bytes) (Obsoletes RFC2112) (Status: PROPOSED + STANDARD) + +2388 Returning Values from Forms: multipart/form-data. L. Masinter. + August 1998. (Format: TXT=16531 bytes) (Status: PROPOSED STANDARD) + +2389 Feature negotiation mechanism for the File Transfer Protocol. P. + Hethmon, R. Elz. August 1998. (Format: TXT=18536 bytes) (Also + RFC0959) (Status: PROPOSED STANDARD) + +2390 Inverse Address Resolution Protocol. T. Bradley, C. Brown, A. + Malis. September 1998. (Format: TXT=20849 bytes) (Obsoletes RFC1293) + (Status: DRAFT STANDARD) + +2391 Load Sharing using IP Network Address Translation (LSNAT). P. + Srisuresh, D. Gan. August 1998. (Format: TXT=44884 bytes) (Status: + INFORMATIONAL) + +2392 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. + August 1998. (Format: TXT=11141 bytes) (Obsoletes RFC2111) (Status: + PROPOSED STANDARD) + +2393 IP Payload Compression Protocol (IPComp). A. Shacham, R. Monsour, + R. Pereira, M. Thomas. December 1998. (Format: TXT=20757 bytes) + (Obsoleted by RFC3173) (Status: PROPOSED STANDARD) + +2394 IP Payload Compression Using DEFLATE. R. Pereira. December 1998. + (Format: TXT=11053 bytes) (Status: INFORMATIONAL) + +2395 IP Payload Compression Using LZS. R. Friend, R. Monsour. December + 1998. (Format: TXT=14882 bytes) (Status: INFORMATIONAL) + +2396 Uniform Resource Identifiers (URI): Generic Syntax. T. + Berners-Lee, R. Fielding, L. Masinter. August 1998. (Format: + TXT=83639 bytes) (Updates RFC1808, RFC1738) (Status: DRAFT STANDARD) + +2397 The "data" URL scheme. L. Masinter. August 1998. (Format: + TXT=9514 bytes) (Status: PROPOSED STANDARD) + +2398 Some Testing Tools for TCP Implementors. S. Parker, C. Schmechel. + August 1998. (Format: TXT=24107 bytes) (Also FYI0033) (Status: + INFORMATIONAL) + +2399 Request for Comments Summary. A. Ramos. January 1999. (Format: + TXT=45853 bytes) (Status: INFORMATIONAL) + +2400 Internet Official Protocol Standards. J. Postel, J. Reynolds. + September 1998. (Format: TXT=110969 bytes) (Obsoletes RFC2300) + (Obsoleted by RFC2500) (Status: HISTORIC) + +2401 Security Architecture for the Internet Protocol. S. Kent, R. + Atkinson. November 1998. (Format: TXT=168162 bytes) (Obsoletes + RFC1825) (Status: PROPOSED STANDARD) + +2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998. + (Format: TXT=52831 bytes) (Obsoletes RFC1826) (Status: PROPOSED + STANDARD) + +2403 The Use of HMAC-MD5-96 within ESP and AH. C. Madson, R. Glenn. + November 1998. (Format: TXT=13578 bytes) (Status: PROPOSED STANDARD) + +2404 The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn. + November 1998. (Format: TXT=13089 bytes) (Status: PROPOSED STANDARD) + +2405 The ESP DES-CBC Cipher Algorithm With Explicit IV. C. Madson, N. + Doraswamy. November 1998. (Format: TXT=20208 bytes) (Status: PROPOSED + STANDARD) + +2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. + November 1998. (Format: TXT=54202 bytes) (Obsoletes RFC1827) (Status: + PROPOSED STANDARD) + +2407 The Internet IP Security Domain of Interpretation for ISAKMP. D. + Piper. November 1998. (Format: TXT=67878 bytes) (Status: PROPOSED + STANDARD) + +2408 Internet Security Association and Key Management Protocol + (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November + 1998. (Format: TXT=209175 bytes) (Status: PROPOSED STANDARD) + +2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November + 1998. (Format: TXT=94949 bytes) (Status: PROPOSED STANDARD) + +2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, + S. Kent. November 1998. (Format: TXT=11239 bytes) (Status: PROPOSED + STANDARD) + +2411 IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. + November 1998. (Format: TXT=22983 bytes) (Status: INFORMATIONAL) + +2412 The OAKLEY Key Determination Protocol. H. Orman. November 1998. + (Format: TXT=118649 bytes) (Status: INFORMATIONAL) + +2413 Dublin Core Metadata for Resource Discovery. S. Weibel, J. Kunze, + C. Lagoze, M. Wolf. September 1998. (Format: TXT=15501 bytes) + (Status: INFORMATIONAL) + +2414 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. + Partridge. September 1998. (Format: TXT=32019 bytes) (Status: + EXPERIMENTAL) + +2415 Simulation Studies of Increased Initial TCP Window Size. K. + Poduri, K. Nichols. September 1998. (Format: TXT=24205 bytes) + (Status: INFORMATIONAL) + +2416 When TCP Starts Up With Four Packets Into Only Three Buffers. T. + Shepard, C. Partridge. September 1998. (Format: TXT=12663 bytes) + (Status: INFORMATIONAL) + +2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 + based ATM Networks. C. Chung, M. Greene. September 1998. (Format: + TXT=134862 bytes) (Obsoletes RFC2366) (Status: PROPOSED STANDARD) + +2418 IETF Working Group Guidelines and Procedures. S. Bradner. + September 1998. (Format: TXT=62857 bytes) (Obsoletes RFC1603) (Also + BCP0025) (Status: BEST CURRENT PRACTICE) + +2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis). K. + Sklower, G. Meyer. September 1998. (Format: TXT=24414 bytes) + (Obsoletes RFC1969) (Status: PROPOSED STANDARD) + +2420 The PPP Triple-DES Encryption Protocol (3DESE). H. Kummert. + September 1998. (Format: TXT=16729 bytes) (Status: PROPOSED STANDARD) + +2421 Voice Profile for Internet Mail - version 2. G. Vaudreuil, G. + Parsons. September 1998. (Format: TXT=123663 bytes) (Obsoletes + RFC1911) (Status: PROPOSED STANDARD) + +2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration. + G. Vaudreuil, G. Parsons. September 1998. (Format: TXT=10157 bytes) + (Obsoletes RFC1911) (Status: PROPOSED STANDARD) + +2423 VPIM Voice Message MIME Sub-type Registration. G. Vaudreuil, G. + Parsons. September 1998. (Format: TXT=10729 bytes) (Obsoletes + RFC1911) (Status: PROPOSED STANDARD) + +2424 Content Duration MIME Header Definition. G. Vaudreuil, G. + Parsons. September 1998. (Format: TXT=7116 bytes) (Status: PROPOSED + STANDARD) + +2425 A MIME Content-Type for Directory Information. T. Howes, M. + Smith, F. Dawson. September 1998. (Format: TXT=64478 bytes) (Status: + PROPOSED STANDARD) + +2426 vCard MIME Directory Profile. F. Dawson, T. Howes. September + 1998. (Format: TXT=74646 bytes) (Status: PROPOSED STANDARD) + +2427 Multiprotocol Interconnect over Frame Relay. C. Brown, A. Malis. + September 1998. (Format: TXT=74671 bytes) (Obsoletes RFC1490, + RFC1294) (Also STD0055) (Status: STANDARD) + +2428 FTP Extensions for IPv6 and NATs. M. Allman, S. Ostermann, C. + Metz. September 1998. (Format: TXT=16028 bytes) (Status: PROPOSED + STANDARD) + +2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video + (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, + D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. October 1998. + (Format: TXT=43166 bytes) (Status: PROPOSED STANDARD) + +2430 A Provider Architecture for Differentiated Services and Traffic + Engineering (PASTE). T. Li, Y. Rekhter. October 1998. (Format: + TXT=40148 bytes) (Status: INFORMATIONAL) + +2431 RTP Payload Format for BT.656 Video Encoding. D. Tynan. October + 1998. (Format: TXT=22323 bytes) (Status: PROPOSED STANDARD) + +2432 Terminology for IP Multicast Benchmarking. K. Dubray. October + 1998. (Format: TXT=29758 bytes) (Status: INFORMATIONAL) + +2433 Microsoft PPP CHAP Extensions. G. Zorn, S. Cobb. October 1998. + (Format: TXT=34502 bytes) (Status: INFORMATIONAL) + +2434 Guidelines for Writing an IANA Considerations Section in RFCs. T. + Narten, H. Alvestrand. October 1998. (Format: TXT=25092 bytes) (Also + BCP0026) (Status: BEST CURRENT PRACTICE) + +2435 RTP Payload Format for JPEG-compressed Video. L. Berc, W. Fenner, + R. Frederick, S. McCanne, P. Stewart. October 1998. (Format: + TXT=54173 bytes) (Obsoletes RFC2035) (Status: PROPOSED STANDARD) + +2436 Collaboration between ISOC/IETF and ITU-T. R. Brett, S. Bradner, + G. Parsons. October 1998. (Format: TXT=31154 bytes) (Status: + INFORMATIONAL) + +2437 PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, + J. Staddon. October 1998. (Format: TXT=73529 bytes) (Obsoletes + RFC2313) (Status: INFORMATIONAL) + +2438 Advancement of MIB specifications on the IETF Standards Track. M. + O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. October 1998. (Format: + TXT=13633 bytes) (Also BCP0027) (Status: BEST CURRENT PRACTICE) + +2439 BGP Route Flap Damping. C. Villamizar, R. Chandra, R. Govindan. + November 1998. (Format: TXT=86376 bytes) (Status: PROPOSED STANDARD) + +2440 OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R. + Thayer. November 1998. (Format: TXT=141371 bytes) (Status: PROPOSED + STANDARD) + +2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998. D. + Cohen. November 1998. (Format: TXT=11992 bytes) (Status: + INFORMATIONAL) + +2442 The Batch SMTP Media Type. N. Freed, D. Newman, J. Belissen, M. + Hoy. November 1998. (Format: TXT=18384 bytes) (Status: INFORMATIONAL) + +2443 A Distributed MARS Service Using SCSP. J. Luciani, A. Gallo. + November 1998. (Format: TXT=41451 bytes) (Status: EXPERIMENTAL) + +2444 The One-Time-Password SASL Mechanism. C. Newman. October 1998. + (Format: TXT=13408 bytes) (Updates RFC2222) (Status: PROPOSED + STANDARD) + +2445 Internet Calendaring and Scheduling Core Object Specification + (iCalendar). F. Dawson, D. Stenerson. November 1998. (Format: + TXT=291838 bytes) (Status: PROPOSED STANDARD) + +2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) + Scheduling Events, BusyTime, To-dos and Journal Entries. S. + Silverberg, S. Mansour, F. Dawson, R. Hopson. November 1998. (Format: + TXT=225964 bytes) (Status: PROPOSED STANDARD) + +2447 iCalendar Message-Based Interoperability Protocol (iMIP). F. + Dawson, S. Mansour, S. Silverberg. November 1998. (Format: TXT=33480 + bytes) (Status: PROPOSED STANDARD) + +2448 AT&T's Error Resilient Video Transmission Technique. M. Civanlar, + G. Cash, B. Haskell. November 1998. (Format: TXT=14655 bytes) + (Status: INFORMATIONAL) + +2449 POP3 Extension Mechanism. R. Gellens, C. Newman, L. Lundblade. + November 1998. (Format: TXT=36017 bytes) (Updates RFC1939) (Status: + PROPOSED STANDARD) + +2450 Proposed TLA and NLA Assignment Rule. R. Hinden. December 1998. + (Format: TXT=24486 bytes) (Status: INFORMATIONAL) + +2451 The ESP CBC-Mode Cipher Algorithms. R. Pereira, R. Adams. + November 1998. (Format: TXT=26400 bytes) (Status: PROPOSED STANDARD) + +2452 IP Version 6 Management Information Base for the Transmission + Control Protocol. M. Daniele. December 1998. (Format: TXT=19066 + bytes) (Status: PROPOSED STANDARD) + +2453 RIP Version 2. G. Malkin. November 1998. (Format: TXT=98462 + bytes) (Obsoletes RFC1723) (Also STD0056) (Status: STANDARD) + +2454 IP Version 6 Management Information Base for the User Datagram + Protocol. M. Daniele. December 1998. (Format: TXT=15862 bytes) + (Status: PROPOSED STANDARD) + +2455 Definitions of Managed Objects for APPN. B. Clouston, B. Moore. + November 1998. (Format: TXT=251061 bytes) (Obsoletes RFC2155) + (Status: PROPOSED STANDARD) + +2456 Definitions of Managed Objects for APPN TRAPS. B. Clouston, B. + Moore. November 1998. (Format: TXT=44023 bytes) (Status: PROPOSED + STANDARD) + +2457 Definitions of Managed Objects for Extended Border Node. B. + Clouston, B. Moore. November 1998. (Format: TXT=54380 bytes) (Status: + PROPOSED STANDARD) + +2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT + Implementations. H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F. + Burg, A., DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K. + Vishwanathan. November 1998. (Format: TXT=139100 bytes) (Status: + INFORMATIONAL) + +2459 Internet X.509 Public Key Infrastructure Certificate and CRL + Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999. + (Format: TXT=278438 bytes) (Status: PROPOSED STANDARD) + +2460 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. + Hinden. December 1998. (Format: TXT=85490 bytes) (Obsoletes RFC1883) + (Status: DRAFT STANDARD) + +2461 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. + Nordmark, W. Simpson. December 1998. (Format: TXT=222516 bytes) + (Obsoletes RFC1970) (Status: DRAFT STANDARD) + +2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. + December 1998. (Format: TXT=61210 bytes) (Obsoletes RFC1971) (Status: + DRAFT STANDARD) + +2463 Internet Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering. + December 1998. (Format: TXT=34190 bytes) (Obsoletes RFC1885) (Status: + DRAFT STANDARD) + +2464 Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. + December 1998. (Format: TXT=12725 bytes) (Obsoletes RFC1972) (Status: + PROPOSED STANDARD) + +2465 Management Information Base for IP Version 6: Textual Conventions + and General Group. D. Haskin, S. Onishi. December 1998. (Format: + TXT=77339 bytes) (Status: PROPOSED STANDARD) + +2466 Management Information Base for IP Version 6: ICMPv6 Group. D. + Haskin, S. Onishi. December 1998. (Format: TXT=27547 bytes) (Status: + PROPOSED STANDARD) + +2467 Transmission of IPv6 Packets over FDDI Networks. M. Crawford. + December 1998. (Format: TXT=16028 bytes) (Obsoletes RFC2019) (Status: + PROPOSED STANDARD) + +2468 I REMEMBER IANA. V. Cerf. October 1998. (Format: TXT=8543 bytes) + (Status: INFORMATIONAL) + +2469 A Caution On The Canonical Ordering Of Link-Layer Addresses. T. + Narten, C. Burton. December 1998. (Format: TXT=9948 bytes) (Status: + INFORMATIONAL) + +2470 Transmission of IPv6 Packets over Token Ring Networks. M. + Crawford, T. Narten, S. Thomas. December 1998. (Format: TXT=21677 + bytes) (Status: PROPOSED STANDARD) + +2471 IPv6 Testing Address Allocation. R. Hinden, R. Fink, J. Postel + (deceased). December 1998. (Format: TXT=8031 bytes) (Obsoletes + RFC1897) (Status: EXPERIMENTAL) + +2472 IP Version 6 over PPP. D. Haskin, E. Allen. December 1998. + (Format: TXT=29696 bytes) (Obsoletes RFC2023) (Status: PROPOSED + STANDARD) + +2473 Generic Packet Tunneling in IPv6 Specification. A. Conta, S. + Deering. December 1998. (Format: TXT=77956 bytes) (Status: PROPOSED + STANDARD) + +2474 Definition of the Differentiated Services Field (DS Field) in the + IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black. + December 1998. (Format: TXT=50576 bytes) (Obsoletes RFC1455, RFC1349) + (Status: PROPOSED STANDARD) + +2475 An Architecture for Differentiated Service. S. Blake, D. Black, + M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998. (Format: + TXT=94786 bytes) (Status: INFORMATIONAL) + +2476 Message Submission. R. Gellens, J. Klensin. December 1998. + (Format: TXT=30050 bytes) (Status: PROPOSED STANDARD) + +2477 Criteria for Evaluating Roaming Protocols. B. Aboba, G. Zorn. + January 1999. (Format: TXT=23530 bytes) (Status: INFORMATIONAL) + +2478 The Simple and Protected GSS-API Negotiation Mechanism. E. Baize, + D. Pinkas. December 1998. (Format: TXT=35581 bytes) (Status: PROPOSED + STANDARD) + +2479 Independent Data Unit Protection Generic Security Service + Application Program Interface (IDUP-GSS-API). C. Adams. December + 1998. (Format: TXT=156070 bytes) (Status: INFORMATIONAL) + +2480 Gateways and MIME Security Multiparts. N. Freed. January 1999. + (Format: TXT=11751 bytes) (Status: PROPOSED STANDARD) + +2481 A Proposal to add Explicit Congestion Notification (ECN) to IP. + K. Ramakrishnan, S. Floyd. January 1999. (Format: TXT=64559 bytes) + (Status: EXPERIMENTAL) + +2482 Language Tagging in Unicode Plain Text. K. Whistler, G. Adams. + January 1999. (Format: TXT=27800 bytes) (Status: INFORMATIONAL) + +2483 URI Resolution Services Necessary for URN Resolution. M. + Mealling, R. Daniel. January 1999. (Format: TXT=30518 bytes) (Status: + EXPERIMENTAL) + +2484 PPP LCP Internationalization Configuration Option. G. Zorn. + January 1999. (Format: TXT=8330 bytes) (Updates RFC2284, RFC1994, + RFC1570) (Status: PROPOSED STANDARD) + +2485 DHCP Option for The Open Group's User Authentication Protocol. S. + Drach. January 1999. (Format: TXT=7205 bytes) (Status: PROPOSED + STANDARD) + +2486 The Network Access Identifier. B. Aboba, M. Beadles. January + 1999. (Format: TXT=14261 bytes) (Status: PROPOSED STANDARD) + +2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman. + January 1999. (Format: TXT=15120 bytes) (Status: PROPOSED STANDARD) + +2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms. + M. Allman, D. Glover, L. Sanchez. January 1999. (Format: TXT=47857 + bytes) (Also BCP0028) (Status: BEST CURRENT PRACTICE) + +2489 Procedure for Defining New DHCP Options. R. Droms. January 1999. + (Format: TXT=10484 bytes) (Obsoleted by RFC2939) (Also BCP0029) + (Status: BEST CURRENT PRACTICE) + +2490 A Simulation Model for IP Multicast with RSVP. M. Pullen, R. + Malghan, L. Lavu, G. Duan, J. Ma, H. Nah. January 1999. (Format: + TXT=74936, PS=1956365, PDF=135368 bytes) (Status: INFORMATIONAL) + +2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks. G. + Armitage, P. Schulter, M. Jork, G. Harter. January 1999. (Format: + TXT=100782 bytes) (Status: PROPOSED STANDARD) + +2492 IPv6 over ATM Networks. G. Armitage, P. Schulter, M. Jork. + January 1999. (Format: TXT=21199 bytes) (Status: PROPOSED STANDARD) + +2493 Textual Conventions for MIB Modules Using Performance History + Based on 15 Minute Intervals. K. Tesink, Ed. January 1999. (Format: + TXT=18749 bytes) (Status: PROPOSED STANDARD) + +2494 Definitions of Managed Objects for the DS0 and DS0 Bundle + Interface Type. D. Fowler, Ed. January 1999. (Format: TXT=47208 + bytes) (Status: PROPOSED STANDARD) + +2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 + Interface Types. D. Fowler, Ed. January 1999. (Format: TXT=155560 + bytes) (Obsoletes RFC1406) (Status: PROPOSED STANDARD) + +2496 Definitions of Managed Object for the DS3/E3 Interface Type. D. + Fowler, Ed. January 1999. (Format: TXT=124251 bytes) (Obsoletes + RFC1407) (Status: PROPOSED STANDARD) + +2497 Transmission of IPv6 Packets over ARCnet Networks. I. Souvatzis. + January 1999. (Format: TXT=10304 bytes) (Also RFC1201) (Status: + PROPOSED STANDARD) + +2498 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. + January 1999. (Format: TXT=17869 bytes) (Obsoleted by RFC2678) + (Status: EXPERIMENTAL) + +2499 Request for Comments Summary. A. Ramos. July 1999. (Format: + TXT=43431 bytes) (Status: INFORMATIONAL) + +2500 Internet Official Protocol Standards. J. Reynolds, R. Braden. + June 1999. (Format: TXT=78845 bytes) (Obsoletes RFC2400) (Obsoleted + by RFC2600) (Status: HISTORIC) + +2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance + Issues and Evaluation Considerations. S. Corson, J. Macker. January + 1999. (Format: TXT=28912 bytes) (Status: INFORMATIONAL) + +2502 Limitations of Internet Protocol Suite for Distributed Simulation + the Large Multicast Environment. M. Pullen, M. Myjak, C. Bouwens. + February 1999. (Format: TXT=28190 bytes) (Status: INFORMATIONAL) + +2503 MIME Types for Use with the ISO ILL Protocol. R. Moulton, M. + Needleman. February 1999. (Format: TXT=9078 bytes) (Status: + INFORMATIONAL) + +2504 Users' Security Handbook. E. Guttman, L. Leong, G. Malkin. + February 1999. (Format: TXT=74036 bytes) (Also FYI0034) (Status: + INFORMATIONAL) + +2505 Anti-Spam Recommendations for SMTP MTAs. G. Lindberg. February + 1999. (Format: TXT=53597 bytes) (Also BCP0030) (Status: BEST CURRENT + PRACTICE) + +2506 Media Feature Tag Registration Procedure. K. Holtman, A. Mutz, T. + Hardie. March 1999. (Format: TXT=24892 bytes) (Also BCP0031) (Status: + BEST CURRENT PRACTICE) + +2507 IP Header Compression. M. Degermark, B. Nordgren, S. Pink. + February 1999. (Format: TXT=106292 bytes) (Status: PROPOSED STANDARD) + +2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. S. + Casner, V. Jacobson. February 1999. (Format: TXT=60474 bytes) + (Status: PROPOSED STANDARD) + +2509 IP Header Compression over PPP. M. Engan, S. Casner, C. Bormann. + February 1999. (Format: TXT=18676 bytes) (Status: PROPOSED STANDARD) + +2510 Internet X.509 Public Key Infrastructure Certificate Management + Protocols. C. Adams, S. Farrell. March 1999. (Format: TXT=158178 + bytes) (Status: PROPOSED STANDARD) + +2511 Internet X.509 Certificate Request Message Format. M. Myers, C. + Adams, D. Solo, D. Kemp. March 1999. (Format: TXT=48278 bytes) + (Status: PROPOSED STANDARD) + +2512 Accounting Information for ATM Networks. K. McCloghrie, J. + Heinanen, W. Greene, A. Prasad. February 1999. (Format: TXT=29119 + bytes) (Status: PROPOSED STANDARD) + +2513 Managed Objects for Controlling the Collection and Storage of + Accounting Information for Connection-Oriented Networks. K. + McCloghrie, J. Heinanen, W. Greene, A. Prasad. February 1999. + (Format: TXT=60789 bytes) (Status: PROPOSED STANDARD) + +2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM + Management. M. Noto, E. Spiegel, K. Tesink. February 1999. (Format: + TXT=37583 bytes) (Status: PROPOSED STANDARD) + +2515 Definitions of Managed Objects for ATM Management. K. Tesink, Ed. + February 1999. (Format: TXT=179993 bytes) (Obsoletes RFC1695) + (Status: PROPOSED STANDARD) + +2516 A Method for Transmitting PPP Over Ethernet (PPPoE). L. Mamakos, + K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. February 1999. + (Format: TXT=32537 bytes) (Status: INFORMATIONAL) + +2517 Building Directories from DNS: Experiences from WWWSeeker. R. + Moats, R. Huber. February 1999. (Format: TXT=14001 bytes) (Status: + INFORMATIONAL) + +2518 HTTP Extensions for Distributed Authoring -- WEBDAV. Y. Goland, + E. Whitehead, A. Faizi, S. Carter, D. Jensen. February 1999. (Format: + TXT=202829 bytes) (Status: PROPOSED STANDARD) + +2519 A Framework for Inter-Domain Route Aggregation. E. Chen, J. + Stewart. February 1999. (Format: TXT=25394 bytes) (Status: + INFORMATIONAL) + +2520 NHRP with Mobile NHCs. J. Luciani, H. Suzuki, N. Doraswamy, D. + Horton. February 1999. (Format: TXT=16763 bytes) (Status: + EXPERIMENTAL) + +2521 ICMP Security Failures Messages. P. Karn, W. Simpson. March 1999. + (Format: TXT=14637 bytes) (Status: EXPERIMENTAL) + +2522 Photuris: Session-Key Management Protocol. P. Karn, W. Simpson. + March 1999. (Format: TXT=157224 bytes) (Status: EXPERIMENTAL) + +2523 Photuris: Extended Schemes and Attributes. P. Karn, W. Simpson. + March 1999. (Format: TXT=38166 bytes) (Status: EXPERIMENTAL) + +2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol + Specification Version 1.3. M. Banan. February 1999. (Format: + TXT=153171 bytes) (Status: INFORMATIONAL) + +2525 Known TCP Implementation Problems. V. Paxson, M Allman, S. + Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. + Volz. March 1999. (Format: TXT=137201 bytes) (Status: INFORMATIONAL) + +2526 Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. Deering. + March 1999. (Format: TXT=14555 bytes) (Status: PROPOSED STANDARD) + +2527 Internet X.509 Public Key Infrastructure Certificate Policy and + Certification Practices Framework. S. Chokhani, W. Ford. March 1999. + (Format: TXT=91860 bytes) (Status: INFORMATIONAL) + +2528 Internet X.509 Public Key Infrastructure Representation of Key + Exchange Algorithm (KEA) Keys in Internet X.509 Public Key + Infrastructure Certificates. R. Housley, W. Polk. March 1999. + (Format: TXT=18273 bytes) (Status: INFORMATIONAL) + +2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. + B. Carpenter, C. Jung. March 1999. (Format: TXT=21049 bytes) (Status: + PROPOSED STANDARD) + +2530 Indicating Supported Media Features Using Extensions to DSN and + MDN. D. Wing. March 1999. (Format: TXT=7824 bytes) (Status: PROPOSED + STANDARD) + +2531 Content Feature Schema for Internet Fax. G. Klyne, L. McIntyre. + March 1999. (Format: TXT=88295 bytes) (Obsoleted by RFC2879) (Status: + PROPOSED STANDARD) + +2532 Extended Facsimile Using Internet Mail. L. Masinter, D. Wing. + March 1999. (Format: TXT=22717 bytes) (Status: PROPOSED STANDARD) + +2533 A Syntax for Describing Media Feature Sets. G. Klyne. March 1999. + (Format: TXT=79057 bytes) (Updated by RFC2938) (Status: PROPOSED + STANDARD) + +2534 Media Features for Display, Print, and Fax. L. Masinter, D. Wing, + A. Mutz, K. Holtman. March 1999. (Format: TXT=15466 bytes) (Status: + PROPOSED STANDARD) + +2535 Domain Name System Security Extensions. D. Eastlake. March 1999. + (Format: TXT=110958 bytes) (Obsoletes RFC2065) (Updates RFC2181, + RFC1035, RFC1034) (Updated by RFC2931, RFC3007, RFC3008, RFC3090) + (Status: PROPOSED STANDARD) + +2536 DSA KEYs and SIGs in the Domain Name System (DNS). D. Eastlake. + March 1999. (Format: TXT=11121 bytes) (Status: PROPOSED STANDARD) + +2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). D. + Eastlake. March 1999. (Format: TXT=10810 bytes) (Status: PROPOSED + STANDARD) + +2538 Storing Certificates in the Domain Name System (DNS). D. + Eastlake, O. Gudmundsson. March 1999. (Format: TXT=19857 bytes) + (Status: PROPOSED STANDARD) + +2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS). + D. Eastlake. March 1999. (Format: TXT=21049 bytes) (Status: PROPOSED + STANDARD) + +2540 Detached Domain Name System (DNS) Information. D. Eastlake. March + 1999. (Format: TXT=12546 bytes) (Status: EXPERIMENTAL) + +2541 DNS Security Operational Considerations. D. Eastlake. March 1999. + (Format: TXT=14498 bytes) (Status: INFORMATIONAL) + +2542 Terminology and Goals for Internet Fax. L. Masinter. March 1999. + (Format: TXT=46372 bytes) (Status: INFORMATIONAL) + +2543 SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E. + Schooler, J. Rosenberg. March 1999. (Format: TXT=338861 bytes) + (Status: PROPOSED STANDARD) + +2544 Benchmarking Methodology for Network Interconnect Devices. S. + Bradner, J. McQuaid. March 1999. (Format: TXT=66688 bytes) (Obsoletes + RFC1944) (Status: INFORMATIONAL) + +2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain + Routing. P. Marques, F. Dupont. March 1999. (Format: TXT=10209 bytes) + (Status: PROPOSED STANDARD) + +2546 6Bone Routing Practice. A. Durand, B. Buclin. March 1999. + (Format: TXT=17844 bytes) (Obsoleted by RFC2772) (Status: + INFORMATIONAL) + +2547 BGP/MPLS VPNs. E. Rosen, Y. Rekhter. March 1999. (Format: + TXT=63270 bytes) (Status: INFORMATIONAL) + +2548 Microsoft Vendor-specific RADIUS Attributes. G. Zorn. March 1999. + (Format: TXT=80763 bytes) (Status: INFORMATIONAL) + +2549 IP over Avian Carriers with Quality of Service. D. Waitzman. + Apr-01-1999. (Format: TXT=9519 bytes) (Updates RFC1149) (Status: + INFORMATIONAL) + +2550 Y10K and Beyond. S. Glassman, M. Manasse, J. Mogul. Apr-01-1999. + (Format: TXT=28011 bytes) (Status: INFORMATIONAL) + +2551 The Roman Standards Process -- Revision III. S. Bradner. + Apr-01-1999. (Format: TXT=28054 bytes) (Status: INFORMATIONAL) + +2552 Architecture for the Information Brokerage in the ACTS Project + GAIA. M. Blinov, M. Bessonov, C. Clissmann. April 1999. (Format: + TXT=65172 bytes) (Status: INFORMATIONAL) + +2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. + Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes) + (Obsoletes RFC2133) (Updated by RFC3152) (Status: INFORMATIONAL) + +2554 SMTP Service Extension for Authentication. J. Myers. March 1999. + (Format: TXT=20534 bytes) (Status: PROPOSED STANDARD) + +2555 30 Years of RFCs. RFC Editor, et al.. Apr-07-1999. (Format: + TXT=42902 bytes) (Status: INFORMATIONAL) + +2556 OSI connectionless transport services on top of UDP Applicability + Statement for Historic Status. S. Bradner. March 1999. (Format: + TXT=5864 bytes) (Status: INFORMATIONAL) + +2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). + J. Palme, A. Hopmann, N. Shelness. March 1999. (Format: TXT=61854 + bytes) (Obsoletes RFC2110) (Status: PROPOSED STANDARD) + +2558 Definitions of Managed Objects for the SONET/SDH Interface Type. + K. Tesink. March 1999. (Format: TXT=138550 bytes) (Obsoletes RFC1595) + (Status: PROPOSED STANDARD) + +2559 Internet X.509 Public Key Infrastructure Operational Protocols - + LDAPv2. S. Boeyen, T. Howes, P. Richard. April 1999. (Format: + TXT=22889 bytes) (Updates RFC1778) (Status: PROPOSED STANDARD) + +2560 X.509 Internet Public Key Infrastructure Online Certificate + Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin, + C. Adams. June 1999. (Format: TXT=43243 bytes) (Status: PROPOSED + STANDARD) + +2561 Base Definitions of Managed Objects for TN3270E Using SMIv2. K. + White, R. Moore. April 1999. (Format: TXT=113705 bytes) (Status: + PROPOSED STANDARD) + +2562 Definitions of Protocol and Managed Objects for TN3270E Response + Time Collection Using SMIv2 (TN3270E-RT-MIB). K. White, R. Moore. + April 1999. (Format: TXT=110633 bytes) (Status: PROPOSED STANDARD) + +2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 + Clients. R. Troll. May 1999. (Format: TXT=17838 bytes) (Status: + PROPOSED STANDARD) + +2564 Application Management MIB. C. Kalbfleisch, C. Krupczak, R. + Presuhn, J. Saperia. May 1999. (Format: TXT=183314 bytes) (Status: + PROPOSED STANDARD) + +2565 Internet Printing Protocol/1.0: Encoding and Transport. R. + Herriot, Ed., S. Butler, P. Moore, R. Turner. April 1999. (Format: + TXT=80439 bytes) (Obsoleted by RFC2910) (Status: EXPERIMENTAL) + +2566 Internet Printing Protocol/1.0: Model and Semantics. R. deBry, T. + Hastings, R. Herriot, S. Isaacson, P. Powell. April 1999. (Format: + TXT=438887 bytes) (Obsoleted by RFC2911) (Status: EXPERIMENTAL) + +2567 Design Goals for an Internet Printing Protocol. F. Wright. April + 1999. (Format: TXT=90260 bytes) (Status: EXPERIMENTAL) + +2568 Rationale for the Structure of the Model and Protocol for the + Internet Printing Protocol. S. Zilles. April 1999. (Format: TXT=23547 + bytes) (Status: EXPERIMENTAL) + +2569 Mapping between LPD and IPP Protocols. R. Herriot, Ed., T. + Hastings, N. Jacobs, J. Martin. April 1999. (Format: TXT=57886 bytes) + (Status: EXPERIMENTAL) + +2570 Introduction to Version 3 of the Internet-standard Network + Management Framework. J. Case, R. Mundy, D. Partain, B. Stewart. + April 1999. (Format: TXT=50381 bytes) (Status: INFORMATIONAL) + +2571 An Architecture for Describing SNMP Management Frameworks. B. + Wijnen, D. Harrington, R. Presuhn. April 1999. (Format: TXT=139260 + bytes) (Obsoletes RFC2271) (Status: DRAFT STANDARD) + +2572 Message Processing and Dispatching for the Simple Network + Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. + Wijnen. April 1999. (Format: TXT=96035 bytes) (Obsoletes RFC2272) + (Status: DRAFT STANDARD) + +2573 SNMP Applications. D. Levi, P. Meyer, B. Stewart. April 1999. + (Format: TXT=150427 bytes) (Obsoletes RFC2273) (Status: DRAFT + STANDARD) + +2574 User-based Security Model (USM) for version 3 of the Simple + Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. April + 1999. (Format: TXT=190755 bytes) (Obsoletes RFC2274) (Status: DRAFT + STANDARD) + +2575 View-based Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. + April 1999. (Format: TXT=79642 bytes) (Obsoletes RFC2275) (Status: + DRAFT STANDARD) + +2576 Coexistence between Version 1, Version 2, and Version 3 of the + Internet-standard Network Management Framework. R. Frye, D. Levi, S. + Routhier, B. Wijnen. March 2000. (Format: TXT=98589 bytes) (Obsoletes + RFC1908, RFC2089) (Status: PROPOSED STANDARD) + +2577 FTP Security Considerations. M. Allman, S. Ostermann. May 1999. + (Format: TXT=17870 bytes) (Status: INFORMATIONAL) + +2578 Structure of Management Information Version 2 (SMIv2). K. + McCloghrie, D. Perkins, J. Schoenwaelder. April 1999. (Format: + TXT=89712 bytes) (Obsoletes RFC1902) (Also STD0058) (Status: + STANDARD) + +2579 Textual Conventions for SMIv2. K. McCloghrie, D. Perkins, J. + Schoenwaelder. April 1999. (Format: TXT=59039 bytes) (Obsoletes + RFC1903) (Also STD0058) (Status: STANDARD) + +2580 Conformance Statements for SMIv2. K. McCloghrie, D. Perkins, J. + Schoenwaelder. April 1999. (Format: TXT=54253 bytes) (Obsoletes + RFC1904) (Also STD0058) (Status: STANDARD) + +2581 TCP Congestion Control. M. Allman, V. Paxson, W. Stevens. April + 1999. (Format: TXT=31351 bytes) (Obsoletes RFC2001) (Status: PROPOSED + STANDARD) + +2582 The NewReno Modification to TCP's Fast Recovery Algorithm. S. + Floyd, T. Henderson. April 1999. (Format: TXT=29393 bytes) (Status: + EXPERIMENTAL) + +2583 Guidelines for Next Hop Client (NHC) Developers. R. Carlson, L. + Winkler. May 1999. (Format: TXT=21338 bytes) (Status: INFORMATIONAL) + +2584 Definitions of Managed Objects for APPN/HPR in IP Networks. B. + Clouston, B. Moore. May 1999. (Format: TXT=40187 bytes) (Status: + PROPOSED STANDARD) + +2585 Internet X.509 Public Key Infrastructure Operational Protocols: + FTP and HTTP. R. Housley, P. Hoffman. May 1999. (Format: TXT=14813 + bytes) (Status: PROPOSED STANDARD) + +2586 The Audio/L16 MIME content type. J. Salsman, H. Alvestrand. May + 1999. (Format: TXT=8694 bytes) (Status: INFORMATIONAL) + +2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema. S. + Boeyen, T. Howes, P. Richard. June 1999. (Format: TXT=15102 bytes) + (Status: PROPOSED STANDARD) + +2588 IP Multicast and Firewalls. R. Finlayson. May 1999. (Format: + TXT=28622 bytes) (Status: INFORMATIONAL) + +2589 Lightweight Directory Access Protocol (v3): Extensions for + Dynamic Directory Services. Y. Yaacovi, M. Wahl, T. Genovese. May + 1999. (Format: TXT=26855 bytes) (Status: PROPOSED STANDARD) + +2590 Transmission of IPv6 Packets over Frame Relay Networks + Specification. A. Conta, A. Malis, M. Mueller. May 1999. (Format: + TXT=41817 bytes) (Status: PROPOSED STANDARD) + +2591 Definitions of Managed Objects for Scheduling Management + Operations. D. Levi, J. Schoenwaelder. May 1999. (Format: TXT=52920 + bytes) (Status: PROPOSED STANDARD) + +2592 Definitions of Managed Objects for the Delegation of Management + Script. D. Levi, J. Schoenwaelder. May 1999. (Format: TXT=110629 + bytes) (Obsoleted by RFC3165) (Status: PROPOSED STANDARD) + +2593 Script MIB Extensibility Protocol Version 1.0. J. Schoenwaelder, + J. Quittek. May 1999. (Format: TXT=49663 bytes) (Status: + EXPERIMENTAL) + +2594 Definitions of Managed Objects for WWW Services. H. Hazewinkel, + C. Kalbfleisch, J. Schoenwaelder. May 1999. (Format: TXT=88876 bytes) + (Status: PROPOSED STANDARD) + +2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. + (Format: TXT=32440 bytes) (Status: PROPOSED STANDARD) + +2596 Use of Language Codes in LDAP. M. Wahl, T. Howes. May 1999. + (Format: TXT=17413 bytes) (Status: PROPOSED STANDARD) + +2597 Assured Forwarding PHB Group. J. Heinanen, F. Baker, W. Weiss, J. + Wroclawski. June 1999. (Format: TXT=24068 bytes) (Status: PROPOSED + STANDARD) + +2598 An Expedited Forwarding PHB. V. Jacobson, K. Nichols, K. Poduri. + June 1999. (Format: TXT=23656 bytes) (Status: PROPOSED STANDARD) + +2599 Request for Comments Summary RFC Numbers 2500-2599. A. DeLaCruz. + March 2000. (Format: TXT=45845 bytes) (Status: INFORMATIONAL) + +2600 Internet Official Protocol Standards. J. Reynolds, R. Braden. + March 2000. (Format: TXT=86139 bytes) (Obsoletes RFC2500) (Obsoleted + by RFC2700) (Status: HISTORIC) + +2601 ILMI-Based Server Discovery for ATMARP. M. Davison. June 1999. + (Format: TXT=11820 bytes) (Status: PROPOSED STANDARD) + +2602 ILMI-Based Server Discovery for MARS. M. Davison. June 1999. + (Format: TXT=12031 bytes) (Status: PROPOSED STANDARD) + +2603 ILMI-Based Server Discovery for NHRP. M. Davison. June 1999. + (Format: TXT=11865 bytes) (Status: PROPOSED STANDARD) + +2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. + June 1999. (Format: TXT=65329 bytes) (Obsoleted by RFC2636) (Status: + INFORMATIONAL) + +2605 Directory Server Monitoring MIB. G. Mansfield, S. Kille. June + 1999. (Format: TXT=49166 bytes) (Obsoletes RFC1567) (Status: PROPOSED + STANDARD) + +2606 Reserved Top Level DNS Names. D. Eastlake, A. Panitz. June 1999. + (Format: TXT=8008 bytes) (Also BCP0032) (Status: BEST CURRENT + PRACTICE) + +2607 Proxy Chaining and Policy Implementation in Roaming. B. Aboba, J. + Vollbrecht. June 1999. (Format: TXT=33271 bytes) (Status: + INFORMATIONAL) + +2608 Service Location Protocol, Version 2. E. Guttman, C. Perkins, J. + Veizades, M. Day. June 1999. (Format: TXT=129475 bytes) (Updates + RFC2165) (Status: PROPOSED STANDARD) + +2609 Service Templates and Service: Schemes. E. Guttman, C. Perkins, + J. Kempf. June 1999. (Format: TXT=72842 bytes) (Updates RFC2165) + (Status: PROPOSED STANDARD) + +2610 DHCP Options for Service Location Protocol. C. Perkins, E. + Guttman. June 1999. (Format: TXT=10859 bytes) (Status: PROPOSED + STANDARD) + +2611 URN Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. + Iannella, P. Falstrom. June 1999. (Format: TXT=26916 bytes) (Also + BCP0033) (Status: BEST CURRENT PRACTICE) + +2612 The CAST-256 Encryption Algorithm. C. Adams, J. Gilchrist. June + 1999. (Format: TXT=37468 bytes) (Status: INFORMATIONAL) + +2613 Remote Network Monitoring MIB Extensions for Switched Networks + Version 1.0. R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser. + June 1999. (Format: TXT=88701 bytes) (Status: PROPOSED STANDARD) + +2614 An API for Service Location. J. Kempf, E. Guttman. June 1999. + (Format: TXT=164002 bytes) (Status: INFORMATIONAL) + +2615 PPP over SONET/SDH. A. Malis, W. Simpson. June 1999. (Format: + TXT=18708 bytes) (Obsoletes RFC1619) (Status: PROPOSED STANDARD) + +2616 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, + J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June + 1999. (Format: TXT=422317, PS=5529857, PDF=550558 bytes) (Obsoletes + RFC2068) (Updated by RFC2817) (Status: DRAFT STANDARD) + +2617 HTTP Authentication: Basic and Digest Access Authentication. J. + Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. + Luotonen, L. Stewart. June 1999. (Format: TXT=77638 bytes) (Obsoletes + RFC2069) (Status: DRAFT STANDARD) + +2618 RADIUS Authentication Client MIB. B. Aboba, G. Zorn. June 1999. + (Format: TXT=26889 bytes) (Status: PROPOSED STANDARD) + +2619 RADIUS Authentication Server MIB. G. Zorn, B. Aboba. June 1999. + (Format: TXT=30464 bytes) (Status: PROPOSED STANDARD) + +2620 RADIUS Accounting Client MIB. B. Aboba, G. Zorn. June 1999. + (Format: TXT=23960 bytes) (Status: INFORMATIONAL) + +2621 RADIUS Accounting Server MIB. G. Zorn, B. Aboba. June 1999. + (Format: TXT=27768 bytes) (Status: INFORMATIONAL) + +2622 Routing Policy Specification Language (RPSL). C. Alaettinoglu, C. + Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, + M. Terpstra. June 1999. (Format: TXT=140811 bytes) (Obsoletes + RFC2280) (Status: PROPOSED STANDARD) + +2623 NFS Version 2 and Version 3 Security Issues and the NFS + Protocol's Use of RPCSEC_GSS and Kerberos V5. M. Eisler. June 1999. + (Format: TXT=42521 bytes) (Status: PROPOSED STANDARD) + +2624 NFS Version 4 Design Considerations. S. Shepler. June 1999. + (Format: TXT=52891 bytes) (Status: INFORMATIONAL) + +2625 IP and ARP over Fibre Channel. M. Rajagopal, R. Bhagwat, W. + Rickard. June 1999. (Format: TXT=137741 bytes) (Status: PROPOSED + STANDARD) + +2626 The Internet and the Millennium Problem (Year 2000). P. Nesser + II. June 1999. (Format: TXT=547560 bytes) (Status: INFORMATIONAL) + +2627 Key Management for Multicast: Issues and Architectures. D. + Wallner, E. Harder, R. Agee. June 1999. (Format: TXT=59263 bytes) + (Status: INFORMATIONAL) + +2628 Simple Cryptographic Program Interface (Crypto API). V. Smyslov. + June 1999. (Format: TXT=60070 bytes) (Status: INFORMATIONAL) + +2629 Writing I-Ds and RFCs using XML. M. Rose. June 1999. (Format: + TXT=48677 bytes) (Status: INFORMATIONAL) + +2630 Cryptographic Message Syntax. R. Housley. June 1999. (Format: + TXT=128599 bytes) (Status: PROPOSED STANDARD) + +2631 Diffie-Hellman Key Agreement Method. E. Rescorla. June 1999. + (Format: TXT=25932 bytes) (Status: PROPOSED STANDARD) + +2632 S/MIME Version 3 Certificate Handling. B. Ramsdell, Ed.. June + 1999. (Format: TXT=27925 bytes) (Status: PROPOSED STANDARD) + +2633 S/MIME Version 3 Message Specification. B. Ramsdell, Ed.. June + 1999. (Format: TXT=67870 bytes) (Status: PROPOSED STANDARD) + +2634 Enhanced Security Services for S/MIME. P. Hoffman, Ed.. June + 1999. (Format: TXT=131153 bytes) (Status: PROPOSED STANDARD) + +2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and + Postings (spam*). S. Hambridge, A. Lunde. June 1999. (Format: + TXT=44669 bytes) (Also FYI0035) (Status: INFORMATIONAL) + +2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. + July 1999. (Format: TXT=65288, PS=1120860, PDF=173655 bytes) + (Obsoletes RFC2604) (Status: INFORMATIONAL) + +2637 Point-to-Point Tunneling Protocol. K. Hamzeh, G. Pall, W. + Verthein, J. Taarud, W. Little, G. Zorn. July 1999. (Format: + TXT=132565 bytes) (Status: INFORMATIONAL) + +2638 A Two-bit Differentiated Services Architecture for the Internet. + K. Nichols, V. Jacobson, L. Zhang. July 1999. (Format: TXT=72785, + PS=1610846, PDF=315195 bytes) (Status: INFORMATIONAL) + +2639 Internet Printing Protocol/1.0: Implementer's Guide. T. Hastings, + C. Manros. July 1999. (Format: TXT=145086 bytes) (Status: + INFORMATIONAL) + +2640 Internationalization of the File Transfer Protocol. B. Curtin. + July 1999. (Format: TXT=57204 bytes) (Updates RFC0959) (Status: + PROPOSED STANDARD) + +2641 Cabletron's VlanHello Protocol Specification Version 4. D. + Hamilton, D. Ruffen. August 1999. (Format: TXT=34686 bytes) (Status: + INFORMATIONAL) + +2642 Cabletron's VLS Protocol Specification. L. Kane. August 1999. + (Format: TXT=204347 bytes) (Status: INFORMATIONAL) + +2643 Cabletron's SecureFast VLAN Operational Model. D. Ruffen, T. Len, + J. Yanacek. August 1999. (Format: TXT=121786 bytes) (Status: + INFORMATIONAL) + +2644 Changing the Default for Directed Broadcasts in Routers. D. + Senie. August 1999. (Format: TXT=6820 bytes) (Updates RFC1812) (Also + BCP0034) (Status: BEST CURRENT PRACTICE) + +2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses. R. + Gellens. August 1999. (Format: TXT=16302 bytes) (Status: PROPOSED + STANDARD) + +2646 The Text/Plain Format Parameter. R. Gellens. August 1999. + (Format: TXT=29175 bytes) (Updates RFC2046) (Status: PROPOSED + STANDARD) + +2647 Benchmarking Terminology for Firewall Performance. D. Newman. + August 1999. (Format: TXT=45374 bytes) (Status: INFORMATIONAL) + +2648 A URN Namespace for IETF Documents. R. Moats. August 1999. + (Format: TXT=46826 bytes) (Status: INFORMATIONAL) + +2649 An LDAP Control and Schema for Holding Operation Signatures. B. + Greenblatt, P. Richard. August 1999. (Format: TXT=20470 bytes) + (Status: EXPERIMENTAL) + +2650 Using RPSL in Practice. D. Meyer, J. Schmitz, C. Orange, M. + Prior, C. Alaettinoglu. August 1999. (Format: TXT=55272 bytes) + (Status: INFORMATIONAL) + +2651 The Architecture of the Common Indexing Protocol (CIP). J. Allen, + M. Mealling. August 1999. (Format: TXT=41933 bytes) (Status: PROPOSED + STANDARD) + +2652 MIME Object Definitions for the Common Indexing Protocol (CIP). + J. Allen, M. Mealling. August 1999. (Format: TXT=42464 bytes) + (Status: PROPOSED STANDARD) + +2653 CIP Transport Protocols. J. Allen, P. Leach, R. Hedberg. August + 1999. (Format: TXT=22999 bytes) (Status: PROPOSED STANDARD) + +2654 A Tagged Index Object for use in the Common Indexing Protocol. R. + Hedberg, B. Greenblatt, R. Moats, M. Wahl. August 1999. (Format: + TXT=46739 bytes) (Status: EXPERIMENTAL) + +2655 CIP Index Object Format for SOIF Objects. T. Hardie, M. Bowman, + D. Hardy, M. Schwartz, D. Wessels. August 1999. (Format: TXT=34285 + bytes) (Status: EXPERIMENTAL) + +2656 Registration Procedures for SOIF Template Types. T. Hardie. + August 1999. (Format: TXT=17409 bytes) (Status: EXPERIMENTAL) + +2657 LDAPv2 Client vs. the Index Mesh. R. Hedberg. August 1999. + (Format: TXT=19251 bytes) (Status: EXPERIMENTAL) + +2658 RTP Payload Format for PureVoice(tm) Audio. K. McKay. August + 1999. (Format: TXT=21895 bytes) (Status: PROPOSED STANDARD) + +2659 Security Extensions For HTML. E. Rescorla, A. Schiffman. August + 1999. (Format: TXT=8134 bytes) (Status: EXPERIMENTAL) + +2660 The Secure HyperText Transfer Protocol. E. Rescorla, A. + Schiffman. August 1999. (Format: TXT=95645 bytes) (Status: + EXPERIMENTAL) + +2661 Layer Two Tunneling Protocol "L2TP". W. Townsley, A. Valencia, A. + Rubens, G. Pall, G. Zorn, B. Palter. August 1999. (Format: TXT=168150 + bytes) (Status: PROPOSED STANDARD) + +2662 Definitions of Managed Objects for the ADSL Lines. G. Bathrick, + F. Ly. August 1999. (Format: TXT=247122 bytes) (Status: PROPOSED + STANDARD) + +2663 IP Network Address Translator (NAT) Terminology and + Considerations. P. Srisuresh, M. Holdrege. August 1999. (Format: + TXT=72265 bytes) (Status: INFORMATIONAL) + +2664 FYI on Questions and Answers - Answers to Commonly Asked "New + Internet User" Questions. R. Plzak, A. Wells, E. Krol. August 1999. + (Format: TXT=23640 bytes) (Obsoletes RFC1594) (Also FYI0004) (Status: + INFORMATIONAL) + +2665 Definitions of Managed Objects for the Ethernet-like Interface + Types. J. Flick, J. Johnson. August 1999. (Format: TXT=110038 bytes) + (Obsoletes RFC2358) (Status: PROPOSED STANDARD) + +2666 Definitions of Object Identifiers for Identifying Ethernet Chip + Sets. J. Flick. August 1999. (Format: TXT=37699 bytes) (Status: + INFORMATIONAL) + +2667 IP Tunnel MIB. D. Thaler. August 1999. (Format: TXT=32770 bytes) + (Status: PROPOSED STANDARD) + +2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment + Units (MAUs). A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. + McMaster, K. McCloghrie, S. Roberts. August 1999. (Format: TXT=121843 + bytes) (Obsoletes RFC2239) (Status: PROPOSED STANDARD) + +2669 DOCSIS Cable Device MIB Cable Device Management Information Base + for DOCSIS compliant Cable Modems and Cable Modem Termination + Systems. M. St. Johns, Ed.. August 1999. (Format: TXT=112880 bytes) + (Status: PROPOSED STANDARD) + +2670 Radio Frequency (RF) Interface Management Information Base for + MCNS/DOCSIS compliant RF interfaces. M. St. Johns, Ed.. August 1999. + (Format: TXT=141077 bytes) (Status: PROPOSED STANDARD) + +2671 Extension Mechanisms for DNS (EDNS0). P. Vixie. August 1999. + (Format: TXT=15257 bytes) (Status: PROPOSED STANDARD) + +2672 Non-Terminal DNS Name Redirection. M. Crawford. August 1999. + (Format: TXT=18321 bytes) (Status: PROPOSED STANDARD) + +2673 Binary Labels in the Domain Name System. M. Crawford. August + 1999. (Format: TXT=12379 bytes) (Status: PROPOSED STANDARD) + +2674 Definitions of Managed Objects for Bridges with Traffic Classes, + Multicast Filtering and Virtual LAN Extensions. E. Bell, A. Smith, P. + Langille, A. Rijhsinghani, K. McCloghrie. August 1999. (Format: + TXT=159971 bytes) (Status: PROPOSED STANDARD) + +2675 IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. + (Format: TXT=17320 bytes) (Obsoletes RFC2147) (Status: PROPOSED + STANDARD) + +2676 QoS Routing Mechanisms and OSPF Extensions. G. Apostolopoulos, S. + Kama, D. Williams, R. Guerin, A. Orda, T. Przygienda. August 1999. + (Format: TXT=124563 bytes) (Status: EXPERIMENTAL) + +2677 Definitions of Managed Objects for the NBMA Next Hop Resolution + Protocol (NHRP). M. Greene, J. Cucchiara, J. Luciani. August 1999. + (Format: TXT=129699 bytes) (Status: PROPOSED STANDARD) + +2678 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. + September 1999. (Format: TXT=18087 bytes) (Obsoletes RFC2498) + (Status: PROPOSED STANDARD) + +2679 A One-way Delay Metric for IPPM. G. Almes, S. Kalidindi, M. + Zekauskas. September 1999. (Format: TXT=43542 bytes) (Status: + PROPOSED STANDARD) + +2680 A One-way Packet Loss Metric for IPPM. G. Almes, S. Kalidindi, M. + Zekauskas. September 1999. (Format: TXT=32266 bytes) (Status: + PROPOSED STANDARD) + +2681 A Round-trip Delay Metric for IPPM. G. Almes, S. Kalidindi, M. + Zekauskas. September 1999. (Format: TXT=44357 bytes) (Status: + PROPOSED STANDARD) + +2682 Performance Issues in VC-Merge Capable ATM LSRs. I. Widjaja, A. + Elwalid. September 1999. (Format: TXT=29491 bytes) (Status: + INFORMATIONAL) + +2683 IMAP4 Implementation Recommendations. B. Leiba. September 1999. + (Format: TXT=56300 bytes) (Status: INFORMATIONAL) + +2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5. D. + Grossman, J. Heinanen. September 1999. (Format: TXT=51390 bytes) + (Obsoletes RFC1483) (Status: PROPOSED STANDARD) + +2685 Virtual Private Networks Identifier. B. Fox, B. Gleeson. + September 1999. (Format: TXT=11168 bytes) (Status: PROPOSED STANDARD) + +2686 The Multi-Class Extension to Multi-Link PPP. C. Bormann. + September 1999. (Format: TXT=24192 bytes) (Status: PROPOSED STANDARD) + +2687 PPP in a Real-time Oriented HDLC-like Framing. C. Bormann. + September 1999. (Format: TXT=28699 bytes) (Status: PROPOSED STANDARD) + +2688 Integrated Services Mappings for Low Speed Networks. S. + Jackowski, D. Putzolu, E. Crawley, B. Davie. September 1999. (Format: + TXT=36685 bytes) (Status: PROPOSED STANDARD) + +2689 Providing Integrated Services over Low-bitrate Links. C. Bormann. + September 1999. (Format: TXT=34345 bytes) (Status: INFORMATIONAL) + +2690 A Proposal for an MOU-Based ICANN Protocol Support Organization. + S. Bradner. September 1999. (Format: TXT=14221 bytes) (Status: + INFORMATIONAL) + +2691 A Memorandum of Understanding for an ICANN Protocol Support + Organization. S. Bradner. September 1999. (Format: TXT=18940 bytes) + (Status: INFORMATIONAL) + +2692 SPKI Requirements. C. Ellison. September 1999. (Format: TXT=29569 + bytes) (Status: EXPERIMENTAL) + +2693 SPKI Certificate Theory. C. Ellison, B. Frantz, B. Lampson, R. + Rivest, B. Thomas, T. Ylonen. September 1999. (Format: TXT=96699 + bytes) (Status: EXPERIMENTAL) + +2694 DNS extensions to Network Address Translators (DNS_ALG). P. + Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan. September 1999. + (Format: TXT=67720 bytes) (Status: INFORMATIONAL) + +2695 Authentication Mechanisms for ONC RPC. A. Chiu. September 1999. + (Format: TXT=39286 bytes) (Status: INFORMATIONAL) + +2696 LDAP Control Extension for Simple Paged Results Manipulation. C. + Weider, A. Herron, A. Anantha, T. Howes. September 1999. (Format: + TXT=12809 bytes) (Status: INFORMATIONAL) + +2697 A Single Rate Three Color Marker. J. Heinanen, R. Guerin. + September 1999. (Format: TXT=10309 bytes) (Status: INFORMATIONAL) + +2698 A Two Rate Three Color Marker. J. Heinanen, R. Guerin. September + 1999. (Format: TXT=9368 bytes) (Status: INFORMATIONAL) + +2699 Request for Comments Summary RFC Numbers 2600-2699. S. Ginoza. + May 2000. (Format: TXT=42462 bytes) (Status: INFORMATIONAL) + +2700 Internet Official Protocol Standards. J. Reynolds, R. Braden. + August 2000. (Format: TXT=90213 bytes) (Obsoletes RFC2600) (Obsoleted + by RFC2800) (Status: HISTORIC) + +2701 Nortel Networks Multi-link Multi-node PPP Bundle Discovery + Protocol. G. Malkin. September 1999. (Format: TXT=17571 bytes) + (Status: INFORMATIONAL) + +2702 Requirements for Traffic Engineering Over MPLS. D. Awduche, J. + Malcolm, J. Agogbua, M. O'Dell, J. McManus. September 1999. (Format: + TXT=68386 bytes) (Status: INFORMATIONAL) + +2703 Protocol-independent Content Negotiation Framework. G. Klyne. + September 1999. (Format: TXT=42071 bytes) (Status: INFORMATIONAL) + +2704 The KeyNote Trust-Management System Version 2. M. Blaze, J. + Feigenbaum, J. Ioannidis, A. Keromytis. September 1999. (Format: + TXT=79998 bytes) (Status: INFORMATIONAL) + +2705 Media Gateway Control Protocol (MGCP) Version 1.0. M. Arango, A. + Dugan, I. Elliott, C. Huitema, S. Pickett. October 1999. (Format: + TXT=304056 bytes) (Status: INFORMATIONAL) + +2706 ECML v1: Field Names for E-Commerce. D. Eastlake, T. Goldstein. + October 1999. (Format: TXT=26135 bytes) (Obsoleted by RFC3106) + (Status: INFORMATIONAL) + +2707 Job Monitoring MIB - V1.0. R. Bergman, T. Hastings, S. Isaacson, + H. Lewis. November 1999. (Format: TXT=255685 bytes) (Status: + INFORMATIONAL) + +2708 Job Submission Protocol Mapping Recommendations for the Job + Monitoring MIB. R. Bergman. November 1999. (Format: TXT=57489 bytes) + (Status: INFORMATIONAL) + +2709 Security Model with Tunnel-mode IPsec for NAT Domains. P. + Srisuresh. October 1999. (Format: TXT=24552 bytes) (Status: + INFORMATIONAL) + +2710 Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. + Fenner, B. Haberman. October 1999. (Format: TXT=46838 bytes) (Status: + PROPOSED STANDARD) + +2711 IPv6 Router Alert Option. C. Partridge, A. Jackson. October 1999. + (Format: TXT=11973 bytes) (Status: PROPOSED STANDARD) + +2712 Addition of Kerberos Cipher Suites to Transport Layer Security + (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT=13763 bytes) + (Status: PROPOSED STANDARD) + +2713 Schema for Representing Java(tm) Objects in an LDAP Directory. V. + Ryan, S. Seligman, R. Lee. October 1999. (Format: TXT=40745 bytes) + (Status: INFORMATIONAL) + +2714 Schema for Representing CORBA Object References in an LDAP + Directory. V. Ryan, S. Seligman, R. Lee. October 1999. (Format: + TXT=14709 bytes) (Status: INFORMATIONAL) + +2715 Interoperability Rules for Multicast Routing Protocols. D. + Thaler. October 1999. (Format: TXT=49638 bytes) (Status: + INFORMATIONAL) + +2716 PPP EAP TLS Authentication Protocol. B. Aboba, D. Simon. October + 1999. (Format: TXT=50108 bytes) (Status: EXPERIMENTAL) + +2717 Registration Procedures for URL Scheme Names. R. Petke, I. King. + November 1999. (Format: TXT=19780 bytes) (Also BCP0035) (Status: BEST + CURRENT PRACTICE) + +2718 Guidelines for new URL Schemes. L. Masinter, H. Alvestrand, D. + Zigmond, R. Petke. November 1999. (Format: TXT=19208 bytes) (Status: + INFORMATIONAL) + +2719 Framework Architecture for Signaling Transport. L. Ong, I. + Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. + Holdrege, C. Sharp. October 1999. (Format: TXT=48646 bytes) (Status: + INFORMATIONAL) + +2720 Traffic Flow Measurement: Meter MIB. N. Brownlee. October 1999. + (Format: TXT=103781 bytes) (Obsoletes RFC2064) (Status: PROPOSED + STANDARD) + +2721 RTFM: Applicability Statement. N. Brownlee. October 1999. + (Format: TXT=21200 bytes) (Status: INFORMATIONAL) + +2722 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. + Ruth. October 1999. (Format: TXT=114064 bytes) (Obsoletes RFC2063) + (Status: INFORMATIONAL) + +2723 SRL: A Language for Describing Traffic Flows and Specifying + Actions for Flow Groups. N. Brownlee. October 1999. (Format: + TXT=44406 bytes) (Status: INFORMATIONAL) + +2724 RTFM: New Attributes for Traffic Flow Measurement. S. Handelman, + S. Stibler, N. Brownlee, G. Ruth. October 1999. (Format: TXT=37951 + bytes) (Status: EXPERIMENTAL) + +2725 Routing Policy System Security. C. Villamizar, C. Alaettinoglu, + D. Meyer, S. Murphy. December 1999. (Format: TXT=101649 bytes) + (Status: PROPOSED STANDARD) + +2726 PGP Authentication for RIPE Database Updates. J. Zsako. December + 1999. (Format: TXT=22594 bytes) (Status: PROPOSED STANDARD) + +2727 IAB and IESG Selection, Confirmation, and Recall Process: + Operation of the Nominating and Recall Committees. J. Galvin. + February 2000. (Format: TXT=33396 bytes) (Obsoletes RFC2282) (Also + BCP0010) (Status: BEST CURRENT PRACTICE) + +2728 The Transmission of IP Over the Vertical Blanking Interval of a + Television Signal. R. Panabaker, S. Wegerif, D. Zigmond. November + 1999. (Format: TXT=49099 bytes) (Status: PROPOSED STANDARD) + +2729 Taxonomy of Communication Requirements for Large-scale Multicast + Applications. P. Bagnall, R. Briscoe, A. Poppitt. December 1999. + (Format: TXT=53322 bytes) (Status: INFORMATIONAL) + +2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP). S. + Hanna, B. Patel, M. Shah. December 1999. (Format: TXT=120341 bytes) + (Status: PROPOSED STANDARD) + +2731 Encoding Dublin Core Metadata in HTML. J. Kunze. December 1999. + (Format: TXT=42450 bytes) (Status: INFORMATIONAL) + +2732 Format for Literal IPv6 Addresses in URL's. R. Hinden, B. + Carpenter, L. Masinter. December 1999. (Format: TXT=7984 bytes) + (Status: PROPOSED STANDARD) + +2733 An RTP Payload Format for Generic Forward Error Correction. J. + Rosenberg, H. Schulzrinne. December 1999. (Format: TXT=53120 bytes) + (Status: PROPOSED STANDARD) + +2734 IPv4 over IEEE 1394. P. Johansson. December 1999. (Format: + TXT=69314 bytes) (Status: PROPOSED STANDARD) + +2735 NHRP Support for Virtual Private Networks. B. Fox, B. Petri. + December 1999. (Format: TXT=26451 bytes) (Status: PROPOSED STANDARD) + +2736 Guidelines for Writers of RTP Payload Format Specifications. M. + Handley, C. Perkins. December 1999. (Format: TXT=24143 bytes) (Also + BCP0036) (Status: BEST CURRENT PRACTICE) + +2737 Entity MIB (Version 2). K. McCloghrie, A. Bierman. December 1999. + (Format: TXT=125141 bytes) (Obsoletes RFC2037) (Status: PROPOSED + STANDARD) + +2738 Corrections to "A Syntax for Describing Media Feature Sets". G. + Klyne. December 1999. (Format: TXT=8353 bytes) (Status: PROPOSED + STANDARD) + +2739 Calendar Attributes for vCard and LDAP. T. Small, D. Hennessy, F. + Dawson. January 2000. (Format: TXT=25892 bytes) (Status: PROPOSED + STANDARD) + +2740 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999. + (Format: TXT=189810 bytes) (Status: PROPOSED STANDARD) + +2741 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B. + Wijnen, M. Ellison, D. Francisco. January 2000. (Format: TXT=199867 + bytes) (Obsoletes RFC2257) (Status: PROPOSED STANDARD) + +2742 Definitions of Managed Objects for Extensible SNMP Agents. L. + Heintz, S. Gudur, M. Ellison. January 2000. (Format: TXT=36644 bytes) + (Status: PROPOSED STANDARD) + +2743 Generic Security Service Application Program Interface Version 2, + Update 1. J. Linn. January 2000. (Format: TXT=229418 bytes) + (Obsoletes RFC2078) (Status: PROPOSED STANDARD) + +2744 Generic Security Service API Version 2 : C-bindings. J. Wray. + January 2000. (Format: TXT=218572 bytes) (Obsoletes RFC1509) (Status: + PROPOSED STANDARD) + +2745 RSVP Diagnostic Messages. A. Terzis, B. Braden, S. Vincent, L. + Zhang. January 2000. (Format: TXT=52256 bytes) (Status: PROPOSED + STANDARD) + +2746 RSVP Operation Over IP Tunnels. A. Terzis, J. Krawczyk, J. + Wroclawski, L. Zhang. January 2000. (Format: TXT=58094 bytes) + (Status: PROPOSED STANDARD) + +2747 RSVP Cryptographic Authentication. F. Baker, B. Lindell, M. + Talwar. January 2000. (Format: TXT=49477 bytes) (Updated by RFC3097) + (Status: PROPOSED STANDARD) + +2748 The COPS (Common Open Policy Service) Protocol. J. Boyle, R. + Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry. January 2000. + (Format: TXT=90906 bytes) (Status: PROPOSED STANDARD) + +2749 COPS usage for RSVP. J. Boyle, R. Cohen, D. Durham, S. Herzog, R. + Rajan, A. Sastry. January 2000. (Format: TXT=33477 bytes) (Status: + PROPOSED STANDARD) + +2750 RSVP Extensions for Policy Control. S. Herzog. January 2000. + (Format: TXT=26379 bytes) (Updates RFC2205) (Status: PROPOSED + STANDARD) + +2751 Signaled Preemption Priority Policy Element. S. Herzog. January + 2000. (Format: TXT=21451 bytes) (Status: PROPOSED STANDARD) + +2752 Identity Representation for RSVP. S. Yadav, R. Yavatkar, R. + Pabbati, P. Ford, T. Moore, S. Herzog. January 2000. (Format: + TXT=33954 bytes) (Status: PROPOSED STANDARD) + +2753 A Framework for Policy-based Admission Control. R. Yavatkar, D. + Pendarakis, R. Guerin. January 2000. (Format: TXT=49763 bytes) + (Status: INFORMATIONAL) + +2754 RPS IANA Issues. C. Alaettinoglu, C. Villamizar, R. Govindan. + January 2000. (Format: TXT=11582 bytes) (Status: INFORMATIONAL) + +2755 Security Negotiation for WebNFS. A. Chiu, M. Eisler, B. + Callaghan. January 2000. (Format: TXT=23493 bytes) (Status: + INFORMATIONAL) + +2756 Hyper Text Caching Protocol (HTCP/0.0). P. Vixie, D. Wessels. + January 2000. (Format: TXT=32176 bytes) (Status: EXPERIMENTAL) + +2757 Long Thin Networks. G. Montenegro, S. Dawkins, M. Kojo, V. + Magret, N. Vaidya. January 2000. (Format: TXT=112988 bytes) (Status: + INFORMATIONAL) + +2758 Definitions of Managed Objects for Service Level Agreements + Performance Monitoring. K. White. February 2000. (Format: TXT=145581 + bytes) (Status: EXPERIMENTAL) + +2759 Microsoft PPP CHAP Extensions, Version 2. G. Zorn. January 2000. + (Format: TXT=34178 bytes) (Status: INFORMATIONAL) + +2760 Ongoing TCP Research Related to Satellites. M. Allman, S. + Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, + J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke. February 2000. + (Format: TXT=111141 bytes) (Status: INFORMATIONAL) + +2761 Terminology for ATM Benchmarking. J. Dunn, C. Martin. February + 2000. (Format: TXT=61219 bytes) (Status: INFORMATIONAL) + +2762 Sampling of the Group Membership in RTP. J. Rosenberg, H. + Schulzrinne. February 2000. (Format: TXT=25796 bytes) (Status: + EXPERIMENTAL) + +2763 Dynamic Hostname Exchange Mechanism for IS-IS. N. Shen, H. Smit. + February 2000. (Format: TXT=8593 bytes) (Status: INFORMATIONAL) + +2764 A Framework for IP Based Virtual Private Networks. B. Gleeson, A. + Lin, J. Heinanen, G. Armitage, A. Malis. February 2000. (Format: + TXT=163215 bytes) (Status: INFORMATIONAL) + +2765 Stateless IP/ICMP Translation Algorithm (SIIT). E. Nordmark. + February 2000. (Format: TXT=59465 bytes) (Status: PROPOSED STANDARD) + +2766 Network Address Translation - Protocol Translation (NAT-PT). G. + Tsirtsis, P. Srisuresh. February 2000. (Format: TXT=49836 bytes) + (Updated by RFC3152) (Status: PROPOSED STANDARD) + +2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS). + K. Tsuchiya, H. Higuchi, Y. Atarashi. February 2000. (Format: + TXT=26402 bytes) (Status: INFORMATIONAL) + +2768 Network Policy and Services: A Report of a Workshop on + Middleware. B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. + Lynch, J. Mambretti, R. Moore, B. Teitelbaum. February 2000. (Format: + TXT=81034 bytes) (Status: INFORMATIONAL) + +2769 Routing Policy System Replication. C. Villamizar, C. + Alaettinoglu, R. Govindan, D. Meyer. February 2000. (Format: + TXT=95255 bytes) (Status: PROPOSED STANDARD) + +2770 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. February 2000. + (Format: TXT=8988 bytes) (Obsoleted by RFC3180) (Status: + EXPERIMENTAL) + +2771 An Abstract API for Multicast Address Allocation. R. Finlayson. + February 2000. (Format: TXT=20954 bytes) (Status: INFORMATIONAL) + +2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February + 2000. (Format: TXT=28565 bytes) (Obsoletes RFC2546) (Updated by + RFC3152) (Status: INFORMATIONAL) + +2773 Encryption using KEA and SKIPJACK. R. Housley, P. Yee, W. Nace. + February 2000. (Format: TXT=20008 bytes) (Updates RFC0959) (Status: + EXPERIMENTAL) + +2774 An HTTP Extension Framework. H. Nielsen, P. Leach, S. Lawrence. + February 2000. (Format: TXT=39719 bytes) (Status: EXPERIMENTAL) + +2775 Internet Transparency. B. Carpenter. February 2000. (Format: + TXT=42956 bytes) (Status: INFORMATIONAL) + +2776 Multicast-Scope Zone Announcement Protocol (MZAP). M. Handley, D. + Thaler, R. Kermode. February 2000. (Format: TXT=61628 bytes) (Status: + PROPOSED STANDARD) + +2777 Publicly Verifiable Nomcom Random Selection. D. Eastlake. + February 2000. (Format: TXT=30064 bytes) (Status: INFORMATIONAL) + +2778 A Model for Presence and Instant Messaging. M. Day, J. Rosenberg, + H. Sugano. February 2000. (Format: TXT=35153 bytes) (Status: + INFORMATIONAL) + +2779 Instant Messaging / Presence Protocol Requirements. M. Day, S. + Aggarwal, G. Mohr, J. Vincent. February 2000. (Format: TXT=47420 + bytes) (Status: INFORMATIONAL) + +2780 IANA Allocation Guidelines For Values In the Internet Protocol + and Related Headers. S. Bradner, V. Paxson. March 2000. (Format: + TXT=18954 bytes) (Also BCP0037) (Status: BEST CURRENT PRACTICE) + +2781 UTF-16, an encoding of ISO 10646. P. Hoffman, F. Yergeau. + February 2000. (Format: TXT=29870 bytes) (Status: INFORMATIONAL) + +2782 A DNS RR for specifying the location of services (DNS SRV). A. + Gulbrandsen, P. Vixie, L. Esibov. February 2000. (Format: TXT=24013 + bytes) (Obsoletes RFC2052) (Status: PROPOSED STANDARD) + +2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version + 1.0. J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl. March + 2000. (Format: TXT=61421 bytes) (Status: INFORMATIONAL) + +2784 Generic Routing Encapsulation (GRE). D. Farinacci, T. Li, S. + Hanks, D. Meyer, P. Traina. March 2000. (Format: TXT=16627 bytes) + (Status: PROPOSED STANDARD) + +2785 Methods for Avoiding the "Small-Subgroup" Attacks on the + Diffie-Hellman Key Agreement Method for S/MIME. R. Zuccherato. March + 2000. (Format: TXT=24415 bytes) (Status: INFORMATIONAL) + +2786 Diffie-Helman USM Key Management Information Base and Textual + Convention. M. St. Johns. March 2000. (Format: TXT=43280 bytes) + (Status: EXPERIMENTAL) + +2787 Definitions of Managed Objects for the Virtual Router Redundancy + Protocol. B. Jewell, D. Chuang. March 2000. (Format: TXT=56672 bytes) + (Status: PROPOSED STANDARD) + +2788 Network Services Monitoring MIB. N. Freed, S. Kille. March 2000. + (Format: TXT=43906 bytes) (Obsoletes RFC2248) (Status: PROPOSED + STANDARD) + +2789 Mail Monitoring MIB. N. Freed, S. Kille. March 2000. (Format: + TXT=65671 bytes) (Obsoletes RFC2249, RFC1566) (Status: PROPOSED + STANDARD) + +2790 Host Resources MIB. S. Waldbusser, P. Grillo. March 2000. + (Format: TXT=95807 bytes) (Obsoletes RFC1514) (Status: DRAFT + STANDARD) + +2791 Scalable Routing Design Principles. J. Yu. July 2000. (Format: + TXT=63416 bytes) (Status: INFORMATIONAL) + +2792 DSA and RSA Key and Signature Encoding for the KeyNote Trust + Management System. M. Blaze, J. Ioannidis, A. Keromytis. March 2000. + (Format: TXT=13461 bytes) (Status: INFORMATIONAL) + +2793 RTP Payload for Text Conversation. G. Hellstrom. May 2000. + (Format: TXT=20674 bytes) (Status: PROPOSED STANDARD) + +2794 Mobile IP Network Access Identifier Extension for IPv4. P. + Calhoun, C. Perkins. March 2000. (Format: TXT=16960 bytes) (Updates + RFC2290) (Status: PROPOSED STANDARD) + +2795 The Infinite Monkey Protocol Suite (IMPS). S. Christey. + Apr-01-2000. (Format: TXT=42902 bytes) (Status: INFORMATIONAL) + +2796 BGP Route Reflection - An Alternative to Full Mesh IBGP. T. + Bates, R. Chandra, E. Chen. April 2000. (Format: TXT=20174 bytes) + (Updates RFC1966) (Status: PROPOSED STANDARD) + +2797 Certificate Management Messages over CMS. M. Myers, X. Liu, J. + Schaad, J. Weinstein. April 2000. (Format: TXT=103357 bytes) (Status: + PROPOSED STANDARD) + +2798 Definition of the inetOrgPerson LDAP Object Class. M. Smith. + April 2000. (Format: TXT=32929 bytes) (Status: INFORMATIONAL) + +2799 Request for Comments Summary RFC Numbers 2700-2799. S. Ginoza. + September 2000. (Format: TXT=42622 bytes) (Status: INFORMATIONAL) + +2800 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. + Ginoza. May 2001. (Format: TXT=101648 bytes) (Obsoletes RFC2700) + (Obsoleted by RFC2900) (Also STD1) (Status: STANDARD) + +2801 Internet Open Trading Protocol - IOTP Version 1.0. D. Burdett. + April 2000. (Format: TXT=598794 bytes) (Status: INFORMATIONAL) + +2802 Digital Signatures for the v1.0 Internet Open Trading Protocol + (IOTP). K. Davidson, Y. Kawatsura. April 2000. (Format: TXT=52756 + bytes) (Status: INFORMATIONAL) + +2803 Digest Values for DOM (DOMHASH). H. Maruyama, K. Tamura, N. + Uramoto. April 2000. (Format: TXT=22552 bytes) (Status: + INFORMATIONAL) + +2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. (Format: + TXT=18934 bytes) (Status: INFORMATIONAL) + +2805 Media Gateway Control Protocol Architecture and Requirements. N. + Greene, M. Ramalho, B. Rosen. April 2000. (Format: TXT=88190 bytes) + (Status: INFORMATIONAL) + +2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format: + TXT=50647 bytes) (Status: PROPOSED STANDARD) + +2807 XML Signature Requirements. J. Reagle. July 2000. (Format: + TXT=21973 bytes) (Status: INFORMATIONAL) + +2808 The SecurID(r) SASL Mechanism. M. Nystrom. April 2000. (Format: + TXT=20342 bytes) (Status: INFORMATIONAL) + +2809 Implementation of L2TP Compulsory Tunneling via RADIUS. B. Aboba, + G. Zorn. April 2000. (Format: TXT=47259 bytes) (Status: + INFORMATIONAL) + +2810 Internet Relay Chat: Architecture. C. Kalt. April 2000. (Format: + TXT=19087 bytes) (Updates RFC1459) (Status: INFORMATIONAL) + +2811 Internet Relay Chat: Channel Management. C. Kalt. April 2000. + (Format: TXT=40788 bytes) (Updates RFC1459) (Status: INFORMATIONAL) + +2812 Internet Relay Chat: Client Protocol. C. Kalt. April 2000. + (Format: TXT=122637 bytes) (Updates RFC1459) (Status: INFORMATIONAL) + +2813 Internet Relay Chat: Server Protocol. C. Kalt. April 2000. + (Format: TXT=56681 bytes) (Updates RFC1459) (Status: INFORMATIONAL) + +2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based + Admission Control over IEEE 802-style networks. R. Yavatkar, D. + Hoffman, Y. Bernet, F. Baker, M. Speer. May 2000. (Format: TXT=141886 + bytes) (Status: PROPOSED STANDARD) + +2815 Integrated Service Mappings on IEEE 802 Networks. M. Seaman, A. + Smith, E. Crawley, J. Wroclawski. May 2000. (Format: TXT=42403 bytes) + (Status: PROPOSED STANDARD) + +2816 A Framework for Integrated Services Over Shared and Switched IEEE + 802 LAN Technologies. A. Ghanwani, J. Pace, V. Srinivasan, A. Smith, + M. Seaman. May 2000. (Format: TXT=119043 bytes) (Status: + INFORMATIONAL) + +2817 Upgrading to TLS Within HTTP/1.1. R. Khare, S. Lawrence. May + 2000. (Format: TXT=27598 bytes) (Updates RFC2616) (Status: PROPOSED + STANDARD) + +2818 HTTP Over TLS. E. Rescorla. May 2000. (Format: TXT=15170 bytes) + (Status: INFORMATIONAL) + +2819 Remote Network Monitoring Management Information Base. S. + Waldbusser. May 2000. (Format: TXT=198676 bytes) (Obsoletes RFC1757) + (Also STD0059) (Status: STANDARD) + +2820 Access Control Requirements for LDAP. E. Stokes, D. Byrne, B. + Blakley, P. Behera. May 2000. (Format: TXT=18172 bytes) (Status: + INFORMATIONAL) + +2821 Simple Mail Transfer Protocol. J. Klensin, Editor. April 2001. + (Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869) + (Status: PROPOSED STANDARD) + +2822 Internet Message Format. P. Resnick, Editor. April 2001. (Format: + TXT=110695 bytes) (Obsoletes RFC0822) (Status: PROPOSED STANDARD) + +2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like + framing. J. Carlson, P. Langner, E. Hernandez-Valencia, J. + Manchester. May 2000. (Format: TXT=60049 bytes) (Status: + EXPERIMENTAL) + +2824 Call Processing Language Framework and Requirements. J. Lennox, + H. Schulzrinne. May 2000. (Format: TXT=58711 bytes) (Status: + INFORMATIONAL) + +2825 A Tangled Web: Issues of I18N, Domain Names, and the Other + Internet protocols. IAB, L. Daigle, ed.. May 2000. (Format: TXT=15612 + bytes) (Status: INFORMATIONAL) + +2826 IAB Technical Comment on the Unique DNS Root. IAB. May 2000. + (Format: TXT=13400 bytes) (Status: INFORMATIONAL) + +2827 Network Ingress Filtering: Defeating Denial of Service Attacks + which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May + 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Also BCP0038) + (Status: BEST CURRENT PRACTICE) + +2828 Internet Security Glossary. R. Shirey. May 2000. (Format: + TXT=489292 bytes) (Also FYI0036) (Status: INFORMATIONAL) + +2829 Authentication Methods for LDAP. M. Wahl, H. Alvestrand, J. + Hodges, R. Morgan. May 2000. (Format: TXT=33471 bytes) (Status: + PROPOSED STANDARD) + +2830 Lightweight Directory Access Protocol (v3): Extension for + Transport Layer Security. J. Hodges, R. Morgan, M. Wahl. May 2000. + (Format: TXT=24469 bytes) (Status: PROPOSED STANDARD) + +2831 Using Digest Authentication as a SASL Mechanism. P. Leach, C. + Newman. May 2000. (Format: TXT=58124 bytes) (Status: PROPOSED + STANDARD) + +2832 NSI Registry Registrar Protocol (RRP) Version 1.1.0. S. + Hollenbeck, M. Srivastava. May 2000. (Format: TXT=77057 bytes) + (Status: INFORMATIONAL) + +2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony + Signals. H. Schulzrinne, S. Petrack. May 2000. (Format: TXT=68786 + bytes) (Status: PROPOSED STANDARD) + +2834 ARP and IP Broadcast over HIPPI-800. J.-M. Pittet. May 2000. + (Format: TXT=76243 bytes) (Obsoletes RFC1374) (Status: PROPOSED + STANDARD) + +2835 IP and ARP over HIPPI-6400 (GSN). J.-M. Pittet. May 2000. + (Format: TXT=74178 bytes) (Status: PROPOSED STANDARD) + +2836 Per Hop Behavior Identification Codes. S. Brim, B. Carpenter, F. + Le Faucheur. May 2000. (Format: TXT=13399 bytes) (Obsoleted by + RFC3140) (Status: PROPOSED STANDARD) + +2837 Definitions of Managed Objects for the Fabric Element in Fibre + Channel Standard. K. Teow. May 2000. (Format: TXT=87860 bytes) + (Status: PROPOSED STANDARD) + +2838 Uniform Resource Identifiers for Television Broadcasts. D. + Zigmond, M. Vickers. May 2000. (Format: TXT=11405 bytes) (Status: + INFORMATIONAL) + +2839 Internet Kermit Service. F. da Cruz, J. Altman. May 2000. + (Format: TXT=42726 bytes) (Status: INFORMATIONAL) + +2840 TELNET KERMIT OPTION. J. Altman, F. da Cruz. May 2000. (Format: + TXT=22519 bytes) (Status: INFORMATIONAL) + +2841 IP Authentication using Keyed SHA1 with Interleaved Padding + (IP-MAC). P. Metzger, W. Simpson. November 2000. (Format: TXT=14139 + bytes) (Obsoletes RFC1852) (Status: HISTORIC) + +2842 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. + May 2000. (Format: TXT=8366 bytes) (Status: PROPOSED STANDARD) + +2843 Proxy-PAR. P. Droz, T. Przygienda. May 2000. (Format: TXT=27891 + bytes) (Status: INFORMATIONAL) + +2844 OSPF over ATM and Proxy-PAR. T. Przygienda, P. Droz, R. Haas. May + 2000. (Format: TXT=32146 bytes) (Status: EXPERIMENTAL) + +2845 Secret Key Transaction Authentication for DNS (TSIG). P. Vixie, + O. Gudmundsson, D. Eastlake, B. Wellington. May 2000. (Format: + TXT=32272 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD) + +2846 GSTN Address Element Extensions in E-mail Services. C. Allocchio. + June 2000. (Format: TXT=54316 bytes) (Status: PROPOSED STANDARD) + +2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM. M. + Eisler. June 2000. (Format: TXT=50045 bytes) (Status: PROPOSED + STANDARD) + +2848 The PINT Service Protocol: Extensions to SIP and SDP for IP + Access to Telephone Call Services. S. Petrack, L. Conroy. June 2000. + (Format: TXT=168851 bytes) (Status: PROPOSED STANDARD) + +2849 The LDAP Data Interchange Format (LDIF) - Technical + Specification. G. Good. June 2000. (Format: TXT=26017 bytes) (Status: + PROPOSED STANDARD) + +2850 Charter of the Internet Architecture Board (IAB). Internet + Architecture Board, B. Carpenter, Editor. May 2000. (Format: + TXT=15984 bytes) (Obsoletes RFC1601) (Also BCP0039) (Status: BEST + CURRENT PRACTICE) + +2851 Textual Conventions for Internet Network Addresses. M. Daniele, + B. Haberman, S. Routhier, J. Schoenwaelder. June 2000. (Format: + TXT=32587 bytes) (Status: PROPOSED STANDARD) + +2852 Deliver By SMTP Service Extension. D. Newman. June 2000. (Format: + TXT=29285 bytes) (Updates RFC1894) (Status: PROPOSED STANDARD) + +2853 Generic Security Service API Version 2 : Java Bindings. J. Kabat, + M. Upadhyay. June 2000. (Format: TXT=199512 bytes) (Status: PROPOSED + STANDARD) + +2854 The 'text/html' Media Type. D. Connolly, L. Masinter. June 2000. + (Format: TXT=16135 bytes) (Obsoletes RFC2070, RFC1980, RFC1942, + RFC1867, RFC1866) (Status: INFORMATIONAL) + +2855 DHCP for IEEE 1394. K. Fujisawa. June 2000. (Format: TXT=8070 + bytes) (Status: PROPOSED STANDARD) + +2856 Textual Conventions for Additional High Capacity Data Types. A. + Bierman, K. McCloghrie, R. Presuhn. June 2000. (Format: TXT=20954 + bytes) (Status: PROPOSED STANDARD) + +2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH. A. Keromytis, N. + Provos. June 2000. (Format: TXT=13544 bytes) (Status: PROPOSED + STANDARD) + +2858 Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. + Chandra, D. Katz. June 2000. (Format: TXT=23305 bytes) (Obsoletes + RFC2283) (Status: PROPOSED STANDARD) + +2859 A Time Sliding Window Three Colour Marker (TSWTCM). W. Fang, N. + Seddigh, B. Nandy. June 2000. (Format: TXT=19203 bytes) (Status: + EXPERIMENTAL) + +2860 Memorandum of Understanding Concerning the Technical Work of the + Internet Assigned Numbers Authority. B. Carpenter, F. Baker, M. + Roberts. June 2000. (Format: TXT=12361 bytes) (Status: INFORMATIONAL) + +2861 TCP Congestion Window Validation. M. Handley, J. Padhye, S. + Floyd. June 2000. (Format: TXT=26993 bytes) (Status: EXPERIMENTAL) + +2862 RTP Payload Format for Real-Time Pointers. M. Civanlar, G. Cash. + June 2000. (Format: TXT=12031 bytes) (Status: PROPOSED STANDARD) + +2863 The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June + 2000. (Format: TXT=155014 bytes) (Obsoletes RFC2233) (Status: DRAFT + STANDARD) + +2864 The Inverted Stack Table Extension to the Interfaces Group MIB. + K. McCloghrie, G. Hanson. June 2000. (Format: TXT=21445 bytes) + (Status: PROPOSED STANDARD) + +2865 Remote Authentication Dial In User Service (RADIUS). C. Rigney, + S. Willens, A. Rubens, W. Simpson. June 2000. (Format: TXT=146456 + bytes) (Obsoletes RFC2138) (Updated by RFC2868) (Status: DRAFT + STANDARD) + +2866 RADIUS Accounting. C. Rigney. June 2000. (Format: TXT=51135 + bytes) (Obsoletes RFC2139) (Updated by RFC2867) (Status: + INFORMATIONAL) + +2867 RADIUS Accounting Modifications for Tunnel Protocol Support. G. + Zorn, B. Aboba, D. Mitton. June 2000. (Format: TXT=51135 bytes) + (Updates RFC2866) (Status: INFORMATIONAL) + +2868 RADIUS Attributes for Tunnel Protocol Support. G. Zorn, D. + Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. June 2000. + (Format: TXT=42609 bytes) (Updates RFC2865) (Status: INFORMATIONAL) + +2869 RADIUS Extensions. C. Rigney, W. Willats, P. Calhoun. June 2000. + (Format: TXT=96854 bytes) (Status: INFORMATIONAL) + +2870 Root Name Server Operational Requirements. R. Bush, D. + Karrenberg, M. Kosters, R. Plzak. June 2000. (Format: TXT=21133 + bytes) (Obsoletes RFC2010) (Also BCP0040) (Status: BEST CURRENT + PRACTICE) + +2871 A Framework for Telephony Routing over IP. J. Rosenberg, H. + Schulzrinne. June 2000. (Format: TXT=60664 bytes) (Status: + INFORMATIONAL) + +2872 Application and Sub Application Identity Policy Element for Use + with RSVP. Y. Bernet, R. Pabbati. June 2000. (Format: TXT=10933 + bytes) (Status: PROPOSED STANDARD) + +2873 TCP Processing of the IPv4 Precedence Field. X. Xiao, A. Hannan, + V. Paxson, E. Crabbe. June 2000. (Format: TXT=15565 bytes) (Status: + PROPOSED STANDARD) + +2874 DNS Extensions to Support IPv6 Address Aggregation and + Renumbering. M. Crawford, C. Huitema. July 2000. (Format: TXT=44204 + bytes) (Updated by RFC3152) (Status: PROPOSED STANDARD) + +2875 Diffie-Hellman Proof-of-Possession Algorithms. H. Prafullchandra, + J. Schaad. July 2000. (Format: TXT=45231 bytes) (Status: PROPOSED + STANDARD) + +2876 Use of the KEA and SKIPJACK Algorithms in CMS. J. Pawling. July + 2000. (Format: TXT=29265 bytes) (Status: INFORMATIONAL) + +2877 5250 Telnet Enhancements. T. Murphy, Jr., P. Rieth, J. Stevens. + July 2000. (Format: TXT=83369 bytes) (Updates RFC1205) (Status: + INFORMATIONAL) + +2878 PPP Bridging Control Protocol (BCP). M. Higashiyama, F. Baker. + July 2000. (Format: TXT=79527 bytes) (Obsoletes RFC1638) (Status: + PROPOSED STANDARD) + +2879 Content Feature Schema for Internet Fax (V2). G. Klyne, L. + McIntyre. August 2000. (Format: TXT=104032 bytes) (Obsoletes RFC2531) + (Status: PROPOSED STANDARD) + +2880 Internet Fax T.30 Feature Mapping. L. McIntyre, G. Klyne. August + 2000. (Format: TXT=75973 bytes) (Status: INFORMATIONAL) + +2881 Network Access Server Requirements Next Generation (NASREQNG) NAS + Model. D. Mitton, M. Beadles. July 2000. (Format: TXT=45029 bytes) + (Status: INFORMATIONAL) + +2882 Network Access Servers Requirements: Extended RADIUS Practices. + D. Mitton. July 2000. (Format: TXT=31426 bytes) (Status: + INFORMATIONAL) + +2883 An Extension to the Selective Acknowledgement (SACK) Option for + TCP. S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. July 2000. + (Format: TXT=35794 bytes) (Status: PROPOSED STANDARD) + +2884 Performance Evaluation of Explicit Congestion Notification (ECN) + in IP Networks. J. Hadi Salim, U. Ahmed. July 2000. (Format: + TXT=44647 bytes) (Status: INFORMATIONAL) + +2885 Megaco Protocol version 0.8. F. Cuervo, N. Greene, C. Huitema, A. + Rayhan, B. Rosen, J. Segers. August 2000. (Format: TXT=344871 bytes) + (Obsoleted by RFC3015) (Status: HISTORIC) + +2886 Megaco Errata. T. Taylor. August 2000. (Format: TXT=41311 bytes) + (Obsoleted by RFC3015) (Status: HISTORIC) + +2887 The Reliable Multicast Design Space for Bulk Data Transfer. M. + Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby. + August 2000. (Format: TXT=51135 bytes) (Status: INFORMATIONAL) + +2888 Secure Remote Access with L2TP. P. Srisuresh. August 2000. + (Format: TXT=41255 bytes) (Status: INFORMATIONAL) + +2889 Benchmarking Methodology for LAN Switching Devices. R. + Mandeville, J. Perser. August 2000. (Format: TXT=73251 bytes) + (Status: INFORMATIONAL) + +2890 Key and Sequence Number Extensions to GRE. G. Dommety. September + 2000. (Format: TXT=14503 bytes) (Status: PROPOSED STANDARD) + +2891 LDAP Control Extension for Server Side Sorting of Search Results. + T. Howes, M. Wahl, A. Anantha. August 2000. (Format: TXT=15833 bytes) + (Status: PROPOSED STANDARD) + +2892 The Cisco SRP MAC Layer Protocol. D. Tsiang, G. Suwala. August + 2000. (Format: TXT=107645 bytes) (Status: INFORMATIONAL) + +2893 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. + Nordmark. August 2000. (Format: TXT=62731 bytes) (Obsoletes RFC1933) + (Status: PROPOSED STANDARD) + +2894 Router Renumbering for IPv6. M. Crawford. August 2000. (Format: + TXT=69135 bytes) (Status: PROPOSED STANDARD) + +2895 Remote Network Monitoring MIB Protocol Identifier Reference. A. + Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT=88094 bytes) + (Obsoletes RFC2074) (Status: PROPOSED STANDARD) + +2896 Remote Network Monitoring MIB Protocol Identifier Macros. A. + Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT=135768 bytes) + (Status: INFORMATIONAL) + +2897 Proposal for an MGCP Advanced Audio Package. D. Cromwell. August + 2000. (Format: TXT=67459 bytes) (Status: INFORMATIONAL) + +2898 PKCS #5: Password-Based Cryptography Specification Version 2.0. + B. Kaliski. September 2000. (Format: TXT=68692 bytes) (Status: + INFORMATIONAL) + +2899 Request for Comments Summary RFC Numbers 2800-2899. S. Ginoza. + May 2001. (Format: TXT=43805 bytes) (Status: INFORMATIONAL) + +2900 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. + Ginoza. August 2001. (Format: TXT=112809 bytes) (Obsoletes RFC2800) + (Also STD1) (Status: STANDARD) + +2901 Guide to Administrative Procedures of the Internet + Infrastructure. Z. Wenzel, J. Klensin, R. Bush, S. Huter. August + 2000. (Format: TXT=63680 bytes) (Also FYI0037) (Status: + INFORMATIONAL) + +2902 Overview of the 1998 IAB Routing Workshop. S. Deering, S. Hares, + C. Perkins, R. Perlman. August 2000. (Format: TXT=32773 bytes) + (Status: INFORMATIONAL) + +2903 Generic AAA Architecture. C. de Laat, G. Gross, L. Gommans, J. + Vollbrecht, D. Spence. August 2000. (Format: TXT=60627 bytes) + (Status: EXPERIMENTAL) + +2904 AAA Authorization Framework. J. Vollbrecht, P. Calhoun, S. + Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, + D. Spence. August 2000. (Format: TXT=78098 bytes) (Status: + INFORMATIONAL) + +2905 AAA Authorization Application Examples. J. Vollbrecht, P. + Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, + M. Holdrege, D. Spence. August 2000. (Format: TXT=118645 bytes) + (Status: INFORMATIONAL) + +2906 AAA Authorization Requirements. S. Farrell, J. Vollbrecht, P. + Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, + D. Spence. August 2000. (Format: TXT=48618 bytes) (Status: + INFORMATIONAL) + +2907 MADCAP Multicast Scope Nesting State Option. R. Kermode. + September 2000. (Format: TXT=27572 bytes) (Status: PROPOSED STANDARD) + +2908 The Internet Multicast Address Allocation Architecture. D. + Thaler, M. Handley, D. Estrin. September 2000. (Format: TXT=30515 + bytes) (Status: INFORMATIONAL) + +2909 The Multicast Address-Set Claim (MASC) Protocol. P. Radoslavov, + D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler. September + 2000. (Format: TXT=127278 bytes) (Status: EXPERIMENTAL) + +2910 Internet Printing Protocol/1.1: Encoding and Transport. R. + Herriot, S. Butler, P. Moore, R. Turner, J. Wenn. September 2000. + (Format: TXT=100599 bytes) (Obsoletes RFC2565) (Status: PROPOSED + STANDARD) + +2911 Internet Printing Protocol/1.1: Model and Semantics. R. deBry, T. + Hastings, R. Herriot, S. Isaacson, P. Powell. September 2000. + (Format: TXT=575805 bytes) (Obsoletes RFC2566) (Status: PROPOSED + STANDARD) + +2912 Indicating Media Features for MIME Content. G. Klyne. September + 2000. (Format: TXT=20618 bytes) (Status: PROPOSED STANDARD) + +2913 MIME Content Types in Media Feature Expressions. G. Klyne. + September 2000. (Format: TXT=16095 bytes) (Status: PROPOSED STANDARD) + +2914 Congestion Control Principles. S. Floyd. September 2000. (Format: + TXT=43823 bytes) (Also BCP0041) (Status: BEST CURRENT PRACTICE) + +2915 The Naming Authority Pointer (NAPTR) DNS Resource Record. M. + Mealling, R. Daniel. September 2000. (Format: TXT=41521 bytes) + (Updates RFC2168) (Status: PROPOSED STANDARD) + +2916 E.164 number and DNS. P. Faltstrom. September 2000. (Format: + TXT=18159 bytes) (Status: PROPOSED STANDARD) + +2917 A Core MPLS IP VPN Architecture. K. Muthukrishnan, A. Malis. + September 2000. (Format: TXT=35352 bytes) (Status: INFORMATIONAL) + +2918 Route Refresh Capability for BGP-4. E. Chen. September 2000. + (Format: TXT=7354 bytes) (Status: PROPOSED STANDARD) + +2919 List-Id: A Structured Field and Namespace for the Identification + of Mailing Lists. R. Chandhok, G. Wenger. March 2001. (Format: + TXT=18480 bytes) (Status: PROPOSED STANDARD) + +2920 SMTP Service Extension for Command Pipelining. N. Freed. + September 2000. (Format: TXT=17065 bytes) (Obsoletes RFC2197) (Also + STD0060) (Status: STANDARD) + +2921 6BONE pTLA and pNLA Formats (pTLA). B. Fink. September 2000. + (Format: TXT=14218 bytes) (Status: INFORMATIONAL) + +2922 Physical Topology MIB. A. Bierman, K. Jones. September 2000. + (Format: TXT=66830 bytes) (Status: INFORMATIONAL) + +2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000. + (Format: TXT=30976 bytes) (Status: INFORMATIONAL) + +2924 Accounting Attributes and Record Formats. N. Brownlee, A. Blount. + September 2000. (Format: TXT=75561 bytes) (Status: INFORMATIONAL) + +2925 Definitions of Managed Objects for Remote Ping, Traceroute, and + Lookup Operations. K. White. September 2000. (Format: TXT=150691 + bytes) (Status: PROPOSED STANDARD) + +2926 Conversion of LDAP Schemas to and from SLP Templates. J. Kempf, + R. Moats, P. St. Pierre. September 2000. (Format: TXT=55365 bytes) + (Status: INFORMATIONAL) + +2927 MIME Directory Profile for LDAP Schema. M. Wahl. September 2000. + (Format: TXT=16122 bytes) (Status: INFORMATIONAL) + +2928 Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S. Deering, R. + Fink, T. Hain. September 2000. (Format: TXT=11882 bytes) (Status: + INFORMATIONAL) + +2929 Domain Name System (DNS) IANA Considerations. D. Eastlake, E. + Brunner-Williams, B. Manning. September 2000. (Format: TXT=22454 + bytes) (Also BCP0042) (Status: BEST CURRENT PRACTICE) + +2930 Secret Key Establishment for DNS (TKEY RR). D. Eastlake. + September 2000. (Format: TXT=34894 bytes) (Status: PROPOSED STANDARD) + +2931 DNS Request and Transaction Signatures ( SIG(0)s). D. Eastlake. + September 2000. (Format: TXT=19073 bytes) (Updates RFC2535) (Status: + PROPOSED STANDARD) + +2932 IPv4 Multicast Routing MIB. K. McCloghrie, D. Farinacci, D. + Thaler. October 2000. (Format: TXT=50430 bytes) (Status: PROPOSED + STANDARD) + +2933 Internet Group Management Protocol MIB. K. McCloghrie, D. + Farinacci, D. Thaler. October 2000. (Format: TXT=33406 bytes) + (Status: PROPOSED STANDARD) + +2934 Protocol Independent Multicast MIB for IPv4. K. McCloghrie, D. + Farinacci, D. Thaler, B. Fenner. October 2000. (Format: TXT=48379 + bytes) (Status: EXPERIMENTAL) + +2935 Internet Open Trading Protocol (IOTP) HTTP Supplement. D. + Eastlake, C. Smith. September 2000. (Format: TXT=16168 bytes) + (Status: PROPOSED STANDARD) + +2936 HTTP MIME Type Handler Detection. D. Eastlake, C. Smith, D. + Soroka. September 2000. (Format: TXT=25238 bytes) (Status: + INFORMATIONAL) + +2937 The Name Service Search Option for DHCP. C. Smith. September + 2000. (Format: TXT=8368 bytes) (Status: PROPOSED STANDARD) + +2938 Identifying Composite Media Features. G. Klyne, L. Masinter. + September 2000. (Format: TXT=34451 bytes) (Updates RFC2533) (Status: + PROPOSED STANDARD) + +2939 Procedures and IANA Guidelines for Definition of New DHCP Options + and Message Types. R. Droms. September 2000. (Format: TXT=13631 + bytes) (Obsoletes RFC2489) (Also BCP0043) (Status: BEST CURRENT + PRACTICE) + +2940 Definitions of Managed Objects for Common Open Policy Service + (COPS) Protocol Clients. A. Smith, D. Partain, J. Seligson. October + 2000. (Format: TXT=52427 bytes) (Status: PROPOSED STANDARD) + +2941 Telnet Authentication Option. T. Ts'o, Editor, J. Altman. + September 2000. (Format: TXT=52427 bytes) (Obsoletes RFC1416) + (Status: PROPOSED STANDARD) + +2942 Telnet Authentication: Kerberos Version 5. T. Ts'o. September + 2000. (Format: TXT=14562 bytes) (Status: PROPOSED STANDARD) + +2943 TELNET Authentication Using DSA. R. Housley, T. Horting, P. Yee. + September 2000. (Format: TXT=21694 bytes) (Status: PROPOSED STANDARD) + +2944 Telnet Authentication: SRP. T. Wu. September 2000. (Format: + TXT=13933 bytes) (Status: PROPOSED STANDARD) + +2945 The SRP Authentication and Key Exchange System. T. Wu. September + 2000. (Format: TXT=17843 bytes) (Status: PROPOSED STANDARD) + +2946 Telnet Data Encryption Option. T. Ts'o. September 2000. (Format: + TXT=16527 bytes) (Status: PROPOSED STANDARD) + +2947 Telnet Encryption: DES3 64 bit Cipher Feedback. J. Altman. + September 2000. (Format: TXT=11064 bytes) (Status: PROPOSED STANDARD) + +2948 Telnet Encryption: DES3 64 bit Output Feedback. J. Altman. + September 2000. (Format: TXT=11064 bytes) (Status: PROPOSED STANDARD) + +2949 Telnet Encryption: CAST-128 64 bit Output Feedback. J. Altman. + September 2000. (Format: TXT=9240 bytes) (Status: PROPOSED STANDARD) + +2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback. J. Altman. + September 2000. (Format: TXT=9267 bytes) (Status: PROPOSED STANDARD) + +2951 TELNET Authentication Using KEA and SKIPJACK. R. Housley, T. + Horting, P. Yee. September 2000. (Format: TXT=20757 bytes) (Status: + INFORMATIONAL) + +2952 Telnet Encryption: DES 64 bit Cipher Feedback. T. Ts'o. September + 2000. (Format: TXT=9064 bytes) (Status: INFORMATIONAL) + +2953 Telnet Encryption: DES 64 bit Output Feedback. T. Ts'o. September + 2000. (Format: TXT=8995 bytes) (Status: INFORMATIONAL) + +2954 Definitions of Managed Objects for Frame Relay Service. K. + Rehbehn, D. Fowler. October 2000. (Format: TXT=164217 bytes) + (Obsoletes RFC1604) (Status: PROPOSED STANDARD) + +2955 Definitions of Managed Objects for Monitoring and Controlling the + Frame Relay/ATM PVC Service Interworking Function. K. Rehbehn, O. + Nicklass, G. Mouradian. October 2000. (Format: TXT=83281 bytes) + (Status: PROPOSED STANDARD) + +2956 Overview of 1999 IAB Network Layer Workshop. M. Kaat. October + 2000. (Format: TXT=36830 bytes) (Status: INFORMATIONAL) + +2957 The application/whoispp-query Content-Type. L. Daigle, P. + Faltstrom. October 2000. (Format: TXT=10262 bytes) (Status: + INFORMATIONAL) + +2958 The application/whoispp-response Content-type. L. Daigle, P. + Faltstrom. October 2000. (Format: TXT=9995 bytes) (Status: + INFORMATIONAL) + +2959 Real-Time Transport Protocol Management Information Base. M. + Baugher, B. Strahm, I. Suconick. October 2000. (Format: TXT=62063 + bytes) (Status: PROPOSED STANDARD) + +2960 Stream Control Transmission Protocol. R. Stewart, Q. Xie, K. + Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, + L. Zhang, V. Paxson. October 2000. (Format: TXT=297757 bytes) + (Status: PROPOSED STANDARD) + +2961 RSVP Refresh Overhead Reduction Extensions. L. Berger, D. Gan, G. + Swallow, P. Pan, F. Tommasi, S. Molendini. April 2001. (Format: + TXT=81675 bytes) (Status: PROPOSED STANDARD) + +2962 An SNMP Application Level Gateway for Payload Address + Translation. D. Raz, J. Schoenwaelder, B. Sugla. October 2000. + (Format: TXT=46803 bytes) (Status: INFORMATIONAL) + +2963 A Rate Adaptive Shaper for Differentiated Services. O. + Bonaventure, S. De Cnodder. October 2000. (Format: TXT=39895 bytes) + (Status: INFORMATIONAL) + +2964 Use of HTTP State Management. K. Moore, N. Freed. October 2000. + (Format: TXT=18899 bytes) (Also BCP0044) (Status: BEST CURRENT + PRACTICE) + +2965 HTTP State Management Mechanism. D. Kristol, L. Montulli. October + 2000. (Format: TXT=56176 bytes) (Obsoletes RFC2109) (Status: PROPOSED + STANDARD) + +2966 Domain-wide Prefix Distribution with Two-Level IS-IS. T. Li, T. + Przygienda, H. Smit. October 2000. (Format: TXT=32465 bytes) (Status: + INFORMATIONAL) + +2967 TISDAG - Technical Infrastructure for Swedish Directory Access + Gateways. L. Daigle, R. Hedberg. October 2000. (Format: TXT=209845 + bytes) (Status: INFORMATIONAL) + +2968 Mesh of Multiple DAG servers - Results from TISDAG. L. Daigle, T. + Eklof. October 2000. (Format: TXT=19306 bytes) (Status: + INFORMATIONAL) + +2969 Wide Area Directory Deployment - Experiences from TISDAG. T. + Eklof, L. Daigle. October 2000. (Format: TXT=43002 bytes) (Status: + INFORMATIONAL) + +2970 Architecture for Integrated Directory Services - Result from + TISDAG. L. Daigle, T. Eklof. October 2000. (Format: TXT=40448 bytes) + (Status: INFORMATIONAL) + +2971 IMAP4 ID extension. T. Showalter. October 2000. (Format: + TXT=14670 bytes) (Status: PROPOSED STANDARD) + +2972 Context and Goals for Common Name Resolution. N. Popp, M. + Mealling, L. Masinter, K. Sollins. October 2000. (Format: TXT=26252 + bytes) (Status: INFORMATIONAL) + +2973 IS-IS Mesh Groups. R. Balay, D. Katz, J. Parker. October 2000. + (Format: TXT=14846 bytes) (Status: INFORMATIONAL) + +2974 Session Announcement Protocol. M. Handley, C. Perkins, E. Whelan. + October 2000. (Format: TXT=40129 bytes) (Status: EXPERIMENTAL) + +2975 Introduction to Accounting Management. B. Aboba, J. Arkko, D. + Harrington. October 2000. (Format: TXT=129771 bytes) (Status: + INFORMATIONAL) + +2976 The SIP INFO Method. S. Donovan. October 2000. (Format: TXT=17736 + bytes) (Status: PROPOSED STANDARD) + +2977 Mobile IP Authentication, Authorization, and Accounting + Requirements. S. Glass, T. Hiller, S. Jacobs, C. Perkins. October + 2000. (Format: TXT=63520 bytes) (Status: INFORMATIONAL) + +2978 IANA Charset Registration Procedures. N. Freed, J. Postel. + October 2000. (Format: TXT=21615 bytes) (Obsoletes RFC2278) (Also + BCP0019) (Status: BEST CURRENT PRACTICE) + +2979 Behavior of and Requirements for Internet Firewalls. N. Freed. + October 2000. (Format: TXT=14350 bytes) (Status: INFORMATIONAL) + +2980 Common NNTP Extensions. S. Barber. October 2000. (Format: + TXT=57165 bytes) (Status: INFORMATIONAL) + +2981 Event MIB. R. Kavasseri (Editor of this version). October 2000. + (Format: TXT=98248 bytes) (Status: PROPOSED STANDARD) + +2982 Distributed Management Expression MIB. R. Kavasseri (Editor of + this version). October 2000. (Format: TXT=81371 bytes) (Status: + PROPOSED STANDARD) + +2983 Differentiated Services and Tunnels. D. Black. October 2000. + (Format: TXT=35644 bytes) (Status: INFORMATIONAL) + +2984 Use of the CAST-128 Encryption Algorithm in CMS. C. Adams. + October 2000. (Format: TXT=11591 bytes) (Status: PROPOSED STANDARD) + +2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0. + M. Nystrom, B. Kaliski. November 2000. (Format: TXT=70703 bytes) + (Status: INFORMATIONAL) + +2986 PKCS #10: Certification Request Syntax Specification Version 1.7. + M. Nystrom, B. Kaliski. November 2000. (Format: TXT=27794 bytes) + (Obsoletes RFC2314) (Status: INFORMATIONAL) + +2987 Registration of Charset and Languages Media Features Tags. P. + Hoffman. November 2000. (Format: TXT=8799 bytes) (Status: PROPOSED + STANDARD) + +2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. + November 2000. (Format: TXT=15280 bytes) (Status: PROPOSED STANDARD) + +2989 Criteria for Evaluating AAA Protocols for Network Access. B. + Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, G. + Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. + Beadles, P. Walsh, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. + Jacobs, B. Lim, B. Hirschman, R. Hsu, Y. Xu, E. Campbell, S. Baba, E. + Jaques. November 2000. (Format: TXT=53197 bytes) (Status: + INFORMATIONAL) + +2990 Next Steps for the IP QoS Architecture. G. Huston. November 2000. + (Format: TXT=65450 bytes) (Status: INFORMATIONAL) + +2991 Multipath Issues in Unicast and Multicast Next-Hop Selection. D. + Thaler, C. Hopps. November 2000. (Format: TXT=17796 bytes) (Status: + INFORMATIONAL) + +2992 Analysis of an Equal-Cost Multi-Path Algorithm. C. Hopps. + November 2000. (Format: TXT=17524 bytes) (Status: INFORMATIONAL) + +2993 Architectural Implications of NAT. T. Hain. November 2000. + (Format: TXT=74136 bytes) (Status: INFORMATIONAL) + +2994 A Description of the MISTY1 Encryption Algorithm. H. Ohta, M. + Matsui. November 2000. (Format: TXT=17803 bytes) (Status: + INFORMATIONAL) + +2995 Pre-Spirits Implementations of PSTN-initiated Services. H. Lu, + Editor, I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. + Hwang, S. Ago,. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. + Nyckelgard, J. Yoakum, L. Robart. November 2000. (Format: TXT=96427 + bytes) (Status: INFORMATIONAL) + +2996 Format of the RSVP DCLASS Object. Y. Bernet. November 2000. + (Format: TXT=18929 bytes) (Status: PROPOSED STANDARD) + +2997 Specification of the Null Service Type. Y. Bernet, A. Smith, B. + Davie. November 2000. (Format: TXT=25071 bytes) (Status: PROPOSED + STANDARD) + +2998 A Framework for Integrated Services Operation over Diffserv + Networks. Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. + Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine. November + 2000. (Format: TXT=76378 bytes) (Status: INFORMATIONAL) + +2999 Request for Comments Summary RFC Numbers 2900-2999. S. Ginoza. + August 2001. (Format: TXT=45307 bytes) (Status: INFORMATIONAL) + +3001 A URN Namespace of Object Identifiers. M. Mealling. November + 2000. (Format: TXT=7459 bytes) (Obsoleted by RFC3061) (Status: + INFORMATIONAL) + +3002 Overview of 2000 IAB Wireless Internetworking Workshop. D. + Mitzel. December 2000. (Format: TXT=101466 bytes) (Status: + INFORMATIONAL) + +3003 The audio/mpeg Media Type. M. Nilsson. November 2000. (Format: + TXT=8381 bytes) (Status: PROPOSED STANDARD) + +3004 The User Class Option for DHCP. G. Stump, R. Droms, Y. Gu, R. + Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. November 2000. + (Format: TXT=10423 bytes) (Status: PROPOSED STANDARD) + +3005 IETF Discussion List Charter. S. Harris. November 2000. (Format: + TXT=5682 bytes) (Also BCP0045) (Status: BEST CURRENT PRACTICE) + +3006 Integrated Services in the Presence of Compressible Flows. B. + Davie, S. Casner, C. Iturralde, D. Oran, J. Wroclawski. November + 2000. (Format: TXT=31588 bytes) (Status: PROPOSED STANDARD) + +3007 Secure Domain Name System (DNS) Dynamic Update. B. Wellington. + November 2000. (Format: TXT=18056 bytes) (Obsoletes RFC2137) (Updates + RFC2535, RFC2136) (Status: PROPOSED STANDARD) + +3008 Domain Name System Security (DNSSEC) Signing Authority. B. + Wellington. November 2000. (Format: TXT=13484 bytes) (Updates + RFC2535) (Status: PROPOSED STANDARD) + +3009 Registration of parityfec MIME types. J. Rosenberg, H. + Schulzrinne. November 2000. (Format: TXT=16022 bytes) (Status: + PROPOSED STANDARD) + +3010 NFS version 4 Protocol. S. Shepler, B. Callaghan, D. Robinson, R. + Thurlow, C. Beame, M. Eisler, D. Noveck. December 2000. (Format: + TXT=450434 bytes) (Obsoletes RFC1813, RFC1094) (Status: PROPOSED + STANDARD) + +3011 The IPv4 Subnet Selection Option for DHCP. G. Waters. November + 2000. (Format: TXT=13967 bytes) (Status: PROPOSED STANDARD) + +3012 Mobile IPv4 Challenge/Response Extensions. C. Perkins, P. + Calhoun. November 2000. (Format: TXT=37005 bytes) (Status: PROPOSED + STANDARD) + +3013 Recommended Internet Service Provider Security Services and + Procedures. T. Killalea. November 2000. (Format: TXT=27905 bytes) + (Also BCP0046) (Status: BEST CURRENT PRACTICE) + +3014 Notification Log MIB. R. Kavasseri. November 2000. (Format: + TXT=48287 bytes) (Status: PROPOSED STANDARD) + +3015 Megaco Protocol Version 1.0. F. Cuervo, N. Greene, A. Rayhan, C. + Huitema, B. Rosen, J. Segers. November 2000. (Format: TXT=385432 + bytes) (Obsoletes RFC2885, RFC2886) (Status: PROPOSED STANDARD) + +3016 RTP Payload Format for MPEG-4 Audio/Visual Streams. Y. Kikuchi, + T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. November 2000. (Format: + TXT=47070 bytes) (Status: PROPOSED STANDARD) + +3017 XML DTD for Roaming Access Phone Book. M. Riegel, G. Zorn. + December 2000. (Format: TXT=59762 bytes) (Status: PROPOSED STANDARD) + +3018 Unified Memory Space Protocol Specification. A. Bogdanov. + December 2000. (Format: TXT=177783 bytes) (Status: EXPERIMENTAL) + +3019 IP Version 6 Management Information Base for The Multicast + Listener Discovery Protocol. B. Haberman, R. Worzella. January 2001. + (Format: TXT=28293 bytes) (Status: PROPOSED STANDARD) + +3020 Definitions of Managed Objects for Monitoring and Controlling the + UNI/NNI Multilink Frame Relay Function. P. Pate, B. Lynch, K. + Rehbehn. December 2000. (Format: TXT=67736 bytes) (Status: PROPOSED + STANDARD) + +3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links. A. Retana, R. + White, V. Fuller, D. McPherson. December 2000. (Format: TXT=19771 + bytes) (Status: PROPOSED STANDARD) + +3022 Traditional IP Network Address Translator (Traditional NAT). P. + Srisuresh, K. Egevang. January 2001. (Format: TXT=37675 bytes) + (Obsoletes RFC1631) (Status: INFORMATIONAL) + +3023 XML Media Types. M. Murata, S. St.Laurent, D. Kohn. January 2001. + (Format: TXT=86011 bytes) (Obsoletes RFC2376) (Updates RFC2048) + (Status: PROPOSED STANDARD) + +3024 Reverse Tunneling for Mobile IP, revised. G. Montenegro, Editor. + January 2001. (Format: TXT=63929 bytes) (Obsoletes RFC2344) (Status: + PROPOSED STANDARD) + +3025 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. + Leung. February 2001. (Format: TXT=15611 bytes) (Obsoleted by + RFC3115) (Status: PROPOSED STANDARD) + +3026 Liaison to IETF/ISOC on ENUM. R. Blane. January 2001. (Format: + TXT=11460 bytes) (Status: INFORMATIONAL) + +3027 Protocol Complications with the IP Network Address Translator. M. + Holdrege, P. Srisuresh. January 2001. (Format: TXT=48662 bytes) + (Status: INFORMATIONAL) + +3028 Sieve: A Mail Filtering Language. T. Showalter. January 2001. + (Format: TXT=73582 bytes) (Status: PROPOSED STANDARD) + +3029 Internet X.509 Public Key Infrastructure Data Validation and + Certification Server Protocols. C. Adams, P. Sylvester, M. Zolotarev, + R. Zuccherato. February 2001. (Format: TXT=107347 bytes) (Status: + EXPERIMENTAL) + +3030 SMTP Service Extensions for Transmission of Large and Binary MIME + Messages. G. Vaudreuil. December 2000. (Format: TXT=23405 bytes) + (Obsoletes RFC1830) (Status: PROPOSED STANDARD) + +3031 Multiprotocol Label Switching Architecture. E. Rosen, A. + Viswanathan, R. Callon. January 2001. (Format: TXT=147175 bytes) + (Status: PROPOSED STANDARD) + +3032 MPLS Label Stack Encoding. E. Rosen, D. Tappan, G. Fedorkow, Y. + Rekhter, D. Farinacci, T. Li, A. Conta. January 2001. (Format: + TXT=48314 bytes) (Status: PROPOSED STANDARD) + +3033 The Assignment of the Information Field and Protocol Identifier + in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling + for the Internet Protocol. M. Suzuki. January 2001. (Format: + TXT=52188 bytes) (Status: PROPOSED STANDARD) + +3034 Use of Label Switching on Frame Relay Networks Specification. A. + Conta, P. Doolan, A. Malis. January 2001. (Format: TXT=53176 bytes) + (Status: PROPOSED STANDARD) + +3035 MPLS using LDP and ATM VC Switching. B. Davie, J. Lawrence, K. + McCloghrie, E. Rosen, G. Swallow, Y. Rekhter, P. Doolan. January + 2001. (Format: TXT=46463 bytes) (Status: PROPOSED STANDARD) + +3036 LDP Specification. L. Andersson, P. Doolan, N. Feldman, A. + Fredette, B. Thomas. January 2001. (Format: TXT=274855 bytes) + (Status: PROPOSED STANDARD) + +3037 LDP Applicability. B. Thomas, E. Gray. January 2001. (Format: + TXT=13601 bytes) (Status: INFORMATIONAL) + +3038 VCID Notification over ATM link for LDP. K. Nagami, Y. Katsube, + N. Demizu, H. Esaki, P. Doolan. January 2001. (Format: TXT=39134 + bytes) (Status: PROPOSED STANDARD) + +3039 Internet X.509 Public Key Infrastructure Qualified Certificates + Profile. S. Santesson, W. Polk, P. Barzin, M. Nystrom. January 2001. + (Format: TXT=67619 bytes) (Status: PROPOSED STANDARD) + +3040 Internet Web Replication and Caching Taxonomy. I. Cooper, I. + Melve, G. Tomlinson. January 2001. (Format: TXT=63257 bytes) (Status: + INFORMATIONAL) + +3041 Privacy Extensions for Stateless Address Autoconfiguration in + IPv6. T. Narten, R. Draves. January 2001. (Format: TXT=44446 bytes) + (Status: PROPOSED STANDARD) + +3042 Enhancing TCP's Loss Recovery Using Limited Transmit. M. Allman, + H. Balakrishnan, S. Floyd. January 2001. (Format: TXT=19885 bytes) + (Status: PROPOSED STANDARD) + +3043 The Network Solutions Personal Internet Name (PIN): A URN + Namespace for People and Organizations. M. Mealling. January 2001. + (Format: TXT=8136 bytes) (Status: INFORMATIONAL) + +3044 Using The ISSN (International Serial Standard Number) as URN + (Uniform Resource Names) within an ISSN-URN Namespace. S. Rozenfeld. + January 2001. (Format: TXT=28094 bytes) (Status: INFORMATIONAL) + +3045 Storing Vendor Information in the LDAP root DSE. M. Meredith. + January 2001. (Format: TXT=10518 bytes) (Status: INFORMATIONAL) + +3046 DHCP Relay Agent Information Option. M. Patrick. January 2001. + (Format: TXT=30633 bytes) (Status: PROPOSED STANDARD) + +3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi. + January 2001. (Format: TXT=16292 bytes) (Status: PROPOSED STANDARD) + +3048 Reliable Multicast Transport Building Blocks for One-to-Many + Bulk-Data Transfer. B. Whetten, L. Vicisano, R. Kermode, M. Handley, + S. Floyd, M. Luby. January 2001. (Format: TXT=48965 bytes) (Status: + INFORMATIONAL) + +3049 TN3270E Service Location and Session Balancing. J. Naugle, K. + Kasthurirangan, G. Ledford. January 2001. (Format: TXT=40743 bytes) + (Status: PROPOSED STANDARD) + +3050 Common Gateway Interface for SIP. J. Lennox, H. Schulzrinne, J. + Rosenberg. January 2001. (Format: TXT=76652 bytes) (Status: + INFORMATIONAL) + +3051 IP Payload Compression Using ITU-T V.44 Packet Method. J. Heath, + J. Border. January 2001. (Format: TXT=15845 bytes) (Status: + INFORMATIONAL) + +3052 Service Management Architectures Issues and Review. M. Eder, S. + Nag. January 2001. (Format: TXT=31859 bytes) (Status: INFORMATIONAL) + +3053 IPv6 Tunnel Broker. A. Durand, P. Fasano, I. Guardini, D. Lento. + January 2001. (Format: TXT=27336 bytes) (Status: INFORMATIONAL) + +3054 Megaco IP Phone Media Gateway Application Profile. P. + Blatherwick, R. Bell, P. Holland. January 2001. (Format: TXT=31971 + bytes) (Status: INFORMATIONAL) + +3055 Management Information Base for the PINT Services Architecture. + M. Krishnaswamy, D. Romascanu. February 2001. (Format: TXT=39315 + bytes) (Status: PROPOSED STANDARD) + +3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. + Moore. February 2001. (Format: TXT=54902 bytes) (Status: PROPOSED + STANDARD) + +3057 ISDN Q.921-User Adaptation Layer. K. Morneault, S. Rengasami, M. + Kalla, G. Sidebottom. February 2001. (Format: TXT=13601 bytes) + (Status: PROPOSED STANDARD) + +3058 Use of the IDEA Encryption Algorithm in CMS. S. Teiwes, P. + Hartmann, D. Kuenzi. February 2001. (Format: TXT=17257 bytes) + (Status: INFORMATIONAL) + +3059 Attribute List Extension for the Service Location Protocol. E. + Guttman. February 2001. (Format: TXT=11208 bytes) (Status: PROPOSED + STANDARD) + +3060 Policy Core Information Model -- Version 1 Specification. B. + Moore, E. Ellesson, J. Strassner, A. Westerinen. February 2001. + (Format: TXT=240309 bytes) (Status: PROPOSED STANDARD) + +3061 A URN Namespace of Object Identifiers. M. Mealling. February + 2001. (Format: TXT=8387 bytes) (Obsoletes RFC3001) (Status: + INFORMATIONAL) + +3062 LDAP Password Modify Extended Operation. K. Zeilenga. February + 2001. (Format: TXT=11807 bytes) (Status: PROPOSED STANDARD) + +3063 MPLS Loop Prevention Mechanism. Y. Ohba, Y. Katsube, E. Rosen, P. + Doolan. February 2001. (Format: TXT=93523 bytes) (Status: + EXPERIMENTAL) + +3064 MGCP CAS Packages. B. Foster. February 2001. (Format: TXT=116818 + bytes) (Status: INFORMATIONAL) + +3065 Autonomous System Confederations for BGP. P. Traina, D. + McPherson, J. Scudder. February 2001. (Format: TXT=20529 bytes) + (Obsoletes RFC1965) (Status: PROPOSED STANDARD) + +3066 Tags for the Identification of Languages. H. Alvestrand. January + 2001. (Format: TXT=26522 bytes) (Obsoletes RFC1766) (Also BCP0047) + (Status: BEST CURRENT PRACTICE) + +3067 TERENA'S Incident Object Description and Exchange Format + Requirements. J. Arvidsson, A. Cormack, Y. Demchenko, J. Meijer. + February 2001. (Format: TXT=36836 bytes) (Status: INFORMATIONAL) + +3068 An Anycast Prefix for 6to4 Relay Routers. C. Huitema. June 2001. + (Format: TXT=20120 bytes) (Status: PROPOSED STANDARD) + +3069 VLAN Aggregation for Efficient IP Address Allocation. D. + McPherson, B. Dykes. February 2001. (Format: TXT=14891 bytes) + (Status: INFORMATIONAL) + +3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay. V. Rawat, + R. Tio, S. Nanji, R. Verma. February 2001. (Format: TXT=12940 bytes) + (Status: PROPOSED STANDARD) + +3071 Reflections on the DNS, RFC 1591, and Categories of Domains. J. + Klensin. February 2001. (Format: TXT=24892 bytes) (Status: + INFORMATIONAL) + +3072 Structured Data Exchange Format (SDXF). M. Wildgrube. March 2001. + (Format: TXT=48481 bytes) (Status: INFORMATIONAL) + +3073 Portable Font Resource (PFR) - application/font-tdpfr MIME + Sub-type Registration. J. Collins. March 2001. (Format: TXT=9076 + bytes) (Status: INFORMATIONAL) + +3074 DHC Load Balancing Algorithm. B. Volz, S. Gonczi, T. Lemon, R. + Stevens. February 2001. (Format: TXT=19374 bytes) (Status: PROPOSED + STANDARD) + +3075 XML-Signature Syntax and Processing. D. Eastlake, J. Reagle, D. + Solo. March 2001. (Format: TXT=145520 bytes) (Status: PROPOSED + STANDARD) + +3076 Canonical XML Version 1.0. J. Boyer. March 2001. (Format: + TXT=63955 bytes) (Status: INFORMATIONAL) + +3077 A Link-Layer Tunneling Mechanism for Unidirectional Links. E. + Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang. March 2001. + (Format: TXT=52410 bytes) (Status: PROPOSED STANDARD) + +3078 Microsoft Point-To-Point Encryption (MPPE) Protocol. G. Pall, G. + Zorn. March 2001. (Format: TXT=22952 bytes) (Status: INFORMATIONAL) + +3079 Deriving Keys for use with Microsoft Point-to-Point Encryption + (MPPE). G. Zorn. March 2001. (Format: TXT=38905 bytes) (Status: + INFORMATIONAL) + +3080 The Blocks Extensible Exchange Protocol Core. M. Rose. March + 2001. (Format: TXT=82089 bytes) (Status: PROPOSED STANDARD) + +3081 Mapping the BEEP Core onto TCP. M. Rose. March 2001. (Format: + TXT=14008 bytes) (Status: PROPOSED STANDARD) + +3082 Notification and Subscription for SLP. J. Kempf, J. Goldschmidt. + March 2001. (Format: TXT=33410 bytes) (Status: EXPERIMENTAL) + +3083 Baseline Privacy Interface Management Information Base for DOCSIS + Compliant Cable Modems and Cable Modem Termination Systems. R. + Woundy. March 2001. (Format: TXT=88318 bytes) (Status: INFORMATIONAL) + +3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. + Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, + R. Yavatkar, A. Smith. March 2001. (Format: TXT=79341 bytes) (Status: + PROPOSED STANDARD) + +3085 URN Namespace for NewsML Resources. A. Coates, D. Allen, D. + Rivers-Moore. March 2001. (Format: TXT=10016 bytes) (Status: + INFORMATIONAL) + +3086 Definition of Differentiated Services Per Domain Behaviors and + Rules for their Specification. K. Nichols, B. Carpenter. April 2001. + (Format: TXT=63122 bytes) (Status: INFORMATIONAL) + +3087 Control of Service Context using SIP Request-URI. B. Campbell, R. + Sparks. April 2001. (Format: TXT=83612 bytes) (Status: INFORMATIONAL) + +3088 OpenLDAP Root Service An experimental LDAP referral service. K. + Zeilenga. April 2001. (Format: TXT=19471 bytes) (Status: + EXPERIMENTAL) + +3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism. H. Kitamura. April + 2001. (Format: TXT=25193 bytes) (Status: INFORMATIONAL) + +3090 DNS Security Extension Clarification on Zone Status. E. Lewis. + March 2001. (Format: TXT=24166 bytes) (Updates RFC2535) (Status: + PROPOSED STANDARD) + +3091 Pi Digit Generation Protocol. H. Kennedy. 1 April 2001. (Format: + TXT=10375 bytes) (Status: INFORMATIONAL) + +3092 Etymology of "Foo". D. Eastlake 3rd, C. Manros, E. Raymond. 1 + April 2001. (Format: TXT=29235 bytes) (Status: INFORMATIONAL) + +3093 Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner. 1 + April 2001. (Format: TXT=22405 bytes) (Status: INFORMATIONAL) + +3094 Tekelec's Transport Adapter Layer Interface. D. Sprague, R. + Benedyk, D. Brendes, J. Keller. April 2001. (Format: TXT=265099 + bytes) (Status: INFORMATIONAL) + +3095 RObust Header Compression (ROHC): Framework and four profiles: + RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M. + Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. + Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. + Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: TXT=368746 bytes) + (Status: PROPOSED STANDARD) + +3096 Requirements for robust IP/UDP/RTP header compression. M. + Degermark. July 2001. (Format: TXT=15018 bytes) (Status: + INFORMATIONAL) + +3097 RSVP Cryptographic Authentication -- Updated Message Type Value. + R. Braden, L. Zhang. April 2001. (Format: TXT=6320 bytes) (Updates + RFC2747) (Status: PROPOSED STANDARD) + +3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how + NOT to $$$$$ MAKE ENEMIES FAST! $$$$$. E. Gavin, D. Eastlake 3rd, S. + Hambridge. April 2001. (Format: TXT=64687 bytes) (Also FYI0038) + (Status: INFORMATIONAL) + +3106 ECML v1.1: Field Specifications for E-Commerce. D. Eastlake, T. + Goldstein. April 2001. (Format: TXT=40715 bytes) (Obsoletes RFC2706) + (Status: INFORMATIONAL) + +3107 Carrying Label Information in BGP-4. Y. Rekhter, E. Rosen. May + 2001. (Format: TXT=16442 bytes) (Status: PROPOSED STANDARD) + +3108 Conventions for the use of the Session Description Protocol (SDP) + for ATM Bearer Connections. R. Kumar, M. Mostafa. May 2001. (Format: + TXT=248037 bytes) (Status: PROPOSED STANDARD) + +3109 Request to Move STD 39 to Historic Status. R. Braden, R. Bush, J. + Klensin. May 2001. (Format: TXT=5841 bytes) (Status: INFORMATIONAL) + +3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS). D. + Eastlake 3rd. May 2001. (Format: TXT=14587 bytes) (Status: PROPOSED + STANDARD) + +3111 Service Location Protocol Modifications for IPv6. E. Guttman. May + 2001. (Format: TXT=25543 bytes) (Status: PROPOSED STANDARD) + +3112 LDAP Authentication Password Schema. K. Zeilenga. May 2001. + (Format: TXT=17116 bytes) (Status: INFORMATIONAL) + +3113 3GPP-IETF Standardization Collaboration. K. Rosenbrock, R. + Sanmugam, S. Bradner, J. Klensin. June 2001. (Format: TXT=11405 + bytes) (Status: INFORMATIONAL) + +3115 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. + Leung. April 2001. (Format: TXT=16363 bytes) (Obsoletes RFC3025) + (Status: PROPOSED STANDARD) + +3116 Methodology for ATM Benchmarking. J. Dunn, C. Martin. June 2001. + (Format: TXT=295052 bytes) (Status: INFORMATIONAL) + +3118 Authentication for DHCP Messages. R. Droms, Editor, W. Arbaugh, + Editor. June 2001. (Format: TXT=35536 bytes) (Status: PROPOSED + STANDARD) + +3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R. + Finlayson. June 2001. (Format: TXT=37796 bytes) (Status: PROPOSED + STANDARD) + +3120 A URN Namespace for XML.org. K. Best, N. Walsh. June 2001. + (Format: TXT=8068 bytes) (Status: INFORMATIONAL) + +3121 A URN Namespace for OASIS. K. Best, N. Walsh. June 2001. (Format: + TXT=11074 bytes) (Status: INFORMATIONAL) + +3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery + Specification. A. Conta. June 2001. (Format: TXT=40416 bytes) + (Status: PROPOSED STANDARD) + +3123 A DNS RR Type for Lists of Address Prefixes (APL RR). P. Koch. + June 2001. (Format: TXT=14648 bytes) (Status: EXPERIMENTAL) + +3124 The Congestion Manager. H. Balakrishnan, S. Seshan. June 2001. + (Format: TXT=53591 bytes) (Status: PROPOSED STANDARD) + +3125 Electronic Signature Policies. J. Ross, D. Pinkas, N. Pope. + September 2001. (Format: TXT=95505 bytes) (Status: EXPERIMENTAL) + +3126 Electronic Signature Formats for long term electronic signatures. + D. Pinkas, J. Ross, N. Pope. September 2001. (Format: TXT=175886 + bytes) (Status: INFORMATIONAL) + +3127 Authentication, Authorization, and Accounting: Protocol + Evaluation. D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, + M. Stevens, B. Wolff. June 2001. (Format: TXT=170579 bytes) (Status: + INFORMATIONAL) + +3128 Protection Against a Variant of the Tiny Fragment Attack (RFC + 1858). I. Miller. June 2001. (Format: TXT=8242 bytes) (Updates + RFC1858) (Status: INFORMATIONAL) + +3129 Requirements for Kerberized Internet Negotiation of Keys. M. + Thomas. June 2001. (Format: TXT=11401 bytes) (Status: INFORMATIONAL) + +3130 Notes from the State-Of-The-Technology: DNSSEC. E. Lewis. June + 2001. (Format: TXT=22291 bytes) (Status: INFORMATIONAL) + +3131 3GPP2-IETF Standardization Collaboration. S. Bradner, P. Calhoun, + H. Cuschieri, S. Dennett, G. Flynn, M. Lipford, M. McPheters. June + 2001. (Format: TXT=13643 bytes) (Status: INFORMATIONAL) + +3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement. J. + Kempf. June 2001. (Format: TXT=34985 bytes) (Status: INFORMATIONAL) + +3133 Terminology for Frame Relay Benchmarking. J. Dunn, C. Martin. + June 2001. (Format: TXT=44182 bytes) (Status: INFORMATIONAL) + +3134 Terminology for ATM ABR Benchmarking. J. Dunn, C. Martin. June + 2001. (Format: TXT=29542 bytes) (Status: INFORMATIONAL) + +3135 Performance Enhancing Proxies Intended to Mitigate Link-Related + Degradations. J. Border, M. Kojo, J. Griner, G. Montenegro, Z. + Shelby. June 2001. (Format: TXT=114825 bytes) (Status: INFORMATIONAL) + +3136 The SPIRITS Architecture. L. Slutsman, Editor, I. Faynberg, H. + Lu, M. Weissman. June 2001. (Format: TXT=19241 bytes) (Status: + INFORMATIONAL) + +3137 OSPF Stub Router Advertisement. A. Retana, L. Nguyen, R. White, + A. Zinin, D. McPherson. June 2001. (Format: TXT=8140 bytes) (Status: + INFORMATIONAL) + +3138 Extended Assignments in 233/8. D. Meyer. June 2001. (Format: + TXT=6776 bytes) (Status: INFORMATIONAL) + +3139 Requirements for Configuration Management of IP-based Networks. + L. Sanchez, K. McCloghrie, J. Saperia. June 2001. (Format: TXT=23624 + bytes) (Status: INFORMATIONAL) + +3140 Per Hop Behavior Identification Codes. D. Black, S. Brim, B. + Carpenter, F. Le Faucheur. June 2001. (Format: TXT=16586 bytes) + (Obsoletes RFC2836) (Status: PROPOSED STANDARD) + +3141 CDMA2000 Wireless Data Requirements for AAA. T. Hiller, P. Walsh, + X. Chen, M. Munson, G. Dommety, S. Sivalingham, B. Lim, P. McCann, H. + Shiino, B. Hirschman, S. Manning, R. Hsu, H. Koo, M. Lipford, P. + Calhoun, C. Lo, E. Jaques, E. Campbell, Y. Xu, S. Baba, T. Ayaki, T. + Seki, A. Hameed. June 2001. (Format: TXT=27998 bytes) (Status: + INFORMATIONAL) + +3142 An IPv6-to-IPv4 Transport Relay Translator. J. Hagino, K. + Yamamoto. June 2001. (Format: TXT=20864 bytes) (Status: + INFORMATIONAL) + +3143 Known HTTP Proxy/Caching Problems. I. Cooper, J. Dilley. June + 2001. (Format: TXT=57117 bytes) (Status: INFORMATIONAL) + +3144 Remote Monitoring MIB Extensions for Interface Parameters + Monitoring. D. Romascanu. August 2001. (Format: TXT=62491 bytes) + (Status: PROPOSED STANDARD) + +3145 L2TP Disconnect Cause Information. R. Verma, M. Verma, J. + Carlson. July 2001. (Format: TXT=17421 bytes) (Status: PROPOSED + STANDARD) + +3147 Generic Routing Encapsulation over CLNS Networks. P. Christian. + July 2001. (Format: TXT=14125 bytes) (Status: INFORMATIONAL) + +3148 A Framework for Defining Empirical Bulk Transfer Capacity + Metrics. M. Mathis, M. Allman. July 2001. (Format: TXT=36041 bytes) + (Status: INFORMATIONAL) + +3149 MGCP Business Phone Packages. A. Srinath, G. Levendel, K. Fritz, + R. Kalyanaram. September 2001. (Format: TXT=77304 bytes) (Status: + INFORMATIONAL) + +3150 End-to-end Performance Implications of Slow Links. S. Dawkins, G. + Montenegro, M. Kojo, V. Magret. July 2001. (Format: TXT=39942 bytes) + (Also BCP0048) (Status: BEST CURRENT PRACTICE) + +3151 A URN Namespace for Public Identifiers. N. Walsh, J. Cowan, P. + Grosso. August 2001. (Format: TXT=15595 bytes) (Status: + INFORMATIONAL) + +3152 Delegation of IP6.ARPA. R. Bush. August 2001. (Format: TXT=5727 + bytes) (Updates RFC2874, RFC2772, RFC2766, RFC2553, RFC1886) (Also + BCP0049) (Status: BEST CURRENT PRACTICE) + +3153 PPP Multiplexing. R. Pazhyannur, I. Ali, C. Fox. August 2001. + (Format: TXT=19244 bytes) (Status: PROPOSED STANDARD) + +3154 Requirements and Functional Architecture for an IP Host Alerting + Protocol. J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, + R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu. August 2001. (Format: + TXT=31534 bytes) (Status: INFORMATIONAL) + +3155 End-to-end Performance Implications of Links with Errors. S. + Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya. August 2001. + (Format: TXT=36388 bytes) (Also BCP0050) (Status: BEST CURRENT + PRACTICE) + +3156 MIME Security with OpenPGP. M. Elkins, D. Del Torto, R. Levien, + T. Roessler. August 2001. (Format: TXT=26809 bytes) (Updates RFC2015) + (Status: PROPOSED STANDARD) + +3157 Securely Available Credentials - Requirements. A. Arsenault, S. + Farrell. August 2001. (Format: TXT=46169 bytes) (Status: + INFORMATIONAL) + +3158 RTP Testing Strategies. C. Perkins, J. Rosenberg, H. Schulzrinne. + August 2001. (Format: TXT=48208 bytes) (Status: INFORMATIONAL) + +3159 Structure of Policy Provisioning Information (SPPI). K. + McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. + Smith, F. Reichmeyer. August 2001. (Format: TXT=78621 bytes) (Status: + PROPOSED STANDARD) + +3160 The Tao of IETF - A Novice's Guide to the Internet Engineering + Task Force. S. Harris. August 2001. (Format: TXT=98411 bytes) + (Obsoletes RFC1718) (Also FYI0017) (Status: INFORMATIONAL) + +3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol + (TSP). C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001. + (Format: TXT=54585 bytes) (Status: PROPOSED STANDARD) + +3162 RADIUS and IPv6. B. Aboba, G. Zorn, D. Mitton. August 2001. + (Format: TXT=20492 bytes) (Status: PROPOSED STANDARD) + +3163 ISO/IEC 9798-3 Authentication SASL Mechanism. R. Zuccherato, M. + Nystrom. August 2001. (Format: TXT=32498 bytes) (Status: + EXPERIMENTAL) + +3164 The BSD Syslog Protocol. C. Lonvick. August 2001. (Format: + TXT=72951 bytes) (Status: INFORMATIONAL) + +3165 Definitions of Managed Objects for the Delegation of Management + Scripts. D. Levi, J. Schoenwaelder. August 2001. (Format: TXT=134479 + bytes) (Obsoletes RFC2592) (Status: PROPOSED STANDARD) + +3166 Request to Move RFC 1403 to Historic Status. D. Meyer, J. + Scudder. August 2001. (Format: TXT=3740 bytes) (Status: + INFORMATIONAL) + +3167 Request to Move RFC 1745 to Historic Status. D. Meyer, J. + Scudder. August 2001. (Format: TXT=3825 bytes) (Status: + INFORMATIONAL) + +3168 The Addition of Explicit Congestion Notification (ECN) to IP. K. + Ramakrishnan, S. Floyd, D. Black. September 2001. (Format: TXT=170966 + bytes) (Status: PROPOSED STANDARD) + +3169 Criteria for Evaluating Network Access Server Protocols. M. + Beadles, D. Mitton. September 2001. (Format: TXT=35303 bytes) + (Status: INFORMATIONAL) + +3170 IP Multicast Applications: Challenges and Solutions. B. Quinn, K. + Almeroth. September 2001. (Format: TXT=67207 bytes) (Status: + INFORMATIONAL) + +3171 IANA Guidelines for IPv4 Multicast Address Assignments. Z. + Albanna, K. Almeroth, D. Meyer, M. Schipper. August 2001. (Format: + TXT=15389 bytes) (Also BCP0051) (Status: BEST CURRENT PRACTICE) + +3172 Management Guidelines & Operational Requirements for the Address + and Routing Parameter Area Domain ("arpa"). G. Huston. September + 2001. (Format: TXT=18097 bytes) (Also BCP0052) (Status: BEST CURRENT + PRACTICE) + +3173 IP Payload Compression Protocol (IPComp). A. Shacham, B. Monsour, + R. Pereira, M. Thomas. September 2001. (Format: TXT=15389 bytes) + (Obsoletes RFC2393) (Status: PROPOSED STANDARD) + +3174 US Secure Hash Algorithm 1 (SHA1). D. Eastlake, 3rd, P. Jones. + September 2001. (Format: TXT=35525 bytes) (Status: INFORMATIONAL) + +3175 Aggregation of RSVP for IPv4 and IPv6 Reservations. F. Baker, C. + Iturralde, F. Le Faucheur, B. Davie. September 2001. (Format: + TXT=88681 bytes) (Status: PROPOSED STANDARD) + +3176 InMon Corporation's sFlow: A Method for Monitoring Traffic in + Switched and Routed Networks. P. Phaal, S. Panchen, N. McKee. + September 2001. (Format: TXT=60171 bytes) (Status: INFORMATIONAL) + +3177 IAB/IESG Recommendations on IPv6 Address. IAB, IESG. September + 2001. (Format: TXT=23178 bytes) (Status: INFORMATIONAL) + +3180 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. September 2001. + (Format: TXT=8225 bytes) (Obsoletes RFC2770) (Also BCP0053) (Status: + BEST CURRENT PRACTICE) diff --git a/Documentation/en/rfc/rfc1034.txt b/Documentation/en/rfc/rfc1034.txt new file mode 100644 index 00000000..55cdb21f --- /dev/null +++ b/Documentation/en/rfc/rfc1034.txt @@ -0,0 +1,3077 @@ +Network Working Group P. Mockapetris +Request for Comments: 1034 ISI +Obsoletes: RFCs 882, 883, 973 November 1987 + + + DOMAIN NAMES - CONCEPTS AND FACILITIES + + + +1. STATUS OF THIS MEMO + +This RFC is an introduction to the Domain Name System (DNS), and omits +many details which can be found in a companion RFC, "Domain Names - +Implementation and Specification" [RFC-1035]. That RFC assumes that the +reader is familiar with the concepts discussed in this memo. + +A subset of DNS functions and data types constitute an official +protocol. The official protocol includes standard queries and their +responses and most of the Internet class data formats (e.g., host +addresses). + +However, the domain system is intentionally extensible. Researchers are +continuously proposing, implementing and experimenting with new data +types, query types, classes, functions, etc. Thus while the components +of the official protocol are expected to stay essentially unchanged and +operate as a production service, experimental behavior should always be +expected in extensions beyond the official protocol. Experimental or +obsolete features are clearly marked in these RFCs, and such information +should be used with caution. + +The reader is especially cautioned not to depend on the values which +appear in examples to be current or complete, since their purpose is +primarily pedagogical. Distribution of this memo is unlimited. + +2. INTRODUCTION + +This RFC introduces domain style names, their use for Internet mail and +host address support, and the protocols and servers used to implement +domain name facilities. + +2.1. The history of domain names + +The impetus for the development of the domain system was growth in the +Internet: + + - Host name to address mappings were maintained by the Network + Information Center (NIC) in a single file (HOSTS.TXT) which + was FTPed by all hosts [RFC-952, RFC-953]. The total network + + + +Mockapetris [Page 1] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + bandwidth consumed in distributing a new version by this + scheme is proportional to the square of the number of hosts in + the network, and even when multiple levels of FTP are used, + the outgoing FTP load on the NIC host is considerable. + Explosive growth in the number of hosts didn't bode well for + the future. + + - The network population was also changing in character. The + timeshared hosts that made up the original ARPANET were being + replaced with local networks of workstations. Local + organizations were administering their own names and + addresses, but had to wait for the NIC to change HOSTS.TXT to + make changes visible to the Internet at large. Organizations + also wanted some local structure on the name space. + + - The applications on the Internet were getting more + sophisticated and creating a need for general purpose name + service. + + +The result was several ideas about name spaces and their management +[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a +common thread was the idea of a hierarchical name space, with the +hierarchy roughly corresponding to organizational structure, and names +using "." as the character to mark the boundary between hierarchy +levels. A design using a distributed database and generalized resources +was described in [RFC-882, RFC-883]. Based on experience with several +implementations, the system evolved into the scheme described in this +memo. + +The terms "domain" or "domain name" are used in many contexts beyond the +DNS described here. Very often, the term domain name is used to refer +to a name with structure indicated by dots, but no relation to the DNS. +This is particularly true in mail addressing [Quarterman 86]. + +2.2. DNS design goals + +The design goals of the DNS influence its structure. They are: + + - The primary goal is a consistent name space which will be used + for referring to resources. In order to avoid the problems + caused by ad hoc encodings, names should not be required to + contain network identifiers, addresses, routes, or similar + information as part of the name. + + - The sheer size of the database and frequency of updates + suggest that it must be maintained in a distributed manner, + with local caching to improve performance. Approaches that + + + +Mockapetris [Page 2] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + attempt to collect a consistent copy of the entire database + will become more and more expensive and difficult, and hence + should be avoided. The same principle holds for the structure + of the name space, and in particular mechanisms for creating + and deleting names; these should also be distributed. + + - Where there tradeoffs between the cost of acquiring data, the + speed of updates, and the accuracy of caches, the source of + the data should control the tradeoff. + + - The costs of implementing such a facility dictate that it be + generally useful, and not restricted to a single application. + We should be able to use names to retrieve host addresses, + mailbox data, and other as yet undetermined information. All + data associated with a name is tagged with a type, and queries + can be limited to a single type. + + - Because we want the name space to be useful in dissimilar + networks and applications, we provide the ability to use the + same name space with different protocol families or + management. For example, host address formats differ between + protocols, though all protocols have the notion of address. + The DNS tags all data with a class as well as the type, so + that we can allow parallel use of different formats for data + of type address. + + - We want name server transactions to be independent of the + communications system that carries them. Some systems may + wish to use datagrams for queries and responses, and only + establish virtual circuits for transactions that need the + reliability (e.g., database updates, long transactions); other + systems will use virtual circuits exclusively. + + - The system should be useful across a wide spectrum of host + capabilities. Both personal computers and large timeshared + hosts should be able to use the system, though perhaps in + different ways. + +2.3. Assumptions about usage + +The organization of the domain system derives from some assumptions +about the needs and usage patterns of its user community and is designed +to avoid many of the the complicated problems found in general purpose +database systems. + +The assumptions are: + + - The size of the total database will initially be proportional + + + +Mockapetris [Page 3] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + to the number of hosts using the system, but will eventually + grow to be proportional to the number of users on those hosts + as mailboxes and other information are added to the domain + system. + + - Most of the data in the system will change very slowly (e.g., + mailbox bindings, host addresses), but that the system should + be able to deal with subsets that change more rapidly (on the + order of seconds or minutes). + + - The administrative boundaries used to distribute + responsibility for the database will usually correspond to + organizations that have one or more hosts. Each organization + that has responsibility for a particular set of domains will + provide redundant name servers, either on the organization's + own hosts or other hosts that the organization arranges to + use. + + - Clients of the domain system should be able to identify + trusted name servers they prefer to use before accepting + referrals to name servers outside of this "trusted" set. + + - Access to information is more critical than instantaneous + updates or guarantees of consistency. Hence the update + process allows updates to percolate out through the users of + the domain system rather than guaranteeing that all copies are + simultaneously updated. When updates are unavailable due to + network or host failure, the usual course is to believe old + information while continuing efforts to update it. The + general model is that copies are distributed with timeouts for + refreshing. The distributor sets the timeout value and the + recipient of the distribution is responsible for performing + the refresh. In special situations, very short intervals can + be specified, or the owner can prohibit copies. + + - In any system that has a distributed database, a particular + name server may be presented with a query that can only be + answered by some other server. The two general approaches to + dealing with this problem are "recursive", in which the first + server pursues the query for the client at another server, and + "iterative", in which the server refers the client to another + server and lets the client pursue the query. Both approaches + have advantages and disadvantages, but the iterative approach + is preferred for the datagram style of access. The domain + system requires implementation of the iterative approach, but + allows the recursive approach as an option. + + + + + +Mockapetris [Page 4] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +The domain system assumes that all data originates in master files +scattered through the hosts that use the domain system. These master +files are updated by local system administrators. Master files are text +files that are read by a local name server, and hence become available +through the name servers to users of the domain system. The user +programs access name servers through standard programs called resolvers. + +The standard format of master files allows them to be exchanged between +hosts (via FTP, mail, or some other mechanism); this facility is useful +when an organization wants a domain, but doesn't want to support a name +server. The organization can maintain the master files locally using a +text editor, transfer them to a foreign host which runs a name server, +and then arrange with the system administrator of the name server to get +the files loaded. + +Each host's name servers and resolvers are configured by a local system +administrator [RFC-1033]. For a name server, this configuration data +includes the identity of local master files and instructions on which +non-local master files are to be loaded from foreign servers. The name +server uses the master files or copies to load its zones. For +resolvers, the configuration data identifies the name servers which +should be the primary sources of information. + +The domain system defines procedures for accessing the data and for +referrals to other name servers. The domain system also defines +procedures for caching retrieved data and for periodic refreshing of +data defined by the system administrator. + +The system administrators provide: + + - The definition of zone boundaries. + + - Master files of data. + + - Updates to master files. + + - Statements of the refresh policies desired. + +The domain system provides: + + - Standard formats for resource data. + + - Standard methods for querying the database. + + - Standard methods for name servers to refresh local data from + foreign name servers. + + + + + +Mockapetris [Page 5] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +2.4. Elements of the DNS + +The DNS has three major components: + + - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are + specifications for a tree structured name space and data + associated with the names. Conceptually, each node and leaf + of the domain name space tree names a set of information, and + query operations are attempts to extract specific types of + information from a particular set. A query names the domain + name of interest and describes the type of resource + information that is desired. For example, the Internet + uses some of its domain names to identify hosts; queries for + address resources return Internet host addresses. + + - NAME SERVERS are server programs which hold information about + the domain tree's structure and set information. A name + server may cache structure or set information about any part + of the domain tree, but in general a particular name server + has complete information about a subset of the domain space, + and pointers to other name servers that can be used to lead to + information from any part of the domain tree. Name servers + know the parts of the domain tree for which they have complete + information; a name server is said to be an AUTHORITY for + these parts of the name space. Authoritative information is + organized into units called ZONEs, and these zones can be + automatically distributed to the name servers which provide + redundant service for the data in a zone. + + - RESOLVERS are programs that extract information from name + servers in response to client requests. Resolvers must be + able to access at least one name server and use that name + server's information to answer a query directly, or pursue the + query using referrals to other name servers. A resolver will + typically be a system routine that is directly accessible to + user programs; hence no protocol is necessary between the + resolver and the user program. + +These three components roughly correspond to the three layers or views +of the domain system: + + - From the user's point of view, the domain system is accessed + through a simple procedure or OS call to a local resolver. + The domain space consists of a single tree and the user can + request information from any section of the tree. + + - From the resolver's point of view, the domain system is + composed of an unknown number of name servers. Each name + + + +Mockapetris [Page 6] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + server has one or more pieces of the whole domain tree's data, + but the resolver views each of these databases as essentially + static. + + - From a name server's point of view, the domain system consists + of separate sets of local information called zones. The name + server has local copies of some of the zones. The name server + must periodically refresh its zones from master copies in + local files or foreign name servers. The name server must + concurrently process queries that arrive from resolvers. + +In the interests of performance, implementations may couple these +functions. For example, a resolver on the same machine as a name server +might share a database consisting of the the zones managed by the name +server and the cache managed by the resolver. + +3. DOMAIN NAME SPACE and RESOURCE RECORDS + +3.1. Name space specifications and terminology + +The domain name space is a tree structure. Each node and leaf on the +tree corresponds to a resource set (which may be empty). The domain +system makes no distinctions between the uses of the interior nodes and +leaves, and this memo uses the term "node" to refer to both. + +Each node has a label, which is zero to 63 octets in length. Brother +nodes may not have the same label, although the same label can be used +for nodes which are not brothers. One label is reserved, and that is +the null (i.e., zero length) label used for the root. + +The domain name of a node is the list of the labels on the path from the +node to the root of the tree. By convention, the labels that compose a +domain name are printed or read left to right, from the most specific +(lowest, farthest from the root) to the least specific (highest, closest +to the root). + +Internally, programs that manipulate domain names should represent them +as sequences of labels, where each label is a length octet followed by +an octet string. Because all domain names end at the root, which has a +null string for a label, these internal representations can use a length +byte of zero to terminate a domain name. + +By convention, domain names can be stored with arbitrary case, but +domain name comparisons for all present domain functions are done in a +case-insensitive manner, assuming an ASCII character set, and a high +order zero bit. This means that you are free to create a node with +label "A" or a node with label "a", but not both as brothers; you could +refer to either using "a" or "A". When you receive a domain name or + + + +Mockapetris [Page 7] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +label, you should preserve its case. The rationale for this choice is +that we may someday need to add full binary domain names for new +services; existing services would not be changed. + +When a user needs to type a domain name, the length of each label is +omitted and the labels are separated by dots ("."). Since a complete +domain name ends with the root label, this leads to a printed form which +ends in a dot. We use this property to distinguish between: + + - a character string which represents a complete domain name + (often called "absolute"). For example, "poneria.ISI.EDU." + + - a character string that represents the starting labels of a + domain name which is incomplete, and should be completed by + local software using knowledge of the local domain (often + called "relative"). For example, "poneria" used in the + ISI.EDU domain. + +Relative names are either taken relative to a well known origin, or to a +list of domains used as a search list. Relative names appear mostly at +the user interface, where their interpretation varies from +implementation to implementation, and in master files, where they are +relative to a single origin domain name. The most common interpretation +uses the root "." as either the single origin or as one of the members +of the search list, so a multi-label relative name is often one where +the trailing dot has been omitted to save typing. + +To simplify implementations, the total number of octets that represent a +domain name (i.e., the sum of all label octets and label lengths) is +limited to 255. + +A domain is identified by a domain name, and consists of that part of +the domain name space that is at or below the domain name which +specifies the domain. A domain is a subdomain of another domain if it +is contained within that domain. This relationship can be tested by +seeing if the subdomain's name ends with the containing domain's name. +For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". + +3.2. Administrative guidelines on use + +As a matter of policy, the DNS technical specifications do not mandate a +particular tree structure or rules for selecting labels; its goal is to +be as general as possible, so that it can be used to build arbitrary +applications. In particular, the system was designed so that the name +space did not have to be organized along the lines of network +boundaries, name servers, etc. The rationale for this is not that the +name space should have no implied semantics, but rather that the choice +of implied semantics should be left open to be used for the problem at + + + +Mockapetris [Page 8] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +hand, and that different parts of the tree can have different implied +semantics. For example, the IN-ADDR.ARPA domain is organized and +distributed by network and host address because its role is to translate +from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- +1002] are flat because that is appropriate for that application. + +However, there are some guidelines that apply to the "normal" parts of +the name space used for hosts, mailboxes, etc., that will make the name +space more uniform, provide for growth, and minimize problems as +software is converted from the older host table. The political +decisions about the top levels of the tree originated in RFC-920. +Current policy for the top levels is discussed in [RFC-1032]. MILNET +conversion issues are covered in [RFC-1031]. + +Lower domains which will eventually be broken into multiple zones should +provide branching at the top of the domain so that the eventual +decomposition can be done without renaming. Node labels which use +special characters, leading digits, etc., are likely to break older +software which depends on more restrictive choices. + +3.3. Technical guidelines on use + +Before the DNS can be used to hold naming information for some kind of +object, two needs must be met: + + - A convention for mapping between object names and domain + names. This describes how information about an object is + accessed. + + - RR types and data formats for describing the object. + +These rules can be quite simple or fairly complex. Very often, the +designer must take into account existing formats and plan for upward +compatibility for existing usage. Multiple mappings or levels of +mapping may be required. + +For hosts, the mapping depends on the existing syntax for host names +which is a subset of the usual text representation for domain names, +together with RR formats for describing host addresses, etc. Because we +need a reliable inverse mapping from address to host name, a special +mapping for addresses into the IN-ADDR.ARPA domain is also defined. + +For mailboxes, the mapping is slightly more complex. The usual mail +address <local-part>@<mail-domain> is mapped into a domain name by +converting <local-part> into a single label (regardles of dots it +contains), converting <mail-domain> into a domain name using the usual +text format for domain names (dots denote label breaks), and +concatenating the two to form a single domain name. Thus the mailbox + + + +Mockapetris [Page 9] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by +HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this +design also must take into account the scheme for mail exchanges [RFC- +974]. + +The typical user is not concerned with defining these rules, but should +understand that they usually are the result of numerous compromises +between desires for upward compatibility with old usage, interactions +between different object definitions, and the inevitable urge to add new +features when defining the rules. The way the DNS is used to support +some object is often more crucial than the restrictions inherent in the +DNS. + +3.4. Example name space + +The following figure shows a part of the current domain name space, and +is used in many examples in this RFC. Note that the tree is a very +small subset of the actual name space. + + | + | + +---------------------+------------------+ + | | | + MIL EDU ARPA + | | | + | | | + +-----+-----+ | +------+-----+-----+ + | | | | | | | + BRL NOSC DARPA | IN-ADDR SRI-NIC ACC + | + +--------+------------------+---------------+--------+ + | | | | | + UCI MIT | UDEL YALE + | ISI + | | + +---+---+ | + | | | + LCS ACHILLES +--+-----+-----+--------+ + | | | | | | + XX A C VAXA VENERA Mockapetris + +In this example, the root domain has three immediate subdomains: MIL, +EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named +XX.LCS.MIT.EDU. All of the leaves are also domains. + +3.5. Preferred name syntax + +The DNS specifications attempt to be as general as possible in the rules + + + +Mockapetris [Page 10] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +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 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 + +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. + +For example, the following strings identify hosts in the Internet: + +A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA + +3.6. Resource Records + +A domain name identifies a node. Each node has a set of resource + + + +Mockapetris [Page 11] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +information, which may be empty. The set of resource information +associated with a particular name is composed of separate resource +records (RRs). The order of RRs in a set is not significant, and need +not be preserved by name servers, resolvers, or other parts of the DNS. + +When we talk about a specific RR, we assume it has the following: + +owner which is the domain name where the RR is found. + +type which is an encoded 16 bit value that specifies the type + of the resource in this resource record. Types refer to + abstract resources. + + This memo uses the following types: + + A a host address + + CNAME identifies the canonical name of an + alias + + HINFO identifies the CPU and OS used by a host + + MX identifies a mail exchange for the + domain. See [RFC-974 for details. + + NS + the authoritative name server for the domain + + PTR + a pointer to another part of the domain name space + + SOA + identifies the start of a zone of authority] + +class which is an encoded 16 bit value which identifies a + protocol family or instance of a protocol. + + This memo uses the following classes: + + IN the Internet system + + CH the Chaos system + +TTL which is the time to live of the RR. This field is a 32 + bit integer in units of seconds, an is primarily used by + resolvers when they cache RRs. The TTL describes how + long a RR can be cached before it should be discarded. + + + + +Mockapetris [Page 12] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +RDATA which is the type and sometimes class dependent data + which describes the resource: + + A For the IN class, a 32 bit IP address + + For the CH class, a domain name followed + by a 16 bit octal Chaos address. + + CNAME a domain name. + + MX a 16 bit preference value (lower is + better) followed by a host name willing + to act as a mail exchange for the owner + domain. + + NS a host name. + + PTR a domain name. + + SOA several fields. + +The owner name is often implicit, rather than forming an integral part +of the RR. For example, many name servers internally form tree or hash +structures for the name space, and chain RRs off nodes. The remaining +RR parts are the fixed header (type, class, TTL) which is consistent for +all RRs, and a variable part (RDATA) that fits the needs of the resource +being described. + +The meaning of the TTL field is a time limit on how long an RR can be +kept in a cache. This limit does not apply to authoritative data in +zones; it is also timed out, but by the refreshing policies for the +zone. The TTL is assigned by the administrator for the zone where the +data originates. While short TTLs can be used to minimize caching, and +a zero TTL prohibits caching, the realities of Internet performance +suggest that these times should be on the order of days for the typical +host. If a change can be anticipated, the TTL can be reduced prior to +the change to minimize inconsistency during the change, and then +increased back to its former value following the change. + +The data in the RDATA section of RRs is carried as a combination of +binary strings and domain names. The domain names are frequently used +as "pointers" to other data in the DNS. + +3.6.1. Textual expression of RRs + +RRs are represented in binary form in the packets of the DNS protocol, +and are usually represented in highly encoded form when stored in a name +server or resolver. In this memo, we adopt a style similar to that used + + + +Mockapetris [Page 13] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +in master files in order to show the contents of RRs. In this format, +most RRs are shown on a single line, although continuation lines are +possible using parentheses. + +The start of the line gives the owner of the RR. If a line begins with +a blank, then the owner is assumed to be the same as that of the +previous RR. Blank lines are often included for readability. + +Following the owner, we list the TTL, type, and class of the RR. Class +and type use the mnemonics defined above, and TTL is an integer before +the type field. In order to avoid ambiguity in parsing, type and class +mnemonics are disjoint, TTLs are integers, and the type mnemonic is +always last. The IN class and TTL values are often omitted from examples +in the interests of clarity. + +The resource data or RDATA section of the RR are given using knowledge +of the typical representation for the data. + +For example, we might show the RRs carried in a message as: + + ISI.EDU. MX 10 VENERA.ISI.EDU. + MX 10 VAXA.ISI.EDU. + VENERA.ISI.EDU. A 128.9.0.32 + A 10.1.0.52 + VAXA.ISI.EDU. A 10.2.0.27 + A 128.9.0.33 + +The MX RRs have an RDATA section which consists of a 16 bit number +followed by a domain name. The address RRs use a standard IP address +format to contain a 32 bit internet address. + +This example shows six RRs, with two RRs at each of three domain names. + +Similarly we might see: + + XX.LCS.MIT.EDU. IN A 10.0.0.44 + CH A MIT.EDU. 2420 + +This example shows two addresses for XX.LCS.MIT.EDU, each of a different +class. + +3.6.2. Aliases and canonical names + +In existing systems, hosts and other resources often have several names +that identify the same resource. For example, the names C.ISI.EDU and +USC-ISIC.ARPA both identify the same host. Similarly, in the case of +mailboxes, many organizations provide many names that actually go to the +same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU, + + + +Mockapetris [Page 14] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +and PVM@ISI.EDU all go to the same mailbox (although the mechanism +behind this is somewhat complicated). + +Most of these systems have a notion that one of the equivalent set of +names is the canonical or primary name and all others are aliases. + +The domain system provides such a feature using the canonical name +(CNAME) RR. A CNAME RR identifies its owner name as an alias, and +specifies the corresponding canonical name in the RDATA section of the +RR. If a CNAME RR is present at a node, no other data should be +present; this ensures that the data for a canonical name and its aliases +cannot be different. This rule also insures that a cached CNAME can be +used without checking with an authoritative server for other RR types. + +CNAME RRs cause special action in DNS software. When a name server +fails to find a desired RR in the resource set associated with the +domain name, it checks to see if the resource set consists of a CNAME +record with a matching class. If so, the name server includes the CNAME +record in the response and restarts the query at the domain name +specified in the data field of the CNAME record. The one exception to +this rule is that queries which match the CNAME type are not restarted. + +For example, suppose a name server was processing a query with for USC- +ISIC.ARPA, asking for type A information, and had the following resource +records: + + USC-ISIC.ARPA IN CNAME C.ISI.EDU + + C.ISI.EDU IN A 10.0.0.52 + +Both of these RRs would be returned in the response to the type A query, +while a type CNAME or * query should return just the CNAME. + +Domain names in RRs which point at another name should always point at +the primary name and not the alias. This avoids extra indirections in +accessing information. For example, the address to name RR for the +above host should be: + + 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU + +rather than pointing at USC-ISIC.ARPA. Of course, by the robustness +principle, domain software should not fail when presented with CNAME +chains or loops; CNAME chains should be followed and CNAME loops +signalled as an error. + +3.7. Queries + +Queries are messages which may be sent to a name server to provoke a + + + +Mockapetris [Page 15] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +response. In the Internet, queries are carried in UDP datagrams or over +TCP connections. The response by the name server either answers the +question posed in the query, refers the requester to another set of name +servers, or signals some error condition. + +In general, the user does not generate queries directly, but instead +makes a request to a resolver which in turn sends one or more queries to +name servers and deals with the error conditions and referrals that may +result. Of course, the possible questions which can be asked in a query +does shape the kind of service a resolver can provide. + +DNS queries and responses are carried in a standard message format. The +message format has a header containing a number of fixed fields which +are always present, and four sections which carry query parameters and +RRs. + +The most important field in the header is a four bit field called an +opcode which separates different queries. Of the possible 16 values, +one (standard query) is part of the official protocol, two (inverse +query and status query) are options, one (completion) is obsolete, and +the rest are unassigned. + +The four sections are: + +Question Carries the query name and other query parameters. + +Answer Carries RRs which directly answer the query. + +Authority Carries RRs which describe other authoritative servers. + May optionally carry the SOA RR for the authoritative + data in the answer section. + +Additional Carries RRs which may be helpful in using the RRs in the + other sections. + +Note that the content, but not the format, of these sections varies with +header opcode. + +3.7.1. Standard queries + +A standard query specifies a target domain name (QNAME), query type +(QTYPE), and query class (QCLASS) and asks for RRs which match. This +type of query makes up such a vast majority of DNS queries that we use +the term "query" to mean standard query unless otherwise specified. The +QTYPE and QCLASS fields are each 16 bits long, and are a superset of +defined types and classes. + + + + + +Mockapetris [Page 16] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +The QTYPE field may contain: + +<any type> matches just that type. (e.g., A, PTR). + +AXFR special zone transfer QTYPE. + +MAILB matches all mail box related RRs (e.g. MB and MG). + +* matches all RR types. + +The QCLASS field may contain: + +<any class> matches just that class (e.g., IN, CH). + +* matches aLL RR classes. + +Using the query domain name, QTYPE, and QCLASS, the name server looks +for matching RRs. In addition to relevant records, the name server may +return RRs that point toward a name server that has the desired +information or RRs that are expected to be useful in interpreting the +relevant RRs. For example, a name server that doesn't have the +requested information may know a name server that does; a name server +that returns a domain name in a relevant RR may also return the RR that +binds that domain name to an address. + +For example, a mailer tying to send mail to Mockapetris@ISI.EDU might +ask the resolver for mail information about ISI.EDU, resulting in a +query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer +section would be: + + ISI.EDU. MX 10 VENERA.ISI.EDU. + MX 10 VAXA.ISI.EDU. + +while the additional section might be: + + VAXA.ISI.EDU. A 10.2.0.27 + A 128.9.0.33 + VENERA.ISI.EDU. A 10.1.0.52 + A 128.9.0.32 + +Because the server assumes that if the requester wants mail exchange +information, it will probably want the addresses of the mail exchanges +soon afterward. + +Note that the QCLASS=* construct requires special interpretation +regarding authority. Since a particular name server may not know all of +the classes available in the domain system, it can never know if it is +authoritative for all classes. Hence responses to QCLASS=* queries can + + + +Mockapetris [Page 17] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +never be authoritative. + +3.7.2. Inverse queries (Optional) + +Name servers may also support inverse queries that map a particular +resource to a domain name or domain names that have that resource. For +example, while a standard query might map a domain name to a SOA RR, the +corresponding inverse query might map the SOA RR back to the domain +name. + +Implementation of this service is optional in a name server, but all +name servers must at least be able to understand an inverse query +message and return a not-implemented error response. + +The domain system cannot guarantee the completeness or uniqueness of +inverse queries because the domain system is organized by domain name +rather than by host address or any other resource type. Inverse queries +are primarily useful for debugging and database maintenance activities. + +Inverse queries may not return the proper TTL, and do not indicate cases +where the identified RR is one of a set (for example, one address for a +host having multiple addresses). Therefore, the RRs returned in inverse +queries should never be cached. + +Inverse queries are NOT an acceptable method for mapping host addresses +to host names; use the IN-ADDR.ARPA domain instead. + +A detailed discussion of inverse queries is contained in [RFC-1035]. + +3.8. Status queries (Experimental) + +To be defined. + +3.9. Completion queries (Obsolete) + +The optional completion services described in RFCs 882 and 883 have been +deleted. Redesigned services may become available in the future, or the +opcodes may be reclaimed for other use. + +4. NAME SERVERS + +4.1. Introduction + +Name servers are the repositories of information that make up the domain +database. The database is divided up into sections called zones, which +are distributed among the name servers. While name servers can have +several optional functions and sources of data, the essential task of a +name server is to answer queries using data in its zones. By design, + + + +Mockapetris [Page 18] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +name servers can answer queries in a simple manner; the response can +always be generated using only local data, and either contains the +answer to the question or a referral to other name servers "closer" to +the desired information. + +A given zone will be available from several name servers to insure its +availability in spite of host or communication link failure. By +administrative fiat, we require every zone to be available on at least +two servers, and many zones have more redundancy than that. + +A given name server will typically support one or more zones, but this +gives it authoritative information about only a small section of the +domain tree. It may also have some cached non-authoritative data about +other parts of the tree. The name server marks its responses to queries +so that the requester can tell whether the response comes from +authoritative data or not. + +4.2. How the database is divided into zones + +The domain database is partitioned in two ways: by class, and by "cuts" +made in the name space between nodes. + +The class partition is simple. The database for any class is organized, +delegated, and maintained separately from all other classes. Since, by +convention, the name spaces are the same for all classes, the separate +classes can be thought of as an array of parallel namespace trees. Note +that the data attached to nodes will be different for these different +parallel classes. The most common reasons for creating a new class are +the necessity for a new data format for existing types or a desire for a +separately managed version of the existing name space. + +Within a class, "cuts" in the name space can be made between any two +adjacent nodes. After all cuts are made, each group of connected name +space is a separate zone. The zone is said to be authoritative for all +names in the connected region. Note that the "cuts" in the name space +may be in different places for different classes, the name servers may +be different, etc. + +These rules mean that every zone has at least one node, and hence domain +name, for which it is authoritative, and all of the nodes in a +particular zone are connected. Given, the tree structure, every zone +has a highest node which is closer to the root than any other node in +the zone. The name of this node is often used to identify the zone. + +It would be possible, though not particularly useful, to partition the +name space so that each domain name was in a separate zone or so that +all nodes were in a single zone. Instead, the database is partitioned +at points where a particular organization wants to take over control of + + + +Mockapetris [Page 19] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +a subtree. Once an organization controls its own zone it can +unilaterally change the data in the zone, grow new tree sections +connected to the zone, delete existing nodes, or delegate new subzones +under its zone. + +If the organization has substructure, it may want to make further +internal partitions to achieve nested delegations of name space control. +In some cases, such divisions are made purely to make database +maintenance more convenient. + +4.2.1. Technical considerations + +The data that describes a zone has four major parts: + + - Authoritative data for all nodes within the zone. + + - Data that defines the top node of the zone (can be thought of + as part of the authoritative data). + + - Data that describes delegated subzones, i.e., cuts around the + bottom of the zone. + + - Data that allows access to name servers for subzones + (sometimes called "glue" data). + +All of this data is expressed in the form of RRs, so a zone can be +completely described in terms of a set of RRs. Whole zones can be +transferred between name servers by transferring the RRs, either carried +in a series of messages or by FTPing a master file which is a textual +representation. + +The authoritative data for a zone is simply all of the RRs attached to +all of the nodes from the top node of the zone down to leaf nodes or +nodes above cuts around the bottom edge of the zone. + +Though logically part of the authoritative data, the RRs that describe +the top node of the zone are especially important to the zone's +management. These RRs are of two types: name server RRs that list, one +per RR, all of the servers for the zone, and a single SOA RR that +describes zone management parameters. + +The RRs that describe cuts around the bottom of the zone are NS RRs that +name the servers for the subzones. Since the cuts are between nodes, +these RRs are NOT part of the authoritative data of the zone, and should +be exactly the same as the corresponding RRs in the top node of the +subzone. Since name servers are always associated with zone boundaries, +NS RRs are only found at nodes which are the top node of some zone. In +the data that makes up a zone, NS RRs are found at the top node of the + + + +Mockapetris [Page 20] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +zone (and are authoritative) and at cuts around the bottom of the zone +(where they are not authoritative), but never in between. + +One of the goals of the zone structure is that any zone have all the +data required to set up communications with the name servers for any +subzones. That is, parent zones have all the information needed to +access servers for their children zones. The NS RRs that name the +servers for subzones are often not enough for this task since they name +the servers, but do not give their addresses. In particular, if the +name of the name server is itself in the subzone, we could be faced with +the situation where the NS RRs tell us that in order to learn a name +server's address, we should contact the server using the address we wish +to learn. To fix this problem, a zone contains "glue" RRs which are not +part of the authoritative data, and are address RRs for the servers. +These RRs are only necessary if the name server's name is "below" the +cut, and are only used as part of a referral response. + +4.2.2. Administrative considerations + +When some organization wants to control its own domain, the first step +is to identify the proper parent zone, and get the parent zone's owners +to agree to the delegation of control. While there are no particular +technical constraints dealing with where in the tree this can be done, +there are some administrative groupings discussed in [RFC-1032] which +deal with top level organization, and middle level zones are free to +create their own rules. For example, one university might choose to use +a single zone, while another might choose to organize by subzones +dedicated to individual departments or schools. [RFC-1033] catalogs +available DNS software an discusses administration procedures. + +Once the proper name for the new subzone is selected, the new owners +should be required to demonstrate redundant name server support. Note +that there is no requirement that the servers for a zone reside in a +host which has a name in that domain. In many cases, a zone will be +more accessible to the internet at large if its servers are widely +distributed rather than being within the physical facilities controlled +by the same organization that manages the zone. For example, in the +current DNS, one of the name servers for the United Kingdom, or UK +domain, is found in the US. This allows US hosts to get UK data without +using limited transatlantic bandwidth. + +As the last installation step, the delegation NS RRs and glue RRs +necessary to make the delegation effective should be added to the parent +zone. The administrators of both zones should insure that the NS and +glue RRs which mark both sides of the cut are consistent and remain so. + +4.3. Name server internals + + + + +Mockapetris [Page 21] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +4.3.1. Queries and responses + +The principal activity of name servers is to answer standard queries. +Both the query and its response are carried in a standard message format +which is described in [RFC-1035]. The query contains a QTYPE, QCLASS, +and QNAME, which describe the types and classes of desired information +and the name of interest. + +The way that the name server answers the query depends upon whether it +is operating in recursive mode or not: + + - The simplest mode for the server is non-recursive, since it + can answer queries using only local information: the response + contains an error, the answer, or a referral to some other + server "closer" to the answer. All name servers must + implement non-recursive queries. + + - The simplest mode for the client is recursive, since in this + mode the name server acts in the role of a resolver and + returns either an error or the answer, but never referrals. + This service is optional in a name server, and the name server + may also choose to restrict the clients which can use + recursive mode. + +Recursive service is helpful in several situations: + + - a relatively simple requester that lacks the ability to use + anything other than a direct answer to the question. + + - a request that needs to cross protocol or other boundaries and + can be sent to a server which can act as intermediary. + + - a network where we want to concentrate the cache rather than + having a separate cache for each client. + +Non-recursive service is appropriate if the requester is capable of +pursuing referrals and interested in information which will aid future +requests. + +The use of recursive mode is limited to cases where both the client and +the name server agree to its use. The agreement is negotiated through +the use of two bits in query and response messages: + + - The recursion available, or RA bit, is set or cleared by a + name server in all responses. The bit is true if the name + server is willing to provide recursive service for the client, + regardless of whether the client requested recursive service. + That is, RA signals availability rather than use. + + + +Mockapetris [Page 22] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + - Queries contain a bit called recursion desired or RD. This + bit specifies specifies whether the requester wants recursive + service for this query. Clients may request recursive service + from any name server, though they should depend upon receiving + it only from servers which have previously sent an RA, or + servers which have agreed to provide service through private + agreement or some other means outside of the DNS protocol. + +The recursive mode occurs when a query with RD set arrives at a server +which is willing to provide recursive service; the client can verify +that recursive mode was used by checking that both RA and RD are set in +the reply. Note that the name server should never perform recursive +service unless asked via RD, since this interferes with trouble shooting +of name servers and their databases. + +If recursive service is requested and available, the recursive response +to a query will be one of the following: + + - The answer to the query, possibly preface by one or more CNAME + RRs that specify aliases encountered on the way to an answer. + + - A name error indicating that the name does not exist. This + may include CNAME RRs that indicate that the original query + name was an alias for a name which does not exist. + + - A temporary error indication. + +If recursive service is not requested or is not available, the non- +recursive response will be one of the following: + + - An authoritative name error indicating that the name does not + exist. + + - A temporary error indication. + + - Some combination of: + + RRs that answer the question, together with an indication + whether the data comes from a zone or is cached. + + A referral to name servers which have zones which are closer + ancestors to the name than the server sending the reply. + + - RRs that the name server thinks will prove useful to the + requester. + + + + + + +Mockapetris [Page 23] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +4.3.2. Algorithm + +The actual algorithm used by the name server will depend on the local OS +and data structures used to store RRs. The following algorithm assumes +that the RRs are organized in several tree structures, one for each +zone, and another for the cache: + + 1. Set or clear the value of recursion available in the response + depending on whether the name server is willing to provide + recursive service. If recursive service is available and + requested via the RD bit in the query, go to step 5, + otherwise step 2. + + 2. Search the available zones for the zone which is the nearest + ancestor to QNAME. If such a zone is found, go to step 3, + otherwise step 4. + + 3. Start matching down, label by label, in the zone. The + matching process can terminate several ways: + + a. If the whole of QNAME is matched, we have found the + node. + + If the data at the node is a CNAME, and QTYPE doesn't + match CNAME, copy the CNAME RR into the answer section + of the response, change QNAME to the canonical name in + the CNAME RR, and go back to step 1. + + Otherwise, copy all RRs which match QTYPE into the + answer section and go to step 6. + + b. If a match would take us out of the authoritative data, + we have a referral. This happens when we encounter a + node with NS RRs marking cuts along the bottom of a + zone. + + Copy the NS RRs for the subzone into the authority + section of the reply. Put whatever addresses are + available into the additional section, using glue RRs + if the addresses are not available from authoritative + data or the cache. Go to step 4. + + c. If at some label, a match is impossible (i.e., the + corresponding label does not exist), look to see if a + the "*" label exists. + + If the "*" label does not exist, check whether the name + we are looking for is the original QNAME in the query + + + +Mockapetris [Page 24] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + or a name we have followed due to a CNAME. If the name + is original, set an authoritative name error in the + response and exit. Otherwise just exit. + + If the "*" label does exist, match RRs at that node + against QTYPE. If any match, copy them into the answer + section, but set the owner of the RR to be QNAME, and + not the node with the "*" label. Go to step 6. + + 4. Start matching down in the cache. If QNAME is found in the + cache, copy all RRs attached to it that match QTYPE into the + answer section. If there was no delegation from + authoritative data, look for the best one from the cache, and + put it in the authority section. Go to step 6. + + 5. Using the local resolver or a copy of its algorithm (see + resolver section of this memo) to answer the query. Store + the results, including any intermediate CNAMEs, in the answer + section of the response. + + 6. Using local data only, attempt to add other RRs which may be + useful to the additional section of the query. Exit. + +4.3.3. Wildcards + +In the previous algorithm, special treatment was given to RRs with owner +names starting with the label "*". Such RRs are called wildcards. +Wildcard RRs can be thought of as instructions for synthesizing RRs. +When the appropriate conditions are met, the name server creates RRs +with an owner name equal to the query name and contents taken from the +wildcard RRs. + +This facility is most often used to create a zone which will be used to +forward mail from the Internet to some other mail system. The general +idea is that any name in that zone which is presented to server in a +query will be assumed to exist, with certain properties, unless explicit +evidence exists to the contrary. Note that the use of the term zone +here, instead of domain, is intentional; such defaults do not propagate +across zone boundaries, although a subzone may choose to achieve that +appearance by setting up similar defaults. + +The contents of the wildcard RRs follows the usual rules and formats for +RRs. The wildcards in the zone have an owner name that controls the +query names they will match. The owner name of the wildcard RRs is of +the form "*.<anydomain>", where <anydomain> is any domain name. +<anydomain> should not contain other * labels, and should be in the +authoritative data of the zone. The wildcards potentially apply to +descendants of <anydomain>, but not to <anydomain> itself. Another way + + + +Mockapetris [Page 25] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +to look at this is that the "*" label always matches at least one whole +label and sometimes more, but always whole labels. + +Wildcard RRs do not apply: + + - When the query is in another zone. That is, delegation cancels + the wildcard defaults. + + - When the query name or a name between the wildcard domain and + the query name is know to exist. For example, if a wildcard + RR has an owner name of "*.X", and the zone also contains RRs + attached to B.X, the wildcards would apply to queries for name + Z.X (presuming there is no explicit information for Z.X), but + not to B.X, A.B.X, or X. + +A * label appearing in a query name has no special effect, but can be +used to test for wildcards in an authoritative zone; such a query is the +only way to get a response containing RRs with an owner name with * in +it. The result of such a query should not be cached. + +Note that the contents of the wildcard RRs are not modified when used to +synthesize RRs. + +To illustrate the use of wildcard RRs, suppose a large company with a +large, non-IP/TCP, network wanted to create a mail gateway. If the +company was called X.COM, and IP/TCP capable gateway machine was called +A.X.COM, the following RRs might be entered into the COM zone: + + X.COM MX 10 A.X.COM + + *.X.COM MX 10 A.X.COM + + A.X.COM A 1.2.3.4 + A.X.COM MX 10 A.X.COM + + *.A.X.COM MX 10 A.X.COM + +This would cause any MX query for any domain name ending in X.COM to +return an MX RR pointing at A.X.COM. Two wildcard RRs are required +since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM +subtree by the explicit data for A.X.COM. Note also that the explicit +MX data at X.COM and A.X.COM is required, and that none of the RRs above +would match a query name of XX.COM. + +4.3.4. Negative response caching (Optional) + +The DNS provides an optional service which allows name servers to +distribute, and resolvers to cache, negative results with TTLs. For + + + +Mockapetris [Page 26] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +example, a name server can distribute a TTL along with a name error +indication, and a resolver receiving such information is allowed to +assume that the name does not exist during the TTL period without +consulting authoritative data. Similarly, a resolver can make a query +with a QTYPE which matches multiple types, and cache the fact that some +of the types are not present. + +This feature can be particularly important in a system which implements +naming shorthands that use search lists beacuse a popular shorthand, +which happens to require a suffix toward the end of the search list, +will generate multiple name errors whenever it is used. + +The method is that a name server may add an SOA RR to the additional +section of a response when that response is authoritative. The SOA must +be that of the zone which was the source of the authoritative data in +the answer section, or name error if applicable. The MINIMUM field of +the SOA controls the length of time that the negative result may be +cached. + +Note that in some circumstances, the answer section may contain multiple +owner names. In this case, the SOA mechanism should only be used for +the data which matches QNAME, which is the only authoritative data in +this section. + +Name servers and resolvers should never attempt to add SOAs to the +additional section of a non-authoritative response, or attempt to infer +results which are not directly stated in an authoritative response. +There are several reasons for this, including: cached information isn't +usually enough to match up RRs and their zone names, SOA RRs may be +cached due to direct SOA queries, and name servers are not required to +output the SOAs in the authority section. + +This feature is optional, although a refined version is expected to +become part of the standard protocol in the future. Name servers are +not required to add the SOA RRs in all authoritative responses, nor are +resolvers required to cache negative results. Both are recommended. +All resolvers and recursive name servers are required to at least be +able to ignore the SOA RR when it is present in a response. + +Some experiments have also been proposed which will use this feature. +The idea is that if cached data is known to come from a particular zone, +and if an authoritative copy of the zone's SOA is obtained, and if the +zone's SERIAL has not changed since the data was cached, then the TTL of +the cached data can be reset to the zone MINIMUM value if it is smaller. +This usage is mentioned for planning purposes only, and is not +recommended as yet. + + + + + +Mockapetris [Page 27] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +4.3.5. Zone maintenance and transfers + +Part of the job of a zone administrator is to maintain the zones at all +of the name servers which are authoritative for the zone. When the +inevitable changes are made, they must be distributed to all of the name +servers. While this distribution can be accomplished using FTP or some +other ad hoc procedure, the preferred method is the zone transfer part +of the DNS protocol. + +The general model of automatic zone transfer or refreshing is that one +of the name servers is the master or primary for the zone. Changes are +coordinated at the primary, typically by editing a master file for the +zone. After editing, the administrator signals the master server to +load the new zone. The other non-master or secondary servers for the +zone periodically check for changes (at a selectable interval) and +obtain new zone copies when changes have been made. + +To detect changes, secondaries just check the SERIAL field of the SOA +for the zone. In addition to whatever other changes are made, the +SERIAL field in the SOA of the zone is always advanced whenever any +change is made to the zone. The advancing can be a simple increment, or +could be based on the write date and time of the master file, etc. The +purpose is to make it possible to determine which of two copies of a +zone is more recent by comparing serial numbers. Serial number advances +and comparisons use sequence space arithmetic, so there is a theoretic +limit on how fast a zone can be updated, basically that old copies must +die out before the serial number covers half of its 32 bit range. In +practice, the only concern is that the compare operation deals properly +with comparisons around the boundary between the most positive and most +negative 32 bit numbers. + +The periodic polling of the secondary servers is controlled by +parameters in the SOA RR for the zone, which set the minimum acceptable +polling intervals. The parameters are called REFRESH, RETRY, and +EXPIRE. Whenever a new zone is loaded in a secondary, the secondary +waits REFRESH seconds before checking with the primary for a new serial. +If this check cannot be completed, new checks are started every RETRY +seconds. The check is a simple query to the primary for the SOA RR of +the zone. If the serial field in the secondary's zone copy is equal to +the serial returned by the primary, then no changes have occurred, and +the REFRESH interval wait is restarted. If the secondary finds it +impossible to perform a serial check for the EXPIRE interval, it must +assume that its copy of the zone is obsolete an discard it. + +When the poll shows that the zone has changed, then the secondary server +must request a zone transfer via an AXFR request for the zone. The AXFR +may cause an error, such as refused, but normally is answered by a +sequence of response messages. The first and last messages must contain + + + +Mockapetris [Page 28] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +the data for the top authoritative node of the zone. Intermediate +messages carry all of the other RRs from the zone, including both +authoritative and non-authoritative RRs. The stream of messages allows +the secondary to construct a copy of the zone. Because accuracy is +essential, TCP or some other reliable protocol must be used for AXFR +requests. + +Each secondary server is required to perform the following operations +against the master, but may also optionally perform these operations +against other secondary servers. This strategy can improve the transfer +process when the primary is unavailable due to host downtime or network +problems, or when a secondary server has better network access to an +"intermediate" secondary than to the primary. + +5. RESOLVERS + +5.1. Introduction + +Resolvers are programs that interface user programs to domain name +servers. In the simplest case, a resolver receives a request from a +user program (e.g., mail programs, TELNET, FTP) in the form of a +subroutine call, system call etc., and returns the desired information +in a form compatible with the local host's data formats. + +The resolver is located on the same machine as the program that requests +the resolver's services, but it may need to consult name servers on +other hosts. Because a resolver may need to consult several name +servers, or may have the requested information in a local cache, the +amount of time that a resolver will take to complete can vary quite a +bit, from milliseconds to several seconds. + +A very important goal of the resolver is to eliminate network delay and +name server load from most requests by answering them from its cache of +prior results. It follows that caches which are shared by multiple +processes, users, machines, etc., are more efficient than non-shared +caches. + +5.2. Client-resolver interface + +5.2.1. Typical functions + +The client interface to the resolver is influenced by the local host's +conventions, but the typical resolver-client interface has three +functions: + + 1. Host name to host address translation. + + This function is often defined to mimic a previous HOSTS.TXT + + + +Mockapetris [Page 29] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + based function. Given a character string, the caller wants + one or more 32 bit IP addresses. Under the DNS, it + translates into a request for type A RRs. Since the DNS does + not preserve the order of RRs, this function may choose to + sort the returned addresses or select the "best" address if + the service returns only one choice to the client. Note that + a multiple address return is recommended, but a single + address may be the only way to emulate prior HOSTS.TXT + services. + + 2. Host address to host name translation + + This function will often follow the form of previous + functions. Given a 32 bit IP address, the caller wants a + character string. The octets of the IP address are reversed, + used as name components, and suffixed with "IN-ADDR.ARPA". A + type PTR query is used to get the RR with the primary name of + the host. For example, a request for the host name + corresponding to IP address 1.2.3.4 looks for PTR RRs for + domain name "4.3.2.1.IN-ADDR.ARPA". + + 3. General lookup function + + This function retrieves arbitrary information from the DNS, + and has no counterpart in previous systems. The caller + supplies a QNAME, QTYPE, and QCLASS, and wants all of the + matching RRs. This function will often use the DNS format + for all RR data instead of the local host's, and returns all + RR content (e.g., TTL) instead of a processed form with local + quoting conventions. + +When the resolver performs the indicated function, it usually has one of +the following results to pass back to the client: + + - One or more RRs giving the requested data. + + In this case the resolver returns the answer in the + appropriate format. + + - A name error (NE). + + This happens when the referenced name does not exist. For + example, a user may have mistyped a host name. + + - A data not found error. + + This happens when the referenced name exists, but data of the + appropriate type does not. For example, a host address + + + +Mockapetris [Page 30] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + function applied to a mailbox name would return this error + since the name exists, but no address RR is present. + +It is important to note that the functions for translating between host +names and addresses may combine the "name error" and "data not found" +error conditions into a single type of error return, but the general +function should not. One reason for this is that applications may ask +first for one type of information about a name followed by a second +request to the same name for some other type of information; if the two +errors are combined, then useless queries may slow the application. + +5.2.2. Aliases + +While attempting to resolve a particular request, the resolver may find +that the name in question is an alias. For example, the resolver might +find that the name given for host name to address translation is an +alias when it finds the CNAME RR. If possible, the alias condition +should be signalled back from the resolver to the client. + +In most cases a resolver simply restarts the query at the new name when +it encounters a CNAME. However, when performing the general function, +the resolver should not pursue aliases when the CNAME RR matches the +query type. This allows queries which ask whether an alias is present. +For example, if the query type is CNAME, the user is interested in the +CNAME RR itself, and not the RRs at the name it points to. + +Several special conditions can occur with aliases. Multiple levels of +aliases should be avoided due to their lack of efficiency, but should +not be signalled as an error. Alias loops and aliases which point to +non-existent names should be caught and an error condition passed back +to the client. + +5.2.3. Temporary failures + +In a less than perfect world, all resolvers will occasionally be unable +to resolve a particular request. This condition can be caused by a +resolver which becomes separated from the rest of the network due to a +link failure or gateway problem, or less often by coincident failure or +unavailability of all servers for a particular domain. + +It is essential that this sort of condition should not be signalled as a +name or data not present error to applications. This sort of behavior +is annoying to humans, and can wreak havoc when mail systems use the +DNS. + +While in some cases it is possible to deal with such a temporary problem +by blocking the request indefinitely, this is usually not a good choice, +particularly when the client is a server process that could move on to + + + +Mockapetris [Page 31] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +other tasks. The recommended solution is to always have temporary +failure as one of the possible results of a resolver function, even +though this may make emulation of existing HOSTS.TXT functions more +difficult. + +5.3. Resolver internals + +Every resolver implementation uses slightly different algorithms, and +typically spends much more logic dealing with errors of various sorts +than typical occurances. This section outlines a recommended basic +strategy for resolver operation, but leaves details to [RFC-1035]. + +5.3.1. Stub resolvers + +One option for implementing a resolver is to move the resolution +function out of the local machine and into a name server which supports +recursive queries. This can provide an easy method of providing domain +service in a PC which lacks the resources to perform the resolver +function, or can centralize the cache for a whole local network or +organization. + +All that the remaining stub needs is a list of name server addresses +that will perform the recursive requests. This type of resolver +presumably needs the information in a configuration file, since it +probably lacks the sophistication to locate it in the domain database. +The user also needs to verify that the listed servers will perform the +recursive service; a name server is free to refuse to perform recursive +services for any or all clients. The user should consult the local +system administrator to find name servers willing to perform the +service. + +This type of service suffers from some drawbacks. Since the recursive +requests may take an arbitrary amount of time to perform, the stub may +have difficulty optimizing retransmission intervals to deal with both +lost UDP packets and dead servers; the name server can be easily +overloaded by too zealous a stub if it interprets retransmissions as new +requests. Use of TCP may be an answer, but TCP may well place burdens +on the host's capabilities which are similar to those of a real +resolver. + +5.3.2. Resources + +In addition to its own resources, the resolver may also have shared +access to zones maintained by a local name server. This gives the +resolver the advantage of more rapid access, but the resolver must be +careful to never let cached information override zone data. In this +discussion the term "local information" is meant to mean the union of +the cache and such shared zones, with the understanding that + + + +Mockapetris [Page 32] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +authoritative data is always used in preference to cached data when both +are present. + +The following resolver algorithm assumes that all functions have been +converted to a general lookup function, and uses the following data +structures to represent the state of a request in progress in the +resolver: + +SNAME the domain name we are searching for. + +STYPE the QTYPE of the search request. + +SCLASS the QCLASS of the search request. + +SLIST a structure which describes the name servers and the + zone which the resolver is currently trying to query. + This structure keeps track of the resolver's current + best guess about which name servers hold the desired + information; it is updated when arriving information + changes the guess. This structure includes the + equivalent of a zone name, the known name servers for + the zone, the known addresses for the name servers, and + history information which can be used to suggest which + server is likely to be the best one to try next. The + zone name equivalent is a match count of the number of + labels from the root down which SNAME has in common with + the zone being queried; this is used as a measure of how + "close" the resolver is to SNAME. + +SBELT a "safety belt" structure of the same form as SLIST, + which is initialized from a configuration file, and + lists servers which should be used when the resolver + doesn't have any local information to guide name server + selection. The match count will be -1 to indicate that + no labels are known to match. + +CACHE A structure which stores the results from previous + responses. Since resolvers are responsible for + discarding old RRs whose TTL has expired, most + implementations convert the interval specified in + arriving RRs to some sort of absolute time when the RR + is stored in the cache. Instead of counting the TTLs + down individually, the resolver just ignores or discards + old RRs when it runs across them in the course of a + search, or discards them during periodic sweeps to + reclaim the memory consumed by old RRs. + + + + + +Mockapetris [Page 33] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +5.3.3. Algorithm + +The top level algorithm has four steps: + + 1. See if the answer is in local information, and if so return + it to the client. + + 2. Find the best servers to ask. + + 3. Send them queries until one returns a response. + + 4. Analyze the response, either: + + a. if the response answers the question or contains a name + error, cache the data as well as returning it back to + the client. + + b. if the response contains a better delegation to other + servers, cache the delegation information, and go to + step 2. + + c. if the response shows a CNAME and that is not the + answer itself, cache the CNAME, change the SNAME to the + canonical name in the CNAME RR and go to step 1. + + d. if the response shows a servers failure or other + bizarre contents, delete the server from the SLIST and + go back to step 3. + +Step 1 searches the cache for the desired data. If the data is in the +cache, it is assumed to be good enough for normal use. Some resolvers +have an option at the user interface which will force the resolver to +ignore the cached data and consult with an authoritative server. This +is not recommended as the default. If the resolver has direct access to +a name server's zones, it should check to see if the desired data is +present in authoritative form, and if so, use the authoritative data in +preference to cached data. + +Step 2 looks for a name server to ask for the required data. The +general strategy is to look for locally-available name server RRs, +starting at SNAME, then the parent domain name of SNAME, the +grandparent, and so on toward the root. Thus if SNAME were +Mockapetris.ISI.EDU, this step would look for NS RRs for +Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root). +These NS RRs list the names of hosts for a zone at or above SNAME. Copy +the names into SLIST. Set up their addresses using local data. It may +be the case that the addresses are not available. The resolver has many +choices here; the best is to start parallel resolver processes looking + + + +Mockapetris [Page 34] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +for the addresses while continuing onward with the addresses which are +available. Obviously, the design choices and options are complicated +and a function of the local host's capabilities. The recommended +priorities for the resolver designer are: + + 1. Bound the amount of work (packets sent, parallel processes + started) so that a request can't get into an infinite loop or + start off a chain reaction of requests or queries with other + implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED + SOME DATA. + + 2. Get back an answer if at all possible. + + 3. Avoid unnecessary transmissions. + + 4. Get the answer as quickly as possible. + +If the search for NS RRs fails, then the resolver initializes SLIST from +the safety belt SBELT. The basic idea is that when the resolver has no +idea what servers to ask, it should use information from a configuration +file that lists several servers which are expected to be helpful. +Although there are special situations, the usual choice is two of the +root servers and two of the servers for the host's domain. The reason +for two of each is for redundancy. The root servers will provide +eventual access to all of the domain space. The two local servers will +allow the resolver to continue to resolve local names if the local +network becomes isolated from the internet due to gateway or link +failure. + +In addition to the names and addresses of the servers, the SLIST data +structure can be sorted to use the best servers first, and to insure +that all addresses of all servers are used in a round-robin manner. The +sorting can be a simple function of preferring addresses on the local +network over others, or may involve statistics from past events, such as +previous response times and batting averages. + +Step 3 sends out queries until a response is received. The strategy is +to cycle around all of the addresses for all of the servers with a +timeout between each transmission. In practice it is important to use +all addresses of a multihomed host, and too aggressive a retransmission +policy actually slows response when used by multiple resolvers +contending for the same name server and even occasionally for a single +resolver. SLIST typically contains data values to control the timeouts +and keep track of previous transmissions. + +Step 4 involves analyzing responses. The resolver should be highly +paranoid in its parsing of responses. It should also check that the +response matches the query it sent using the ID field in the response. + + + +Mockapetris [Page 35] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +The ideal answer is one from a server authoritative for the query which +either gives the required data or a name error. The data is passed back +to the user and entered in the cache for future use if its TTL is +greater than zero. + +If the response shows a delegation, the resolver should check to see +that the delegation is "closer" to the answer than the servers in SLIST +are. This can be done by comparing the match count in SLIST with that +computed from SNAME and the NS RRs in the delegation. If not, the reply +is bogus and should be ignored. If the delegation is valid the NS +delegation RRs and any address RRs for the servers should be cached. +The name servers are entered in the SLIST, and the search is restarted. + +If the response contains a CNAME, the search is restarted at the CNAME +unless the response has the data for the canonical name or if the CNAME +is the answer itself. + +Details and implementation hints can be found in [RFC-1035]. + +6. A SCENARIO + +In our sample domain space, suppose we wanted separate administrative +control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might +allocate name servers as follows: + + + |(C.ISI.EDU,SRI-NIC.ARPA + | A.ISI.EDU) + +---------------------+------------------+ + | | | + MIL EDU ARPA + |(SRI-NIC.ARPA, |(SRI-NIC.ARPA, | + | A.ISI.EDU | C.ISI.EDU) | + +-----+-----+ | +------+-----+-----+ + | | | | | | | + BRL NOSC DARPA | IN-ADDR SRI-NIC ACC + | + +--------+------------------+---------------+--------+ + | | | | | + UCI MIT | UDEL YALE + |(XX.LCS.MIT.EDU, ISI + |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU, + +---+---+ | A.ISI.EDU) + | | | + LCS ACHILLES +--+-----+-----+--------+ + | | | | | | + XX A C VAXA VENERA Mockapetris + + + + +Mockapetris [Page 36] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +In this example, the authoritative name server is shown in parentheses +at the point in the domain tree at which is assumes control. + +Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and +A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The +EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers +may have zones which are contiguous or disjoint. In this scenario, +C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU +has contiguous zones at the root and MIL domains, but also has a non- +contiguous zone at ISI.EDU. + +6.1. C.ISI.EDU name server + +C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN +class, and would have zones for these domains. The zone data for the +root domain might be: + + . IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( + 870611 ;serial + 1800 ;refresh every 30 min + 300 ;retry every 5 min + 604800 ;expire after a week + 86400) ;minimum of a day + NS A.ISI.EDU. + NS C.ISI.EDU. + NS SRI-NIC.ARPA. + + MIL. 86400 NS SRI-NIC.ARPA. + 86400 NS A.ISI.EDU. + + EDU. 86400 NS SRI-NIC.ARPA. + 86400 NS C.ISI.EDU. + + SRI-NIC.ARPA. A 26.0.0.73 + A 10.0.0.51 + MX 0 SRI-NIC.ARPA. + HINFO DEC-2060 TOPS20 + + ACC.ARPA. A 26.6.0.65 + HINFO PDP-11/70 UNIX + MX 10 ACC.ARPA. + + USC-ISIC.ARPA. CNAME C.ISI.EDU. + + 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. + 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + 52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU. + + + +Mockapetris [Page 37] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU. + + A.ISI.EDU. 86400 A 26.3.0.103 + C.ISI.EDU. 86400 A 10.0.0.52 + +This data is represented as it would be in a master file. Most RRs are +single line entries; the sole exception here is the SOA RR, which uses +"(" to start a multi-line RR and ")" to show the end of a multi-line RR. +Since the class of all RRs in a zone must be the same, only the first RR +in a zone need specify the class. When a name server loads a zone, it +forces the TTL of all authoritative RRs to be at least the MINIMUM field +of the SOA, here 86400 seconds, or one day. The NS RRs marking +delegation of the MIL and EDU domains, together with the glue RRs for +the servers host addresses, are not part of the authoritative data in +the zone, and hence have explicit TTLs. + +Four RRs are attached to the root node: the SOA which describes the root +zone and the 3 NS RRs which list the name servers for the root. The +data in the SOA RR describes the management of the zone. The zone data +is maintained on host SRI-NIC.ARPA, and the responsible party for the +zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400 +second minimum TTL, which means that all authoritative data in the zone +has at least that TTL, although higher values may be explicitly +specified. + +The NS RRs for the MIL and EDU domains mark the boundary between the +root zone and the MIL and EDU zones. Note that in this example, the +lower zones happen to be supported by name servers which also support +the root zone. + +The master file for the EDU zone might be stated relative to the origin +EDU. The zone data for the EDU domain might be: + + EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( + 870729 ;serial + 1800 ;refresh every 30 minutes + 300 ;retry every 5 minutes + 604800 ;expire after a week + 86400 ;minimum of a day + ) + NS SRI-NIC.ARPA. + NS C.ISI.EDU. + + UCI 172800 NS ICS.UCI + 172800 NS ROME.UCI + ICS.UCI 172800 A 192.5.19.1 + ROME.UCI 172800 A 192.5.19.31 + + + + +Mockapetris [Page 38] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + ISI 172800 NS VAXA.ISI + 172800 NS A.ISI + 172800 NS VENERA.ISI.EDU. + VAXA.ISI 172800 A 10.2.0.27 + 172800 A 128.9.0.33 + VENERA.ISI.EDU. 172800 A 10.1.0.52 + 172800 A 128.9.0.32 + A.ISI 172800 A 26.3.0.103 + + UDEL.EDU. 172800 NS LOUIE.UDEL.EDU. + 172800 NS UMN-REI-UC.ARPA. + LOUIE.UDEL.EDU. 172800 A 10.0.0.96 + 172800 A 192.5.39.3 + + YALE.EDU. 172800 NS YALE.ARPA. + YALE.EDU. 172800 NS YALE-BULLDOG.ARPA. + + MIT.EDU. 43200 NS XX.LCS.MIT.EDU. + 43200 NS ACHILLES.MIT.EDU. + XX.LCS.MIT.EDU. 43200 A 10.0.0.44 + ACHILLES.MIT.EDU. 43200 A 18.72.0.8 + +Note the use of relative names here. The owner name for the ISI.EDU. is +stated using a relative name, as are two of the name server RR contents. +Relative and absolute domain names may be freely intermixed in a master + +6.2. Example standard queries + +The following queries and responses illustrate name server behavior. +Unless otherwise noted, the queries do not have recursion desired (RD) +in the header. Note that the answers to non-recursive queries do depend +on the server being asked, but do not depend on the identity of the +requester. + + + + + + + + + + + + + + + + + + +Mockapetris [Page 39] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A + +The query would look like: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY | + +---------------------------------------------------+ + Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | + +---------------------------------------------------+ + Answer | <empty> | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +The response from C.ISI.EDU would be: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA | + +---------------------------------------------------+ + Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | + +---------------------------------------------------+ + Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | + | 86400 IN A 10.0.0.51 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +The header of the response looks like the header of the query, except +that the RESPONSE bit is set, indicating that this message is a +response, not a query, and the Authoritative Answer (AA) bit is set +indicating that the address RRs in the answer section are from +authoritative data. The question section of the response matches the +question section of the query. + + + + + + + + + + + + + + +Mockapetris [Page 40] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +If the same query was sent to some other server which was not +authoritative for SRI-NIC.ARPA, the response might be: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY,RESPONSE | + +---------------------------------------------------+ + Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | + +---------------------------------------------------+ + Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 | + | 1777 IN A 26.0.0.73 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +This response is different from the previous one in two ways: the header +does not have AA set, and the TTLs are different. The inference is that +the data did not come from a zone, but from a cache. The difference +between the authoritative TTL and the TTL here is due to aging of the +data in a cache. The difference in ordering of the RRs in the answer +section is not significant. + +6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=* + +A query similar to the previous one, but using a QTYPE of *, would +receive the following response from C.ISI.EDU: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA | + +---------------------------------------------------+ + Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | + +---------------------------------------------------+ + Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | + | A 10.0.0.51 | + | MX 0 SRI-NIC.ARPA. | + | HINFO DEC-2060 TOPS20 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + + + + + + + + + +Mockapetris [Page 41] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +If a similar query was directed to two name servers which are not +authoritative for SRI-NIC.ARPA, the responses might be: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | + +---------------------------------------------------+ + Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 | + | A 10.0.0.51 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +and + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | + +---------------------------------------------------+ + Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +Neither of these answers have AA set, so neither response comes from +authoritative data. The different contents and different TTLs suggest +that the two servers cached data at different times, and that the first +server cached the response to a QTYPE=A query and the second cached the +response to a HINFO query. + + + + + + + + + + + + + + + + +Mockapetris [Page 42] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX + +This type of query might be result from a mailer trying to look up +routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA. +The response from C.ISI.EDU would be: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA | + +---------------------------------------------------+ + Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX | + +---------------------------------------------------+ + Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.| + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | + | A 10.0.0.51 | + +---------------------------------------------------+ + +This response contains the MX RR in the answer section of the response. +The additional section contains the address RRs because the name server +at C.ISI.EDU guesses that the requester will need the addresses in order +to properly use the information carried by the MX. + +6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS + +C.ISI.EDU would reply to this query with: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA | + +---------------------------------------------------+ + Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS | + +---------------------------------------------------+ + Answer | <empty> | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +The only difference between the response and the query is the AA and +RESPONSE bits in the header. The interpretation of this response is +that the server is authoritative for the name, and the name exists, but +no RRs of type NS are present there. + +6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A + +If a user mistyped a host name, we might see this type of query. + + + +Mockapetris [Page 43] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +C.ISI.EDU would answer it with: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE | + +---------------------------------------------------+ + Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A | + +---------------------------------------------------+ + Answer | <empty> | + +---------------------------------------------------+ + Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. | + | 870611 1800 300 604800 86400 | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +This response states that the name does not exist. This condition is +signalled in the response code (RCODE) section of the header. + +The SOA RR in the authority section is the optional negative caching +information which allows the resolver using this response to assume that +the name will not exist for the SOA MINIMUM (86400) seconds. + +6.2.6. QNAME=BRL.MIL, QTYPE=A + +If this query is sent to C.ISI.EDU, the reply would be: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A | + +---------------------------------------------------+ + Answer | <empty> | + +---------------------------------------------------+ + Authority | MIL. 86400 IN NS SRI-NIC.ARPA. | + | 86400 NS A.ISI.EDU. | + +---------------------------------------------------+ + Additional | A.ISI.EDU. A 26.3.0.103 | + | SRI-NIC.ARPA. A 26.0.0.73 | + | A 10.0.0.51 | + +---------------------------------------------------+ + +This response has an empty answer section, but is not authoritative, so +it is a referral. The name server on C.ISI.EDU, realizing that it is +not authoritative for the MIL domain, has referred the requester to +servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative +for the MIL domain. + + + + + +Mockapetris [Page 44] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A + +The response to this query from A.ISI.EDU would be: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA | + +---------------------------------------------------+ + Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | + +---------------------------------------------------+ + Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | + | C.ISI.EDU. 86400 IN A 10.0.0.52 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +Note that the AA bit in the header guarantees that the data matching +QNAME is authoritative, but does not say anything about whether the data +for C.ISI.EDU is authoritative. This complete reply is possible because +A.ISI.EDU happens to be authoritative for both the ARPA domain where +USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is +found. + +If the same query was sent to C.ISI.EDU, its response might be the same +as shown above if it had its own address in its cache, but might also +be: + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 45] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA | + +---------------------------------------------------+ + Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | + +---------------------------------------------------+ + Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | + +---------------------------------------------------+ + Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | + | NS A.ISI.EDU. | + | NS VENERA.ISI.EDU. | + +---------------------------------------------------+ + Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | + | 172800 A 128.9.0.33 | + | VENERA.ISI.EDU. 172800 A 10.1.0.52 | + | 172800 A 128.9.0.32 | + | A.ISI.EDU. 172800 A 26.3.0.103 | + +---------------------------------------------------+ + +This reply contains an authoritative reply for the alias USC-ISIC.ARPA, +plus a referral to the name servers for ISI.EDU. This sort of reply +isn't very likely given that the query is for the host name of the name +server being asked, but would be common for other aliases. + +6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME + +If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would +be: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA | + +---------------------------------------------------+ + Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | + +---------------------------------------------------+ + Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name +server doesn't attempt to look up anything for C.ISI.EDU. (Except +possibly for the additional section.) + +6.3. Example resolution + +The following examples illustrate the operations a resolver must perform +for its client. We assume that the resolver is starting without a + + + +Mockapetris [Page 46] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +cache, as might be the case after system boot. We further assume that +the system is not one of the hosts in the data and that the host is +located somewhere on net 26, and that its safety belt (SBELT) data +structure has the following information: + + Match count = -1 + SRI-NIC.ARPA. 26.0.0.73 10.0.0.51 + A.ISI.EDU. 26.3.0.103 + +This information specifies servers to try, their addresses, and a match +count of -1, which says that the servers aren't very close to the +target. Note that the -1 isn't supposed to be an accurate closeness +measure, just a value so that later stages of the algorithm will work. + +The following examples illustrate the use of a cache, so each example +assumes that previous requests have completed. + +6.3.1. Resolve MX for ISI.EDU. + +Suppose the first request to the resolver comes from the local mailer, +which has mail for PVM@ISI.EDU. The mailer might then ask for type MX +RRs for the domain name ISI.EDU. + +The resolver would look in its cache for MX RRs at ISI.EDU, but the +empty cache wouldn't be helpful. The resolver would recognize that it +needed to query foreign servers and try to determine the best servers to +query. This search would look for NS RRs for the domains ISI.EDU, EDU, +and the root. These searches of the cache would also fail. As a last +resort, the resolver would use the information from the SBELT, copying +it into its SLIST structure. + +At this point the resolver would need to pick one of the three available +addresses to try. Given that the resolver is on net 26, it should +choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would +then send off a query of the form: + + + + + + + + + + + + + + + + +Mockapetris [Page 47] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + +---------------------------------------------------+ + Header | OPCODE=SQUERY | + +---------------------------------------------------+ + Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | + +---------------------------------------------------+ + Answer | <empty> | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +The resolver would then wait for a response to its query or a timeout. +If the timeout occurs, it would try different servers, then different +addresses of the same servers, lastly retrying addresses already tried. +It might eventually receive a reply from SRI-NIC.ARPA: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | + +---------------------------------------------------+ + Answer | <empty> | + +---------------------------------------------------+ + Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | + | NS A.ISI.EDU. | + | NS VENERA.ISI.EDU.| + +---------------------------------------------------+ + Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | + | 172800 A 128.9.0.33 | + | VENERA.ISI.EDU. 172800 A 10.1.0.52 | + | 172800 A 128.9.0.32 | + | A.ISI.EDU. 172800 A 26.3.0.103 | + +---------------------------------------------------+ + +The resolver would notice that the information in the response gave a +closer delegation to ISI.EDU than its existing SLIST (since it matches +three labels). The resolver would then cache the information in this +response and use it to set up a new SLIST: + + Match count = 3 + A.ISI.EDU. 26.3.0.103 + VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 + VENERA.ISI.EDU. 10.1.0.52 128.9.0.32 + +A.ISI.EDU appears on this list as well as the previous one, but that is +purely coincidental. The resolver would again start transmitting and +waiting for responses. Eventually it would get an answer: + + + +Mockapetris [Page 48] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA | + +---------------------------------------------------+ + Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | + +---------------------------------------------------+ + Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. | + | MX 20 VAXA.ISI.EDU. | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | + | 172800 A 128.9.0.33 | + | VENERA.ISI.EDU. 172800 A 10.1.0.52 | + | 172800 A 128.9.0.32 | + +---------------------------------------------------+ + +The resolver would add this information to its cache, and return the MX +RRs to its client. + +6.3.2. Get the host name for address 26.6.0.65 + +The resolver would translate this into a request for PTR RRs for +65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the +resolver would look for foreign servers to ask. No servers would match, +so it would use SBELT again. (Note that the servers for the ISI.EDU +domain are in the cache, but ISI.EDU is not an ancestor of +65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.) + +Since this request is within the authoritative data of both servers in +SBELT, eventually one would return: + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 49] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE, AA | + +---------------------------------------------------+ + Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR | + +---------------------------------------------------+ + Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +6.3.3. Get the host address of poneria.ISI.EDU + +This request would translate into a type A request for poneria.ISI.EDU. +The resolver would not find any cached data for this name, but would +find the NS RRs in the cache for ISI.EDU when it looks for foreign +servers to ask. Using this data, it would construct a SLIST of the +form: + + Match count = 3 + + A.ISI.EDU. 26.3.0.103 + VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 + VENERA.ISI.EDU. 10.1.0.52 + +A.ISI.EDU is listed first on the assumption that the resolver orders its +choices by preference, and A.ISI.EDU is on the same network. + +One of these servers would answer the query. + +7. REFERENCES and BIBLIOGRAPHY + +[Dyer 87] Dyer, S., and F. Hsu, "Hesiod", Project Athena + Technical Plan - Name Service, April 1987, version 1.9. + + Describes the fundamentals of the Hesiod name service. + +[IEN-116] J. Postel, "Internet Name Server", IEN-116, + USC/Information Sciences Institute, August 1979. + + A name service obsoleted by the Domain Name System, but + still in use. + + + + + + + + +Mockapetris [Page 50] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer + Networks",Communications of the ACM, October 1986, + volume 29, number 10. + +[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network + Information Center, SRI International, December 1977. + +[RFC-768] J. Postel, "User Datagram Protocol", RFC-768, + USC/Information Sciences Institute, August 1980. + +[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793, + USC/Information Sciences Institute, September 1981. + +[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT, + September 1981. + + Suggests introduction of a hierarchy in place of a flat + name space for the Internet. + +[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805, + USC/Information Sciences Institute, February 1982. + +[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD + Internet Host Table Specification", RFC-810, Network + Information Center, SRI International, March 1982. + + Obsolete. See RFC-952. + +[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames + Server", RFC-811, Network Information Center, SRI + International, March 1982. + + Obsolete. See RFC-953. + +[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812, + Network Information Center, SRI International, March + 1982. + +[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for + Internet User Applications", RFC-819, Network + Information Center, SRI International, August 1982. + + Early thoughts on the design of the domain system. + Current implementation is completely different. + +[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821, + USC/Information Sciences Institute, August 1980. + + + + +Mockapetris [Page 51] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +[RFC-830] Z. Su, "A Distributed System for Internet Name Service", + RFC-830, Network Information Center, SRI International, + October 1982. + + Early thoughts on the design of the domain system. + Current implementation is completely different. + +[RFC-882] P. Mockapetris, "Domain names - Concepts and + Facilities," RFC-882, USC/Information Sciences + Institute, November 1983. + + Superceeded by this memo. + +[RFC-883] P. Mockapetris, "Domain names - Implementation and + Specification," RFC-883, USC/Information Sciences + Institute, November 1983. + + Superceeded by this memo. + +[RFC-920] J. Postel and J. Reynolds, "Domain Requirements", + RFC-920, USC/Information Sciences Institute + October 1984. + + Explains the naming scheme for top level domains. + +[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host + Table Specification", RFC-952, SRI, October 1985. + + Specifies the format of HOSTS.TXT, the host/address + table replaced by the DNS. + +[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server", + RFC-953, SRI, October 1985. + + This RFC contains the official specification of the + hostname server protocol, which is obsoleted by the DNS. + This TCP based protocol accesses information stored in + the RFC-952 format, and is used to obtain copies of the + host table. + +[RFC-973] P. Mockapetris, "Domain System Changes and + Observations", RFC-973, USC/Information Sciences + Institute, January 1986. + + Describes changes to RFC-882 and RFC-883 and reasons for + them. Now obsolete. + + + + + +Mockapetris [Page 52] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +[RFC-974] C. Partridge, "Mail routing and the domain system", + RFC-974, CSNET CIC BBN Labs, January 1986. + + Describes the transition from HOSTS.TXT based mail + addressing to the more powerful MX system used with the + domain system. + +[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS + service on a TCP/UDP transport: Concepts and Methods", + RFC-1001, March 1987. + + This RFC and RFC-1002 are a preliminary design for + NETBIOS on top of TCP/IP which proposes to base NetBIOS + name service on top of the DNS. + +[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS + service on a TCP/UDP transport: Detailed + Specifications", RFC-1002, March 1987. + +[RFC-1010] J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010, + USC/Information Sciences Institute, May 1987 + + Contains socket numbers and mnemonics for host names, + operating systems, etc. + +[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031, + November 1987. + + Describes a plan for converting the MILNET to the DNS. + +[RFC-1032] M. K. Stahl, "Establishing a Domain - Guidelines for + Administrators", RFC-1032, November 1987. + + Describes the registration policies used by the NIC to + administer the top level domains and delegate subzones. + +[RFC-1033] M. K. Lottor, "Domain Administrators Operations Guide", + RFC-1033, November 1987. + + A cookbook for domain administrators. + +[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET + Name Server", Computer Networks, vol 6, nr 3, July 1982. + + Describes a name service for CSNET which is independent + from the DNS and DNS use in the CSNET. + + + + + +Mockapetris [Page 53] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +Index + + A 12 + Absolute names 8 + Aliases 14, 31 + Authority 6 + AXFR 17 + + Case of characters 7 + CH 12 + CNAME 12, 13, 31 + Completion queries 18 + + Domain name 6, 7 + + Glue RRs 20 + + HINFO 12 + + IN 12 + Inverse queries 16 + Iterative 4 + + Label 7 + + Mailbox names 9 + MX 12 + + Name error 27, 36 + Name servers 5, 17 + NE 30 + Negative caching 44 + NS 12 + + Opcode 16 + + PTR 12 + + QCLASS 16 + QTYPE 16 + + RDATA 13 + Recursive 4 + Recursive service 22 + Relative names 7 + Resolvers 6 + RR 12 + + + + +Mockapetris [Page 54] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + Safety belt 33 + Sections 16 + SOA 12 + Standard queries 22 + + Status queries 18 + Stub resolvers 32 + + TTL 12, 13 + + Wildcards 25 + + Zone transfers 28 + Zones 19 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 55] + diff --git a/Documentation/en/rfc/rfc1035.txt b/Documentation/en/rfc/rfc1035.txt new file mode 100644 index 00000000..b1a9bf5a --- /dev/null +++ b/Documentation/en/rfc/rfc1035.txt @@ -0,0 +1,3077 @@ +Network Working Group P. Mockapetris +Request for Comments: 1035 ISI + November 1987 +Obsoletes: RFCs 882, 883, 973 + + DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION + + +1. STATUS OF THIS MEMO + +This RFC describes the details of the domain system and protocol, and +assumes that the reader is familiar with the concepts discussed in a +companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034]. + +The domain system is a mixture of functions and data types which are an +official protocol and functions and data types which are still +experimental. Since the domain system is intentionally extensible, new +data types and experimental behavior should always be expected in parts +of the system beyond the official protocol. The official protocol parts +include standard queries, responses and the Internet class RR data +formats (e.g., host addresses). Since the previous RFC set, several +definitions have changed, so some previous definitions are obsolete. + +Experimental or obsolete features are clearly marked in these RFCs, and +such information should be used with caution. + +The reader is especially cautioned not to depend on the values which +appear in examples to be current or complete, since their purpose is +primarily pedagogical. Distribution of this memo is unlimited. + + Table of Contents + + 1. STATUS OF THIS MEMO 1 + 2. INTRODUCTION 3 + 2.1. Overview 3 + 2.2. Common configurations 4 + 2.3. Conventions 7 + 2.3.1. Preferred name syntax 7 + 2.3.2. Data Transmission Order 8 + 2.3.3. Character Case 9 + 2.3.4. Size limits 10 + 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10 + 3.1. Name space definitions 10 + 3.2. RR definitions 11 + 3.2.1. Format 11 + 3.2.2. TYPE values 12 + 3.2.3. QTYPE values 12 + 3.2.4. CLASS values 13 + + + +Mockapetris [Page 1] + +RFC 1035 Domain Implementation and Specification November 1987 + + + 3.2.5. QCLASS values 13 + 3.3. Standard RRs 13 + 3.3.1. CNAME RDATA format 14 + 3.3.2. HINFO RDATA format 14 + 3.3.3. MB RDATA format (EXPERIMENTAL) 14 + 3.3.4. MD RDATA format (Obsolete) 15 + 3.3.5. MF RDATA format (Obsolete) 15 + 3.3.6. MG RDATA format (EXPERIMENTAL) 16 + 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16 + 3.3.8. MR RDATA format (EXPERIMENTAL) 17 + 3.3.9. MX RDATA format 17 + 3.3.10. NULL RDATA format (EXPERIMENTAL) 17 + 3.3.11. NS RDATA format 18 + 3.3.12. PTR RDATA format 18 + 3.3.13. SOA RDATA format 19 + 3.3.14. TXT RDATA format 20 + 3.4. ARPA Internet specific RRs 20 + 3.4.1. A RDATA format 20 + 3.4.2. WKS RDATA format 21 + 3.5. IN-ADDR.ARPA domain 22 + 3.6. Defining new types, classes, and special namespaces 24 + 4. MESSAGES 25 + 4.1. Format 25 + 4.1.1. Header section format 26 + 4.1.2. Question section format 28 + 4.1.3. Resource record format 29 + 4.1.4. Message compression 30 + 4.2. Transport 32 + 4.2.1. UDP usage 32 + 4.2.2. TCP usage 32 + 5. MASTER FILES 33 + 5.1. Format 33 + 5.2. Use of master files to define zones 35 + 5.3. Master file example 36 + 6. NAME SERVER IMPLEMENTATION 37 + 6.1. Architecture 37 + 6.1.1. Control 37 + 6.1.2. Database 37 + 6.1.3. Time 39 + 6.2. Standard query processing 39 + 6.3. Zone refresh and reload processing 39 + 6.4. Inverse queries (Optional) 40 + 6.4.1. The contents of inverse queries and responses 40 + 6.4.2. Inverse query and response example 41 + 6.4.3. Inverse query processing 42 + + + + + + +Mockapetris [Page 2] + +RFC 1035 Domain Implementation and Specification November 1987 + + + 6.5. Completion queries and responses 42 + 7. RESOLVER IMPLEMENTATION 43 + 7.1. Transforming a user request into a query 43 + 7.2. Sending the queries 44 + 7.3. Processing responses 46 + 7.4. Using the cache 47 + 8. MAIL SUPPORT 47 + 8.1. Mail exchange binding 48 + 8.2. Mailbox binding (Experimental) 48 + 9. REFERENCES and BIBLIOGRAPHY 50 + Index 54 + +2. INTRODUCTION + +2.1. Overview + +The goal of domain names is to provide a mechanism for naming resources +in such a way that the names are usable in different hosts, networks, +protocol families, internets, and administrative organizations. + +From the user's point of view, domain names are useful as arguments to a +local agent, called a resolver, which retrieves information associated +with the domain name. Thus a user might ask for the host address or +mail information associated with a particular domain name. To enable +the user to request a particular type of information, an appropriate +query type is passed to the resolver with the domain name. To the user, +the domain tree is a single information space; the resolver is +responsible for hiding the distribution of data among name servers from +the user. + +From the resolver's point of view, the database that makes up the domain +space is distributed among various name servers. Different parts of the +domain space are stored in different name servers, although a particular +data item will be stored redundantly in two or more name servers. The +resolver starts with knowledge of at least one name server. When the +resolver processes a user query it asks a known name server for the +information; in return, the resolver either receives the desired +information or a referral to another name server. Using these +referrals, resolvers learn the identities and contents of other name +servers. Resolvers are responsible for dealing with the distribution of +the domain space and dealing with the effects of name server failure by +consulting redundant databases in other servers. + +Name servers manage two kinds of data. The first kind of data held in +sets called zones; each zone is the complete database for a particular +"pruned" subtree of the domain space. This data is called +authoritative. A name server periodically checks to make sure that its +zones are up to date, and if not, obtains a new copy of updated zones + + + +Mockapetris [Page 3] + +RFC 1035 Domain Implementation and Specification November 1987 + + +from master files stored locally or in another name server. The second +kind of data is cached data which was acquired by a local resolver. +This data may be incomplete, but improves the performance of the +retrieval process when non-local data is repeatedly accessed. Cached +data is eventually discarded by a timeout mechanism. + +This functional structure isolates the problems of user interface, +failure recovery, and distribution in the resolvers and isolates the +database update and refresh problems in the name servers. + +2.2. Common configurations + +A host can participate in the domain name system in a number of ways, +depending on whether the host runs programs that retrieve information +from the domain system, name servers that answer queries from other +hosts, or various combinations of both functions. The simplest, and +perhaps most typical, configuration is shown below: + + Local Host | Foreign + | + +---------+ +----------+ | +--------+ + | | user queries | |queries | | | + | User |-------------->| |---------|->|Foreign | + | Program | | Resolver | | | Name | + | |<--------------| |<--------|--| Server | + | | user responses| |responses| | | + +---------+ +----------+ | +--------+ + | A | + cache additions | | references | + V | | + +----------+ | + | cache | | + +----------+ | + +User programs interact with the domain name space through resolvers; the +format of user queries and user responses is specific to the host and +its operating system. User queries will typically be operating system +calls, and the resolver and its cache will be part of the host operating +system. Less capable hosts may choose to implement the resolver as a +subroutine to be linked in with every program that needs its services. +Resolvers answer user queries with information they acquire via queries +to foreign name servers and the local cache. + +Note that the resolver may have to make several queries to several +different foreign name servers to answer a particular user query, and +hence the resolution of a user query may involve several network +accesses and an arbitrary amount of time. The queries to foreign name +servers and the corresponding responses have a standard format described + + + +Mockapetris [Page 4] + +RFC 1035 Domain Implementation and Specification November 1987 + + +in this memo, and may be datagrams. + +Depending on its capabilities, a name server could be a stand alone +program on a dedicated machine or a process or processes on a large +timeshared host. A simple configuration might be: + + Local Host | Foreign + | + +---------+ | + / /| | + +---------+ | +----------+ | +--------+ + | | | | |responses| | | + | | | | Name |---------|->|Foreign | + | Master |-------------->| Server | | |Resolver| + | files | | | |<--------|--| | + | |/ | | queries | +--------+ + +---------+ +----------+ | + +Here a primary name server acquires information about one or more zones +by reading master files from its local file system, and answers queries +about those zones that arrive from foreign resolvers. + +The DNS requires that all zones be redundantly supported by more than +one name server. Designated secondary servers can acquire zones and +check for updates from the primary server using the zone transfer +protocol of the DNS. This configuration is shown below: + + Local Host | Foreign + | + +---------+ | + / /| | + +---------+ | +----------+ | +--------+ + | | | | |responses| | | + | | | | Name |---------|->|Foreign | + | Master |-------------->| Server | | |Resolver| + | files | | | |<--------|--| | + | |/ | | queries | +--------+ + +---------+ +----------+ | + A |maintenance | +--------+ + | +------------|->| | + | queries | |Foreign | + | | | Name | + +------------------|--| Server | + maintenance responses | +--------+ + +In this configuration, the name server periodically establishes a +virtual circuit to a foreign name server to acquire a copy of a zone or +to check that an existing copy has not changed. The messages sent for + + + +Mockapetris [Page 5] + +RFC 1035 Domain Implementation and Specification November 1987 + + +these maintenance activities follow the same form as queries and +responses, but the message sequences are somewhat different. + +The information flow in a host that supports all aspects of the domain +name system is shown below: + + Local Host | Foreign + | + +---------+ +----------+ | +--------+ + | | user queries | |queries | | | + | User |-------------->| |---------|->|Foreign | + | Program | | Resolver | | | Name | + | |<--------------| |<--------|--| Server | + | | user responses| |responses| | | + +---------+ +----------+ | +--------+ + | A | + cache additions | | references | + V | | + +----------+ | + | Shared | | + | database | | + +----------+ | + A | | + +---------+ refreshes | | references | + / /| | V | + +---------+ | +----------+ | +--------+ + | | | | |responses| | | + | | | | Name |---------|->|Foreign | + | Master |-------------->| Server | | |Resolver| + | files | | | |<--------|--| | + | |/ | | queries | +--------+ + +---------+ +----------+ | + A |maintenance | +--------+ + | +------------|->| | + | queries | |Foreign | + | | | Name | + +------------------|--| Server | + maintenance responses | +--------+ + +The shared database holds domain space data for the local name server +and resolver. The contents of the shared database will typically be a +mixture of authoritative data maintained by the periodic refresh +operations of the name server and cached data from previous resolver +requests. The structure of the domain data and the necessity for +synchronization between name servers and resolvers imply the general +characteristics of this database, but the actual format is up to the +local implementor. + + + + +Mockapetris [Page 6] + +RFC 1035 Domain Implementation and Specification November 1987 + + +Information flow can also be tailored so that a group of hosts act +together to optimize activities. Sometimes this is done to offload less +capable hosts so that they do not have to implement a full resolver. +This can be appropriate for PCs or hosts which want to minimize the +amount of new network code which is required. This scheme can also +allow a group of hosts can share a small number of caches rather than +maintaining a large number of separate caches, on the premise that the +centralized caches will have a higher hit ratio. In either case, +resolvers are replaced with stub resolvers which act as front ends to +resolvers located in a recursive server in one or more name servers +known to perform that service: + + Local Hosts | Foreign + | + +---------+ | + | | responses | + | Stub |<--------------------+ | + | Resolver| | | + | |----------------+ | | + +---------+ recursive | | | + queries | | | + V | | + +---------+ recursive +----------+ | +--------+ + | | queries | |queries | | | + | Stub |-------------->| Recursive|---------|->|Foreign | + | Resolver| | Server | | | Name | + | |<--------------| |<--------|--| Server | + +---------+ responses | |responses| | | + +----------+ | +--------+ + | Central | | + | cache | | + +----------+ | + +In any case, note that domain components are always replicated for +reliability whenever possible. + +2.3. Conventions + +The domain system has several conventions dealing with low-level, but +fundamental, issues. While the implementor is free to violate these +conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in +ALL behavior observed from other hosts. + +2.3.1. Preferred name syntax + +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. + + + +Mockapetris [Page 7] + +RFC 1035 Domain Implementation and Specification November 1987 + + +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 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 + +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. + +For example, the following strings identify hosts in the Internet: + +A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA + +2.3.2. Data Transmission Order + +The order of transmission of the header and data described in this +document is resolved to the octet level. Whenever a diagram shows a + + + +Mockapetris [Page 8] + +RFC 1035 Domain Implementation and Specification November 1987 + + +group of octets, the order of transmission of those octets is the normal +order in which they are read in English. For example, in the following +diagram, the octets are transmitted in the order they are numbered. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 3 | 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 5 | 6 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Whenever an octet represents a numeric quantity, the left most bit in +the diagram is the high order or most significant bit. That is, the bit +labeled 0 is the most significant bit. For example, the following +diagram represents the value 170 (decimal). + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |1 0 1 0 1 0 1 0| + +-+-+-+-+-+-+-+-+ + +Similarly, whenever a multi-octet field represents a numeric quantity +the left most bit of the whole field is the most significant bit. When +a multi-octet quantity is transmitted the most significant octet is +transmitted first. + +2.3.3. Character Case + +For all parts of the DNS that are part of the official protocol, all +comparisons between character strings (e.g., labels, domain names, etc.) +are done in a case-insensitive manner. At present, this rule is in +force throughout the domain system without exception. However, future +additions beyond current usage may need to use the full binary octet +capabilities in names, so attempts to store domain names in 7-bit ASCII +or use of special bytes to terminate labels, etc., should be avoided. + +When data enters the domain system, its original case should be +preserved whenever possible. In certain circumstances this cannot be +done. For example, if two RRs are stored in a database, one at x.y and +one at X.Y, they are actually stored at the same place in the database, +and hence only one casing would be preserved. The basic rule is that +case can be discarded only when data is used to define structure in a +database, and two names are identical when compared in a case +insensitive manner. + + + + +Mockapetris [Page 9] + +RFC 1035 Domain Implementation and Specification November 1987 + + +Loss of case sensitive data must be minimized. Thus while data for x.y +and X.Y may both be stored under a single location x.y or X.Y, data for +a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In +general, this preserves the case of the first label of a domain name, +but forces standardization of interior node labels. + +Systems administrators who enter data into the domain database should +take care to represent the data they supply to the domain system in a +case-consistent manner if their system is case-sensitive. The data +distribution system in the domain system will ensure that consistent +representations are preserved. + +2.3.4. Size limits + +Various objects and parameters in the DNS have size limits. They are +listed below. Some could be easily changed, others are more +fundamental. + +labels 63 octets or less + +names 255 octets or less + +TTL positive values of a signed 32 bit number. + +UDP messages 512 octets or less + +3. DOMAIN NAME SPACE AND RR DEFINITIONS + +3.1. Name space definitions + +Domain names in messages are expressed in terms of a sequence of labels. +Each label is represented as a one octet length field followed by that +number of octets. Since every domain name ends with the null label of +the root, a domain name is terminated by a length byte of zero. The +high order two bits of every length octet must be zero, and the +remaining six bits of the length field limit the label to 63 octets or +less. + +To simplify implementations, the total length of a domain name (i.e., +label octets and label length octets) is restricted to 255 octets or +less. + +Although labels can contain any 8 bit values in octets that make up a +label, it is strongly recommended that labels follow the preferred +syntax described elsewhere in this memo, which is compatible with +existing host naming conventions. Name servers and resolvers must +compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII +with zero parity. Non-alphabetic codes must match exactly. + + + +Mockapetris [Page 10] + +RFC 1035 Domain Implementation and Specification November 1987 + + +3.2. RR definitions + +3.2.1. Format + +All RRs have the same top level format shown below: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + +where: + +NAME an owner name, i.e., the name of the node to which this + resource record pertains. + +TYPE two octets containing one of the RR TYPE codes. + +CLASS two octets containing one of the RR CLASS codes. + +TTL a 32 bit signed integer that specifies the time interval + that the resource record may be cached before the source + of the information should again be consulted. Zero + values are interpreted to mean that the RR can only be + used for the transaction in progress, and should not be + cached. For example, SOA records are always distributed + with a zero TTL to prohibit caching. Zero values can + also be used for extremely volatile data. + +RDLENGTH an unsigned 16 bit integer that specifies the length in + octets of the RDATA field. + + + +Mockapetris [Page 11] + +RFC 1035 Domain Implementation and Specification November 1987 + + +RDATA a variable length string of octets that describes the + resource. The format of this information varies + according to the TYPE and CLASS of the resource record. + +3.2.2. TYPE values + +TYPE fields are used in resource records. Note that these types are a +subset of QTYPEs. + +TYPE value and meaning + +A 1 a host address + +NS 2 an authoritative name server + +MD 3 a mail destination (Obsolete - use MX) + +MF 4 a mail forwarder (Obsolete - use MX) + +CNAME 5 the canonical name for an alias + +SOA 6 marks the start of a zone of authority + +MB 7 a mailbox domain name (EXPERIMENTAL) + +MG 8 a mail group member (EXPERIMENTAL) + +MR 9 a mail rename domain name (EXPERIMENTAL) + +NULL 10 a null RR (EXPERIMENTAL) + +WKS 11 a well known service description + +PTR 12 a domain name pointer + +HINFO 13 host information + +MINFO 14 mailbox or mail list information + +MX 15 mail exchange + +TXT 16 text strings + +3.2.3. QTYPE values + +QTYPE fields appear in the question part of a query. QTYPES are a +superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the +following QTYPEs are defined: + + + +Mockapetris [Page 12] + +RFC 1035 Domain Implementation and Specification November 1987 + + +AXFR 252 A request for a transfer of an entire zone + +MAILB 253 A request for mailbox-related records (MB, MG or MR) + +MAILA 254 A request for mail agent RRs (Obsolete - see MX) + +* 255 A request for all records + +3.2.4. CLASS values + +CLASS fields appear in resource records. The following CLASS mnemonics +and values are defined: + +IN 1 the Internet + +CS 2 the CSNET class (Obsolete - used only for examples in + some obsolete RFCs) + +CH 3 the CHAOS class + +HS 4 Hesiod [Dyer 87] + +3.2.5. QCLASS values + +QCLASS fields appear in the question section of a query. QCLASS values +are a superset of CLASS values; every CLASS is a valid QCLASS. In +addition to CLASS values, the following QCLASSes are defined: + +* 255 any class + +3.3. Standard RRs + +The following RR definitions are expected to occur, at least +potentially, in all classes. In particular, NS, SOA, CNAME, and PTR +will be used in all classes, and have the same format in all classes. +Because their RDATA format is known, all domain names in the RDATA +section of these RRs may be compressed. + +<domain-name> is a domain name represented as a series of labels, and +terminated by a label with zero length. <character-string> is a single +length octet followed by that number of characters. <character-string> +is treated as binary information, and can be up to 256 characters in +length (including the length octet). + + + + + + + + +Mockapetris [Page 13] + +RFC 1035 Domain Implementation and Specification November 1987 + + +3.3.1. CNAME RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / CNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +CNAME A <domain-name> which specifies the canonical or primary + name for the owner. The owner name is an alias. + +CNAME RRs cause no additional section processing, but name servers may +choose to restart the query at the canonical name in certain cases. See +the description of name server logic in [RFC-1034] for details. + +3.3.2. HINFO RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / CPU / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / OS / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +CPU A <character-string> which specifies the CPU type. + +OS A <character-string> which specifies the operating + system type. + +Standard values for CPU and OS can be found in [RFC-1010]. + +HINFO records are used to acquire general information about a host. The +main use is for protocols such as FTP that can use special procedures +when talking between machines or operating systems of the same type. + +3.3.3. MB RDATA format (EXPERIMENTAL) + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MADNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +MADNAME A <domain-name> which specifies a host which has the + specified mailbox. + + + +Mockapetris [Page 14] + +RFC 1035 Domain Implementation and Specification November 1987 + + +MB records cause additional section processing which looks up an A type +RRs corresponding to MADNAME. + +3.3.4. MD RDATA format (Obsolete) + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MADNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +MADNAME A <domain-name> which specifies a host which has a mail + agent for the domain which should be able to deliver + mail for the domain. + +MD records cause additional section processing which looks up an A type +record corresponding to MADNAME. + +MD is obsolete. See the definition of MX and [RFC-974] for details of +the new scheme. The recommended policy for dealing with MD RRs found in +a master file is to reject them, or to convert them to MX RRs with a +preference of 0. + +3.3.5. MF RDATA format (Obsolete) + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MADNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +MADNAME A <domain-name> which specifies a host which has a mail + agent for the domain which will accept mail for + forwarding to the domain. + +MF records cause additional section processing which looks up an A type +record corresponding to MADNAME. + +MF is obsolete. See the definition of MX and [RFC-974] for details ofw +the new scheme. The recommended policy for dealing with MD RRs found in +a master file is to reject them, or to convert them to MX RRs with a +preference of 10. + + + + + + + +Mockapetris [Page 15] + +RFC 1035 Domain Implementation and Specification November 1987 + + +3.3.6. MG RDATA format (EXPERIMENTAL) + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MGMNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +MGMNAME A <domain-name> which specifies a mailbox which is a + member of the mail group specified by the domain name. + +MG records cause no additional section processing. + +3.3.7. MINFO RDATA format (EXPERIMENTAL) + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / RMAILBX / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / EMAILBX / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +RMAILBX A <domain-name> which specifies a mailbox which is + responsible for the mailing list or mailbox. If this + domain name names the root, the owner of the MINFO RR is + responsible for itself. Note that many existing mailing + lists use a mailbox X-request for the RMAILBX field of + mailing list X, e.g., Msgroup-request for Msgroup. This + field provides a more general mechanism. + + +EMAILBX A <domain-name> which specifies a mailbox which is to + receive error messages related to the mailing list or + mailbox specified by the owner of the MINFO RR (similar + to the ERRORS-TO: field which has been proposed). If + this domain name names the root, errors should be + returned to the sender of the message. + +MINFO records cause no additional section processing. Although these +records can be associated with a simple mailbox, they are usually used +with a mailing list. + + + + + + + + +Mockapetris [Page 16] + +RFC 1035 Domain Implementation and Specification November 1987 + + +3.3.8. MR RDATA format (EXPERIMENTAL) + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / NEWNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +NEWNAME A <domain-name> which specifies a mailbox which is the + proper rename of the specified mailbox. + +MR records cause no additional section processing. The main use for MR +is as a forwarding entry for a user who has moved to a different +mailbox. + +3.3.9. MX RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | PREFERENCE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / EXCHANGE / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +PREFERENCE A 16 bit integer which specifies the preference given to + this RR among others at the same owner. Lower values + are preferred. + +EXCHANGE A <domain-name> which specifies a host willing to act as + a mail exchange for the owner name. + +MX records cause type A additional section processing for the host +specified by EXCHANGE. The use of MX RRs is explained in detail in +[RFC-974]. + +3.3.10. NULL RDATA format (EXPERIMENTAL) + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / <anything> / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +Anything at all may be in the RDATA field so long as it is 65535 octets +or less. + + + + +Mockapetris [Page 17] + +RFC 1035 Domain Implementation and Specification November 1987 + + +NULL records cause no additional section processing. NULL RRs are not +allowed in master files. NULLs are used as placeholders in some +experimental extensions of the DNS. + +3.3.11. NS RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / NSDNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +NSDNAME A <domain-name> which specifies a host which should be + authoritative for the specified class and domain. + +NS records cause both the usual additional section processing to locate +a type A record, and, when used in a referral, a special search of the +zone in which they reside for glue information. + +The NS RR states that the named host should be expected to have a zone +starting at owner name of the specified class. Note that the class may +not indicate the protocol family which should be used to communicate +with the host, although it is typically a strong hint. For example, +hosts which are name servers for either Internet (IN) or Hesiod (HS) +class information are normally queried using IN class protocols. + +3.3.12. PTR RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / PTRDNAME / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +PTRDNAME A <domain-name> which points to some location in the + domain name space. + +PTR records cause no additional section processing. These RRs are used +in special domains to point to some other location in the domain space. +These records are simple data, and don't imply any special processing +similar to that performed by CNAME, which identifies aliases. See the +description of the IN-ADDR.ARPA domain for an example. + + + + + + + + +Mockapetris [Page 18] + +RFC 1035 Domain Implementation and Specification November 1987 + + +3.3.13. SOA RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / RNAME / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | SERIAL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | REFRESH | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RETRY | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | EXPIRE | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | MINIMUM | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +MNAME The <domain-name> of the name server that was the + original or primary source of data for this zone. + +RNAME A <domain-name> which specifies the mailbox of the + person responsible for this zone. + +SERIAL The unsigned 32 bit version number of the original copy + of the zone. Zone transfers preserve this value. This + value wraps and should be compared using sequence space + arithmetic. + +REFRESH A 32 bit time interval before the zone should be + refreshed. + +RETRY A 32 bit time interval that should elapse before a + failed refresh should be retried. + +EXPIRE A 32 bit time value that specifies the upper limit on + the time interval that can elapse before the zone is no + longer authoritative. + + + + + +Mockapetris [Page 19] + +RFC 1035 Domain Implementation and Specification November 1987 + + +MINIMUM The unsigned 32 bit minimum TTL field that should be + exported with any RR from this zone. + +SOA records cause no additional section processing. + +All times are in units of seconds. + +Most of these fields are pertinent only for name server maintenance +operations. However, MINIMUM is used in all query operations that +retrieve RRs from a zone. Whenever a RR is sent in a response to a +query, the TTL field is set to the maximum of the TTL field from the RR +and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower +bound on the TTL field for all RRs in a zone. Note that this use of +MINIMUM should occur when the RRs are copied into the response and not +when the zone is loaded from a master file or via a zone transfer. The +reason for this provison is to allow future dynamic update facilities to +change the SOA RR with known semantics. + + +3.3.14. TXT RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / TXT-DATA / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +TXT-DATA One or more <character-string>s. + +TXT RRs are used to hold descriptive text. The semantics of the text +depends on the domain where it is found. + +3.4. Internet specific RRs + +3.4.1. A RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ADDRESS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +ADDRESS A 32 bit Internet address. + +Hosts that have multiple Internet addresses will have multiple A +records. + + + + + +Mockapetris [Page 20] + +RFC 1035 Domain Implementation and Specification November 1987 + + +A records cause no additional section processing. The RDATA section of +an A line in a master file is an Internet address expressed as four +decimal numbers separated by dots without any imbedded spaces (e.g., +"10.2.0.52" or "192.0.5.6"). + +3.4.2. WKS RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ADDRESS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | PROTOCOL | | + +--+--+--+--+--+--+--+--+ | + | | + / <BIT MAP> / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +ADDRESS An 32 bit Internet address + +PROTOCOL An 8 bit IP protocol number + +<BIT MAP> A variable length bit map. The bit map must be a + multiple of 8 bits long. + +The WKS record is used to describe the well known services supported by +a particular protocol on a particular internet address. The PROTOCOL +field specifies an IP protocol number, and the bit map has one bit per +port of the specified protocol. The first bit corresponds to port 0, +the second to port 1, etc. If the bit map does not include a bit for a +protocol of interest, that bit is assumed zero. The appropriate values +and mnemonics for ports and protocols are specified in [RFC-1010]. + +For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port +25 (SMTP). If this bit is set, a SMTP server should be listening on TCP +port 25; if zero, SMTP service is not supported on the specified +address. + +The purpose of WKS RRs is to provide availability information for +servers for TCP and UDP. If a server supports both TCP and UDP, or has +multiple Internet addresses, then multiple WKS RRs are used. + +WKS RRs cause no additional section processing. + +In master files, both ports and protocols are expressed using mnemonics +or decimal numbers. + + + + +Mockapetris [Page 21] + +RFC 1035 Domain Implementation and Specification November 1987 + + +3.5. IN-ADDR.ARPA domain + +The Internet uses a special domain to support gateway location and +Internet address to host mapping. Other classes may employ a similar +strategy in other domains. The intent of this domain is to provide a +guaranteed method to perform host address to host name mapping, and to +facilitate queries to locate all gateways on a particular network in the +Internet. + +Note that both of these services are similar to functions that could be +performed by inverse queries; the difference is that this part of the +domain name space is structured according to address, and hence can +guarantee that the appropriate data can be located without an exhaustive +search of the domain space. + +The domain begins at IN-ADDR.ARPA and has a substructure which follows +the Internet addressing structure. + +Domain names in the IN-ADDR.ARPA domain are defined to have up to four +labels in addition to the IN-ADDR.ARPA suffix. Each label represents +one octet of an Internet address, and is expressed as a character string +for a decimal value in the range 0-255 (with leading zeros omitted +except in the case of a zero octet which is represented by a single +zero). + +Host addresses are represented by domain names that have all four labels +specified. Thus data for Internet address 10.2.0.52 is located at +domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to +read, allows zones to be delegated which are exactly one network of +address space. For example, 10.IN-ADDR.ARPA can be a zone containing +data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for +MILNET. Address nodes are used to hold pointers to primary host names +in the normal domain space. + +Network numbers correspond to some non-terminal nodes at various depths +in the IN-ADDR.ARPA domain, since Internet network numbers are either 1, +2, or 3 octets. Network nodes are used to hold pointers to the primary +host names of gateways attached to that network. Since a gateway is, by +definition, on more than one network, it will typically have two or more +network nodes which point at it. Gateways will also have host level +pointers at their fully qualified addresses. + +Both the gateway pointers at network nodes and the normal host pointers +at full address nodes use the PTR RR to point back to the primary domain +names of the corresponding hosts. + +For example, the IN-ADDR.ARPA domain will contain information about the +ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's + + + +Mockapetris [Page 22] + +RFC 1035 Domain Implementation and Specification November 1987 + + +net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI +gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET- +GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4 +and a name GW.LCS.MIT.EDU, the domain database would contain: + + 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. + 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. + 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. + 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. + 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. + 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. + 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. + 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. + 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU. + 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU. + +Thus a program which wanted to locate gateways on net 10 would originate +a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It +would receive two RRs in response: + + 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. + 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. + +The program could then originate QTYPE=A, QCLASS=IN queries for MILNET- +GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of +these gateways. + +A resolver which wanted to find the host name corresponding to Internet +host address 10.0.0.6 would pursue a query of the form QTYPE=PTR, +QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive: + + 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU. + +Several cautions apply to the use of these services: + - Since the IN-ADDR.ARPA special domain and the normal domain + for a particular host or gateway will be in different zones, + the possibility exists that that the data may be inconsistent. + + - Gateways will often have two names in separate domains, only + one of which can be primary. + + - Systems that use the domain database to initialize their + routing tables must start with enough gateway information to + guarantee that they can access the appropriate name server. + + - The gateway data only reflects the existence of a gateway in a + manner equivalent to the current HOSTS.TXT file. It doesn't + replace the dynamic availability information from GGP or EGP. + + + +Mockapetris [Page 23] + +RFC 1035 Domain Implementation and Specification November 1987 + + +3.6. Defining new types, classes, and special namespaces + +The previously defined types and classes are the ones in use as of the +date of this memo. New definitions should be expected. This section +makes some recommendations to designers considering additions to the +existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the +forum where general discussion of design issues takes place. + +In general, a new type is appropriate when new information is to be +added to the database about an existing object, or we need new data +formats for some totally new object. Designers should attempt to define +types and their RDATA formats that are generally applicable to all +classes, and which avoid duplication of information. New classes are +appropriate when the DNS is to be used for a new protocol, etc which +requires new class-specific data formats, or when a copy of the existing +name space is desired, but a separate management domain is necessary. + +New types and classes need mnemonics for master files; the format of the +master files requires that the mnemonics for type and class be disjoint. + +TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes +respectively. + +The present system uses multiple RRs to represent multiple values of a +type rather than storing multiple values in the RDATA section of a +single RR. This is less efficient for most applications, but does keep +RRs shorter. The multiple RRs assumption is incorporated in some +experimental work on dynamic update methods. + +The present system attempts to minimize the duplication of data in the +database in order to insure consistency. Thus, in order to find the +address of the host for a mail exchange, you map the mail domain name to +a host name, then the host name to addresses, rather than a direct +mapping to host address. This approach is preferred because it avoids +the opportunity for inconsistency. + +In defining a new type of data, multiple RR types should not be used to +create an ordering between entries or express different formats for +equivalent bindings, instead this information should be carried in the +body of the RR and a single type used. This policy avoids problems with +caching multiple types and defining QTYPEs to match multiple types. + +For example, the original form of mail exchange binding used two RR +types one to represent a "closer" exchange (MD) and one to represent a +"less close" exchange (MF). The difficulty is that the presence of one +RR type in a cache doesn't convey any information about the other +because the query which acquired the cached information might have used +a QTYPE of MF, MD, or MAILA (which matched both). The redesigned + + + +Mockapetris [Page 24] + +RFC 1035 Domain Implementation and Specification November 1987 + + +service used a single type (MX) with a "preference" value in the RDATA +section which can order different RRs. However, if any MX RRs are found +in the cache, then all should be there. + +4. MESSAGES + +4.1. Format + +All communications inside of the domain protocol are carried in a single +format called a message. The top level format of message is divided +into 5 sections (some of which are empty in certain cases) shown below: + + +---------------------+ + | Header | + +---------------------+ + | Question | the question for the name server + +---------------------+ + | Answer | RRs answering the question + +---------------------+ + | Authority | RRs pointing toward an authority + +---------------------+ + | Additional | RRs holding additional information + +---------------------+ + +The header section is always present. The header includes fields that +specify which of the remaining sections are present, and also specify +whether the message is a query or a response, a standard query or some +other opcode, etc. + +The names of the sections after the header are derived from their use in +standard queries. The question section contains fields that describe a +question to a name server. These fields are a query type (QTYPE), a +query class (QCLASS), and a query domain name (QNAME). The last three +sections have the same format: a possibly empty list of concatenated +resource records (RRs). The answer section contains RRs that answer the +question; the authority section contains RRs that point toward an +authoritative name server; the additional records section contains RRs +which relate to the query, but are not strictly answers for the +question. + + + + + + + + + + + + +Mockapetris [Page 25] + +RFC 1035 Domain Implementation and Specification November 1987 + + +4.1.1. Header section format + +The header contains the following fields: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| Z | RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +ID A 16 bit identifier assigned by the program that + generates any kind of query. This identifier is copied + the corresponding reply and can be used by the requester + to match up replies to outstanding queries. + +QR A one bit field that specifies whether this message is a + query (0), or a response (1). + +OPCODE A four bit field that specifies kind of query in this + message. This value is set by the originator of a query + and copied into the response. The values are: + + 0 a standard query (QUERY) + + 1 an inverse query (IQUERY) + + 2 a server status request (STATUS) + + 3-15 reserved for future use + +AA Authoritative Answer - this bit is valid in responses, + and specifies that the responding name server is an + authority for the domain name in question section. + + Note that the contents of the answer section may have + multiple owner names because of aliases. The AA bit + + + +Mockapetris [Page 26] + +RFC 1035 Domain Implementation and Specification November 1987 + + + corresponds to the name which matches the query name, or + the first owner name in the answer section. + +TC TrunCation - specifies that this message was truncated + due to length greater than that permitted on the + transmission channel. + +RD Recursion Desired - this bit may be set in a query and + is copied into the response. If RD is set, it directs + the name server to pursue the query recursively. + Recursive query support is optional. + +RA Recursion Available - this be is set or cleared in a + response, and denotes whether recursive query support is + available in the name server. + +Z Reserved for future use. Must be zero in all queries + and responses. + +RCODE Response code - this 4 bit field is set as part of + responses. The values have the following + interpretation: + + 0 No error condition + + 1 Format error - The name server was + unable to interpret the query. + + 2 Server failure - The name server was + unable to process this query due to a + problem with the name server. + + 3 Name Error - Meaningful only for + responses from an authoritative name + server, this code signifies that the + domain name referenced in the query does + not exist. + + 4 Not Implemented - The name server does + not support the requested kind of query. + + 5 Refused - The name server refuses to + perform the specified operation for + policy reasons. For example, a name + server may not wish to provide the + information to the particular requester, + or a name server may not wish to perform + a particular operation (e.g., zone + + + +Mockapetris [Page 27] + +RFC 1035 Domain Implementation and Specification November 1987 + + + transfer) for particular data. + + 6-15 Reserved for future use. + +QDCOUNT an unsigned 16 bit integer specifying the number of + entries in the question section. + +ANCOUNT an unsigned 16 bit integer specifying the number of + resource records in the answer section. + +NSCOUNT an unsigned 16 bit integer specifying the number of name + server resource records in the authority records + section. + +ARCOUNT an unsigned 16 bit integer specifying the number of + resource records in the additional records section. + +4.1.2. Question section format + +The question section is used to carry the "question" in most queries, +i.e., the parameters that define what is being asked. The section +contains QDCOUNT (usually 1) entries, each of the following format: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / QNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QTYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QCLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +QNAME a domain name represented as a sequence of labels, where + each label consists of a length octet followed by that + number of octets. The domain name terminates with the + zero length octet for the null label of the root. Note + that this field may be an odd number of octets; no + padding is used. + +QTYPE a two octet code which specifies the type of the query. + The values for this field include all codes valid for a + TYPE field, together with some more general codes which + can match more than one type of RR. + + + +Mockapetris [Page 28] + +RFC 1035 Domain Implementation and Specification November 1987 + + +QCLASS a two octet code that specifies the class of the query. + For example, the QCLASS field is IN for the Internet. + +4.1.3. Resource record format + +The answer, authority, and additional sections all share the same +format: a variable number of resource records, where the number of +records is specified in the corresponding count field in the header. +Each resource record has the following format: + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +where: + +NAME a domain name to which this resource record pertains. + +TYPE two octets containing one of the RR type codes. This + field specifies the meaning of the data in the RDATA + field. + +CLASS two octets which specify the class of the data in the + RDATA field. + +TTL a 32 bit unsigned integer that specifies the time + interval (in seconds) that the resource record may be + cached before it should be discarded. Zero values are + interpreted to mean that the RR can only be used for the + transaction in progress, and should not be cached. + + + + + +Mockapetris [Page 29] + +RFC 1035 Domain Implementation and Specification November 1987 + + +RDLENGTH an unsigned 16 bit integer that specifies the length in + octets of the RDATA field. + +RDATA a variable length string of octets that describes the + resource. The format of this information varies + according to the TYPE and CLASS of the resource record. + For example, the if the TYPE is A and the CLASS is IN, + the RDATA field is a 4 octet ARPA Internet address. + +4.1.4. Message compression + +In order to reduce the size of messages, the domain system utilizes a +compression scheme which eliminates the repetition of domain names in a +message. In this scheme, an entire domain name or a list of labels at +the end of a domain name is replaced with a pointer to a prior occurance +of the same name. + +The pointer takes the form of a two octet sequence: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | 1 1| OFFSET | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +The first two bits are ones. This allows a pointer to be distinguished +from a label, since the label must begin with two zero bits because +labels are restricted to 63 octets or less. (The 10 and 01 combinations +are reserved for future use.) The OFFSET field specifies an offset from +the start of the message (i.e., the first octet of the ID field in the +domain header). A zero offset specifies the first byte of the ID field, +etc. + +The compression scheme allows a domain name in a message to be +represented as either: + + - a sequence of labels ending in a zero octet + + - a pointer + + - a sequence of labels ending with a pointer + +Pointers can only be used for occurances of a domain name where the +format is not class specific. If this were not the case, a name server +or resolver would be required to know the format of all RRs it handled. +As yet, there are no such cases, but they may occur in future RDATA +formats. + +If a domain name is contained in a part of the message subject to a +length field (such as the RDATA section of an RR), and compression is + + + +Mockapetris [Page 30] + +RFC 1035 Domain Implementation and Specification November 1987 + + +used, the length of the compressed name is used in the length +calculation, rather than the length of the expanded name. + +Programs are free to avoid using pointers in messages they generate, +although this will reduce datagram capacity, and may cause truncation. +However all programs are required to understand arriving messages that +contain pointers. + +For example, a datagram might need to use the domain names F.ISI.ARPA, +FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the +message, these domain names might be represented as: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 20 | 1 | F | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 22 | 3 | I | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 24 | S | I | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 26 | 4 | A | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 28 | R | P | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 30 | A | 0 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 40 | 3 | F | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 42 | O | O | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 44 | 1 1| 20 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 64 | 1 1| 26 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 92 | 0 | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +The domain name for F.ISI.ARPA is shown at offset 20. The domain name +FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to +concatenate a label for FOO to the previously defined F.ISI.ARPA. The +domain name ARPA is defined at offset 64 using a pointer to the ARPA +component of the name F.ISI.ARPA at 20; note that this pointer relies on +ARPA being the last label in the string at 20. The root domain name is + + + +Mockapetris [Page 31] + +RFC 1035 Domain Implementation and Specification November 1987 + + +defined by a single octet of zeros at 92; the root domain name has no +labels. + +4.2. Transport + +The DNS assumes that messages will be transmitted as datagrams or in a +byte stream carried by a virtual circuit. While virtual circuits can be +used for any DNS activity, datagrams are preferred for queries due to +their lower overhead and better performance. Zone refresh activities +must use virtual circuits because of the need for reliable transfer. + +The Internet supports name server access using TCP [RFC-793] on server +port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP +port 53 (decimal). + +4.2.1. UDP usage + +Messages sent using UDP user server port 53 (decimal). + +Messages carried by UDP are restricted to 512 bytes (not counting the IP +or UDP headers). Longer messages are truncated and the TC bit is set in +the header. + +UDP is not acceptable for zone transfers, but is the recommended method +for standard queries in the Internet. Queries sent using UDP may be +lost, and hence a retransmission strategy is required. Queries or their +responses may be reordered by the network, or by processing in name +servers, so resolvers should not depend on them being returned in order. + +The optimal UDP retransmission policy will vary with performance of the +Internet and the needs of the client, but the following are recommended: + + - The client should try other servers and server addresses + before repeating a query to a specific address of a server. + + - The retransmission interval should be based on prior + statistics if possible. Too aggressive retransmission can + easily slow responses for the community at large. Depending + on how well connected the client is to its expected servers, + the minimum retransmission interval should be 2-5 seconds. + +More suggestions on server selection and retransmission policy can be +found in the resolver section of this memo. + +4.2.2. TCP usage + +Messages sent over TCP connections use server port 53 (decimal). The +message is prefixed with a two byte length field which gives the message + + + +Mockapetris [Page 32] + +RFC 1035 Domain Implementation and Specification November 1987 + + +length, excluding the two byte length field. This length field allows +the low-level processing to assemble a complete message before beginning +to parse it. + +Several connection management policies are recommended: + + - The server should not block other activities waiting for TCP + data. + + - The server should support multiple connections. + + - The server should assume that the client will initiate + connection closing, and should delay closing its end of the + connection until all outstanding client requests have been + satisfied. + + - If the server needs to close a dormant connection to reclaim + resources, it should wait until the connection has been idle + for a period on the order of two minutes. In particular, the + server should allow the SOA and AXFR request sequence (which + begins a refresh operation) to be made on a single connection. + Since the server would be unable to answer queries anyway, a + unilateral close or reset may be used instead of a graceful + close. + +5. MASTER FILES + +Master files are text files that contain RRs in text form. Since the +contents of a zone can be expressed in the form of a list of RRs a +master file is most often used to define a zone, though it can be used +to list a cache's contents. Hence, this section first discusses the +format of RRs in a master file, and then the special considerations when +a master file is used to create a zone in some name server. + +5.1. Format + +The format of these files is a sequence of entries. Entries are +predominantly line-oriented, though parentheses can be used to continue +a list of items across a line boundary, and text literals can contain +CRLF within the text. Any combination of tabs and spaces act as a +delimiter between the separate items that make up an entry. The end of +any line in the master file can end with a comment. The comment starts +with a ";" (semicolon). + +The following entries are defined: + + <blank>[<comment>] + + + + +Mockapetris [Page 33] + +RFC 1035 Domain Implementation and Specification November 1987 + + + $ORIGIN <domain-name> [<comment>] + + $INCLUDE <file-name> [<domain-name>] [<comment>] + + <domain-name><rr> [<comment>] + + <blank><rr> [<comment>] + +Blank lines, with or without comments, are allowed anywhere in the file. + +Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is +followed by a domain name, and resets the current origin for relative +domain names to the stated name. $INCLUDE inserts the named file into +the current file, and may optionally specify a domain name that sets the +relative domain name origin for the included file. $INCLUDE may also +have a comment. Note that a $INCLUDE entry never changes the relative +origin of the parent file, regardless of changes to the relative origin +made within the included file. + +The last two forms represent RRs. If an entry for an RR begins with a +blank, then the RR is assumed to be owned by the last stated owner. If +an RR entry begins with a <domain-name>, then the owner name is reset. + +<rr> contents take one of the following forms: + + [<TTL>] [<class>] <type> <RDATA> + + [<class>] [<TTL>] <type> <RDATA> + +The RR begins with optional TTL and class fields, followed by a type and +RDATA field appropriate to the type and class. Class and type use the +standard mnemonics, TTL is a decimal integer. Omitted class and TTL +values are default to the last explicitly stated values. Since type and +class mnemonics are disjoint, the parse is unique. (Note that this +order is different from the order used in examples and the order used in +the actual RRs; the given order allows easier parsing and defaulting.) + +<domain-name>s make up a large share of the data in the master file. +The labels in the domain name are expressed as character strings and +separated by dots. Quoting conventions allow arbitrary characters to be +stored in domain names. Domain names that end in a dot are called +absolute, and are taken as complete. Domain names which do not end in a +dot are called relative; the actual domain name is the concatenation of +the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as +an argument to the master file loading routine. A relative name is an +error when no origin is available. + + + + + +Mockapetris [Page 34] + +RFC 1035 Domain Implementation and Specification November 1987 + + +<character-string> is expressed in one or two ways: as a contiguous set +of characters without interior spaces, or as a string beginning with a " +and ending with a ". Inside a " delimited string any character can +occur, except for a " itself, which must be quoted using \ (back slash). + +Because these files are text files several special encodings are +necessary to allow arbitrary data to be loaded. In particular: + + of the root. + +@ A free standing @ is used to denote the current origin. + +\X where X is any character other than a digit (0-9), is + used to quote that character so that its special meaning + does not apply. For example, "\." can be used to place + a dot character in a label. + +\DDD where each D is a digit is the octet corresponding to + the decimal number described by DDD. The resulting + octet is assumed to be text and is not checked for + special meaning. + +( ) Parentheses are used to group data that crosses a line + boundary. In effect, line terminations are not + recognized within parentheses. + +; Semicolon is used to start a comment; the remainder of + the line is ignored. + +5.2. Use of master files to define zones + +When a master file is used to load a zone, the operation should be +suppressed if any errors are encountered in the master file. The +rationale for this is that a single error can have widespread +consequences. For example, suppose that the RRs defining a delegation +have syntax errors; then the server will return authoritative name +errors for all names in the subzone (except in the case where the +subzone is also present on the server). + +Several other validity checks that should be performed in addition to +insuring that the file is syntactically correct: + + 1. All RRs in the file should have the same class. + + 2. Exactly one SOA RR should be present at the top of the zone. + + 3. If delegations are present and glue information is required, + it should be present. + + + +Mockapetris [Page 35] + +RFC 1035 Domain Implementation and Specification November 1987 + + + 4. Information present outside of the authoritative nodes in the + zone should be glue information, rather than the result of an + origin or similar error. + +5.3. Master file example + +The following is an example file which might be used to define the +ISI.EDU zone.and is loaded with an origin of ISI.EDU: + +@ IN SOA VENERA Action\.domains ( + 20 ; SERIAL + 7200 ; REFRESH + 600 ; RETRY + 3600000; EXPIRE + 60) ; MINIMUM + + NS A.ISI.EDU. + NS VENERA + NS VAXA + MX 10 VENERA + MX 20 VAXA + +A A 26.3.0.103 + +VENERA A 10.1.0.52 + A 128.9.0.32 + +VAXA A 10.2.0.27 + A 128.9.0.33 + + +$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT + +Where the file <SUBSYS>ISI-MAILBOXES.TXT is: + + MOE MB A.ISI.EDU. + LARRY MB A.ISI.EDU. + CURLEY MB A.ISI.EDU. + STOOGES MG MOE + MG LARRY + MG CURLEY + +Note the use of the \ character in the SOA RR to specify the responsible +person mailbox "Action.domains@E.ISI.EDU". + + + + + + + +Mockapetris [Page 36] + +RFC 1035 Domain Implementation and Specification November 1987 + + +6. NAME SERVER IMPLEMENTATION + +6.1. Architecture + +The optimal structure for the name server will depend on the host +operating system and whether the name server is integrated with resolver +operations, either by supporting recursive service, or by sharing its +database with a resolver. This section discusses implementation +considerations for a name server which shares a database with a +resolver, but most of these concerns are present in any name server. + +6.1.1. Control + +A name server must employ multiple concurrent activities, whether they +are implemented as separate tasks in the host's OS or multiplexing +inside a single name server program. It is simply not acceptable for a +name server to block the service of UDP requests while it waits for TCP +data for refreshing or query activities. Similarly, a name server +should not attempt to provide recursive service without processing such +requests in parallel, though it may choose to serialize requests from a +single client, or to regard identical requests from the same client as +duplicates. A name server should not substantially delay requests while +it reloads a zone from master files or while it incorporates a newly +refreshed zone into its database. + +6.1.2. Database + +While name server implementations are free to use any internal data +structures they choose, the suggested structure consists of three major +parts: + + - A "catalog" data structure which lists the zones available to + this server, and a "pointer" to the zone data structure. The + main purpose of this structure is to find the nearest ancestor + zone, if any, for arriving standard queries. + + - Separate data structures for each of the zones held by the + name server. + + - A data structure for cached data. (or perhaps separate caches + for different classes) + +All of these data structures can be implemented an identical tree +structure format, with different data chained off the nodes in different +parts: in the catalog the data is pointers to zones, while in the zone +and cache data structures, the data will be RRs. In designing the tree +framework the designer should recognize that query processing will need +to traverse the tree using case-insensitive label comparisons; and that + + + +Mockapetris [Page 37] + +RFC 1035 Domain Implementation and Specification November 1987 + + +in real data, a few nodes have a very high branching factor (100-1000 or +more), but the vast majority have a very low branching factor (0-1). + +One way to solve the case problem is to store the labels for each node +in two pieces: a standardized-case representation of the label where all +ASCII characters are in a single case, together with a bit mask that +denotes which characters are actually of a different case. The +branching factor diversity can be handled using a simple linked list for +a node until the branching factor exceeds some threshold, and +transitioning to a hash structure after the threshold is exceeded. In +any case, hash structures used to store tree sections must insure that +hash functions and procedures preserve the casing conventions of the +DNS. + +The use of separate structures for the different parts of the database +is motivated by several factors: + + - The catalog structure can be an almost static structure that + need change only when the system administrator changes the + zones supported by the server. This structure can also be + used to store parameters used to control refreshing + activities. + + - The individual data structures for zones allow a zone to be + replaced simply by changing a pointer in the catalog. Zone + refresh operations can build a new structure and, when + complete, splice it into the database via a simple pointer + replacement. It is very important that when a zone is + refreshed, queries should not use old and new data + simultaneously. + + - With the proper search procedures, authoritative data in zones + will always "hide", and hence take precedence over, cached + data. + + - Errors in zone definitions that cause overlapping zones, etc., + may cause erroneous responses to queries, but problem + determination is simplified, and the contents of one "bad" + zone can't corrupt another. + + - Since the cache is most frequently updated, it is most + vulnerable to corruption during system restarts. It can also + become full of expired RR data. In either case, it can easily + be discarded without disturbing zone data. + +A major aspect of database design is selecting a structure which allows +the name server to deal with crashes of the name server's host. State +information which a name server should save across system crashes + + + +Mockapetris [Page 38] + +RFC 1035 Domain Implementation and Specification November 1987 + + +includes the catalog structure (including the state of refreshing for +each zone) and the zone data itself. + +6.1.3. Time + +Both the TTL data for RRs and the timing data for refreshing activities +depends on 32 bit timers in units of seconds. Inside the database, +refresh timers and TTLs for cached data conceptually "count down", while +data in the zone stays with constant TTLs. + +A recommended implementation strategy is to store time in two ways: as +a relative increment and as an absolute time. One way to do this is to +use positive 32 bit numbers for one type and negative numbers for the +other. The RRs in zones use relative times; the refresh timers and +cache data use absolute times. Absolute numbers are taken with respect +to some known origin and converted to relative values when placed in the +response to a query. When an absolute TTL is negative after conversion +to relative, then the data is expired and should be ignored. + +6.2. Standard query processing + +The major algorithm for standard query processing is presented in +[RFC-1034]. + +When processing queries with QCLASS=*, or some other QCLASS which +matches multiple classes, the response should never be authoritative +unless the server can guarantee that the response covers all classes. + +When composing a response, RRs which are to be inserted in the +additional section, but duplicate RRs in the answer or authority +sections, may be omitted from the additional section. + +When a response is so long that truncation is required, the truncation +should start at the end of the response and work forward in the +datagram. Thus if there is any data for the authority section, the +answer section is guaranteed to be unique. + +The MINIMUM value in the SOA should be used to set a floor on the TTL of +data distributed from a zone. This floor function should be done when +the data is copied into a response. This will allow future dynamic +update protocols to change the SOA MINIMUM field without ambiguous +semantics. + +6.3. Zone refresh and reload processing + +In spite of a server's best efforts, it may be unable to load zone data +from a master file due to syntax errors, etc., or be unable to refresh a +zone within the its expiration parameter. In this case, the name server + + + +Mockapetris [Page 39] + +RFC 1035 Domain Implementation and Specification November 1987 + + +should answer queries as if it were not supposed to possess the zone. + +If a master is sending a zone out via AXFR, and a new version is created +during the transfer, the master should continue to send the old version +if possible. In any case, it should never send part of one version and +part of another. If completion is not possible, the master should reset +the connection on which the zone transfer is taking place. + +6.4. Inverse queries (Optional) + +Inverse queries are an optional part of the DNS. Name servers are not +required to support any form of inverse queries. If a name server +receives an inverse query that it does not support, it returns an error +response with the "Not Implemented" error set in the header. While +inverse query support is optional, all name servers must be at least +able to return the error response. + +6.4.1. The contents of inverse queries and responses Inverse +queries reverse the mappings performed by standard query operations; +while a standard query maps a domain name to a resource, an inverse +query maps a resource to a domain name. For example, a standard query +might bind a domain name to a host address; the corresponding inverse +query binds the host address to a domain name. + +Inverse queries take the form of a single RR in the answer section of +the message, with an empty question section. The owner name of the +query RR and its TTL are not significant. The response carries +questions in the question section which identify all names possessing +the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows +about all of the domain name space, the response can never be assumed to +be complete. Thus inverse queries are primarily useful for database +management and debugging activities. Inverse queries are NOT an +acceptable method of mapping host addresses to host names; use the IN- +ADDR.ARPA domain instead. + +Where possible, name servers should provide case-insensitive comparisons +for inverse queries. Thus an inverse query asking for an MX RR of +"Venera.isi.edu" should get the same response as a query for +"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should +produce the same result as an inverse query for "IBM-pc unix". However, +this cannot be guaranteed because name servers may possess RRs that +contain character strings but the name server does not know that the +data is character. + +When a name server processes an inverse query, it either returns: + + 1. zero, one, or multiple domain names for the specified + resource as QNAMEs in the question section + + + +Mockapetris [Page 40] + +RFC 1035 Domain Implementation and Specification November 1987 + + + 2. an error code indicating that the name server doesn't support + inverse mapping of the specified resource type. + +When the response to an inverse query contains one or more QNAMEs, the +owner name and TTL of the RR in the answer section which defines the +inverse query is modified to exactly match an RR found at the first +QNAME. + +RRs returned in the inverse queries cannot be cached using the same +mechanism as is used for the replies to standard queries. One reason +for this is that a name might have multiple RRs of the same type, and +only one would appear. For example, an inverse query for a single +address of a multiply homed host might create the impression that only +one address existed. + +6.4.2. Inverse query and response example The overall structure +of an inverse query for retrieving the domain name that corresponds to +Internet address 10.1.0.52 is shown below: + + +-----------------------------------------+ + Header | OPCODE=IQUERY, ID=997 | + +-----------------------------------------+ + Question | <empty> | + +-----------------------------------------+ + Answer | <anyname> A IN 10.1.0.52 | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | <empty> | + +-----------------------------------------+ + +This query asks for a question whose answer is the Internet style +address 10.1.0.52. Since the owner name is not known, any domain name +can be used as a placeholder (and is ignored). A single octet of zero, +signifying the root, is usually used because it minimizes the length of +the message. The TTL of the RR is not significant. The response to +this query might be: + + + + + + + + + + + + + + +Mockapetris [Page 41] + +RFC 1035 Domain Implementation and Specification November 1987 + + + +-----------------------------------------+ + Header | OPCODE=RESPONSE, ID=997 | + +-----------------------------------------+ + Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU | + +-----------------------------------------+ + Answer | VENERA.ISI.EDU A IN 10.1.0.52 | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | <empty> | + +-----------------------------------------+ + +Note that the QTYPE in a response to an inverse query is the same as the +TYPE field in the answer section of the inverse query. Responses to +inverse queries may contain multiple questions when the inverse is not +unique. If the question section in the response is not empty, then the +RR in the answer section is modified to correspond to be an exact copy +of an RR at the first QNAME. + +6.4.3. Inverse query processing + +Name servers that support inverse queries can support these operations +through exhaustive searches of their databases, but this becomes +impractical as the size of the database increases. An alternative +approach is to invert the database according to the search key. + +For name servers that support multiple zones and a large amount of data, +the recommended approach is separate inversions for each zone. When a +particular zone is changed during a refresh, only its inversions need to +be redone. + +Support for transfer of this type of inversion may be included in future +versions of the domain system, but is not supported in this version. + +6.5. Completion queries and responses + +The optional completion services described in RFC-882 and RFC-883 have +been deleted. Redesigned services may become available in the future. + + + + + + + + + + + + + +Mockapetris [Page 42] + +RFC 1035 Domain Implementation and Specification November 1987 + + +7. RESOLVER IMPLEMENTATION + +The top levels of the recommended resolver algorithm are discussed in +[RFC-1034]. This section discusses implementation details assuming the +database structure suggested in the name server implementation section +of this memo. + +7.1. Transforming a user request into a query + +The first step a resolver takes is to transform the client's request, +stated in a format suitable to the local OS, into a search specification +for RRs at a specific name which match a specific QTYPE and QCLASS. +Where possible, the QTYPE and QCLASS should correspond to a single type +and a single class, because this makes the use of cached data much +simpler. The reason for this is that the presence of data of one type +in a cache doesn't confirm the existence or non-existence of data of +other types, hence the only way to be sure is to consult an +authoritative source. If QCLASS=* is used, then authoritative answers +won't be available. + +Since a resolver must be able to multiplex multiple requests if it is to +perform its function efficiently, each pending request is usually +represented in some block of state information. This state block will +typically contain: + + - A timestamp indicating the time the request began. + The timestamp is used to decide whether RRs in the database + can be used or are out of date. This timestamp uses the + absolute time format previously discussed for RR storage in + zones and caches. Note that when an RRs TTL indicates a + relative time, the RR must be timely, since it is part of a + zone. When the RR has an absolute time, it is part of a + cache, and the TTL of the RR is compared against the timestamp + for the start of the request. + + Note that using the timestamp is superior to using a current + time, since it allows RRs with TTLs of zero to be entered in + the cache in the usual manner, but still used by the current + request, even after intervals of many seconds due to system + load, query retransmission timeouts, etc. + + - Some sort of parameters to limit the amount of work which will + be performed for this request. + + The amount of work which a resolver will do in response to a + client request must be limited to guard against errors in the + database, such as circular CNAME references, and operational + problems, such as network partition which prevents the + + + +Mockapetris [Page 43] + +RFC 1035 Domain Implementation and Specification November 1987 + + + resolver from accessing the name servers it needs. While + local limits on the number of times a resolver will retransmit + a particular query to a particular name server address are + essential, the resolver should have a global per-request + counter to limit work on a single request. The counter should + be set to some initial value and decremented whenever the + resolver performs any action (retransmission timeout, + retransmission, etc.) If the counter passes zero, the request + is terminated with a temporary error. + + Note that if the resolver structure allows one request to + start others in parallel, such as when the need to access a + name server for one request causes a parallel resolve for the + name server's addresses, the spawned request should be started + with a lower counter. This prevents circular references in + the database from starting a chain reaction of resolver + activity. + + - The SLIST data structure discussed in [RFC-1034]. + + This structure keeps track of the state of a request if it + must wait for answers from foreign name servers. + +7.2. Sending the queries + +As described in [RFC-1034], the basic task of the resolver is to +formulate a query which will answer the client's request and direct that +query to name servers which can provide the information. The resolver +will usually only have very strong hints about which servers to ask, in +the form of NS RRs, and may have to revise the query, in response to +CNAMEs, or revise the set of name servers the resolver is asking, in +response to delegation responses which point the resolver to name +servers closer to the desired information. In addition to the +information requested by the client, the resolver may have to call upon +its own services to determine the address of name servers it wishes to +contact. + +In any case, the model used in this memo assumes that the resolver is +multiplexing attention between multiple requests, some from the client, +and some internally generated. Each request is represented by some +state information, and the desired behavior is that the resolver +transmit queries to name servers in a way that maximizes the probability +that the request is answered, minimizes the time that the request takes, +and avoids excessive transmissions. The key algorithm uses the state +information of the request to select the next name server address to +query, and also computes a timeout which will cause the next action +should a response not arrive. The next action will usually be a +transmission to some other server, but may be a temporary error to the + + + +Mockapetris [Page 44] + +RFC 1035 Domain Implementation and Specification November 1987 + + +client. + +The resolver always starts with a list of server names to query (SLIST). +This list will be all NS RRs which correspond to the nearest ancestor +zone that the resolver knows about. To avoid startup problems, the +resolver should have a set of default servers which it will ask should +it have no current NS RRs which are appropriate. The resolver then adds +to SLIST all of the known addresses for the name servers, and may start +parallel requests to acquire the addresses of the servers when the +resolver has the name, but no addresses, for the name servers. + +To complete initialization of SLIST, the resolver attaches whatever +history information it has to the each address in SLIST. This will +usually consist of some sort of weighted averages for the response time +of the address, and the batting average of the address (i.e., how often +the address responded at all to the request). Note that this +information should be kept on a per address basis, rather than on a per +name server basis, because the response time and batting average of a +particular server may vary considerably from address to address. Note +also that this information is actually specific to a resolver address / +server address pair, so a resolver with multiple addresses may wish to +keep separate histories for each of its addresses. Part of this step +must deal with addresses which have no such history; in this case an +expected round trip time of 5-10 seconds should be the worst case, with +lower estimates for the same local network, etc. + +Note that whenever a delegation is followed, the resolver algorithm +reinitializes SLIST. + +The information establishes a partial ranking of the available name +server addresses. Each time an address is chosen and the state should +be altered to prevent its selection again until all other addresses have +been tried. The timeout for each transmission should be 50-100% greater +than the average predicted value to allow for variance in response. + +Some fine points: + + - The resolver may encounter a situation where no addresses are + available for any of the name servers named in SLIST, and + where the servers in the list are precisely those which would + normally be used to look up their own addresses. This + situation typically occurs when the glue address RRs have a + smaller TTL than the NS RRs marking delegation, or when the + resolver caches the result of a NS search. The resolver + should detect this condition and restart the search at the + next ancestor zone, or alternatively at the root. + + + + + +Mockapetris [Page 45] + +RFC 1035 Domain Implementation and Specification November 1987 + + + - If a resolver gets a server error or other bizarre response + from a name server, it should remove it from SLIST, and may + wish to schedule an immediate transmission to the next + candidate server address. + +7.3. Processing responses + +The first step in processing arriving response datagrams is to parse the +response. This procedure should include: + + - Check the header for reasonableness. Discard datagrams which + are queries when responses are expected. + + - Parse the sections of the message, and insure that all RRs are + correctly formatted. + + - As an optional step, check the TTLs of arriving data looking + for RRs with excessively long TTLs. If a RR has an + excessively long TTL, say greater than 1 week, either discard + the whole response, or limit all TTLs in the response to 1 + week. + +The next step is to match the response to a current resolver request. +The recommended strategy is to do a preliminary matching using the ID +field in the domain header, and then to verify that the question section +corresponds to the information currently desired. This requires that +the transmission algorithm devote several bits of the domain ID field to +a request identifier of some sort. This step has several fine points: + + - Some name servers send their responses from different + addresses than the one used to receive the query. That is, a + resolver cannot rely that a response will come from the same + address which it sent the corresponding query to. This name + server bug is typically encountered in UNIX systems. + + - If the resolver retransmits a particular request to a name + server it should be able to use a response from any of the + transmissions. However, if it is using the response to sample + the round trip time to access the name server, it must be able + to determine which transmission matches the response (and keep + transmission times for each outgoing message), or only + calculate round trip times based on initial transmissions. + + - A name server will occasionally not have a current copy of a + zone which it should have according to some NS RRs. The + resolver should simply remove the name server from the current + SLIST, and continue. + + + + +Mockapetris [Page 46] + +RFC 1035 Domain Implementation and Specification November 1987 + + +7.4. Using the cache + +In general, we expect a resolver to cache all data which it receives in +responses since it may be useful in answering future client requests. +However, there are several types of data which should not be cached: + + - When several RRs of the same type are available for a + particular owner name, the resolver should either cache them + all or none at all. When a response is truncated, and a + resolver doesn't know whether it has a complete set, it should + not cache a possibly partial set of RRs. + + - Cached data should never be used in preference to + authoritative data, so if caching would cause this to happen + the data should not be cached. + + - The results of an inverse query should not be cached. + + - The results of standard queries where the QNAME contains "*" + labels if the data might be used to construct wildcards. The + reason is that the cache does not necessarily contain existing + RRs or zone boundary information which is necessary to + restrict the application of the wildcard RRs. + + - RR data in responses of dubious reliability. When a resolver + receives unsolicited responses or RR data other than that + requested, it should discard it without caching it. The basic + implication is that all sanity checks on a packet should be + performed before any of it is cached. + +In a similar vein, when a resolver has a set of RRs for some name in a +response, and wants to cache the RRs, it should check its cache for +already existing RRs. Depending on the circumstances, either the data +in the response or the cache is preferred, but the two should never be +combined. If the data in the response is from authoritative data in the +answer section, it is always preferred. + +8. MAIL SUPPORT + +The domain system defines a standard for mapping mailboxes into domain +names, and two methods for using the mailbox information to derive mail +routing information. The first method is called mail exchange binding +and the other method is mailbox binding. The mailbox encoding standard +and mail exchange binding are part of the DNS official protocol, and are +the recommended method for mail routing in the Internet. Mailbox +binding is an experimental feature which is still under development and +subject to change. + + + + +Mockapetris [Page 47] + +RFC 1035 Domain Implementation and Specification November 1987 + + +The mailbox encoding standard assumes a mailbox name of the form +"<local-part>@<mail-domain>". While the syntax allowed in each of these +sections varies substantially between the various mail internets, the +preferred syntax for the ARPA Internet is given in [RFC-822]. + +The DNS encodes the <local-part> as a single label, and encodes the +<mail-domain> as a domain name. The single label from the <local-part> +is prefaced to the domain name from <mail-domain> to form the domain +name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI- +NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the +<local-part> contains dots or other special characters, its +representation in a master file will require the use of backslash +quoting to ensure that the domain name is properly encoded. For +example, the mailbox Action.domains@ISI.EDU would be represented as +Action\.domains.ISI.EDU. + +8.1. Mail exchange binding + +Mail exchange binding uses the <mail-domain> part of a mailbox +specification to determine where mail should be sent. The <local-part> +is not even consulted. [RFC-974] specifies this method in detail, and +should be consulted before attempting to use mail exchange support. + +One of the advantages of this method is that it decouples mail +destination naming from the hosts used to support mail service, at the +cost of another layer of indirection in the lookup function. However, +the addition layer should eliminate the need for complicated "%", "!", +etc encodings in <local-part>. + +The essence of the method is that the <mail-domain> is used as a domain +name to locate type MX RRs which list hosts willing to accept mail for +<mail-domain>, together with preference values which rank the hosts +according to an order specified by the administrators for <mail-domain>. + +In this memo, the <mail-domain> ISI.EDU is used in examples, together +with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for +ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would +route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name +VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host +addresses. + +8.2. Mailbox binding (Experimental) + +In mailbox binding, the mailer uses the entire mail destination +specification to construct a domain name. The encoded domain name for +the mailbox is used as the QNAME field in a QTYPE=MAILB query. + +Several outcomes are possible for this query: + + + +Mockapetris [Page 48] + +RFC 1035 Domain Implementation and Specification November 1987 + + + 1. The query can return a name error indicating that the mailbox + does not exist as a domain name. + + In the long term, this would indicate that the specified + mailbox doesn't exist. However, until the use of mailbox + binding is universal, this error condition should be + interpreted to mean that the organization identified by the + global part does not support mailbox binding. The + appropriate procedure is to revert to exchange binding at + this point. + + 2. The query can return a Mail Rename (MR) RR. + + The MR RR carries new mailbox specification in its RDATA + field. The mailer should replace the old mailbox with the + new one and retry the operation. + + 3. The query can return a MB RR. + + The MB RR carries a domain name for a host in its RDATA + field. The mailer should deliver the message to that host + via whatever protocol is applicable, e.g., b,SMTP. + + 4. The query can return one or more Mail Group (MG) RRs. + + This condition means that the mailbox was actually a mailing + list or mail group, rather than a single mailbox. Each MG RR + has a RDATA field that identifies a mailbox that is a member + of the group. The mailer should deliver a copy of the + message to each member. + + 5. The query can return a MB RR as well as one or more MG RRs. + + This condition means the the mailbox was actually a mailing + list. The mailer can either deliver the message to the host + specified by the MB RR, which will in turn do the delivery to + all members, or the mailer can use the MG RRs to do the + expansion itself. + +In any of these cases, the response may include a Mail Information +(MINFO) RR. This RR is usually associated with a mail group, but is +legal with a MB. The MINFO RR identifies two mailboxes. One of these +identifies a responsible person for the original mailbox name. This +mailbox should be used for requests to be added to a mail group, etc. +The second mailbox name in the MINFO RR identifies a mailbox that should +receive error messages for mail failures. This is particularly +appropriate for mailing lists when errors in member names should be +reported to a person other than the one who sends a message to the list. + + + +Mockapetris [Page 49] + +RFC 1035 Domain Implementation and Specification November 1987 + + +New fields may be added to this RR in the future. + + +9. REFERENCES and BIBLIOGRAPHY + +[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena + Technical Plan - Name Service, April 1987, version 1.9. + + Describes the fundamentals of the Hesiod name service. + +[IEN-116] J. Postel, "Internet Name Server", IEN-116, + USC/Information Sciences Institute, August 1979. + + A name service obsoleted by the Domain Name System, but + still in use. + +[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks", + Communications of the ACM, October 1986, volume 29, number + 10. + +[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network + Information Center, SRI International, December 1977. + +[RFC-768] J. Postel, "User Datagram Protocol", RFC-768, + USC/Information Sciences Institute, August 1980. + +[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793, + USC/Information Sciences Institute, September 1981. + +[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT, + September 1981. + + Suggests introduction of a hierarchy in place of a flat + name space for the Internet. + +[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805, + USC/Information Sciences Institute, February 1982. + +[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD + Internet Host Table Specification", RFC-810, Network + Information Center, SRI International, March 1982. + + Obsolete. See RFC-952. + +[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames + Server", RFC-811, Network Information Center, SRI + International, March 1982. + + + + +Mockapetris [Page 50] + +RFC 1035 Domain Implementation and Specification November 1987 + + + Obsolete. See RFC-953. + +[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812, + Network Information Center, SRI International, March + 1982. + +[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for + Internet User Applications", RFC-819, Network + Information Center, SRI International, August 1982. + + Early thoughts on the design of the domain system. + Current implementation is completely different. + +[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821, + USC/Information Sciences Institute, August 1980. + +[RFC-830] Z. Su, "A Distributed System for Internet Name Service", + RFC-830, Network Information Center, SRI International, + October 1982. + + Early thoughts on the design of the domain system. + Current implementation is completely different. + +[RFC-882] P. Mockapetris, "Domain names - Concepts and + Facilities," RFC-882, USC/Information Sciences + Institute, November 1983. + + Superceeded by this memo. + +[RFC-883] P. Mockapetris, "Domain names - Implementation and + Specification," RFC-883, USC/Information Sciences + Institute, November 1983. + + Superceeded by this memo. + +[RFC-920] J. Postel and J. Reynolds, "Domain Requirements", + RFC-920, USC/Information Sciences Institute, + October 1984. + + Explains the naming scheme for top level domains. + +[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host + Table Specification", RFC-952, SRI, October 1985. + + Specifies the format of HOSTS.TXT, the host/address + table replaced by the DNS. + + + + + +Mockapetris [Page 51] + +RFC 1035 Domain Implementation and Specification November 1987 + + +[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server", + RFC-953, SRI, October 1985. + + This RFC contains the official specification of the + hostname server protocol, which is obsoleted by the DNS. + This TCP based protocol accesses information stored in + the RFC-952 format, and is used to obtain copies of the + host table. + +[RFC-973] P. Mockapetris, "Domain System Changes and + Observations", RFC-973, USC/Information Sciences + Institute, January 1986. + + Describes changes to RFC-882 and RFC-883 and reasons for + them. + +[RFC-974] C. Partridge, "Mail routing and the domain system", + RFC-974, CSNET CIC BBN Labs, January 1986. + + Describes the transition from HOSTS.TXT based mail + addressing to the more powerful MX system used with the + domain system. + +[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS + service on a TCP/UDP transport: Concepts and Methods", + RFC-1001, March 1987. + + This RFC and RFC-1002 are a preliminary design for + NETBIOS on top of TCP/IP which proposes to base NetBIOS + name service on top of the DNS. + +[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS + service on a TCP/UDP transport: Detailed + Specifications", RFC-1002, March 1987. + +[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010, + USC/Information Sciences Institute, May 1987. + + Contains socket numbers and mnemonics for host names, + operating systems, etc. + +[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031, + November 1987. + + Describes a plan for converting the MILNET to the DNS. + +[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for + Administrators", RFC-1032, November 1987. + + + +Mockapetris [Page 52] + +RFC 1035 Domain Implementation and Specification November 1987 + + + Describes the registration policies used by the NIC to + administer the top level domains and delegate subzones. + +[RFC-1033] M. Lottor, "Domain Administrators Operations Guide", + RFC-1033, November 1987. + + A cookbook for domain administrators. + +[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET + Name Server", Computer Networks, vol 6, nr 3, July 1982. + + Describes a name service for CSNET which is independent + from the DNS and DNS use in the CSNET. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 53] + +RFC 1035 Domain Implementation and Specification November 1987 + + +Index + + * 13 + + ; 33, 35 + + <character-string> 35 + <domain-name> 34 + + @ 35 + + \ 35 + + A 12 + + Byte order 8 + + CH 13 + Character case 9 + CLASS 11 + CNAME 12 + Completion 42 + CS 13 + + Hesiod 13 + HINFO 12 + HS 13 + + IN 13 + IN-ADDR.ARPA domain 22 + Inverse queries 40 + + Mailbox names 47 + MB 12 + MD 12 + MF 12 + MG 12 + MINFO 12 + MINIMUM 20 + MR 12 + MX 12 + + NS 12 + NULL 12 + + Port numbers 32 + Primary server 5 + PTR 12, 18 + + + +Mockapetris [Page 54] + +RFC 1035 Domain Implementation and Specification November 1987 + + + QCLASS 13 + QTYPE 12 + + RDATA 12 + RDLENGTH 11 + + Secondary server 5 + SOA 12 + Stub resolvers 7 + + TCP 32 + TXT 12 + TYPE 11 + + UDP 32 + + WKS 12 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 55] + diff --git a/Documentation/en/rfc/rfc1101.txt b/Documentation/en/rfc/rfc1101.txt new file mode 100644 index 00000000..66c9d8b8 --- /dev/null +++ b/Documentation/en/rfc/rfc1101.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group P. Mockapetris +Request for Comments: 1101 ISI +Updates: RFCs 1034, 1035 April 1989 + + + DNS Encoding of Network Names and Other Types + + +1. STATUS OF THIS MEMO + + This RFC proposes two extensions to the Domain Name System: + + - A specific method for entering and retrieving RRs which map + between network names and numbers. + + - Ideas for a general method for describing mappings between + arbitrary identifiers and numbers. + + The method for mapping between network names and addresses is a + proposed standard, the ideas for a general method are experimental. + + This RFC assumes that the reader is familiar with the DNS [RFC 1034, + RFC 1035] and its use. The data shown is for pedagogical use and + does not necessarily reflect the real Internet. + + Distribution of this memo is unlimited. + +2. INTRODUCTION + + The DNS is extensible and can be used for a virtually unlimited + number of data types, name spaces, etc. New type definitions are + occasionally necessary as are revisions or deletions of old types + (e.g., MX replacement of MD and MF [RFC 974]), and changes described + in [RFC 973]. This RFC describes changes due to the general need to + map between identifiers and values, and a specific need for network + name support. + + Users wish to be able to use the DNS to map between network names and + numbers. This need is the only capability found in HOSTS.TXT which + is not available from the DNS. In designing a method to do this, + there were two major areas of concern: + + - Several tradeoffs involving control of network names, the + syntax of network names, backward compatibility, etc. + + - A desire to create a method which would be sufficiently + general to set a good precedent for future mappings, + for example, between TCP-port names and numbers, + + + +Mockapetris [Page 1] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + autonomous system names and numbers, X.500 Relative + Distinguished Names (RDNs) and their servers, or whatever. + + It was impossible to reconcile these two areas of concern for network + names because of the desire to unify network number support within + existing IP address to host name support. The existing support is + the IN-ADDR.ARPA section of the DNS name space. As a result this RFC + describes one structure for network names which builds on the + existing support for host names, and another family of structures for + future yellow pages (YP) functions such as conversions between TCP- + port numbers and mnemonics. + + Both structures are described in following sections. Each structure + has a discussion of design issues and specific structure + recommendations. + + We wish to avoid defining structures and methods which can work but + do not because of indifference or errors on the part of system + administrators when maintaining the database. The WKS RR is an + example. Thus, while we favor distribution as a general method, we + also recognize that centrally maintained tables (such as HOSTS.TXT) + are usually more consistent though less maintainable and timely. + Hence we recommend both specific methods for mapping network names, + addresses, and subnets, as well as an instance of the general method + for mapping between allocated network numbers and network names. + (Allocation is centrally performed by the SRI Network Information + Center, aka the NIC). + +3. NETWORK NAME ISSUES AND DISCUSSION + + The issues involved in the design were the definition of network name + syntax, the mappings to be provided, and possible support for similar + functions at the subnet level. + +3.1. Network name syntax + + The current syntax for network names, as defined by [RFC 952] is an + alphanumeric string of up to 24 characters, which begins with an + alpha, and may include "." and "-" except as first and last + characters. This is the format which was also used for host names + before the DNS. Upward compatibility with existing names might be a + goal of any new scheme. + + However, the present syntax has been used to define a flat name + space, and hence would prohibit the same distributed name allocation + method used for host names. There is some sentiment for allowing the + NIC to continue to allocate and regulate network names, much as it + allocates numbers, but the majority opinion favors local control of + + + +Mockapetris [Page 2] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + network names. Although it would be possible to provide a flat space + or a name space in which, for example, the last label of a domain + name captured the old-style network name, any such approach would add + complexity to the method and create different rules for network names + and host names. + + For these reasons, we assume that the syntax of network names will be + the same as the expanded syntax for host names permitted in [HR]. + The new syntax expands the set of names to allow leading digits, so + long as the resulting representations do not conflict with IP + addresses in decimal octet form. For example, 3Com.COM and 3M.COM + are now legal, although 26.0.0.73.COM is not. See [HR] for details. + + The price is that network names will get as complicated as host + names. An administrator will be able to create network names in any + domain under his control, and also create network number to name + entries in IN-ADDR.ARPA domains under his control. Thus, the name + for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa- + network.MIL., depending on the preferences of the owner. + +3.2. Mappings + + The desired mappings, ranked by priority with most important first, + are: + + - Mapping a IP address or network number to a network name. + + This mapping is for use in debugging tools and status displays + of various sorts. The conversion from IP address to network + number is well known for class A, B, and C IP addresses, and + involves a simple mask operation. The needs of other classes + are not yet defined and are ignored for the rest of this RFC. + + - Mapping a network name to a network address. + + This facility is of less obvious application, but a + symmetrical mapping seems desirable. + + - Mapping an organization to its network names and numbers. + + This facility is useful because it may not always be possible + to guess the local choice for network names, but the + organization name is often well known. + + - Similar mappings for subnets, even when nested. + + The primary application is to be able to identify all of the + subnets involved in a particular IP address. A secondary + + + +Mockapetris [Page 3] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + requirement is to retrieve address mask information. + +3.3. Network address section of the name space + + The network name syntax discussed above can provide domain names + which will contain mappings from network names to various quantities, + but we also need a section of the name space, organized by network + and subnet number to hold the inverse mappings. + + The choices include: + + - The same network number slots already assigned and delegated + in the IN-ADDR.ARPA section of the name space. + + For example, 10.IN-ADDR.ARPA for class A net 10, + 2.128.IN-ADDR.ARPA for class B net 128.2, etc. + + - Host-zero addresses in the IN-ADDR.ARPA tree. (A host field + of all zero in an IP address is prohibited because of + confusion related to broadcast addresses, et al.) + + For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10, + 0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc. Like the + first scheme, it uses in-place name space delegations to + distribute control. + + The main advantage of this scheme over the first is that it + allows convenient names for subnets as well as networks. A + secondary advantage is that it uses names which are not in use + already, and hence it is possible to test whether an + organization has entered this information in its domain + database. + + - Some new section of the name space. + + While this option provides the most opportunities, it creates + a need to delegate a whole new name space. Since the IP + address space is so closely related to the network number + space, most believe that the overhead of creating such a new + space is overwhelming and would lead to the WKS syndrome. (As + of February, 1989, approximately 400 sections of the + IN-ADDR.ARPA tree are already delegated, usually at network + boundaries.) + + + + + + + + +Mockapetris [Page 4] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + +4. SPECIFICS FOR NETWORK NAME MAPPINGS + + The proposed solution uses information stored at: + + - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP + addresses. The same method is used for subnets in a nested + fashion. For example, 0.0.0.10.IN-ADDR.ARPA. for net 10. + + Two types of information are stored here: PTR RRs which point + to the network name in their data sections, and A RRs, which + are present if the network (or subnet) is subnetted further. + If a type A RR is present, then it has the address mask as its + data. The general form is: + + <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name> + <reversed-host-zero-number>.IN-ADDR.ARPA. A <subnet-mask> + + For example: + + 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA. + + or + + 0.0.2.128.IN-ADDR.ARPA. PTR cmu-net.cmu.edu. + A 255.255.255.0 + + In general, this information will be added to an existing + master file for some IN-ADDR.ARPA domain for each network + involved. Similar RRs can be used at host-zero subnet + entries. + + - Names which are network names. + + The data stored here is PTR RRs pointing at the host-zero + entries. The general form is: + + <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA + + For example: + + ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA. + + or + + isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA. + + In general, this information will be inserted in the master + file for the domain name of the organization; this is a + + + +Mockapetris [Page 5] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + different file from that which holds the information below + IN-ADDR.ARPA. Similar PTR RRs can be used at subnet names. + + - Names corresponding to organizations. + + The data here is one or more PTR RRs pointing at the + IN-ADDR.ARPA names corresponding to host-zero entries for + networks. + + For example: + + ISI.EDU. PTR 0.0.9.128.IN-ADDR.ARPA. + + MCC.COM. PTR 0.167.5.192.IN-ADDR.ARPA. + PTR 0.168.5.192.IN-ADDR.ARPA. + PTR 0.169.5.192.IN-ADDR.ARPA. + PTR 0.0.62.128.IN-ADDR.ARPA. + +4.1. A simple example + + The ARPANET is a Class A network without subnets. The RRs which + would be added, assuming the ARPANET.ARPA was selected as a network + name, would be: + + ARPA. PTR 0.0.0.10.IN-ADDR.ARPA. + + ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA. + + 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA. + + The first RR states that the organization named ARPA owns net 10 (It + might also own more network numbers, and these would be represented + with an additional RR per net.) The second states that the network + name ARPANET.ARPA. maps to net 10. The last states that net 10 is + named ARPANET.ARPA. + + Note that all of the usual host and corresponding IN-ADDR.ARPA + entries would still be required. + +4.2. A complicated, subnetted example + + The ISI network is 128.9, a class B number. Suppose the ISI network + was organized into two levels of subnet, with the first level using + an additional 8 bits of address, and the second level using 4 bits, + for address masks of x'FFFFFF00' and X'FFFFFFF0'. + + Then the following RRs would be entered in ISI's master file for the + ISI.EDU zone: + + + +Mockapetris [Page 6] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + ; Define network entry + isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA. + + ; Define first level subnets + div1-subnet.isi.edu. PTR 0.1.9.128.IN-ADDR.ARPA. + div2-subnet.isi.edu. PTR 0.2.9.128.IN-ADDR.ARPA. + + ; Define second level subnets + inc-subsubnet.isi.edu. PTR 16.2.9.128.IN-ADDR.ARPA. + + in the 9.128.IN-ADDR.ARPA zone: + + ; Define network number and address mask + 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu. + A 255.255.255.0 ;aka X'FFFFFF00' + + ; Define one of the first level subnet numbers and masks + 0.1.9.128.IN-ADDR.ARPA. PTR div1-subnet.isi.edu. + A 255.255.255.240 ;aka X'FFFFFFF0' + + ; Define another first level subnet number and mask + 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu. + A 255.255.255.240 ;aka X'FFFFFFF0' + + ; Define second level subnet number + 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu. + + This assumes that the ISI network is named isi-net.isi.edu., first + level subnets are named div1-subnet.isi.edu. and div2- + subnet.isi.edu., and a second level subnet is called inc- + subsubnet.isi.edu. (In a real system as complicated as this there + would be more first and second level subnets defined, but we have + shown enough to illustrate the ideas.) + +4.3. Procedure for using an IP address to get network name + + Depending on whether the IP address is class A, B, or C, mask off the + high one, two, or three bytes, respectively. Reverse the octets, + suffix IN-ADDR.ARPA, and do a PTR query. + + For example, suppose the IP address is 10.0.0.51. + + 1. Since this is a class A address, use a mask x'FF000000' and + get 10.0.0.0. + + 2. Construct the name 0.0.0.10.IN-ADDR.ARPA. + + 3. Do a PTR query. Get back + + + +Mockapetris [Page 7] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA. + + 4. Conclude that the network name is "ARPANET.ARPA." + + Suppose that the IP address is 128.9.2.17. + + 1. Since this is a class B address, use a mask of x'FFFF0000' + and get 128.9.0.0. + + 2. Construct the name 0.0.9.128.IN-ADDR.ARPA. + + 3. Do a PTR query. Get back + + 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu + + 4. Conclude that the network name is "isi-net.isi.edu." + +4.4. Procedure for finding all subnets involved with an IP address + + This is a simple extension of the IP address to network name method. + When the network entry is located, do a lookup for a possible A RR. + If the A RR is found, look up the next level of subnet using the + original IP address and the mask in the A RR. Repeat this procedure + until no A RR is found. + + For example, repeating the use of 128.9.2.17. + + 1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA. + Retrieve: + + 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu. + A 255.255.255.0 + + 2. Since an A RR was found, repeat using mask from RR + (255.255.255.0), constructing a query for + 0.2.9.128.IN-ADDR.ARPA. Retrieve: + + 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu. + A 255.255.255.240 + + 3. Since another A RR was found, repeat using mask + 255.255.255.240 (x'FFFFFFF0'). constructing a query for + 16.2.9.128.IN-ADDR.ARPA. Retrieve: + + 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu. + + 4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there + are no more subnet levels. + + + +Mockapetris [Page 8] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + +5. YP ISSUES AND DISCUSSION + + The term "Yellow Pages" is used in almost as many ways as the term + "domain", so it is useful to define what is meant herein by YP. The + general problem to be solved is to create a method for creating + mappings from one kind of identifier to another, often with an + inverse capability. The traditional methods are to search or use a + precomputed index of some kind. + + Searching is impractical when the search is too large, and + precomputed indexes are possible only when it is possible to specify + search criteria in advance, and pay for the resources necessary to + build the index. For example, it is impractical to search the entire + domain tree to find a particular address RR, so we build the IN- + ADDR.ARPA YP. Similarly, we could never build an Internet-wide index + of "hosts with a load average of less than 2" in less time than it + would take for the data to change, so indexes are a useless approach + for that problem. + + Such a precomputed index is what we mean by YP, and we regard the + IN-ADDR.ARPA domain as the first instance of a YP in the DNS. + Although a single, centrally-managed YP for well-known values such as + TCP-port is desirable, we regard organization-specific YPs for, say, + locally defined TCP ports as a natural extension, as are combinations + of YPs using search lists to merge the two. + + In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC + 1010], it is clear that there are several mappings which might be of + value. For example: + + <assigned-network-name> <==> <IP-address> + <autonomous-system-id> <==> <number> + <protocol-id> <==> <number> + <port-id> <==> <number> + <ethernet-type> <==> <number> + <public-data-net> <==> <IP-address> + + Following the IN-ADDR example, the YP takes the form of a domain tree + organized to optimize retrieval by search key and distribution via + normal DNS rules. The name used as a key must include: + + 1. A well known origin. For example, IN-ADDR.ARPA is the + current IP-address to host name YP. + + 2. A "from" data type. This identifies the input type of the + mapping. This is necessary because we may be mapping + something as anonymous as a number to any number of + mnemonics, etc. + + + +Mockapetris [Page 9] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + 3. A "to" data type. Since we assume several symmetrical + mnemonic <==> number mappings, this is also necessary. + + This ordering reflects the natural scoping of control, and hence the + order of the components in a domain name. Thus domain names would be + of the form: + + <from-value>.<to-data-type>.<from-data-type>.<YP-origin> + + To make this work, we need to define well-know strings for each of + these metavariables, as well as encoding rules for converting a + <from-value> into a domain name. We might define: + + <YP-origin> :=YP + <from-data-type>:=TCP-port | IN-ADDR | Number | + Assigned-network-number | Name + <to-data-type> :=<from-data-type> + + Note that "YP" is NOT a valid country code under [ISO 3166] (although + we may want to worry about the future), and the existence of a + syntactically valid <to-data-type>.<from-data-type> pair does not + imply that a meaningful mapping exists, or is even possible. + + The encoding rules might be: + + TCP-port Six character alphanumeric + + IN-ADDR Reversed 4-octet decimal string + + Number decimal integer + + Assigned-network-number + Reversed 4-octet decimal string + + Name Domain name + +6. SPECIFICS FOR YP MAPPINGS + +6.1. TCP-PORT + + $origin Number.TCP-port.YP. + + 23 PTR TELNET.TCP-port.Number.YP. + 25 PTR SMTP.TCP-port.Number.YP. + + $origin TCP-port.Number.YP. + + TELNET PTR 23.Number.TCP-port.YP. + + + +Mockapetris [Page 10] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + SMTP PTR 25.Number.TCP-port.YP. + + Thus the mapping between 23 and TELNET is represented by a pair of + PTR RRs, one for each direction of the mapping. + +6.2. Assigned networks + + Network numbers are assigned by the NIC and reported in "Internet + Numbers" RFCs. To create a YP, the NIC would set up two domains: + + Name.Assigned-network-number.YP and Assigned-network-number.YP + + The first would contain entries of the form: + + $origin Name.Assigned-network-number.YP. + + 0.0.0.4 PTR SATNET.Assigned-network-number.Name.YP. + 0.0.0.10 PTR ARPANET.Assigned-network-number.Name.YP. + + The second would contain entries of the form: + + $origin Assigned-network-number.Name.YP. + + SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP. + ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP. + + These YPs are not in conflict with the network name support described + in the first half of this RFC since they map between ASSIGNED network + names and numbers, not those allocated by the organizations + themselves. That is, they document the NIC's decisions about + allocating network numbers but do not automatically track any + renaming performed by the new owners. + + As a practical matter, we might want to create both of these domains + to enable users on the Internet to experiment with centrally + maintained support as well as the distributed version, or might want + to implement only the allocated number to name mapping and request + organizations to convert their allocated network names to the network + names described in the distributed model. + +6.3. Operational improvements + + We could imagine that all conversion routines using these YPs might + be instructed to use "YP.<local-domain>" followed by "YP." as a + search list. Thus, if the organization ISI.EDU wished to define + locally meaningful TCP-PORT, it would define the domains: + + <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>. + + + +Mockapetris [Page 11] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + We could add another level of indirection in the YP lookup, defining + the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the + YP tree, rather than being the YP tree directly. This would enable + entries of the form: + + IN-ADDR.Netname.YP. PTR IN-ADDR.ARPA. + + to splice in YPs from other origins or existing spaces. + + Another possibility would be to shorten the RDATA section of the RRs + which map back and forth by deleting the origin. This could be done + either by allowing the domain name in the RDATA portion to not + identify a real domain name, or by defining a new RR which used a + simple text string rather than a domain name. + + Thus, we might replace + + $origin Assigned-network-number.Name.YP. + + SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP. + ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP. + + with + + $origin Assigned-network-number.Name.YP. + + SATNET. PTR 0.0.0.4. + ARPANET. PTR 0.0.0.10. + + or + + $origin Assigned-network-number.Name.YP. + + SATNET. PTT "0.0.0.4" + ARPANET. PTT "0.0.0.10" + + where PTT is a new type whose RDATA section is a text string. + +7. ACKNOWLEDGMENTS + + Drew Perkins, Mark Lottor, and Rob Austein contributed several of the + ideas in this RFC. Numerous contributions, criticisms, and + compromises were produced in the IETF Domain working group and the + NAMEDROPPERS mailing list. + + + + + + + +Mockapetris [Page 12] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + +8. REFERENCES + + [HR] Braden, B., editor, "Requirements for Internet Hosts", + RFC in preparation. + + [ISO 3166] ISO, "Codes for the Representation of Names of + Countries", 1981. + + [RFC 882] Mockapetris, P., "Domain names - Concepts and + Facilities", RFC 882, USC/Information Sciences Institute, + November 1983. + + Superseded by RFC 1034. + + [RFC 883] Mockapetris, P.,"Domain names - Implementation and + Specification", RFC 883, USC/Information Sciences + Institute, November 1983. + + Superceeded by RFC 1035. + + [RFC 920] Postel, J. and J. Reynolds, "Domain Requirements", RFC + 920, October 1984. + + Explains the naming scheme for top level domains. + + [RFC 952] Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet + Host Table Specification", RFC 952, SRI, October 1985. + + Specifies the format of HOSTS.TXT, the host/address table + replaced by the DNS + + [RFC 973] Mockapetris, P., "Domain System Changes and + Observations", RFC 973, USC/Information Sciences + Institute, January 1986. + + Describes changes to RFCs 882 and 883 and reasons for + them. + + [RFC 974] Partridge, C., "Mail routing and the domain system", RFC + 974, CSNET CIC BBN Labs, January 1986. + + Describes the transition from HOSTS.TXT based mail + addressing to the more powerful MX system used with the + domain system. + + + + + + + +Mockapetris [Page 13] + +RFC 1101 DNS Encoding of Network Names and Other Types April 1989 + + + [RFC 997] Reynolds, J., and J. Postel, "Internet Numbers", RFC 997, + USC/Information Sciences Institute, March 1987 + + Contains network numbers, autonomous system numbers, etc. + + [RFC 1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC + 1010, USC/Information Sciences Institute, May 1987 + + Contains socket numbers and mnemonics for host names, + operating systems, etc. + + + [RFC 1034] Mockapetris, P., "Domain names - Concepts and + Facilities", RFC 1034, USC/Information Sciences + Institute, November 1987. + + Introduction/overview of the DNS. + + [RFC 1035] Mockapetris, P., "Domain names - Implementation and + Specification", RFC 1035, USC/Information Sciences + Institute, November 1987. + + DNS implementation instructions. + +Author's Address: + + Paul Mockapetris + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292 + + Phone: (213) 822-1511 + + Email: PVM@ISI.EDU + + + + + + + + + + + + + + + + + +Mockapetris [Page 14] +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc1183.txt b/Documentation/en/rfc/rfc1183.txt new file mode 100644 index 00000000..6f080448 --- /dev/null +++ b/Documentation/en/rfc/rfc1183.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group C. Everhart +Request for Comments: 1183 Transarc +Updates: RFCs 1034, 1035 L. Mamakos + University of Maryland + R. Ullmann + Prime Computer + P. Mockapetris, Editor + ISI + October 1990 + + + New DNS RR Definitions + +Status of this Memo + + This memo defines five new DNS types for experimental purposes. This + RFC describes an Experimental Protocol for the Internet community, + and requests discussion and suggestions for improvements. + Distribution of this memo is unlimited. + +Table of Contents + + Introduction.................................................... 1 + 1. AFS Data Base location....................................... 2 + 2. Responsible Person........................................... 3 + 2.1. Identification of the guilty party......................... 3 + 2.2. The Responsible Person RR.................................. 4 + 3. X.25 and ISDN addresses, Route Binding....................... 6 + 3.1. The X25 RR................................................. 6 + 3.2. The ISDN RR................................................ 7 + 3.3. The Route Through RR....................................... 8 + REFERENCES and BIBLIOGRAPHY..................................... 9 + Security Considerations......................................... 10 + Authors' Addresses.............................................. 11 + +Introduction + + This RFC defines the format of new Resource Records (RRs) for the + Domain Name System (DNS), and reserves corresponding DNS type + mnemonics and numerical codes. The definitions are in three + independent sections: (1) location of AFS database servers, (2) + location of responsible persons, and (3) representation of X.25 and + ISDN addresses and route binding. All are experimental. + + This RFC assumes that the reader is familiar with the DNS [3,4]. The + data shown is for pedagogical use and does not necessarily reflect + the real Internet. + + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 1] + +RFC 1183 New DNS RR Definitions October 1990 + + +1. AFS Data Base location + + This section defines an extension of the DNS to locate servers both + for AFS (AFS is a registered trademark of Transarc Corporation) and + for the Open Software Foundation's (OSF) Distributed Computing + Environment (DCE) authenticated naming system using HP/Apollo's NCA, + both to be components of the OSF DCE. The discussion assumes that + the reader is familiar with AFS [5] and NCA [6]. + + The AFS (originally the Andrew File System) system uses the DNS to + map from a domain name to the name of an AFS cell database server. + The DCE Naming service uses the DNS for a similar function: mapping + from the domain name of a cell to authenticated name servers for that + cell. The method uses a new RR type with mnemonic AFSDB and type + code of 18 (decimal). + + AFSDB has the following format: + + <owner> <ttl> <class> AFSDB <subtype> <hostname> + + Both RDATA fields are required in all AFSDB RRs. The <subtype> field + is a 16 bit integer. The <hostname> field is a domain name of a host + that has a server for the cell named by the owner name of the RR. + + The format of the AFSDB RR is class insensitive. AFSDB records cause + type A additional section processing for <hostname>. This, in fact, + is the rationale for using a new type code, rather than trying to + build the same functionality with TXT RRs. + + Note that the format of AFSDB in a master file is identical to MX. + For purposes of the DNS itself, the subtype is merely an integer. + The present subtype semantics are discussed below, but changes are + possible and will be announced in subsequent RFCs. + + In the case of subtype 1, the host has an AFS version 3.0 Volume + Location Server for the named AFS cell. In the case of subtype 2, + the host has an authenticated name server holding the cell-root + directory node for the named DCE/NCA cell. + + The use of subtypes is motivated by two considerations. First, the + space of DNS RR types is limited. Second, the services provided are + sufficiently distinct that it would continue to be confusing for a + client to attempt to connect to a cell's servers using the protocol + for one service, if the cell offered only the other service. + + As an example of the use of this RR, suppose that the Toaster + Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE. Their + cell, named toaster.com, has three "AFS 3.0 cell database server" + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 2] + +RFC 1183 New DNS RR Definitions October 1990 + + + machines: bigbird.toaster.com, ernie.toaster.com, and + henson.toaster.com. These three machines would be listed in three + AFSDB RRs. These might appear in a master file as: + + toaster.com. AFSDB 1 bigbird.toaster.com. + toaster.com. AFSDB 1 ernie.toaster.com. + toaster.com. AFSDB 1 henson.toaster.com. + + As another example use of this RR, suppose that Femto College (domain + name femto.edu) has deployed DCE, and that their DCE cell root + directory is served by processes running on green.femto.edu and + turquoise.femto.edu. Furthermore, their DCE file servers also run + AFS 3.0-compatible volume location servers, on the hosts + turquoise.femto.edu and orange.femto.edu. These machines would be + listed in four AFSDB RRs, which might appear in a master file as: + + femto.edu. AFSDB 2 green.femto.edu. + femto.edu. AFSDB 2 turquoise.femto.edu. + femto.edu. AFSDB 1 turquoise.femto.edu. + femto.edu. AFSDB 1 orange.femto.edu. + +2. Responsible Person + + The purpose of this section is to provide a standard method for + associating responsible person identification to any name in the DNS. + + The domain name system functions as a distributed database which + contains many different form of information. For a particular name + or host, you can discover it's Internet address, mail forwarding + information, hardware type and operating system among others. + + A key aspect of the DNS is that the tree-structured namespace can be + divided into pieces, called zones, for purposes of distributing + control and responsibility. The responsible person for zone database + purposes is named in the SOA RR for that zone. This section + describes an extension which allows different responsible persons to + be specified for different names in a zone. + +2.1. Identification of the guilty party + + Often it is desirable to be able to identify the responsible entity + for a particular host. When that host is down or malfunctioning, it + is difficult to contact those parties which might resolve or repair + the host. Mail sent to POSTMASTER may not reach the person in a + timely fashion. If the host is one of a multitude of workstations, + there may be no responsible person which can be contacted on that + host. + + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 3] + +RFC 1183 New DNS RR Definitions October 1990 + + + The POSTMASTER mailbox on that host continues to be a good contact + point for mail problems, and the zone contact in the SOA record for + database problem, but the RP record allows us to associate a mailbox + to entities that don't receive mail or are not directly connected + (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to + point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the + ISI zone administrator have a clue about fixing gateways). + +2.2. The Responsible Person RR + + The method uses a new RR type with mnemonic RP and type code of 17 + (decimal). + + RP has the following format: + + <owner> <ttl> <class> RP <mbox-dname> <txt-dname> + + Both RDATA fields are required in all RP RRs. + + The first field, <mbox-dname>, is a domain name that specifies the + mailbox for the responsible person. Its format in master files uses + the DNS convention for mailbox encoding, identical to that used for + the RNAME mailbox field in the SOA RR. The root domain name (just + ".") may be specified for <mbox-dname> to indicate that no mailbox is + available. + + The second field, <txt-dname>, is a domain name for which TXT RR's + exist. A subsequent query can be performed to retrieve the + associated TXT resource records at <txt-dname>. This provides a + level of indirection so that the entity can be referred to from + multiple places in the DNS. The root domain name (just ".") may be + specified for <txt-dname> to indicate that the TXT_DNAME is absent, + and no associated TXT RR exists. + + The format of the RP RR is class insensitive. RP records cause no + additional section processing. (TXT additional section processing + for <txt-dname> is allowed as an option, but only if it is disabled + for the root, i.e., "."). + + The Responsible Person RR can be associated with any node in the + Domain Name System hierarchy, not just at the leaves of the tree. + + The TXT RR associated with the TXT_DNAME contain free format text + suitable for humans. Refer to [4] for more details on the TXT RR. + + Multiple RP records at a single name may be present in the database. + They should have identical TTLs. + + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 4] + +RFC 1183 New DNS RR Definitions October 1990 + + + EXAMPLES + + Some examples of how the RP record might be used. + + sayshell.umd.edu. A 128.8.1.14 + MX 10 sayshell.umd.edu. + HINFO NeXT UNIX + WKS 128.8.1.14 tcp ftp telnet smtp + RP louie.trantor.umd.edu. LAM1.people.umd.edu. + + LAM1.people.umd.edu. TXT ( + "Louis A. Mamakos, (301) 454-2946, don't call me at home!" ) + + In this example, the responsible person's mailbox for the host + SAYSHELL.UMD.EDU is louie@trantor.umd.edu. The TXT RR at + LAM1.people.umd.edu provides additional information and advice. + + TERP.UMD.EDU. A 128.8.10.90 + MX 10 128.8.10.90 + HINFO MICROVAX-II UNIX + WKS 128.8.10.90 udp domain + WKS 128.8.10.90 tcp ftp telnet smtp domain + RP louie.trantor.umd.edu. LAM1.people.umd.edu. + RP root.terp.umd.edu. ops.CS.UMD.EDU. + + TRANTOR.UMD.EDU. A 128.8.10.14 + MX 10 trantor.umd.edu. + HINFO MICROVAX-II UNIX + WKS 128.8.10.14 udp domain + WKS 128.8.10.14 tcp ftp telnet smtp domain + RP louie.trantor.umd.edu. LAM1.people.umd.edu. + RP petry.netwolf.umd.edu. petry.people.UMD.EDU. + RP root.trantor.umd.edu. ops.CS.UMD.EDU. + RP gregh.sunset.umd.edu. . + + LAM1.people.umd.edu. TXT "Louis A. Mamakos (301) 454-2946" + petry.people.umd.edu. TXT "Michael G. Petry (301) 454-2946" + ops.CS.UMD.EDU. TXT "CS Operations Staff (301) 454-2943" + + This set of resource records has two hosts, TRANTOR.UMD.EDU and + TERP.UMD.EDU, as well as a number of TXT RRs. Note that TERP.UMD.EDU + and TRANTOR.UMD.EDU both reference the same pair of TXT resource + records, although the mail box names (root.terp.umd.edu and + root.trantor.umd.edu) differ. + + Here, we obviously care much more if the machine flakes out, as we've + specified four persons which might want to be notified of problems or + other events involving TRANTOR.UMD.EDU. In this example, the last RP + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 5] + +RFC 1183 New DNS RR Definitions October 1990 + + + RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu), + but no associated TXT RR. + +3. X.25 and ISDN addresses, Route Binding + + This section describes an experimental representation of X.25 and + ISDN addresses in the DNS, as well as a route binding method, + analogous to the MX for mail routing, for very large scale networks. + + There are several possible uses, all experimental at this time. + First, the RRs provide simple documentation of the correct addresses + to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12]. + + The RRs could also be used automatically by an internet network-layer + router, typically IP. The procedure would be to map IP address to + domain name, then name to canonical name if needed, then following RT + records, and finally attempting an IP/X.25 call to the address found. + Alternately, configured domain names could be resolved to identify IP + to X.25/ISDN bindings for a static but periodically refreshed routing + table. + + This provides a function similar to ARP for wide area non-broadcast + networks that will scale well to a network with hundreds of millions + of hosts. + + Also, a standard address binding reference will facilitate other + experiments in the use of X.25 and ISDN, especially in serious + inter-operability testing. The majority of work in such a test is + establishing the n-squared entries in static tables. + + Finally, the RRs are intended for use in a proposal [13] by one of + the authors for a possible next-generation internet. + +3.1. The X25 RR + + The X25 RR is defined with mnemonic X25 and type code 19 (decimal). + + X25 has the following format: + + <owner> <ttl> <class> X25 <PSDN-address> + + <PSDN-address> is required in all X25 RRs. + + <PSDN-address> identifies the PSDN (Public Switched Data Network) + address in the X.121 [10] numbering plan associated with <owner>. + Its format in master files is a <character-string> syntactically + identical to that used in TXT and HINFO. + + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 6] + +RFC 1183 New DNS RR Definitions October 1990 + + + The format of X25 is class insensitive. X25 RRs cause no additional + section processing. + + The <PSDN-address> is a string of decimal digits, beginning with the + 4 digit DNIC (Data Network Identification Code), as specified in + X.121. National prefixes (such as a 0) MUST NOT be used. + + For example: + + Relay.Prime.COM. X25 311061700956 + +3.2. The ISDN RR + + The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal). + + An ISDN (Integrated Service Digital Network) number is simply a + telephone number. The intent of the members of the CCITT is to + upgrade all telephone and data network service to a common service. + + The numbering plan (E.163/E.164) is the same as the familiar + international plan for POTS (an un-official acronym, meaning Plain + Old Telephone Service). In E.166, CCITT says "An E.163/E.164 + telephony subscriber may become an ISDN subscriber without a number + change." + + ISDN has the following format: + + <owner> <ttl> <class> ISDN <ISDN-address> <sa> + + The <ISDN-address> field is required; <sa> is optional. + + <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct + Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and + PSTN (Public Switched Telephone Network) numbering plan. E.163 + defines the country codes, and E.164 the form of the addresses. Its + format in master files is a <character-string> syntactically + identical to that used in TXT and HINFO. + + <sa> specifies the subaddress (SA). The format of <sa> in master + files is a <character-string> syntactically identical to that used in + TXT and HINFO. + + The format of ISDN is class insensitive. ISDN RRs cause no + additional section processing. + + The <ISDN-address> is a string of characters, normally decimal + digits, beginning with the E.163 country code and ending with the DDI + if any. Note that ISDN, in Q.931, permits any IA5 character in the + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 7] + +RFC 1183 New DNS RR Definitions October 1990 + + + general case. + + The <sa> is a string of hexadecimal digits. For digits 0-9, the + concrete encoding in the Q.931 call setup information element is + identical to BCD. + + For example: + + Relay.Prime.COM. IN ISDN 150862028003217 + sh.Prime.COM. IN ISDN 150862028003217 004 + + (Note: "1" is the country code for the North American Integrated + Numbering Area, i.e., the system of "area codes" familiar to people + in those countries.) + + The RR data is the ASCII representation of the digits. It is encoded + as one or two <character-string>s, i.e., count followed by + characters. + + CCITT recommendation E.166 [9] defines prefix escape codes for the + representation of ISDN (E.163/E.164) addresses in X.121, and PSDN + (X.121) addresses in E.164. It specifies that the exact codes are a + "national matter", i.e., different on different networks. A host + connected to the ISDN may be able to use both the X25 and ISDN + addresses, with the local prefix added. + +3.3. The Route Through RR + + The Route Through RR is defined with mnemonic RT and type code 21 + (decimal). + + The RT resource record provides a route-through binding for hosts + that do not have their own direct wide area network addresses. It is + used in much the same way as the MX RR. + + RT has the following format: + + <owner> <ttl> <class> RT <preference> <intermediate-host> + + Both RDATA fields are required in all RT RRs. + + The first field, <preference>, is a 16 bit integer, representing the + preference of the route. Smaller numbers indicate more preferred + routes. + + <intermediate-host> is the domain name of a host which will serve as + an intermediate in reaching the host specified by <owner>. The DNS + RRs associated with <intermediate-host> are expected to include at + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 8] + +RFC 1183 New DNS RR Definitions October 1990 + + + least one A, X25, or ISDN record. + + The format of the RT RR is class insensitive. RT records cause type + X25, ISDN, and A additional section processing for <intermediate- + host>. + + For example, + + sh.prime.com. IN RT 2 Relay.Prime.COM. + IN RT 10 NET.Prime.COM. + *.prime.com. IN RT 90 Relay.Prime.COM. + + When a host is looking up DNS records to attempt to route a datagram, + it first looks for RT records for the destination host, which point + to hosts with address records (A, X25, ISDN) compatible with the wide + area networks available to the host. If it is itself in the set of + RT records, it discards any RTs with preferences higher or equal to + its own. If there are no (remaining) RTs, it can then use address + records of the destination itself. + + Wild-card RTs are used exactly as are wild-card MXs. RT's do not + "chain"; that is, it is not valid to use the RT RRs found for a host + referred to by an RT. + + The concrete encoding is identical to the MX RR. + +REFERENCES and BIBLIOGRAPHY + + [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network + Information Center, SRI International, November 1987. + + [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, + Network Information Center, SRI International, November, 1987. + + [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC + 1034, USC/Information Sciences Institute, November 1987. + + [4] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, USC/Information Sciences Institute, + November 1987. + + [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review, + 7(3), pp. 61-69, March 1989. + + [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall, + 1989. + + [7] International Telegraph and Telephone Consultative Committee, + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 9] + +RFC 1183 New DNS RR Definitions October 1990 + + + "Numbering Plan for the International Telephone Service", CCITT + Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988, + Fascicle II.2 ("Blue Book"). + + [8] International Telegraph and Telephone Consultative Committee, + "Numbering Plan for the ISDN Era", CCITT Recommendations E.164., + IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue + Book"). + + [9] International Telegraph and Telephone Consultative Committee. + "Numbering Plan Interworking in the ISDN Era", CCITT + Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988, + Fascicle II.2 ("Blue Book"). + + [10] International Telegraph and Telephone Consultative Committee, + "International Numbering Plan for the Public Data Networks", + CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne, + 1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978; + amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne, + 1988. + + [11] Korb, J., "Standard for the Transmission of IP datagrams Over + Public Data Networks", RFC 877, Purdue University, September + 1983. + + [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February + 1989. + + [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer + (unpublished), July 1990. + + [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types", + RFC 1101, USC/Information Sciences Institute, April 1989. + +Security Considerations + + Security issues are not addressed in this memo. + + + + + + + + + + + + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 10] + +RFC 1183 New DNS RR Definitions October 1990 + + +Authors' Addresses + + Craig F. Everhart + Transarc Corporation + The Gulf Tower + 707 Grant Street + Pittsburgh, PA 15219 + + Phone: +1 412 338 4467 + + EMail: Craig_Everhart@transarc.com + + + Louis A. Mamakos + Network Infrastructure Group + Computer Science Center + University of Maryland + College Park, MD 20742-2411 + + Phone: +1-301-405-7836 + + Email: louie@Sayshell.UMD.EDU + + + Robert Ullmann 10-30 + Prime Computer, Inc. + 500 Old Connecticut Path + Framingham, MA 01701 + + Phone: +1 508 620 2800 ext 1736 + + Email: Ariel@Relay.Prime.COM + + + Paul Mockapetris + USC Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292 + + Phone: 213-822-1511 + + EMail: pvm@isi.edu + + + + + + + + + +Everhart, Mamakos, Ullmann & Mockapetris [Page 11] +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc1341.txt b/Documentation/en/rfc/rfc1341.txt new file mode 100644 index 00000000..1be6f7d6 --- /dev/null +++ b/Documentation/en/rfc/rfc1341.txt @@ -0,0 +1,5265 @@ + + + + + + + Network Working Group N. Borenstein, Bellcore + Request for Comments: 1341 N. Freed, Innosoft + June 1992 + + + + MIME (Multipurpose Internet Mail Extensions): + + + Mechanisms for Specifying and Describing + the Format of Internet Message Bodies + + + Status of this Memo + + This RFC specifies an IAB standards track protocol for the + Internet community, and requests discussion and suggestions + for improvements. Please refer to the current edition of + the "IAB Official Protocol Standards" for the + standardization state and status of this protocol. + Distribution of this memo is unlimited. + + Abstract + + RFC 822 defines a message representation protocol which + specifies considerable detail about message headers, but + which leaves the message content, or message body, as flat + ASCII text. This document redefines the format of message + bodies to allow multi-part textual and non-textual message + bodies to be represented and exchanged without loss of + information. This is based on earlier work documented in + RFC 934 and RFC 1049, but extends and revises that work. + Because RFC 822 said so little about message bodies, this + document is largely orthogonal to (rather than a revision + of) RFC 822. + + In particular, this document is designed to provide + facilities to include multiple objects in a single message, + to represent body text in character sets other than US- + ASCII, to represent formatted multi-font text messages, to + represent non-textual material such as images and audio + fragments, and generally to facilitate later extensions + defining new types of Internet mail for use by cooperating + mail agents. + + This document does NOT extend Internet mail header fields to + permit anything other than US-ASCII text data. It is + recognized that such extensions are necessary, and they are + the subject of a companion document [RFC -1342]. + + A table of contents appears at the end of this document. + + + + + + + Borenstein & Freed [Page i] + + + + + + + + 1 Introduction + + Since its publication in 1982, RFC 822 [RFC-822] has defined + the standard format of textual mail messages on the + Internet. Its success has been such that the RFC 822 format + has been adopted, wholly or partially, well beyond the + confines of the Internet and the Internet SMTP transport + defined by RFC 821 [RFC-821]. As the format has seen wider + use, a number of limitations have proven increasingly + restrictive for the user community. + + RFC 822 was intended to specify a format for text messages. + As such, non-text messages, such as multimedia messages that + might include audio or images, are simply not mentioned. + Even in the case of text, however, RFC 822 is inadequate for + the needs of mail users whose languages require the use of + character sets richer than US ASCII [US-ASCII]. Since RFC + 822 does not specify mechanisms for mail containing audio, + video, Asian language text, or even text in most European + languages, additional specifications are needed + + One of the notable limitations of RFC 821/822 based mail + systems is the fact that they limit the contents of + electronic mail messages to relatively short lines of + seven-bit ASCII. This forces users to convert any non- + textual data that they may wish to send into seven-bit bytes + representable as printable ASCII characters before invoking + a local mail UA (User Agent, a program with which human + users send and receive mail). Examples of such encodings + currently used in the Internet include pure hexadecimal, + uuencode, the 3-in-4 base 64 scheme specified in RFC 1113, + the Andrew Toolkit Representation [ATK], and many others. + + The limitations of RFC 822 mail become even more apparent as + gateways are designed to allow for the exchange of mail + messages between RFC 822 hosts and X.400 hosts. X.400 [X400] + specifies mechanisms for the inclusion of non-textual body + parts within electronic mail messages. The current + standards for the mapping of X.400 messages to RFC 822 + messages specify that either X.400 non-textual body parts + should be converted to (not encoded in) an ASCII format, or + that they should be discarded, notifying the RFC 822 user + that discarding has occurred. This is clearly undesirable, + as information that a user may wish to receive is lost. + Even though a user's UA may not have the capability of + dealing with the non-textual body part, the user might have + some mechanism external to the UA that can extract useful + information from the body part. Moreover, it does not allow + for the fact that the message may eventually be gatewayed + back into an X.400 message handling system (i.e., the X.400 + message is "tunneled" through Internet mail), where the + non-textual information would definitely become useful + again. + + + + + Borenstein & Freed [Page 1] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + This document describes several mechanisms that combine to + solve most of these problems without introducing any serious + incompatibilities with the existing world of RFC 822 mail. + In particular, it describes: + + 1. A MIME-Version header field, which uses a version number + to declare a message to be conformant with this + specification and allows mail processing agents to + distinguish between such messages and those generated + by older or non-conformant software, which is presumed + to lack such a field. + + 2. A Content-Type header field, generalized from RFC 1049 + [RFC-1049], which can be used to specify the type and + subtype of data in the body of a message and to fully + specify the native representation (encoding) of such + data. + + 2.a. A "text" Content-Type value, which can be used to + represent textual information in a number of + character sets and formatted text description + languages in a standardized manner. + + 2.b. A "multipart" Content-Type value, which can be + used to combine several body parts, possibly of + differing types of data, into a single message. + + 2.c. An "application" Content-Type value, which can be + used to transmit application data or binary data, + and hence, among other uses, to implement an + electronic mail file transfer service. + + 2.d. A "message" Content-Type value, for encapsulating + a mail message. + + 2.e An "image" Content-Type value, for transmitting + still image (picture) data. + + 2.f. An "audio" Content-Type value, for transmitting + audio or voice data. + + 2.g. A "video" Content-Type value, for transmitting + video or moving image data, possibly with audio as + part of the composite video data format. + + 3. A Content-Transfer-Encoding header field, which can be + used to specify an auxiliary encoding that was applied + to the data in order to allow it to pass through mail + transport mechanisms which may have data or character + set limitations. + + 4. Two optional header fields that can be used to further + describe the data in a message body, the Content-ID and + Content-Description header fields. + + + + Borenstein & Freed [Page 2] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + MIME has been carefully designed as an extensible mechanism, + and it is expected that the set of content-type/subtype + pairs and their associated parameters will grow + significantly with time. Several other MIME fields, notably + including character set names, are likely to have new values + defined over time. In order to ensure that the set of such + values is developed in an orderly, well-specified, and + public manner, MIME defines a registration process which + uses the Internet Assigned Numbers Authority (IANA) as a + central registry for such values. Appendix F provides + details about how IANA registration is accomplished. + + Finally, to specify and promote interoperability, Appendix A + of this document provides a basic applicability statement + for a subset of the above mechanisms that defines a minimal + level of "conformance" with this document. + + HISTORICAL NOTE: Several of the mechanisms described in + this document may seem somewhat strange or even baroque at + first reading. It is important to note that compatibility + with existing standards AND robustness across existing + practice were two of the highest priorities of the working + group that developed this document. In particular, + compatibility was always favored over elegance. + + 2 Notations, Conventions, and Generic BNF Grammar + + This document is being published in two versions, one as + plain ASCII text and one as PostScript. The latter is + recommended, though the textual contents are identical. An + Andrew-format copy of this document is also available from + the first author (Borenstein). + + Although the mechanisms specified in this document are all + described in prose, most are also described formally in the + modified BNF notation of RFC 822. Implementors will need to + be familiar with this notation in order to understand this + specification, and are referred to RFC 822 for a complete + explanation of the modified BNF notation. + + Some of the modified BNF in this document makes reference to + syntactic entities that are defined in RFC 822 and not in + this document. A complete formal grammar, then, is obtained + by combining the collected grammar appendix of this document + with that of RFC 822. + + The term CRLF, in this document, refers to the sequence of + the two ASCII characters CR (13) and LF (10) which, taken + together, in this order, denote a line break in RFC 822 + mail. + + The term "character set", wherever it is used in this + document, refers to a coded character set, in the sense of + ISO character set standardization work, and must not be + + + + Borenstein & Freed [Page 3] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + misinterpreted as meaning "a set of characters." + + The term "message", when not further qualified, means either + the (complete or "top-level") message being transferred on a + network, or a message encapsulated in a body of type + "message". + + The term "body part", in this document, means one of the + parts of the body of a multipart entity. A body part has a + header and a body, so it makes sense to speak about the body + of a body part. + + The term "entity", in this document, means either a message + or a body part. All kinds of entities share the property + that they have a header and a body. + + The term "body", when not further qualified, means the body + of an entity, that is the body of either a message or of a + body part. + + Note : the previous four definitions are clearly circular. + This is unavoidable, since the overal structure of a MIME + message is indeed recursive. + + In this document, all numeric and octet values are given in + decimal notation. + + It must be noted that Content-Type values, subtypes, and + parameter names as defined in this document are case- + insensitive. However, parameter values are case-sensitive + unless otherwise specified for the specific parameter. + + FORMATTING NOTE: This document has been carefully formatted + for ease of reading. The PostScript version of this + document, in particular, places notes like this one, which + may be skipped by the reader, in a smaller, italicized, + font, and indents it as well. In the text version, only the + indentation is preserved, so if you are reading the text + version of this you might consider using the PostScript + version instead. However, all such notes will be indented + and preceded by "NOTE:" or some similar introduction, even + in the text version. + + The primary purpose of these non-essential notes is to + convey information about the rationale of this document, or + to place this document in the proper historical or + evolutionary context. Such information may be skipped by + those who are focused entirely on building a compliant + implementation, but may be of use to those who wish to + understand why this document is written as it is. + + For ease of recognition, all BNF definitions have been + placed in a fixed-width font in the PostScript version of + this document. + + + + Borenstein & Freed [Page 4] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 3 The MIME-Version Header Field + + Since RFC 822 was published in 1982, there has really been + only one format standard for Internet messages, and there + has been little perceived need to declare the format + standard in use. This document is an independent document + that complements RFC 822. Although the extensions in this + document have been defined in such a way as to be compatible + with RFC 822, there are still circumstances in which it + might be desirable for a mail-processing agent to know + whether a message was composed with the new standard in + mind. + + Therefore, this document defines a new header field, "MIME- + Version", which is to be used to declare the version of the + Internet message body format standard in use. + + Messages composed in accordance with this document MUST + include such a header field, with the following verbatim + text: + + MIME-Version: 1.0 + + The presence of this header field is an assertion that the + message has been composed in compliance with this document. + + Since it is possible that a future document might extend the + message format standard again, a formal BNF is given for the + content of the MIME-Version field: + + MIME-Version := text + + Thus, future format specifiers, which might replace or + extend "1.0", are (minimally) constrained by the definition + of "text", which appears in RFC 822. + + Note that the MIME-Version header field is required at the + top level of a message. It is not required for each body + part of a multipart entity. It is required for the embedded + headers of a body of type "message" if and only if the + embedded message is itself claimed to be MIME-compliant. + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 5] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 4 The Content-Type Header Field + + The purpose of the Content-Type field is to describe the + data contained in the body fully enough that the receiving + user agent can pick an appropriate agent or mechanism to + present the data to the user, or otherwise deal with the + data in an appropriate manner. + + HISTORICAL NOTE: The Content-Type header field was first + defined in RFC 1049. RFC 1049 Content-types used a simpler + and less powerful syntax, but one that is largely compatible + with the mechanism given here. + + The Content-Type header field is used to specify the nature + of the data in the body of an entity, by giving type and + subtype identifiers, and by providing auxiliary information + that may be required for certain types. After the type and + subtype names, the remainder of the header field is simply a + set of parameters, specified in an attribute/value notation. + The set of meaningful parameters differs for the different + types. The ordering of parameters is not significant. + Among the defined parameters is a "charset" parameter by + which the character set used in the body may be declared. + Comments are allowed in accordance with RFC 822 rules for + structured header fields. + + In general, the top-level Content-Type is used to declare + the general type of data, while the subtype specifies a + specific format for that type of data. Thus, a Content-Type + of "image/xyz" is enough to tell a user agent that the data + is an image, even if the user agent has no knowledge of the + specific image format "xyz". Such information can be used, + for example, to decide whether or not to show a user the raw + data from an unrecognized subtype -- such an action might be + reasonable for unrecognized subtypes of text, but not for + unrecognized subtypes of image or audio. For this reason, + registered subtypes of audio, image, text, and video, should + not contain embedded information that is really of a + different type. Such compound types should be represented + using the "multipart" or "application" types. + + Parameters are modifiers of the content-subtype, and do not + fundamentally affect the requirements of the host system. + Although most parameters make sense only with certain + content-types, others are "global" in the sense that they + might apply to any subtype. For example, the "boundary" + parameter makes sense only for the "multipart" content-type, + but the "charset" parameter might make sense with several + content-types. + + An initial set of seven Content-Types is defined by this + document. This set of top-level names is intended to be + substantially complete. It is expected that additions to + the larger set of supported types can generally be + + + + Borenstein & Freed [Page 6] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + accomplished by the creation of new subtypes of these + initial types. In the future, more top-level types may be + defined only by an extension to this standard. If another + primary type is to be used for any reason, it must be given + a name starting with "X-" to indicate its non-standard + status and to avoid a potential conflict with a future + official name. + + In the Extended BNF notation of RFC 822, a Content-Type + header field value is defined as follows: + + Content-Type := type "/" subtype *[";" parameter] + + type := "application" / "audio" + / "image" / "message" + / "multipart" / "text" + / "video" / x-token + + x-token := <The two characters "X-" followed, with no + intervening white space, by any token> + + subtype := token + + parameter := attribute "=" value + + attribute := token + + value := token / quoted-string + + token := 1*<any CHAR except SPACE, CTLs, or tspecials> + + tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in + / "," / ";" / ":" / "\" / <"> ; quoted-string, + / "/" / "[" / "]" / "?" / "." ; to use within + / "=" ; parameter values + + Note that the definition of "tspecials" is the same as the + RFC 822 definition of "specials" with the addition of the + three characters "/", "?", and "=". + + Note also that a subtype specification is MANDATORY. There + are no default subtypes. + + The type, subtype, and parameter names are not case + sensitive. For example, TEXT, Text, and TeXt are all + equivalent. Parameter values are normally case sensitive, + but certain parameters are interpreted to be case- + insensitive, depending on the intended use. (For example, + multipart boundaries are case-sensitive, but the "access- + type" for message/External-body is not case-sensitive.) + + Beyond this syntax, the only constraint on the definition of + subtype names is the desire that their uses must not + conflict. That is, it would be undesirable to have two + + + + Borenstein & Freed [Page 7] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + different communities using "Content-Type: + application/foobar" to mean two different things. The + process of defining new content-subtypes, then, is not + intended to be a mechanism for imposing restrictions, but + simply a mechanism for publicizing the usages. There are, + therefore, two acceptable mechanisms for defining new + Content-Type subtypes: + + 1. Private values (starting with "X-") may be + defined bilaterally between two cooperating + agents without outside registration or + standardization. + + 2. New standard values must be documented, + registered with, and approved by IANA, as + described in Appendix F. Where intended for + public use, the formats they refer to must + also be defined by a published specification, + and possibly offered for standardization. + + The seven standard initial predefined Content-Types are + detailed in the bulk of this document. They are: + + text -- textual information. The primary subtype, + "plain", indicates plain (unformatted) text. No + special software is required to get the full + meaning of the text, aside from support for the + indicated character set. Subtypes are to be used + for enriched text in forms where application + software may enhance the appearance of the text, + but such software must not be required in order to + get the general idea of the content. Possible + subtypes thus include any readable word processor + format. A very simple and portable subtype, + richtext, is defined in this document. + multipart -- data consisting of multiple parts of + independent data types. Four initial subtypes + are defined, including the primary "mixed" + subtype, "alternative" for representing the same + data in multiple formats, "parallel" for parts + intended to be viewed simultaneously, and "digest" + for multipart entities in which each part is of + type "message". + message -- an encapsulated message. A body of + Content-Type "message" is itself a fully formatted + RFC 822 conformant message which may contain its + own different Content-Type header field. The + primary subtype is "rfc822". The "partial" + subtype is defined for partial messages, to permit + the fragmented transmission of bodies that are + thought to be too large to be passed through mail + transport facilities. Another subtype, + "External-body", is defined for specifying large + bodies by reference to an external data source. + + + + Borenstein & Freed [Page 8] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + image -- image data. Image requires a display device + (such as a graphical display, a printer, or a FAX + machine) to view the information. Initial + subtypes are defined for two widely-used image + formats, jpeg and gif. + audio -- audio data, with initial subtype "basic". + Audio requires an audio output device (such as a + speaker or a telephone) to "display" the contents. + video -- video data. Video requires the capability to + display moving images, typically including + specialized hardware and software. The initial + subtype is "mpeg". + application -- some other kind of data, typically + either uninterpreted binary data or information to + be processed by a mail-based application. The + primary subtype, "octet-stream", is to be used in + the case of uninterpreted binary data, in which + case the simplest recommended action is to offer + to write the information into a file for the user. + Two additional subtypes, "ODA" and "PostScript", + are defined for transporting ODA and PostScript + documents in bodies. Other expected uses for + "application" include spreadsheets, data for + mail-based scheduling systems, and languages for + "active" (computational) email. (Note that active + email entails several securityconsiderations, + which are discussed later in this memo, + particularly in the context of + application/PostScript.) + + Default RFC 822 messages are typed by this protocol as plain + text in the US-ASCII character set, which can be explicitly + specified as "Content-type: text/plain; charset=us-ascii". + If no Content-Type is specified, either by error or by an + older user agent, this default is assumed. In the presence + of a MIME-Version header field, a receiving User Agent can + also assume that plain US-ASCII text was the sender's + intent. In the absence of a MIME-Version specification, + plain US-ASCII text must still be assumed, but the sender's + intent might have been otherwise. + + RATIONALE: In the absence of any Content-Type header field + or MIME-Version header field, it is impossible to be certain + that a message is actually text in the US-ASCII character + set, since it might well be a message that, using the + conventions that predate this document, includes text in + another character set or non-textual data in a manner that + cannot be automatically recognized (e.g., a uuencoded + compressed UNIX tar file). Although there is no fully + acceptable alternative to treating such untyped messages as + "text/plain; charset=us-ascii", implementors should remain + aware that if a message lacks both the MIME-Version and the + Content-Type header fields, it may in practice contain + almost anything. + + + + Borenstein & Freed [Page 9] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + It should be noted that the list of Content-Type values + given here may be augmented in time, via the mechanisms + described above, and that the set of subtypes is expected to + grow substantially. + + When a mail reader encounters mail with an unknown Content- + type value, it should generally treat it as equivalent to + "application/octet-stream", as described later in this + document. + + 5 The Content-Transfer-Encoding Header Field + + Many Content-Types which could usefully be transported via + email are represented, in their "natural" format, as 8-bit + character or binary data. Such data cannot be transmitted + over some transport protocols. For example, RFC 821 + restricts mail messages to 7-bit US-ASCII data with 1000 + character lines. + + It is necessary, therefore, to define a standard mechanism + for re-encoding such data into a 7-bit short-line format. + This document specifies that such encodings will be + indicated by a new "Content-Transfer-Encoding" header field. + The Content-Transfer-Encoding field is used to indicate the + type of transformation that has been used in order to + represent the body in an acceptable manner for transport. + + Unlike Content-Types, a proliferation of Content-Transfer- + Encoding values is undesirable and unnecessary. However, + establishing only a single Content-Transfer-Encoding + mechanism does not seem possible. There is a tradeoff + between the desire for a compact and efficient encoding of + largely-binary data and the desire for a readable encoding + of data that is mostly, but not entirely, 7-bit data. For + this reason, at least two encoding mechanisms are necessary: + a "readable" encoding and a "dense" encoding. + + The Content-Transfer-Encoding field is designed to specify + an invertible mapping between the "native" representation of + a type of data and a representation that can be readily + exchanged using 7 bit mail transport protocols, such as + those defined by RFC 821 (SMTP). This field has not been + defined by any previous standard. The field's value is a + single token specifying the type of encoding, as enumerated + below. Formally: + + Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" / + "8BIT" / "7BIT" / + "BINARY" / x-token + + These values are not case sensitive. That is, Base64 and + BASE64 and bAsE64 are all equivalent. An encoding type of + 7BIT requires that the body is already in a seven-bit mail- + ready representation. This is the default value -- that is, + + + + Borenstein & Freed [Page 10] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + "Content-Transfer-Encoding: 7BIT" is assumed if the + Content-Transfer-Encoding header field is not present. + + The values "8bit", "7bit", and "binary" all imply that NO + encoding has been performed. However, they are potentially + useful as indications of the kind of data contained in the + object, and therefore of the kind of encoding that might + need to be performed for transmission in a given transport + system. "7bit" means that the data is all represented as + short lines of US-ASCII data. "8bit" means that the lines + are short, but there may be non-ASCII characters (octets + with the high-order bit set). "Binary" means that not only + may non-ASCII characters be present, but also that the lines + are not necessarily short enough for SMTP transport. + + The difference between "8bit" (or any other conceivable + bit-width token) and the "binary" token is that "binary" + does not require adherence to any limits on line length or + to the SMTP CRLF semantics, while the bit-width tokens do + require such adherence. If the body contains data in any + bit-width other than 7-bit, the appropriate bit-width + Content-Transfer-Encoding token must be used (e.g., "8bit" + for unencoded 8 bit wide data). If the body contains binary + data, the "binary" Content-Transfer-Encoding token must be + used. + + NOTE: The distinction between the Content-Transfer-Encoding + values of "binary," "8bit," etc. may seem unimportant, in + that all of them really mean "none" -- that is, there has + been no encoding of the data for transport. However, clear + labeling will be of enormous value to gateways between + future mail transport systems with differing capabilities in + transporting data that do not meet the restrictions of RFC + 821 transport. + + As of the publication of this document, there are no + standardized Internet transports for which it is legitimate + to include unencoded 8-bit or binary data in mail bodies. + Thus there are no circumstances in which the "8bit" or + "binary" Content-Transfer-Encoding is actually legal on the + Internet. However, in the event that 8-bit or binary mail + transport becomes a reality in Internet mail, or when this + document is used in conjunction with any other 8-bit or + binary-capable transport mechanism, 8-bit or binary bodies + should be labeled as such using this mechanism. + + NOTE: The five values defined for the Content-Transfer- + Encoding field imply nothing about the Content-Type other + than the algorithm by which it was encoded or the transport + system requirements if unencoded. + + Implementors may, if necessary, define new Content- + Transfer-Encoding values, but must use an x-token, which is + a name prefixed by "X-" to indicate its non-standard status, + + + + Borenstein & Freed [Page 11] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + e.g., "Content-Transfer-Encoding: x-my-new-encoding". + However, unlike Content-Types and subtypes, the creation of + new Content-Transfer-Encoding values is explicitly and + strongly discouraged, as it seems likely to hinder + interoperability with little potential benefit. Their use + is allowed only as the result of an agreement between + cooperating user agents. + + If a Content-Transfer-Encoding header field appears as part + of a message header, it applies to the entire body of that + message. If a Content-Transfer-Encoding header field + appears as part of a body part's headers, it applies only to + the body of that body part. If an entity is of type + "multipart" or "message", the Content-Transfer-Encoding is + not permitted to have any value other than a bit width + (e.g., "7bit", "8bit", etc.) or "binary". + + It should be noted that email is character-oriented, so that + the mechanisms described here are mechanisms for encoding + arbitrary byte streams, not bit streams. If a bit stream is + to be encoded via one of these mechanisms, it must first be + converted to an 8-bit byte stream using the network standard + bit order ("big-endian"), in which the earlier bits in a + stream become the higher-order bits in a byte. A bit stream + not ending at an 8-bit boundary must be padded with zeroes. + This document provides a mechanism for noting the addition + of such padding in the case of the application Content-Type, + which has a "padding" parameter. + + The encoding mechanisms defined here explicitly encode all + data in ASCII. Thus, for example, suppose an entity has + header fields such as: + + Content-Type: text/plain; charset=ISO-8859-1 + Content-transfer-encoding: base64 + + This should be interpreted to mean that the body is a base64 + ASCII encoding of data that was originally in ISO-8859-1, + and will be in that character set again after decoding. + + The following sections will define the two standard encoding + mechanisms. The definition of new content-transfer- + encodings is explicitly discouraged and should only occur + when absolutely necessary. All content-transfer-encoding + namespace except that beginning with "X-" is explicitly + reserved to the IANA for future use. Private agreements + about content-transfer-encodings are also explicitly + discouraged. + + Certain Content-Transfer-Encoding values may only be used on + certain Content-Types. In particular, it is expressly + forbidden to use any encodings other than "7bit", "8bit", or + "binary" with any Content-Type that recursively includes + other Content-Type fields, notably the "multipart" and + + + + Borenstein & Freed [Page 12] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + "message" Content-Types. All encodings that are desired for + bodies of type multipart or message must be done at the + innermost level, by encoding the actual body that needs to + be encoded. + + NOTE ON ENCODING RESTRICTIONS: Though the prohibition + against using content-transfer-encodings on data of type + multipart or message may seem overly restrictive, it is + necessary to prevent nested encodings, in which data are + passed through an encoding algorithm multiple times, and + must be decoded multiple times in order to be properly + viewed. Nested encodings add considerable complexity to + user agents: aside from the obvious efficiency problems + with such multiple encodings, they can obscure the basic + structure of a message. In particular, they can imply that + several decoding operations are necessary simply to find out + what types of objects a message contains. Banning nested + encodings may complicate the job of certain mail gateways, + but this seems less of a problem than the effect of nested + encodings on user agents. + + NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT- + TRANSFER-ENCODING: It may seem that the Content-Transfer- + Encoding could be inferred from the characteristics of the + Content-Type that is to be encoded, or, at the very least, + that certain Content-Transfer-Encodings could be mandated + for use with specific Content-Types. There are several + reasons why this is not the case. First, given the varying + types of transports used for mail, some encodings may be + appropriate for some Content-Type/transport combinations and + not for others. (For example, in an 8-bit transport, no + encoding would be required for text in certain character + sets, while such encodings are clearly required for 7-bit + SMTP.) Second, certain Content-Types may require different + types of transfer encoding under different circumstances. + For example, many PostScript bodies might consist entirely + of short lines of 7-bit data and hence require little or no + encoding. Other PostScript bodies (especially those using + Level 2 PostScript's binary encoding mechanism) may only be + reasonably represented using a binary transport encoding. + Finally, since Content-Type is intended to be an open-ended + specification mechanism, strict specification of an + association between Content-Types and encodings effectively + couples the specification of an application protocol with a + specific lower-level transport. This is not desirable since + the developers of a Content-Type should not have to be aware + of all the transports in use and what their limitations are. + + NOTE ON TRANSLATING ENCODINGS: The quoted-printable and + base64 encodings are designed so that conversion between + them is possible. The only issue that arises in such a + conversion is the handling of line breaks. When converting + from quoted-printable to base64 a line break must be + converted into a CRLF sequence. Similarly, a CRLF sequence + + + + Borenstein & Freed [Page 13] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + in base64 data should be converted to a quoted-printable + line break, but ONLY when converting text data. + + NOTE ON CANONICAL ENCODING MODEL: There was some + confusion, in earlier drafts of this memo, regarding the + model for when email data was to be converted to canonical + form and encoded, and in particular how this process would + affect the treatment of CRLFs, given that the representation + of newlines varies greatly from system to system. For this + reason, a canonical model for encoding is presented as + Appendix H. + + 5.1 Quoted-Printable Content-Transfer-Encoding + + The Quoted-Printable encoding is intended to represent data + that largely consists of octets that correspond to printable + characters in the ASCII character set. It encodes the data + in such a way that the resulting octets are unlikely to be + modified by mail transport. If the data being encoded are + mostly ASCII text, the encoded form of the data remains + largely recognizable by humans. A body which is entirely + ASCII may also be encoded in Quoted-Printable to ensure the + integrity of the data should the message pass through a + character-translating, and/or line-wrapping gateway. + + In this encoding, octets are to be represented as determined + by the following rules: + + Rule #1: (General 8-bit representation) Any octet, + except those indicating a line break according to the + newline convention of the canonical form of the data + being encoded, may be represented by an "=" followed by + a two digit hexadecimal representation of the octet's + value. The digits of the hexadecimal alphabet, for this + purpose, are "0123456789ABCDEF". Uppercase letters must + be + used when sending hexadecimal data, though a robust + implementation may choose to recognize lowercase + letters on receipt. Thus, for example, the value 12 + (ASCII form feed) can be represented by "=0C", and the + value 61 (ASCII EQUAL SIGN) can be represented by + "=3D". Except when the following rules allow an + alternative encoding, this rule is mandatory. + + Rule #2: (Literal representation) Octets with decimal + values of 33 through 60 inclusive, and 62 through 126, + inclusive, MAY be represented as the ASCII characters + which correspond to those octets (EXCLAMATION POINT + through LESS THAN, and GREATER THAN through TILDE, + respectively). + + Rule #3: (White Space): Octets with values of 9 and 32 + MAY be represented as ASCII TAB (HT) and SPACE + characters, respectively, but MUST NOT be so + + + + Borenstein & Freed [Page 14] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + represented at the end of an encoded line. Any TAB (HT) + or SPACE characters on an encoded line MUST thus be + followed on that line by a printable character. In + particular, an "=" at the end of an encoded line, + indicating a soft line break (see rule #5) may follow + one or more TAB (HT) or SPACE characters. It follows + that an octet with value 9 or 32 appearing at the end + of an encoded line must be represented according to + Rule #1. This rule is necessary because some MTAs + (Message Transport Agents, programs which transport + messages from one user to another, or perform a part of + such transfers) are known to pad lines of text with + SPACEs, and others are known to remove "white space" + characters from the end of a line. Therefore, when + decoding a Quoted-Printable body, any trailing white + space on a line must be deleted, as it will necessarily + have been added by intermediate transport agents. + + Rule #4 (Line Breaks): A line break in a text body + part, independent of what its representation is + following the canonical representation of the data + being encoded, must be represented by a (RFC 822) line + break, which is a CRLF sequence, in the Quoted- + Printable encoding. If isolated CRs and LFs, or LF CR + and CR LF sequences are allowed to appear in binary + data according to the canonical form, they must be + represented using the "=0D", "=0A", "=0A=0D" and + "=0D=0A" notations respectively. + + Note that many implementation may elect to encode the + local representation of various content types directly. + In particular, this may apply to plain text material on + systems that use newline conventions other than CRLF + delimiters. Such an implementation is permissible, but + the generation of line breaks must be generalized to + account for the case where alternate representations of + newline sequences are used. + + Rule #5 (Soft Line Breaks): The Quoted-Printable + encoding REQUIRES that encoded lines be no more than 76 + characters long. If longer lines are to be encoded with + the Quoted-Printable encoding, 'soft' line breaks must + be used. An equal sign as the last character on a + encoded line indicates such a non-significant ('soft') + line break in the encoded text. Thus if the "raw" form + of the line is a single unencoded line that says: + + Now's the time for all folk to come to the aid of + their country. + + This can be represented, in the Quoted-Printable + encoding, as + + + + + + Borenstein & Freed [Page 15] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Now's the time = + for all folk to come= + to the aid of their country. + + This provides a mechanism with which long lines are + encoded in such a way as to be restored by the user + agent. The 76 character limit does not count the + trailing CRLF, but counts all other characters, + including any equal signs. + + Since the hyphen character ("-") is represented as itself in + the Quoted-Printable encoding, care must be taken, when + encapsulating a quoted-printable encoded body in a multipart + entity, to ensure that the encapsulation boundary does not + appear anywhere in the encoded body. (A good strategy is to + choose a boundary that includes a character sequence such as + "=_" which can never appear in a quoted-printable body. See + the definition of multipart messages later in this + document.) + + NOTE: The quoted-printable encoding represents something of + a compromise between readability and reliability in + transport. Bodies encoded with the quoted-printable + encoding will work reliably over most mail gateways, but may + not work perfectly over a few gateways, notably those + involving translation into EBCDIC. (In theory, an EBCDIC + gateway could decode a quoted-printable body and re-encode + it using base64, but such gateways do not yet exist.) A + higher level of confidence is offered by the base64 + Content-Transfer-Encoding. A way to get reasonably reliable + transport through EBCDIC gateways is to also quote the ASCII + characters + + !"#$@[\]^`{|}~ + + according to rule #1. See Appendix B for more information. + + Because quoted-printable data is generally assumed to be + line-oriented, it is to be expected that the breaks between + the lines of quoted printable data may be altered in + transport, in the same manner that plain text mail has + always been altered in Internet mail when passing between + systems with differing newline conventions. If such + alterations are likely to constitute a corruption of the + data, it is probably more sensible to use the base64 + encoding rather than the quoted-printable encoding. + + + + + + + + + + + + Borenstein & Freed [Page 16] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 5.2 Base64 Content-Transfer-Encoding + + The Base64 Content-Transfer-Encoding is designed to + represent arbitrary sequences of octets in a form that is + not humanly readable. The encoding and decoding algorithms + are simple, but the encoded data are consistently only about + 33 percent larger than the unencoded data. This encoding is + based on the one used in Privacy Enhanced Mail applications, + as defined in RFC 1113. The base64 encoding is adapted + from RFC 1113, with one change: base64 eliminates the "*" + mechanism for embedded clear text. + + A 65-character subset of US-ASCII is used, enabling 6 bits + to be represented per printable character. (The extra 65th + character, "=", is used to signify a special processing + function.) + + NOTE: This subset has the important property that it is + represented identically in all versions of ISO 646, + including US ASCII, and all characters in the subset are + also represented identically in all versions of EBCDIC. + Other popular encodings, such as the encoding used by the + UUENCODE utility and the base85 encoding specified as part + of Level 2 PostScript, do not share these properties, and + thus do not fulfill the portability requirements a binary + transport encoding for mail must meet. + + The encoding process represents 24-bit groups of input bits + as output strings of 4 encoded characters. Proceeding from + left to right, a 24-bit input group is formed by + concatenating 3 8-bit input groups. These 24 bits are then + treated as 4 concatenated 6-bit groups, each of which is + translated into a single digit in the base64 alphabet. When + encoding a bit stream via the base64 encoding, the bit + stream must be presumed to be ordered with the most- + significant-bit first. That is, the first bit in the stream + will be the high-order bit in the first byte, and the eighth + bit will be the low-order bit in the first byte, and so on. + + Each 6-bit group is used as an index into an array of 64 + printable characters. The character referenced by the index + is placed in the output string. These characters, identified + in Table 1, below, are selected so as to be universally + representable, and the set excludes characters with + particular significance to SMTP (e.g., ".", "CR", "LF") and + to the encapsulation boundaries defined in this document + (e.g., "-"). + + + + + + + + + + + Borenstein & Freed [Page 17] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Table 1: The Base64 Alphabet + + Value Encoding Value Encoding Value Encoding Value + Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y + + The output stream (encoded bytes) must be represented in + lines of no more than 76 characters each. All line breaks + or other characters not found in Table 1 must be ignored by + decoding software. In base64 data, characters other than + those in Table 1, line breaks, and other white space + probably indicate a transmission error, about which a + warning message or even a message rejection might be + appropriate under some circumstances. + + Special processing is performed if fewer than 24 bits are + available at the end of the data being encoded. A full + encoding quantum is always completed at the end of a body. + When fewer than 24 input bits are available in an input + group, zero bits are added (on the right) to form an + integral number of 6-bit groups. Output character positions + which are not required to represent actual input data are + set to the character "=". Since all base64 input is an + integral number of octets, only the following cases can + arise: (1) the final quantum of encoding input is an + integral multiple of 24 bits; here, the final unit of + encoded output will be an integral multiple of 4 characters + with no "=" padding, (2) the final quantum of encoding input + is exactly 8 bits; here, the final unit of encoded output + will be two characters followed by two "=" padding + characters, or (3) the final quantum of encoding input is + exactly 16 bits; here, the final unit of encoded output will + be three characters followed by one "=" padding character. + + Care must be taken to use the proper octets for line breaks + if base64 encoding is applied directly to text material that + has not been converted to canonical form. In particular, + text line breaks should be converted into CRLF sequences + + + + Borenstein & Freed [Page 18] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + prior to base64 encoding. The important thing to note is + that this may be done directly by the encoder rather than in + a prior canonicalization step in some implementations. + + NOTE: There is no need to worry about quoting apparent + encapsulation boundaries within base64-encoded parts of + multipart entities because no hyphen characters are used in + the base64 encoding. + + 6 Additional Optional Content- Header Fields + + 6.1 Optional Content-ID Header Field + + In constructing a high-level user agent, it may be desirable + to allow one body to make reference to another. + Accordingly, bodies may be labeled using the "Content-ID" + header field, which is syntactically identical to the + "Message-ID" header field: + + Content-ID := msg-id + + Like the Message-ID values, Content-ID values must be + generated to be as unique as possible. + + 6.2 Optional Content-Description Header Field + + The ability to associate some descriptive information with a + given body is often desirable. For example, it may be useful + to mark an "image" body as "a picture of the Space Shuttle + Endeavor." Such text may be placed in the Content- + Description header field. + + Content-Description := *text + + The description is presumed to be given in the US-ASCII + character set, although the mechanism specified in [RFC- + 1342] may be used for non-US-ASCII Content-Description + values. + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 19] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 7 The Predefined Content-Type Values + + This document defines seven initial Content-Type values and + an extension mechanism for private or experimental types. + Further standard types must be defined by new published + specifications. It is expected that most innovation in new + types of mail will take place as subtypes of the seven types + defined here. The most essential characteristics of the + seven content-types are summarized in Appendix G. + + 7.1 The Text Content-Type + + The text Content-Type is intended for sending material which + is principally textual in form. It is the default Content- + Type. A "charset" parameter may be used to indicate the + character set of the body text. The primary subtype of text + is "plain". This indicates plain (unformatted) text. The + default Content-Type for Internet mail is "text/plain; + charset=us-ascii". + + Beyond plain text, there are many formats for representing + what might be known as "extended text" -- text with embedded + formatting and presentation information. An interesting + characteristic of many such representations is that they are + to some extent readable even without the software that + interprets them. It is useful, then, to distinguish them, + at the highest level, from such unreadable data as images, + audio, or text represented in an unreadable form. In the + absence of appropriate interpretation software, it is + reasonable to show subtypes of text to the user, while it is + not reasonable to do so with most nontextual data. + + Such formatted textual data should be represented using + subtypes of text. Plausible subtypes of text are typically + given by the common name of the representation format, e.g., + "text/richtext". + + 7.1.1 The charset parameter + + A critical parameter that may be specified in the Content- + Type field for text data is the character set. This is + specified with a "charset" parameter, as in: + + Content-type: text/plain; charset=us-ascii + + Unlike some other parameter values, the values of the + charset parameter are NOT case sensitive. The default + character set, which must be assumed in the absence of a + charset parameter, is US-ASCII. + + An initial list of predefined character set names can be + found at the end of this section. Additional character sets + may be registered with IANA as described in Appendix F, + although the standardization of their use requires the usual + + + + Borenstein & Freed [Page 20] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + IAB review and approval. Note that if the specified + character set includes 8-bit data, a Content-Transfer- + Encoding header field and a corresponding encoding on the + data are required in order to transmit the body via some + mail transfer protocols, such as SMTP. + + The default character set, US-ASCII, has been the subject of + some confusion and ambiguity in the past. Not only were + there some ambiguities in the definition, there have been + wide variations in practice. In order to eliminate such + ambiguity and variations in the future, it is strongly + recommended that new user agents explicitly specify a + character set via the Content-Type header field. "US-ASCII" + does not indicate an arbitrary seven-bit character code, but + specifies that the body uses character coding that uses the + exact correspondence of codes to characters specified in + ASCII. National use variations of ISO 646 [ISO-646] are NOT + ASCII and their use in Internet mail is explicitly + discouraged. The omission of the ISO 646 character set is + deliberate in this regard. The character set name of "US- + ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only. + The character set name "ASCII" is reserved and must not be + used for any purpose. + + NOTE: RFC 821 explicitly specifies "ASCII", and references + an earlier version of the American Standard. Insofar as one + of the purposes of specifying a Content-Type and character + set is to permit the receiver to unambiguously determine how + the sender intended the coded message to be interpreted, + assuming anything other than "strict ASCII" as the default + would risk unintentional and incompatible changes to the + semantics of messages now being transmitted. This also + implies that messages containing characters coded according + to national variations on ISO 646, or using code-switching + procedures (e.g., those of ISO 2022), as well as 8-bit or + multiple octet character encodings MUST use an appropriate + character set specification to be consistent with this + specification. + + The complete US-ASCII character set is listed in [US-ASCII]. + Note that the control characters including DEL (0-31, 127) + have no defined meaning apart from the combination CRLF + (ASCII values 13 and 10) indicating a new line. Two of the + characters have de facto meanings in wide use: FF (12) often + means "start subsequent text on the beginning of a new + page"; and TAB or HT (9) often (though not always) means + "move the cursor to the next available column after the + current position where the column number is a multiple of 8 + (counting the first column as column 0)." Apart from this, + any use of the control characters or DEL in a body must be + part of a private agreement between the sender and + recipient. Such private agreements are discouraged and + should be replaced by the other capabilities of this + document. + + + + Borenstein & Freed [Page 21] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + NOTE: Beyond US-ASCII, an enormous proliferation of + character sets is possible. It is the opinion of the IETF + working group that a large number of character sets is NOT a + good thing. We would prefer to specify a single character + set that can be used universally for representing all of the + world's languages in electronic mail. Unfortunately, + existing practice in several communities seems to point to + the continued use of multiple character sets in the near + future. For this reason, we define names for a small number + of character sets for which a strong constituent base + exists. It is our hope that ISO 10646 or some other + effort will eventually define a single world character set + which can then be specified for use in Internet mail, but in + the advance of that definition we cannot specify the use of + ISO 10646, Unicode, or any other character set whose + definition is, as of this writing, incomplete. + + The defined charset values are: + + US-ASCII -- as defined in [US-ASCII]. + + ISO-8859-X -- where "X" is to be replaced, as + necessary, for the parts of ISO-8859 [ISO- + 8859]. Note that the ISO 646 character sets + have deliberately been omitted in favor of + their 8859 replacements, which are the + designated character sets for Internet mail. + As of the publication of this document, the + legitimate values for "X" are the digits 1 + through 9. + + Note that the character set used, if anything other than + US-ASCII, must always be explicitly specified in the + Content-Type field. + + No other character set name may be used in Internet mail + without the publication of a formal specification and its + registration with IANA as described in Appendix F, or by + private agreement, in which case the character set name must + begin with "X-". + + Implementors are discouraged from defining new character + sets for mail use unless absolutely necessary. + + The "charset" parameter has been defined primarily for the + purpose of textual data, and is described in this section + for that reason. However, it is conceivable that non- + textual data might also wish to specify a charset value for + some purpose, in which case the same syntax and values + should be used. + + In general, mail-sending software should always use the + "lowest common denominator" character set possible. For + example, if a body contains only US-ASCII characters, it + + + + Borenstein & Freed [Page 22] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + should be marked as being in the US-ASCII character set, not + ISO-8859-1, which, like all the ISO-8859 family of character + sets, is a superset of US-ASCII. More generally, if a + widely-used character set is a subset of another character + set, and a body contains only characters in the widely-used + subset, it should be labeled as being in that subset. This + will increase the chances that the recipient will be able to + view the mail correctly. + + 7.1.2 The Text/plain subtype + + The primary subtype of text is "plain". This indicates + plain (unformatted) text. The default Content-Type for + Internet mail, "text/plain; charset=us-ascii", describes + existing Internet practice, that is, it is the type of body + defined by RFC 822. + + 7.1.3 The Text/richtext subtype + + In order to promote the wider interoperability of simple + formatted text, this document defines an extremely simple + subtype of "text", the "richtext" subtype. This subtype was + designed to meet the following criteria: + + 1. The syntax must be extremely simple to parse, + so that even teletype-oriented mail systems can + easily strip away the formatting information and + leave only the readable text. + + 2. The syntax must be extensible to allow for new + formatting commands that are deemed essential. + + 3. The capabilities must be extremely limited, to + ensure that it can represent no more than is + likely to be representable by the user's primary + word processor. While this limits what can be + sent, it increases the likelihood that what is + sent can be properly displayed. + + 4. The syntax must be compatible with SGML, so + that, with an appropriate DTD (Document Type + Definition, the standard mechanism for defining a + document type using SGML), a general SGML parser + could be made to parse richtext. However, despite + this compatibility, the syntax should be far + simpler than full SGML, so that no SGML knowledge + is required in order to implement it. + + The syntax of "richtext" is very simple. It is assumed, at + the top-level, to be in the US-ASCII character set, unless + of course a different charset parameter was specified in the + Content-type field. All characters represent themselves, + with the exception of the "<" character (ASCII 60), which is + used to mark the beginning of a formatting command. + + + + Borenstein & Freed [Page 23] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Formatting instructions consist of formatting commands + surrounded by angle brackets ("<>", ASCII 60 and 62). Each + formatting command may be no more than 40 characters in + length, all in US-ASCII, restricted to the alphanumeric and + hyphen ("-") characters. Formatting commands may be preceded + by a forward slash or solidus ("/", ASCII 47), making them + negations, and such negations must always exist to balance + the initial opening commands, except as noted below. Thus, + if the formatting command "<bold>" appears at some point, + there must later be a "</bold>" to balance it. There are + only three exceptions to this "balancing" rule: First, the + command "<lt>" is used to represent a literal "<" character. + Second, the command "<nl>" is used to represent a required + line break. (Otherwise, CRLFs in the data are treated as + equivalent to a single SPACE character.) Finally, the + command "<np>" is used to represent a page break. (NOTE: + The 40 character limit on formatting commands does not + include the "<", ">", or "/" characters that might be + attached to such commands.) + + Initially defined formatting commands, not all of which will + be implemented by all richtext implementations, include: + + Bold -- causes the subsequent text to be in a bold + font. + Italic -- causes the subsequent text to be in an italic + font. + Fixed -- causes the subsequent text to be in a fixed + width font. + Smaller -- causes the subsequent text to be in a + smaller font. + Bigger -- causes the subsequent text to be in a bigger + font. + Underline -- causes the subsequent text to be + underlined. + Center -- causes the subsequent text to be centered. + FlushLeft -- causes the subsequent text to be left + justified. + FlushRight -- causes the subsequent text to be right + justified. + Indent -- causes the subsequent text to be indented at + the left margin. + IndentRight -- causes the subsequent text to be + indented at the right margin. + Outdent -- causes the subsequent text to be outdented + at the left margin. + OutdentRight -- causes the subsequent text to be + outdented at the right margin. + SamePage -- causes the subsequent text to be grouped, + if possible, on one page. + Subscript -- causes the subsequent text to be + interpreted as a subscript. + + + + + + Borenstein & Freed [Page 24] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Superscript -- causes the subsequent text to be + interpreted as a superscript. + Heading -- causes the subsequent text to be interpreted + as a page heading. + Footing -- causes the subsequent text to be interpreted + as a page footing. + ISO-8859-X (for any value of X that is legal as a + "charset" parameter) -- causes the subsequent text + to be interpreted as text in the appropriate + character set. + US-ASCII -- causes the subsequent text to be + interpreted as text in the US-ASCII character set. + Excerpt -- causes the subsequent text to be interpreted + as a textual excerpt from another source. + Typically this will be displayed using indentation + and an alternate font, but such decisions are up + to the viewer. + Paragraph -- causes the subsequent text to be + interpreted as a single paragraph, with + appropriate paragraph breaks (typically blank + space) before and after. + Signature -- causes the subsequent text to be + interpreted as a "signature". Some systems may + wish to display signatures in a smaller font or + otherwise set them apart from the main text of the + message. + Comment -- causes the subsequent text to be interpreted + as a comment, and hence not shown to the reader. + No-op -- has no effect on the subsequent text. + lt -- <lt> is replaced by a literal "<" character. No + balancing </lt> is allowed. + nl -- <nl> causes a line break. No balancing </nl> is + allowed. + np -- <np> causes a page break. No balancing </np> is + allowed. + + Each positive formatting command affects all subsequent text + until the matching negative formatting command. Such pairs + of formatting commands must be properly balanced and nested. + Thus, a proper way to describe text in bold italics is: + + <bold><italic>the-text</italic></bold> + + or, alternately, + + <italic><bold>the-text</bold></italic> + + but, in particular, the following is illegal + richtext: + + <bold><italic>the-text</bold></italic> + + NOTE: The nesting requirement for formatting commands + imposes a slightly higher burden upon the composers of + + + + Borenstein & Freed [Page 25] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + richtext bodies, but potentially simplifies richtext + displayers by allowing them to be stack-based. The main + goal of richtext is to be simple enough to make multifont, + formatted email widely readable, so that those with the + capability of sending it will be able to do so with + confidence. Thus slightly increased complexity in the + composing software was deemed a reasonable tradeoff for + simplified reading software. Nonetheless, implementors of + richtext readers are encouraged to follow the general + Internet guidelines of being conservative in what you send + and liberal in what you accept. Those implementations that + can do so are encouraged to deal reasonably with improperly + nested richtext. + + Implementations must regard any unrecognized formatting + command as equivalent to "No-op", thus facilitating future + extensions to "richtext". Private extensions may be defined + using formatting commands that begin with "X-", by analogy + to Internet mail header field names. + + It is worth noting that no special behavior is required for + the TAB (HT) character. It is recommended, however, that, at + least when fixed-width fonts are in use, the common + semantics of the TAB (HT) character should be observed, + namely that it moves to the next column position that is a + multiple of 8. (In other words, if a TAB (HT) occurs in + column n, where the leftmost column is column 0, then that + TAB (HT) should be replaced by 8-(n mod 8) SPACE + characters.) + + Richtext also differentiates between "hard" and "soft" line + breaks. A line break (CRLF) in the richtext data stream is + interpreted as a "soft" line break, one that is included + only for purposes of mail transport, and is to be treated as + white space by richtext interpreters. To include a "hard" + line break (one that must be displayed as such), the "<nl>" + or "<paragraph> formatting constructs should be used. In + general, a soft line break should be treated as white space, + but when soft line breaks immediately follow a <nl> or a + </paragraph> tag they should be ignored rather than treated + as white space. + + Putting all this together, the following "text/richtext" + body fragment: + + <bold>Now</bold> is the time for + <italic>all</italic> good men + <smaller>(and <lt>women>)</smaller> to + <ignoreme></ignoreme> come + + to the aid of their + <nl> + + + + + + Borenstein & Freed [Page 26] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + beloved <nl><nl>country. <comment> Stupid + quote! </comment> -- the end + + represents the following formatted text (which will, no + doubt, look cryptic in the text-only version of this + document): + + Now is the time for all good men (and <women>) to + come to the aid of their + beloved + + country. -- the end + + Richtext conformance: A minimal richtext implementation is + one that simply converts "<lt>" to "<", converts CRLFs to + SPACE, converts <nl> to a newline according to local newline + convention, removes everything between a <comment> command + and the next balancing </comment> command, and removes all + other formatting commands (all text enclosed in angle + brackets). + + NOTE ON THE RELATIONSHIP OF RICHTEXT TO SGML: Richtext is + decidedly not SGML, and must not be used to transport + arbitrary SGML documents. Those who wish to use SGML + document types as a mail transport format must define a new + text or application subtype, e.g., "text/sgml-dtd-whatever" + or "application/sgml-dtd-whatever", depending on the + perceived readability of the DTD in use. Richtext is + designed to be compatible with SGML, and specifically so + that it will be possible to define a richtext DTD if one is + needed. However, this does not imply that arbitrary SGML + can be called richtext, nor that richtext implementors have + any need to understand SGML; the description in this + document is a complete definition of richtext, which is far + simpler than complete SGML. + + NOTE ON THE INTENDED USE OF RICHTEXT: It is recognized that + implementors of future mail systems will want rich text + functionality far beyond that currently defined for + richtext. The intent of richtext is to provide a common + format for expressing that functionality in a form in which + much of it, at least, will be understood by interoperating + software. Thus, in particular, software with a richer + notion of formatted text than richtext can still use + richtext as its basic representation, but can extend it with + new formatting commands and by hiding information specific + to that software system in richtext comments. As such + systems evolve, it is expected that the definition of + richtext will be further refined by future published + specifications, but richtext as defined here provides a + platform on which evolutionary refinements can be based. + + IMPLEMENTATION NOTE: In some environments, it might be + impossible to combine certain richtext formatting commands, + + + + Borenstein & Freed [Page 27] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + whereas in others they might be combined easily. For + example, the combination of <bold> and <italic> might + produce bold italics on systems that support such fonts, but + there exist systems that can make text bold or italicized, + but not both. In such cases, the most recently issued + recognized formatting command should be preferred. + + One of the major goals in the design of richtext was to make + it so simple that even text-only mailers will implement + richtext-to-plain-text translators, thus increasing the + likelihood that multifont text will become "safe" to use + very widely. To demonstrate this simplicity, an extremely + simple 35-line C program that converts richtext input into + plain text output is included in Appendix D. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 28] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 7.2 The Multipart Content-Type + + In the case of multiple part messages, in which one or more + different sets of data are combined in a single body, a + "multipart" Content-Type field must appear in the entity's + header. The body must then contain one or more "body parts," + each preceded by an encapsulation boundary, and the last one + followed by a closing boundary. Each part starts with an + encapsulation boundary, and then contains a body part + consisting of header area, a blank line, and a body area. + Thus a body part is similar to an RFC 822 message in syntax, + but different in meaning. + + A body part is NOT to be interpreted as actually being an + RFC 822 message. To begin with, NO header fields are + actually required in body parts. A body part that starts + with a blank line, therefore, is allowed and is a body part + for which all default values are to be assumed. In such a + case, the absence of a Content-Type header field implies + that the encapsulation is plain US-ASCII text. The only + header fields that have defined meaning for body parts are + those the names of which begin with "Content-". All other + header fields are generally to be ignored in body parts. + Although they should generally be retained in mail + processing, they may be discarded by gateways if necessary. + Such other fields are permitted to appear in body parts but + should not be depended on. "X-" fields may be created for + experimental or private purposes, with the recognition that + the information they contain may be lost at some gateways. + + The distinction between an RFC 822 message and a body part + is subtle, but important. A gateway between Internet and + X.400 mail, for example, must be able to tell the difference + between a body part that contains an image and a body part + that contains an encapsulated message, the body of which is + an image. In order to represent the latter, the body part + must have "Content-Type: message", and its body (after the + blank line) must be the encapsulated message, with its own + "Content-Type: image" header field. The use of similar + syntax facilitates the conversion of messages to body parts, + and vice versa, but the distinction between the two must be + understood by implementors. (For the special case in which + all parts actually are messages, a "digest" subtype is also + defined.) + + As stated previously, each body part is preceded by an + encapsulation boundary. The encapsulation boundary MUST NOT + appear inside any of the encapsulated parts. Thus, it is + crucial that the composing agent be able to choose and + specify the unique boundary that will separate the parts. + + All present and future subtypes of the "multipart" type must + use an identical syntax. Subtypes may differ in their + semantics, and may impose additional restrictions on syntax, + + + + Borenstein & Freed [Page 29] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + but must conform to the required syntax for the multipart + type. This requirement ensures that all conformant user + agents will at least be able to recognize and separate the + parts of any multipart entity, even of an unrecognized + subtype. + + As stated in the definition of the Content-Transfer-Encoding + field, no encoding other than "7bit", "8bit", or "binary" is + permitted for entities of type "multipart". The multipart + delimiters and header fields are always 7-bit ASCII in any + case, and data within the body parts can be encoded on a + part-by-part basis, with Content-Transfer-Encoding fields + for each appropriate body part. + + Mail gateways, relays, and other mail handling agents are + commonly known to alter the top-level header of an RFC 822 + message. In particular, they frequently add, remove, or + reorder header fields. Such alterations are explicitly + forbidden for the body part headers embedded in the bodies + of messages of type "multipart." + + 7.2.1 Multipart: The common syntax + + All subtypes of "multipart" share a common syntax, defined + in this section. A simple example of a multipart message + also appears in this section. An example of a more complex + multipart message is given in Appendix C. + + The Content-Type field for multipart entities requires one + parameter, "boundary", which is used to specify the + encapsulation boundary. The encapsulation boundary is + defined as a line consisting entirely of two hyphen + characters ("-", decimal code 45) followed by the boundary + parameter value from the Content-Type header field. + + NOTE: The hyphens are for rough compatibility with the + earlier RFC 934 method of message encapsulation, and for + ease of searching for the boundaries in some + implementations. However, it should be noted that multipart + messages are NOT completely compatible with RFC 934 + encapsulations; in particular, they do not obey RFC 934 + quoting conventions for embedded lines that begin with + hyphens. This mechanism was chosen over the RFC 934 + mechanism because the latter causes lines to grow with each + level of quoting. The combination of this growth with the + fact that SMTP implementations sometimes wrap long lines + made the RFC 934 mechanism unsuitable for use in the event + that deeply-nested multipart structuring is ever desired. + + Thus, a typical multipart Content-Type header field might + look like this: + + Content-Type: multipart/mixed; + + + + + Borenstein & Freed [Page 30] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + boundary=gc0p4Jq0M2Yt08jU534c0p + + This indicates that the entity consists of several parts, + each itself with a structure that is syntactically identical + to an RFC 822 message, except that the header area might be + completely empty, and that the parts are each preceded by + the line + + --gc0p4Jq0M2Yt08jU534c0p + + Note that the encapsulation boundary must occur at the + beginning of a line, i.e., following a CRLF, and that that + initial CRLF is considered to be part of the encapsulation + boundary rather than part of the preceding part. The + boundary must be followed immediately either by another CRLF + and the header fields for the next part, or by two CRLFs, in + which case there are no header fields for the next part (and + it is therefore assumed to be of Content-Type text/plain). + + NOTE: The CRLF preceding the encapsulation line is + considered part of the boundary so that it is possible to + have a part that does not end with a CRLF (line break). + Body parts that must be considered to end with line breaks, + therefore, should have two CRLFs preceding the encapsulation + line, the first of which is part of the preceding body part, + and the second of which is part of the encapsulation + boundary. + + The requirement that the encapsulation boundary begins with + a CRLF implies that the body of a multipart entity must + itself begin with a CRLF before the first encapsulation line + -- that is, if the "preamble" area is not used, the entity + headers must be followed by TWO CRLFs. This is indeed how + such entities should be composed. A tolerant mail reading + program, however, may interpret a body of type multipart + that begins with an encapsulation line NOT initiated by a + CRLF as also being an encapsulation boundary, but a + compliant mail sending program must not generate such + entities. + + Encapsulation boundaries must not appear within the + encapsulations, and must be no longer than 70 characters, + not counting the two leading hyphens. + + The encapsulation boundary following the last body part is a + distinguished delimiter that indicates that no further body + parts will follow. Such a delimiter is identical to the + previous delimiters, with the addition of two more hyphens + at the end of the line: + + --gc0p4Jq0M2Yt08jU534c0p-- + + There appears to be room for additional information prior to + the first encapsulation boundary and following the final + + + + Borenstein & Freed [Page 31] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + boundary. These areas should generally be left blank, and + implementations should ignore anything that appears before + the first boundary or after the last one. + + NOTE: These "preamble" and "epilogue" areas are not used + because of the lack of proper typing of these parts and the + lack of clear semantics for handling these areas at + gateways, particularly X.400 gateways. + + NOTE: Because encapsulation boundaries must not appear in + the body parts being encapsulated, a user agent must + exercise care to choose a unique boundary. The boundary in + the example above could have been the result of an algorithm + designed to produce boundaries with a very low probability + of already existing in the data to be encapsulated without + having to prescan the data. Alternate algorithms might + result in more 'readable' boundaries for a recipient with an + old user agent, but would require more attention to the + possibility that the boundary might appear in the + encapsulated part. The simplest boundary possible is + something like "---", with a closing boundary of "-----". + + As a very simple example, the following multipart message + has two parts, both of them plain text, one of them + explicitly typed and one of them implicitly typed: + + From: Nathaniel Borenstein <nsb@bellcore.com> + To: Ned Freed <ned@innosoft.com> + Subject: Sample message + MIME-Version: 1.0 + Content-type: multipart/mixed; boundary="simple + boundary" + + This is the preamble. It is to be ignored, though it + is a handy place for mail composers to include an + explanatory note to non-MIME compliant readers. + --simple boundary + + This is implicitly typed plain ASCII text. + It does NOT end with a linebreak. + --simple boundary + Content-type: text/plain; charset=us-ascii + + This is explicitly typed plain ASCII text. + It DOES end with a linebreak. + + --simple boundary-- + This is the epilogue. It is also to be ignored. + + The use of a Content-Type of multipart in a body part within + another multipart entity is explicitly allowed. In such + cases, for obvious reasons, care must be taken to ensure + that each nested multipart entity must use a different + boundary delimiter. See Appendix C for an example of nested + + + + Borenstein & Freed [Page 32] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + multipart entities. + + The use of the multipart Content-Type with only a single + body part may be useful in certain contexts, and is + explicitly permitted. + + The only mandatory parameter for the multipart Content-Type + is the boundary parameter, which consists of 1 to 70 + characters from a set of characters known to be very robust + through email gateways, and NOT ending with white space. + (If a boundary appears to end with white space, the white + space must be presumed to have been added by a gateway, and + should be deleted.) It is formally specified by the + following BNF: + + boundary := 0*69<bchars> bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / + "_" + / "," / "-" / "." / "/" / ":" / "=" / "?" + + Overall, the body of a multipart entity may be specified as + follows: + + multipart-body := preamble 1*encapsulation + close-delimiter epilogue + + encapsulation := delimiter CRLF body-part + + delimiter := CRLF "--" boundary ; taken from Content-Type + field. + ; when content-type is + multipart + ; There must be no space + ; between "--" and boundary. + + close-delimiter := delimiter "--" ; Again, no space before + "--" + + preamble := *text ; to be ignored upon + receipt. + + epilogue := *text ; to be ignored upon + receipt. + + body-part = <"message" as defined in RFC 822, + with all header fields optional, and with the + specified delimiter not occurring anywhere in + the message body, either on a line by itself + or as a substring anywhere. Note that the + + + + + + Borenstein & Freed [Page 33] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + semantics of a part differ from the semantics + of a message, as described in the text.> + + NOTE: Conspicuously missing from the multipart type is a + notion of structured, related body parts. In general, it + seems premature to try to standardize interpart structure + yet. It is recommended that those wishing to provide a more + structured or integrated multipart messaging facility should + define a subtype of multipart that is syntactically + identical, but that always expects the inclusion of a + distinguished part that can be used to specify the structure + and integration of the other parts, probably referring to + them by their Content-ID field. If this approach is used, + other implementations will not recognize the new subtype, + but will treat it as the primary subtype (multipart/mixed) + and will thus be able to show the user the parts that are + recognized. + + 7.2.2 The Multipart/mixed (primary) subtype + + The primary subtype for multipart, "mixed", is intended for + use when the body parts are independent and intended to be + displayed serially. Any multipart subtypes that an + implementation does not recognize should be treated as being + of subtype "mixed". + + 7.2.3 The Multipart/alternative subtype + + The multipart/alternative type is syntactically identical to + multipart/mixed, but the semantics are different. In + particular, each of the parts is an "alternative" version of + the same information. User agents should recognize that the + content of the various parts are interchangeable. The user + agent should either choose the "best" type based on the + user's environment and preferences, or offer the user the + available alternatives. In general, choosing the best type + means displaying only the LAST part that can be displayed. + This may be used, for example, to send mail in a fancy text + format in such a way that it can easily be displayed + anywhere: + + From: Nathaniel Borenstein <nsb@bellcore.com> + To: Ned Freed <ned@innosoft.com> + Subject: Formatted text mail + MIME-Version: 1.0 + Content-Type: multipart/alternative; boundary=boundary42 + + + --boundary42 + Content-Type: text/plain; charset=us-ascii + + ...plain text version of message goes here.... + + + + + + Borenstein & Freed [Page 34] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + --boundary42 + Content-Type: text/richtext + + .... richtext version of same message goes here ... + --boundary42 + Content-Type: text/x-whatever + + .... fanciest formatted version of same message goes here + ... + --boundary42-- + + In this example, users whose mail system understood the + "text/x-whatever" format would see only the fancy version, + while other users would see only the richtext or plain text + version, depending on the capabilities of their system. + + In general, user agents that compose multipart/alternative + entities should place the body parts in increasing order of + preference, that is, with the preferred format last. For + fancy text, the sending user agent should put the plainest + format first and the richest format last. Receiving user + agents should pick and display the last format they are + capable of displaying. In the case where one of the + alternatives is itself of type "multipart" and contains + unrecognized sub-parts, the user agent may choose either to + show that alternative, an earlier alternative, or both. + + NOTE: From an implementor's perspective, it might seem more + sensible to reverse this ordering, and have the plainest + alternative last. However, placing the plainest alternative + first is the friendliest possible option when + mutlipart/alternative entities are viewed using a non-MIME- + compliant mail reader. While this approach does impose some + burden on compliant mail readers, interoperability with + older mail readers was deemed to be more important in this + case. + + It may be the case that some user agents, if they can + recognize more than one of the formats, will prefer to offer + the user the choice of which format to view. This makes + sense, for example, if mail includes both a nicely-formatted + image version and an easily-edited text version. What is + most critical, however, is that the user not automatically + be shown multiple versions of the same data. Either the + user should be shown the last recognized version or should + explicitly be given the choice. + + + + + + + + + + + + Borenstein & Freed [Page 35] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 7.2.4 The Multipart/digest subtype + + This document defines a "digest" subtype of the multipart + Content-Type. This type is syntactically identical to + multipart/mixed, but the semantics are different. In + particular, in a digest, the default Content-Type value for + a body part is changed from "text/plain" to + "message/rfc822". This is done to allow a more readable + digest format that is largely compatible (except for the + quoting convention) with RFC 934. + + A digest in this format might, then, look something like + this: + + From: Moderator-Address + MIME-Version: 1.0 + Subject: Internet Digest, volume 42 + Content-Type: multipart/digest; + boundary="---- next message ----" + + + ------ next message ---- + + From: someone-else + Subject: my opinion + + ...body goes here ... + + ------ next message ---- + + From: someone-else-again + Subject: my different opinion + + ... another body goes here... + + ------ next message ------ + + 7.2.5 The Multipart/parallel subtype + + This document defines a "parallel" subtype of the multipart + Content-Type. This type is syntactically identical to + multipart/mixed, but the semantics are different. In + particular, in a parallel entity, all of the parts are + intended to be presented in parallel, i.e., simultaneously, + on hardware and software that are capable of doing so. + Composing agents should be aware that many mail readers will + lack this capability and will show the parts serially in any + event. + + + + + + + + + + Borenstein & Freed [Page 36] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 7.3 The Message Content-Type + + It is frequently desirable, in sending mail, to encapsulate + another mail message. For this common operation, a special + Content-Type, "message", is defined. The primary subtype, + message/rfc822, has no required parameters in the Content- + Type field. Additional subtypes, "partial" and "External- + body", do have required parameters. These subtypes are + explained below. + + NOTE: It has been suggested that subtypes of message might + be defined for forwarded or rejected messages. However, + forwarded and rejected messages can be handled as multipart + messages in which the first part contains any control or + descriptive information, and a second part, of type + message/rfc822, is the forwarded or rejected message. + Composing rejection and forwarding messages in this manner + will preserve the type information on the original message + and allow it to be correctly presented to the recipient, and + hence is strongly encouraged. + + As stated in the definition of the Content-Transfer-Encoding + field, no encoding other than "7bit", "8bit", or "binary" is + permitted for messages or parts of type "message". The + message header fields are always US-ASCII in any case, and + data within the body can still be encoded, in which case the + Content-Transfer-Encoding header field in the encapsulated + message will reflect this. Non-ASCII text in the headers of + an encapsulated message can be specified using the + mechanisms described in [RFC-1342]. + + Mail gateways, relays, and other mail handling agents are + commonly known to alter the top-level header of an RFC 822 + message. In particular, they frequently add, remove, or + reorder header fields. Such alterations are explicitly + forbidden for the encapsulated headers embedded in the + bodies of messages of type "message." + + 7.3.1 The Message/rfc822 (primary) subtype + + A Content-Type of "message/rfc822" indicates that the body + contains an encapsulated message, with the syntax of an RFC + 822 message. + + 7.3.2 The Message/Partial subtype + + A subtype of message, "partial", is defined in order to + allow large objects to be delivered as several separate + pieces of mail and automatically reassembled by the + receiving user agent. (The concept is similar to IP + fragmentation/reassembly in the basic Internet Protocols.) + This mechanism can be used when intermediate transport + agents limit the size of individual messages that can be + sent. Content-Type "message/partial" thus indicates that + + + + Borenstein & Freed [Page 37] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + the body contains a fragment of a larger message. + + Three parameters must be specified in the Content-Type field + of type message/partial: The first, "id", is a unique + identifier, as close to a world-unique identifier as + possible, to be used to match the parts together. (In + general, the identifier is essentially a message-id; if + placed in double quotes, it can be any message-id, in + accordance with the BNF for "parameter" given earlier in + this specification.) The second, "number", an integer, is + the part number, which indicates where this part fits into + the sequence of fragments. The third, "total", another + integer, is the total number of parts. This third subfield + is required on the final part, and is optional on the + earlier parts. Note also that these parameters may be given + in any order. + + Thus, part 2 of a 3-part message may have either of the + following header fields: + + Content-Type: Message/Partial; + number=2; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; + + Content-Type: Message/Partial; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; + number=2 + + But part 3 MUST specify the total number of parts: + + Content-Type: Message/Partial; + number=3; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; + + Note that part numbering begins with 1, not 0. + + When the parts of a message broken up in this manner are put + together, the result is a complete RFC 822 format message, + which may have its own Content-Type header field, and thus + may contain any other data type. + + Message fragmentation and reassembly: The semantics of a + reassembled partial message must be those of the "inner" + message, rather than of a message containing the inner + message. This makes it possible, for example, to send a + large audio message as several partial messages, and still + have it appear to the recipient as a simple audio message + rather than as an encapsulated message containing an audio + message. That is, the encapsulation of the message is + considered to be "transparent". + + When generating and reassembling the parts of a + message/partial message, the headers of the encapsulated + message must be merged with the headers of the enclosing + + + + Borenstein & Freed [Page 38] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + entities. In this process the following rules must be + observed: + + (1) All of the headers from the initial enclosing + entity (part one), except those that start with + "Content-" and "Message-ID", must be copied, in + order, to the new message. + + (2) Only those headers in the enclosed message + which start with "Content-" and "Message-ID" must + be appended, in order, to the headers of the new + message. Any headers in the enclosed message + which do not start with "Content-" (except for + "Message-ID") will be ignored. + + (3) All of the headers from the second and any + subsequent messages will be ignored. + + For example, if an audio message is broken into two parts, + the first part might look something like this: + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + Message-ID: id1@host.com + MIME-Version: 1.0 + Content-type: message/partial; + id="ABC@host.com"; + number=1; total=2 + + X-Weird-Header-1: Bar + X-Weird-Header-2: Hello + Message-ID: anotherid@foo.com + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here... + + and the second half might look something like this: + + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + MIME-Version: 1.0 + Message-ID: id2@host.com + Content-type: message/partial; + id="ABC@host.com"; number=2; total=2 + + ... second half of encoded audio data goes here... + + Then, when the fragmented message is reassembled, the + resulting message to be displayed to the user should look + something like this: + + + + Borenstein & Freed [Page 39] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + Message-ID: anotherid@foo.com + MIME-Version: 1.0 + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here... + ... second half of encoded audio data goes here... + + It should be noted that, because some message transfer + agents may choose to automatically fragment large messages, + and because such agents may use different fragmentation + thresholds, it is possible that the pieces of a partial + message, upon reassembly, may prove themselves to comprise a + partial message. This is explicitly permitted. + + It should also be noted that the inclusion of a "References" + field in the headers of the second and subsequent pieces of + a fragmented message that references the Message-Id on the + previous piece may be of benefit to mail readers that + understand and track references. However, the generation of + such "References" fields is entirely optional. + + 7.3.3 The Message/External-Body subtype + + The external-body subtype indicates that the actual body + data are not included, but merely referenced. In this case, + the parameters describe a mechanism for accessing the + external data. + + When a message body or body part is of type + "message/external-body", it consists of a header, two + consecutive CRLFs, and the message header for the + encapsulated message. If another pair of consecutive CRLFs + appears, this of course ends the message header for the + encapsulated message. However, since the encapsulated + message's body is itself external, it does NOT appear in the + area that follows. For example, consider the following + message: + + Content-type: message/external-body; access- + type=local-file; + name=/u/nsb/Me.gif + + Content-type: image/gif + + THIS IS NOT REALLY THE BODY! + + The area at the end, which might be called the "phantom + body", is ignored for most external-body messages. However, + it may be used to contain auxilliary information for some + + + + Borenstein & Freed [Page 40] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + such messages, as indeed it is when the access-type is + "mail-server". Of the access-types defined by this + document, the phantom body is used only when the access-type + is "mail-server". In all other cases, the phantom body is + ignored. + + The only always-mandatory parameter for message/external- + body is "access-type"; all of the other parameters may be + mandatory or optional depending on the value of access-type. + + ACCESS-TYPE -- One or more case-insensitive words, + comma-separated, indicating supported access + mechanisms by which the file or data may be + obtained. Values include, but are not limited to, + "FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE", + and "MAIL-SERVER". Future values, except for + experimental values beginning with "X-", must be + registered with IANA, as described in Appendix F . + + In addition, the following two parameters are optional for + ALL access-types: + + EXPIRATION -- The date (in the RFC 822 "date-time" + syntax, as extended by RFC 1123 to permit 4 digits + in the date field) after which the existence of + the external data is not guaranteed. + + SIZE -- The size (in octets) of the data. The + intent of this parameter is to help the recipient + decide whether or not to expend the necessary + resources to retrieve the external data. + + PERMISSION -- A field that indicates whether or + not it is expected that clients might also attempt + to overwrite the data. By default, or if + permission is "read", the assumption is that they + are not, and that if the data is retrieved once, + it is never needed again. If PERMISSION is "read- + write", this assumption is invalid, and any local + copy must be considered no more than a cache. + "Read" and "Read-write" are the only defined + values of permission. + + The precise semantics of the access-types defined here are + described in the sections that follow. + + 7.3.3.1 The "ftp" and "tftp" access-types + + An access-type of FTP or TFTP indicates that the message + body is accessible as a file using the FTP [RFC-959] or TFTP + [RFC-783] protocols, respectively. For these access-types, + the following additional parameters are mandatory: + + + + + + Borenstein & Freed [Page 41] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + NAME -- The name of the file that contains the + actual body data. + + SITE -- A machine from which the file may be + obtained, using the given protocol + + Before the data is retrieved, using these protocols, the + user will generally need to be asked to provide a login id + and a password for the machine named by the site parameter. + + In addition, the following optional parameters may also + appear when the access-type is FTP or ANON-FTP: + + DIRECTORY -- A directory from which the data named + by NAME should be retrieved. + + MODE -- A transfer mode for retrieving the + information, e.g. "image". + + 7.3.3.2 The "anon-ftp" access-type + + The "anon-ftp" access-type is identical to the "ftp" access + type, except that the user need not be asked to provide a + name and password for the specified site. Instead, the ftp + protocol will be used with login "anonymous" and a password + that corresponds to the user's email address. + + 7.3.3.3 The "local-file" and "afs" access-types + + An access-type of "local-file" indicates that the actual + body is accessible as a file on the local machine. An + access-type of "afs" indicates that the file is accessible + via the global AFS file system. In both cases, only a + single parameter is required: + + NAME -- The name of the file that contains the + actual body data. + + The following optional parameter may be used to describe the + locality of reference for the data, that is, the site or + sites at which the file is expected to be visible: + + SITE -- A domain specifier for a machine or set of + machines that are known to have access to the data + file. Asterisks may be used for wildcard matching + to a part of a domain name, such as + "*.bellcore.com", to indicate a set of machines on + which the data should be directly visible, while a + single asterisk may be used to indicate a file + that is expected to be universally available, + e.g., via a global file system. + + 7.3.3.4 The "mail-server" access-type + + + + + Borenstein & Freed [Page 42] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + The "mail-server" access-type indicates that the actual body + is available from a mail server. The mandatory parameter + for this access-type is: + + SERVER -- The email address of the mail server + from which the actual body data can be obtained. + + Because mail servers accept a variety of syntax, some of + which is multiline, the full command to be sent to a mail + server is not included as a parameter on the content-type + line. Instead, it may be provided as the "phantom body" + when the content-type is message/external-body and the + access-type is mail-server. + + Note that MIME does not define a mail server syntax. + Rather, it allows the inclusion of arbitrary mail server + commands in the phantom body. Implementations should + include the phantom body in the body of the message it sends + to the mail server address to retrieve the relevant data. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 43] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 7.3.3.5 Examples and Further Explanations + + With the emerging possibility of very wide-area file + systems, it becomes very hard to know in advance the set of + machines where a file will and will not be accessible + directly from the file system. Therefore it may make sense + to provide both a file name, to be tried directly, and the + name of one or more sites from which the file is known to be + accessible. An implementation can try to retrieve remote + files using FTP or any other protocol, using anonymous file + retrieval or prompting the user for the necessary name and + password. If an external body is accessible via multiple + mechanisms, the sender may include multiple parts of type + message/external-body within an entity of type + multipart/alternative. + + However, the external-body mechanism is not intended to be + limited to file retrieval, as shown by the mail-server + access-type. Beyond this, one can imagine, for example, + using a video server for external references to video clips. + + If an entity is of type "message/external-body", then the + body of the entity will contain the header fields of the + encapsulated message. The body itself is to be found in the + external location. This means that if the body of the + "message/external-body" message contains two consecutive + CRLFs, everything after those pairs is NOT part of the + message itself. For most message/external-body messages, + this trailing area must simply be ignored. However, it is a + convenient place for additional data that cannot be included + in the content-type header field. In particular, if the + "access-type" value is "mail-server", then the trailing area + must contain commands to be sent to the mail server at the + address given by NAME@SITE, where NAME and SITE are the + values of the NAME and SITE parameters, respectively. + + The embedded message header fields which appear in the body + of the message/external-body data can be used to declare the + Content-type of the external body. Thus a complete + message/external-body message, referring to a document in + PostScript format, might look like this: + + From: Whomever + Subject: whatever + MIME-Version: 1.0 + Message-ID: id1@host.com + Content-Type: multipart/alternative; boundary=42 + + + --42 + Content-Type: message/external-body; + name="BodyFormats.ps"; + + + + + + Borenstein & Freed [Page 44] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + site="thumper.bellcore.com"; + access-type=ANON-FTP; + directory="pub"; + mode="image"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + + --42 + Content-Type: message/external-body; + name="/u/nsb/writing/rfcs/RFC-XXXX.ps"; + site="thumper.bellcore.com"; + access-type=AFS + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + + --42 + Content-Type: message/external-body; + access-type=mail-server + server="listserv@bogus.bitnet"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + + get rfc-xxxx doc + + --42-- + + Like the message/partial type, the message/external-body + type is intended to be transparent, that is, to convey the + data type in the external body rather than to convey a + message with a body of that type. Thus the headers on the + outer and inner parts must be merged using the same rules as + for message/partial. In particular, this means that the + Content-type header is overridden, but the From and Subject + headers are preserved. + + Note that since the external bodies are not transported as + mail, they need not conform to the 7-bit and line length + requirements, but might in fact be binary files. Thus a + Content-Transfer-Encoding is not generally necessary, though + it is permitted. + + Note that the body of a message of type "message/external- + body" is governed by the basic syntax for an RFC 822 + message. In particular, anything before the first + consecutive pair of CRLFs is header information, while + anything after it is body information, which is ignored for + most access-types. + + + + + + + + Borenstein & Freed [Page 45] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 7.4 The Application Content-Type + + The "application" Content-Type is to be used for data which + do not fit in any of the other categories, and particularly + for data to be processed by mail-based uses of application + programs. This is information which must be processed by an + application before it is viewable or usable to a user. + Expected uses for Content-Type application include mail- + based file transfer, spreadsheets, data for mail-based + scheduling systems, and languages for "active" + (computational) email. (The latter, in particular, can pose + security problems which should be understood by + implementors, and are considered in detail in the discussion + of the application/PostScript content-type.) + + For example, a meeting scheduler might define a standard + representation for information about proposed meeting dates. + An intelligent user agent would use this information to + conduct a dialog with the user, and might then send further + mail based on that dialog. More generally, there have been + several "active" messaging languages developed in which + programs in a suitably specialized language are sent through + the mail and automatically run in the recipient's + environment. + + Such applications may be defined as subtypes of the + "application" Content-Type. This document defines three + subtypes: octet-stream, ODA, and PostScript. + + In general, the subtype of application will often be the + name of the application for which the data are intended. + This does not mean, however, that any application program + name may be used freely as a subtype of application. Such + usages must be registered with IANA, as described in + Appendix F. + + 7.4.1 The Application/Octet-Stream (primary) subtype + + The primary subtype of application, "octet-stream", may be + used to indicate that a body contains binary data. The set + of possible parameters includes, but is not limited to: + + NAME -- a suggested name for the binary data if + stored as a file. + + TYPE -- the general type or category of binary + data. This is intended as information for the + human recipient rather than for any automatic + processing. + + CONVERSIONS -- the set of operations that have + been performed on the data before putting it in + the mail (and before any Content-Transfer-Encoding + that might have been applied). If multiple + + + + Borenstein & Freed [Page 46] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + conversions have occurred, they must be separated + by commas and specified in the order they were + applied -- that is, the leftmost conversion must + have occurred first, and conversions are undone + from right to left. Note that NO conversion + values are defined by this document. Any + conversion values that that do not begin with "X-" + must be preceded by a published specification and + by registration with IANA, as described in + Appendix F. + + PADDING -- the number of bits of padding that were + appended to the bitstream comprising the actual + contents to produce the enclosed byte-oriented + data. This is useful for enclosing a bitstream in + a body when the total number of bits is not a + multiple of the byte size. + + The values for these attributes are left undefined at + present, but may require specification in the future. An + example of a common (though UNIX-specific) usage might be: + + Content-Type: application/octet-stream; + name=foo.tar.Z; type=tar; + conversions="x-encrypt,x-compress" + + However, it should be noted that the use of such conversions + is explicitly discouraged due to a lack of portability and + standardization. The use of uuencode is particularly + discouraged, in favor of the Content-Transfer-Encoding + mechanism, which is both more standardized and more portable + across mail boundaries. + + The recommended action for an implementation that receives + application/octet-stream mail is to simply offer to put the + data in a file, with any Content-Transfer-Encoding undone, + or perhaps to use it as input to a user-specified process. + + To reduce the danger of transmitting rogue programs through + the mail, it is strongly recommended that implementations + NOT implement a path-search mechanism whereby an arbitrary + program named in the Content-Type parameter (e.g., an + "interpreter=" parameter) is found and executed using the + mail body as input. + + 7.4.2 The Application/PostScript subtype + + A Content-Type of "application/postscript" indicates a + PostScript program. The language is defined in + [POSTSCRIPT]. It is recommended that Postscript as sent + through email should use Postscript document structuring + conventions if at all possible, and correctly. + + + + + + Borenstein & Freed [Page 47] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + The execution of general-purpose PostScript interpreters + entails serious security risks, and implementors are + discouraged from simply sending PostScript email bodies to + "off-the-shelf" interpreters. While it is usually safe to + send PostScript to a printer, where the potential for harm + is greatly constrained, implementors should consider all of + the following before they add interactive display of + PostScript bodies to their mail readers. + + The remainder of this section outlines some, though probably + not all, of the possible problems with sending PostScript + through the mail. + + Dangerous operations in the PostScript language include, but + may not be limited to, the PostScript operators deletefile, + renamefile, filenameforall, and file. File is only + dangerous when applied to something other than standard + input or output. Implementations may also define additional + nonstandard file operators; these may also pose a threat to + security. Filenameforall, the wildcard file search + operator, may appear at first glance to be harmless. Note, + however, that this operator has the potential to reveal + information about what files the recipient has access to, + and this information may itself be sensitive. Message + senders should avoid the use of potentially dangerous file + operators, since these operators are quite likely to be + unavailable in secure PostScript implementations. Message- + receiving and -displaying software should either completely + disable all potentially dangerous file operators or take + special care not to delegate any special authority to their + operation. These operators should be viewed as being done by + an outside agency when interpreting PostScript documents. + Such disabling and/or checking should be done completely + outside of the reach of the PostScript language itself; care + should be taken to insure that no method exists for + reenabling full-function versions of these operators. + + The PostScript language provides facilities for exiting the + normal interpreter, or server, loop. Changes made in this + "outer" environment are customarily retained across + documents, and may in some cases be retained semipermanently + in nonvolatile memory. The operators associated with exiting + the interpreter loop have the potential to interfere with + subsequent document processing. As such, their unrestrained + use constitutes a threat of service denial. PostScript + operators that exit the interpreter loop include, but may + not be limited to, the exitserver and startjob operators. + Message-sending software should not generate PostScript that + depends on exiting the interpreter loop to operate. The + ability to exit will probably be unavailable in secure + PostScript implementations. Message-receiving and + -displaying software should, if possible, disable the + ability to make retained changes to the PostScript + environment. Eliminate the startjob and exitserver commands. + + + + Borenstein & Freed [Page 48] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + If these commands cannot be eliminated, at least set the + password associated with them to a hard-to-guess value. + + PostScript provides operators for setting system-wide and + device-specific parameters. These parameter settings may be + retained across jobs and may potentially pose a threat to + the correct operation of the interpreter. The PostScript + operators that set system and device parameters include, but + may not be limited to, the setsystemparams and setdevparams + operators. Message-sending software should not generate + PostScript that depends on the setting of system or device + parameters to operate correctly. The ability to set these + parameters will probably be unavailable in secure PostScript + implementations. Message-receiving and -displaying software + should, if possible, disable the ability to change system + and device parameters. If these operators cannot be + disabled, at least set the password associated with them to + a hard-to-guess value. + + Some PostScript implementations provide nonstandard + facilities for the direct loading and execution of machine + code. Such facilities are quite obviously open to + substantial abuse. Message-sending software should not + make use of such features. Besides being totally hardware- + specific, they are also likely to be unavailable in secure + implementations of PostScript. Message-receiving and + -displaying software should not allow such operators to be + used if they exist. + + PostScript is an extensible language, and many, if not most, + implementations of it provide a number of their own + extensions. This document does not deal with such extensions + explicitly since they constitute an unknown factor. + Message-sending software should not make use of nonstandard + extensions; they are likely to be missing from some + implementations. Message-receiving and -displaying software + should make sure that any nonstandard PostScript operators + are secure and don't present any kind of threat. + + It is possible to write PostScript that consumes huge + amounts of various system resources. It is also possible to + write PostScript programs that loop infinitely. Both types + of programs have the potential to cause damage if sent to + unsuspecting recipients. Message-sending software should + avoid the construction and dissemination of such programs, + which is antisocial. Message-receiving and -displaying + software should provide appropriate mechanisms to abort + processing of a document after a reasonable amount of time + has elapsed. In addition, PostScript interpreters should be + limited to the consumption of only a reasonable amount of + any given system resource. + + Finally, bugs may exist in some PostScript interpreters + which could possibly be exploited to gain unauthorized + + + + Borenstein & Freed [Page 49] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + access to a recipient's system. Apart from noting this + possibility, there is no specific action to take to prevent + this, apart from the timely correction of such bugs if any + are found. + + 7.4.3 The Application/ODA subtype + + The "ODA" subtype of application is used to indicate that a + body contains information encoded according to the Office + Document Architecture [ODA] standards, using the ODIF + representation format. For application/oda, the Content- + Type line should also specify an attribute/value pair that + indicates the document application profile (DAP), using the + key word "profile". Thus an appropriate header field might + look like this: + + Content-Type: application/oda; profile=Q112 + + Consult the ODA standard [ODA] for further information. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 50] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 7.5 The Image Content-Type + + A Content-Type of "image" indicates that the bodycontains an + image. The subtype names the specific image format. These + names are case insensitive. Two initial subtypes are "jpeg" + for the JPEG format, JFIF encoding, and "gif" for GIF format + [GIF]. + + The list of image subtypes given here is neither exclusive + nor exhaustive, and is expected to grow as more types are + registered with IANA, as described in Appendix F. + + 7.6 The Audio Content-Type + + A Content-Type of "audio" indicates that the body contains + audio data. Although there is not yet a consensus on an + "ideal" audio format for use with computers, there is a + pressing need for a format capable of providing + interoperable behavior. + + The initial subtype of "basic" is specified to meet this + requirement by providing an absolutely minimal lowest common + denominator audio format. It is expected that richer + formats for higher quality and/or lower bandwidth audio will + be defined by a later document. + + The content of the "audio/basic" subtype is audio encoded + using 8-bit ISDN u-law [PCM]. When this subtype is present, + a sample rate of 8000 Hz and a single channel is assumed. + + 7.7 The Video Content-Type + + A Content-Type of "video" indicates that the body contains a + time-varying-picture image, possibly with color and + coordinated sound. The term "video" is used extremely + generically, rather than with reference to any particular + technology or format, and is not meant to preclude subtypes + such as animated drawings encoded compactly. The subtype + "mpeg" refers to video coded according to the MPEG standard + [MPEG]. + + Note that although in general this document strongly + discourages the mixing of multiple media in a single body, + it is recognized that many so-called "video" formats include + a representation for synchronized audio, and this is + explicitly permitted for subtypes of "video". + + 7.8 Experimental Content-Type Values + + A Content-Type value beginning with the characters "X-" is a + private value, to be used by consenting mail systems by + mutual agreement. Any format without a rigorous and public + definition must be named with an "X-" prefix, and publicly + specified values shall never begin with "X-". (Older + + + + Borenstein & Freed [Page 51] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + versions of the widely-used Andrew system use the "X-BE2" + name, so new systems should probably choose a different + name.) + + In general, the use of "X-" top-level types is strongly + discouraged. Implementors should invent subtypes of the + existing types whenever possible. The invention of new + types is intended to be restricted primarily to the + development of new media types for email, such as digital + odors or holography, and not for new data formats in + general. In many cases, a subtype of application will be + more appropriate than a new top-level type. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 52] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Summary + + Using the MIME-Version, Content-Type, and Content-Transfer- + Encoding header fields, it is possible to include, in a + standardized way, arbitrary types of data objects with RFC + 822 conformant mail messages. No restrictions imposed by + either RFC 821 or RFC 822 are violated, and care has been + taken to avoid problems caused by additional restrictions + imposed by the characteristics of some Internet mail + transport mechanisms (see Appendix B). The "multipart" and + "message" Content-Types allow mixing and hierarchical + structuring of objects of different types in a single + message. Further Content-Types provide a standardized + mechanism for tagging messages or body parts as audio, + image, or several other kinds of data. A distinguished + parameter syntax allows further specification of data format + details, particularly the specification of alternate + character sets. Additional optional header fields provide + mechanisms for certain extensions deemed desirable by many + implementors. Finally, a number of useful Content-Types are + defined for general use by consenting user agents, notably + text/richtext, message/partial, and message/external-body. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 53] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Acknowledgements + + This document is the result of the collective effort of a + large number of people, at several IETF meetings, on the + IETF-SMTP and IETF-822 mailing lists, and elsewhere. + Although any enumeration seems doomed to suffer from + egregious omissions, the following are among the many + contributors to this effort: + + Harald Tveit Alvestrand Timo Lehtinen + Randall Atkinson John R. MacMillan + Philippe Brandon Rick McGowan + Kevin Carosso Leo Mclaughlin + Uhhyung Choi Goli Montaser-Kohsari + Cristian Constantinof Keith Moore + Mark Crispin Tom Moore + Dave Crocker Erik Naggum + Terry Crowley Mark Needleman + Walt Daniels John Noerenberg + Frank Dawson Mats Ohrman + Hitoshi Doi Julian Onions + Kevin Donnelly Michael Patton + Keith Edwards David J. Pepper + Chris Eich Blake C. Ramsdell + Johnny Eriksson Luc Rooijakkers + Craig Everhart Marshall T. Rose + Patrik Faeltstroem Jonathan Rosenberg + Erik E. Fair Jan Rynning + Roger Fajman Harri Salminen + Alain Fontaine Michael Sanderson + James M. Galvin Masahiro Sekiguchi + Philip Gladstone Mark Sherman + Thomas Gordon Keld Simonsen + Phill Gross Bob Smart + James Hamilton Peter Speck + Steve Hardcastle-Kille Henry Spencer + David Herron Einar Stefferud + Bruce Howard Michael Stein + Bill Janssen Klaus Steinberger + Olle Jaernefors Peter Svanberg + Risto Kankkunen James Thompson + Phil Karn Steve Uhler + Alan Katz Stuart Vance + Tim Kehres Erik van der Poel + Neil Katin Guido van Rossum + Kyuho Kim Peter Vanderbilt + Anders Klemets Greg Vaudreuil + John Klensin Ed Vielmetti + Valdis Kletniek Ryan Waldron + Jim Knowles Wally Wedel + Stev Knowles Sven-Ove Westberg + Bob Kummerfeld Brian Wideen + + + + + + Borenstein & Freed [Page 54] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Pekka Kytolaakso John Wobus + Stellan Lagerstr.m Glenn Wright + Vincent Lau Rayan Zachariassen + Donald Lindsay David Zimmerman + The authors apologize for any omissions from this list, + which are certainly unintentional. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 55] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Appendix A -- Minimal MIME-Conformance + + The mechanisms described in this document are open-ended. + It is definitely not expected that all implementations will + support all of the Content-Types described, nor that they + will all share the same extensions. In order to promote + interoperability, however, it is useful to define the + concept of "MIME-conformance" to define a certain level of + implementation that allows the useful interworking of + messages with content that differs from US ASCII text. In + this section, we specify the requirements for such + conformance. + + A mail user agent that is MIME-conformant MUST: + + 1. Always generate a "MIME-Version: 1.0" header + field. + + 2. Recognize the Content-Transfer-Encoding header + field, and decode all received data encoded with + either the quoted-printable or base64 + implementations. Encode any data sent that is + not in seven-bit mail-ready representation using + one of these transformations and include the + appropriate Content-Transfer-Encoding header + field, unless the underlying transport mechanism + supports non-seven-bit data, as SMTP does not. + + 3. Recognize and interpret the Content-Type + header field, and avoid showing users raw data + with a Content-Type field other than text. Be + able to send at least text/plain messages, with + the character set specified as a parameter if it + is not US-ASCII. + + 4. Explicitly handle the following Content-Type + values, to at least the following extents: + + Text: + -- Recognize and display "text" mail + with the character set "US-ASCII." + -- Recognize other character sets at + least to the extent of being able + to inform the user about what + character set the message uses. + -- Recognize the "ISO-8859-*" character + sets to the extent of being able to + display those characters that are + common to ISO-8859-* and US-ASCII, + namely all characters represented + by octet values 0-127. + -- For unrecognized subtypes, show or + offer to show the user the "raw" + version of the data. An ability at + + + + Borenstein & Freed [Page 56] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + least to convert "text/richtext" to + plain text, as shown in Appendix D, + is encouraged, but not required for + conformance. + Message: + --Recognize and display at least the + primary (822) encapsulation. + Multipart: + -- Recognize the primary (mixed) + subtype. Display all relevant + information on the message level + and the body part header level and + then display or offer to display + each of the body parts + individually. + -- Recognize the "alternative" subtype, + and avoid showing the user + redundant parts of + multipart/alternative mail. + -- Treat any unrecognized subtypes as if + they were "mixed". + Application: + -- Offer the ability to remove either of + the two types of Content-Transfer- + Encoding defined in this document + and put the resulting information + in a user file. + + 5. Upon encountering any unrecognized Content- + Type, an implementation must treat it as if it had + a Content-Type of "application/octet-stream" with + no parameter sub-arguments. How such data are + handled is up to an implementation, but likely + options for handling such unrecognized data + include offering the user to write it into a file + (decoded from its mail transport format) or + offering the user to name a program to which the + decoded data should be passed as input. + Unrecognized predefined types, which in a MIME- + conformant mailer might still include audio, + image, or video, should also be treated in this + way. + + A user agent that meets the above conditions is said to be + MIME-conformant. The meaning of this phrase is that it is + assumed to be "safe" to send virtually any kind of + properly-marked data to users of such mail systems, because + such systems will at least be able to treat the data as + undifferentiated binary, and will not simply splash it onto + the screen of unsuspecting users. There is another sense + in which it is always "safe" to send data in a format that + is MIME-conformant, which is that such data will not break + or be broken by any known systems that are conformant with + RFC 821 and RFC 822. User agents that are MIME-conformant + + + + Borenstein & Freed [Page 57] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + have the additional guarantee that the user will not be + shown data that were never intended to be viewed as text. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 58] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Appendix B -- General Guidelines For Sending Email Data + + Internet email is not a perfect, homogeneous system. Mail + may become corrupted at several stages in its travel to a + final destination. Specifically, email sent throughout the + Internet may travel across many networking technologies. + Many networking and mail technologies do not support the + full functionality possible in the SMTP transport + environment. Mail traversing these systems is likely to be + modified in such a way that it can be transported. + + There exist many widely-deployed non-conformant MTAs in the + Internet. These MTAs, speaking the SMTP protocol, alter + messages on the fly to take advantage of the internal data + structure of the hosts they are implemented on, or are just + plain broken. + + The following guidelines may be useful to anyone devising a + data format (Content-Type) that will survive the widest + range of networking technologies and known broken MTAs + unscathed. Note that anything encoded in the base64 + encoding will satisfy these rules, but that some well-known + mechanisms, notably the UNIX uuencode facility, will not. + Note also that anything encoded in the Quoted-Printable + encoding will survive most gateways intact, but possibly not + some gateways to systems that use the EBCDIC character set. + + (1) Under some circumstances the encoding used for + data may change as part of normal gateway or user + agent operation. In particular, conversion from + base64 to quoted-printable and vice versa may be + necessary. This may result in the confusion of + CRLF sequences with line breaks in text body + parts. As such, the persistence of CRLF as + something other than a line break should not be + relied on. + + (2) Many systems may elect to represent and store + text data using local newline conventions. Local + newline conventions may not match the RFC822 CRLF + convention -- systems are known that use plain CR, + plain LF, CRLF, or counted records. The result is + that isolated CR and LF characters are not well + tolerated in general; they may be lost or + converted to delimiters on some systems, and hence + should not be relied on. + + (3) TAB (HT) characters may be misinterpreted or + may be automatically converted to variable numbers + of spaces. This is unavoidable in some + environments, notably those not based on the ASCII + character set. Such conversion is STRONGLY + DISCOURAGED, but it may occur, and mail formats + should not rely on the persistence of TAB (HT) + + + + Borenstein & Freed [Page 59] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + characters. + + (4) Lines longer than 76 characters may be wrapped + or truncated in some environments. Line wrapping + and line truncation are STRONGLY DISCOURAGED, but + unavoidable in some cases. Applications which + require long lines should somehow differentiate + between soft and hard line breaks. (A simple way + to do this is to use the quoted-printable + encoding.) + + (5) Trailing "white space" characters (SPACE, TAB + (HT)) on a line may be discarded by some transport + agents, while other transport agents may pad lines + with these characters so that all lines in a mail + file are of equal length. The persistence of + trailing white space, therefore, should not be + relied on. + + (6) Many mail domains use variations on the ASCII + character set, or use character sets such as + EBCDIC which contain most but not all of the US- + ASCII characters. The correct translation of + characters not in the "invariant" set cannot be + depended on across character converting gateways. + For example, this situation is a problem when + sending uuencoded information across BITNET, an + EBCDIC system. Similar problems can occur without + crossing a gateway, since many Internet hosts use + character sets other than ASCII internally. The + definition of Printable Strings in X.400 adds + further restrictions in certain special cases. In + particular, the only characters that are known to + be consistent across all gateways are the 73 + characters that correspond to the upper and lower + case letters A-Z and a-z, the 10 digits 0-9, and + the following eleven special characters: + + "'" (ASCII code 39) + "(" (ASCII code 40) + ")" (ASCII code 41) + "+" (ASCII code 43) + "," (ASCII code 44) + "-" (ASCII code 45) + "." (ASCII code 46) + "/" (ASCII code 47) + ":" (ASCII code 58) + "=" (ASCII code 61) + "?" (ASCII code 63) + + A maximally portable mail representation, such as + the base64 encoding, will confine itself to + relatively short lines of text in which the only + meaningful characters are taken from this set of + + + + Borenstein & Freed [Page 60] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + 73 characters. + + Please note that the above list is NOT a list of recommended + practices for MTAs. RFC 821 MTAs are prohibited from + altering the character of white space or wrapping long + lines. These BAD and illegal practices are known to occur + on established networks, and implementions should be robust + in dealing with the bad effects they can cause. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 61] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Appendix C -- A Complex Multipart Example + + What follows is the outline of a complex multipart message. + This message has five parts to be displayed serially: two + introductory plain text parts, an embedded multipart + message, a richtext part, and a closing encapsulated text + message in a non-ASCII character set. The embedded + multipart message has two parts to be displayed in parallel, + a picture and an audio fragment. + + MIME-Version: 1.0 + From: Nathaniel Borenstein <nsb@bellcore.com> + Subject: A multipart example + Content-Type: multipart/mixed; + boundary=unique-boundary-1 + + This is the preamble area of a multipart message. + Mail readers that understand multipart format + should ignore this preamble. + If you are reading this text, you might want to + consider changing to a mail reader that understands + how to properly display multipart messages. + --unique-boundary-1 + + ...Some text appears here... + [Note that the preceding blank line means + no header fields were given and this is text, + with charset US ASCII. It could have been + done with explicit typing as in the next part.] + + --unique-boundary-1 + Content-type: text/plain; charset=US-ASCII + + This could have been part of the previous part, + but illustrates explicit versus implicit + typing of body parts. + + --unique-boundary-1 + Content-Type: multipart/parallel; + boundary=unique-boundary-2 + + + --unique-boundary-2 + Content-Type: audio/basic + Content-Transfer-Encoding: base64 + + ... base64-encoded 8000 Hz single-channel + u-law-format audio data goes here.... + + --unique-boundary-2 + Content-Type: image/gif + Content-Transfer-Encoding: Base64 + + + + + + Borenstein & Freed [Page 62] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + ... base64-encoded image data goes here.... + + --unique-boundary-2-- + + --unique-boundary-1 + Content-type: text/richtext + + This is <bold><italic>richtext.</italic></bold> + <nl><nl>Isn't it + <bigger><bigger>cool?</bigger></bigger> + + --unique-boundary-1 + Content-Type: message/rfc822 + + From: (name in US-ASCII) + Subject: (subject in US-ASCII) + Content-Type: Text/plain; charset=ISO-8859-1 + Content-Transfer-Encoding: Quoted-printable + + ... Additional text in ISO-8859-1 goes here ... + + --unique-boundary-1-- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 63] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Appendix D -- A Simple Richtext-to-Text Translator in C + + One of the major goals in the design of the richtext subtype + of the text Content-Type is to make formatted text so simple + that even text-only mailers will implement richtext-to- + plain-text translators, thus increasing the likelihood that + multifont text will become "safe" to use very widely. To + demonstrate this simplicity, what follows is an extremely + simple 44-line C program that converts richtext input into + plain text output: + + #include <stdio.h> + #include <ctype.h> + main() { + int c, i; + char token[50]; + + while((c = getc(stdin)) != EOF) { + if (c == '<') { + for (i=0; (i<49 && (c = getc(stdin)) != '>' + && c != EOF); ++i) { + token[i] = isupper(c) ? tolower(c) : c; + } + if (c == EOF) break; + if (c != '>') while ((c = getc(stdin)) != + '>' + && c != EOF) {;} + if (c == EOF) break; + token[i] = '\0'; + if (!strcmp(token, "lt")) { + putc('<', stdout); + } else if (!strcmp(token, "nl")) { + putc('\n', stdout); + } else if (!strcmp(token, "/paragraph")) { + fputs("\n\n", stdout); + } else if (!strcmp(token, "comment")) { + int commct=1; + while (commct > 0) { + while ((c = getc(stdin)) != '<' + && c != EOF) ; + if (c == EOF) break; + for (i=0; (c = getc(stdin)) != '>' + && c != EOF; ++i) { + token[i] = isupper(c) ? + tolower(c) : c; + } + if (c== EOF) break; + token[i] = NULL; + if (!strcmp(token, "/comment")) -- + commct; + if (!strcmp(token, "comment")) + ++commct; + + + + + + Borenstein & Freed [Page 64] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + } + } /* Ignore all other tokens */ + } else if (c != '\n') putc(c, stdout); + } + putc('\n', stdout); /* for good measure */ + } + It should be noted that one can do considerably better than + this in displaying richtext data on a dumb terminal. In + particular, one can replace font information such as "bold" + with textual emphasis (like *this* or _T_H_I_S_). One can + also properly handle the richtext formatting commands + regarding indentation, justification, and others. However, + the above program is all that is necessary in order to + present richtext on a dumb terminal. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 65] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Appendix E -- Collected Grammar + + This appendix contains the complete BNF grammar for all the + syntax specified by this document. + + By itself, however, this grammar is incomplete. It refers + to several entities that are defined by RFC 822. Rather + than reproduce those definitions here, and risk + unintentional differences between the two, this document + simply refers the reader to RFC 822 for the remaining + definitions. Wherever a term is undefined, it refers to the + RFC 822 definition. + + attribute := token + + body-part = <"message" as defined in RFC 822, + with all header fields optional, and with the + specified delimiter not occurring anywhere in + the message body, either on a line by itself + or as a substring anywhere.> + + boundary := 0*69<bchars> bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / + "_" + / "," / "-" / "." / "/" / ":" / "=" / "?" + + close-delimiter := delimiter "--" + + Content-Description := *text + + Content-ID := msg-id + + Content-Transfer-Encoding := "BASE64" / "QUOTED- + PRINTABLE" / + "8BIT" / "7BIT" / + "BINARY" / x-token + + Content-Type := type "/" subtype *[";" parameter] + + delimiter := CRLF "--" boundary ; taken from Content-Type + field. + ; when content-type is + multipart + ; There should be no space + ; between "--" and boundary. + + encapsulation := delimiter CRLF body-part + + epilogue := *text ; to be ignored upon + receipt. + + + + + Borenstein & Freed [Page 66] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + MIME-Version := 1*text + + multipart-body := preamble 1*encapsulation close-delimiter + epilogue + + parameter := attribute "=" value + + preamble := *text ; to be ignored upon + receipt. + + subtype := token + + token := 1*<any CHAR except SPACE, CTLs, or tspecials> + + tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in + / "," / ";" / ":" / "\" / <"> ; quoted-string, + / "/" / "[" / "]" / "?" / "." ; to use within + / "=" ; parameter values + + + type := "application" / "audio" ; case- + insensitive + / "image" / "message" + / "multipart" / "text" + / "video" / x-token + + value := token / quoted-string + + x-token := <The two characters "X-" followed, with no + intervening white space, by any token> + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 67] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Appendix F -- IANA Registration Procedures + + MIME has been carefully designed to have extensible + mechanisms, and it is expected that the set of content- + type/subtype pairs and their associated parameters will grow + significantly with time. Several other MIME fields, notably + character set names, access-type parameters for the + message/external-body type, conversions parameters for the + application type, and possibly even Content-Transfer- + Encoding values, are likely to have new values defined over + time. In order to ensure that the set of such values is + developed in an orderly, well-specified, and public manner, + MIME defines a registration process which uses the Internet + Assigned Numbers Authority (IANA) as a central registry for + such values. + + In general, parameters in the content-type header field are + used to convey supplemental information for various content + types, and their use is defined when the content-type and + subtype are defined. New parameters should not be defined + as a way to introduce new functionality. + + In order to simplify and standardize the registration + process, this appendix gives templates for the registration + of new values with IANA. Each of these is given in the form + of an email message template, to be filled in by the + registering party. + + F.1 Registration of New Content-type/subtype Values + + Note that MIME is generally expected to be extended by + subtypes. If a new fundamental top-level type is needed, + its specification should be published as an RFC or + submitted in a form suitable to become an RFC, and be + subject to the Internet standards process. + + To: IANA@isi.edu + Subject: Registration of new MIME content-type/subtype + + MIME type name: + + (If the above is not an existing top-level MIME type, + please explain why an existing type cannot be used.) + + MIME subtype name: + + Required parameters: + + Optional parameters: + + Encoding considerations: + + Security considerations: + + + + + Borenstein & Freed [Page 68] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be if a new top-level type is being defined, and + must be a publicly available specification in any + case.) + + Person & email address to contact for further + information: + F.2 Registration of New Character Set Values + + To: IANA@isi.edu + Subject: Registration of new MIME character set value + + MIME character set name: + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be or an international standard.) + + Person & email address to contact for further + information: + + F.3 Registration of New Access-type Values for + Message/external-body + + To: IANA@isi.edu + Subject: Registration of new MIME Access-type for + Message/external-body content-type + + MIME access-type name: + + Required parameters: + + Optional parameters: + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be.) + + Person & email address to contact for further + information: + + + F.4 Registration of New Conversions Values for Application + + To: IANA@isi.edu + Subject: Registration of new MIME Conversions value + for Application content-type + + MIME Conversions name: + + + + + Borenstein & Freed [Page 69] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be.) + + Person & email address to contact for further + information: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 70] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Appendix G -- Summary of the Seven Content-types + + Content-type: text + + Subtypes defined by this document: plain, richtext + + Important Parameters: charset + + Encoding notes: quoted-printable generally preferred if an + encoding is needed and the character set is mostly an + ASCII superset. + + Security considerations: Rich text formats such as TeX and + Troff often contain mechanisms for executing arbitrary + commands or file system operations, and should not be + used automatically unless these security problems have + been addressed. Even plain text may contain control + characters that can be used to exploit the capabilities + of "intelligent" terminals and cause security + violations. User interfaces designed to run on such + terminals should be aware of and try to prevent such + problems. + ________________________________________________________________ + + Content-type: multipart + + Subtypes defined by this document: mixed, alternative, + digest, parallel. + + Important Parameters: boundary + + Encoding notes: No content-transfer-encoding is permitted. + + ________________________________________________________________ + + Content-type: message + + Subtypes defined by this document: rfc822, partial, + external-body + + Important Parameters: id, number, total + + Encoding notes: No content-transfer-encoding is permitted. + + ________________________________________________________________ + + Content-type: application + + Subtypes defined by this document: octet-stream, + postscript, oda + + Important Parameters: profile + + + + + + Borenstein & Freed [Page 71] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Encoding notes: base64 generally preferred for octet-stream + or other unreadable subtypes. + + Security considerations: This type is intended for the + transmission of data to be interpreted by locally-installed + programs. If used, for example, to transmit executable + binary programs or programs in general-purpose interpreted + languages, such as LISP programs or shell scripts, severe + security problems could result. In general, authors of + mail-reading agents are cautioned against giving their + systems the power to execute mail-based application data + without carefully considering the security implications. + While it is certainly possible to define safe application + formats and even safe interpreters for unsafe formats, each + interpreter should be evaluated separately for possible + security problems. + ________________________________________________________________ + + Content-type: image + + Subtypes defined by this document: jpeg, gif + + Important Parameters: none + + Encoding notes: base64 generally preferred + + ________________________________________________________________ + + Content-type: audio + + Subtypes defined by this document: basic + + Important Parameters: none + + Encoding notes: base64 generally preferred + + ________________________________________________________________ + + Content-type: video + + Subtypes defined by this document: mpeg + + Important Parameters: none + + Encoding notes: base64 generally preferred + + + + + + + + + + + + + Borenstein & Freed [Page 72] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Appendix H -- Canonical Encoding Model + + + + There was some confusion, in earlier drafts of this memo, + regarding the model for when email data was to be converted + to canonical form and encoded, and in particular how this + process would affect the treatment of CRLFs, given that the + representation of newlines varies greatly from system to + system. For this reason, a canonical model for encoding is + presented below. + + The process of composing a MIME message part can be modelled + as being done in a number of steps. Note that these steps + are roughly similar to those steps used in RFC1113: + + Step 1. Creation of local form. + + The body part to be transmitted is created in the system's + native format. The native character set is used, and where + appropriate local end of line conventions are used as well. + The may be a UNIX-style text file, or a Sun raster image, or + a VMS indexed file, or audio data in a system-dependent + format stored only in memory, or anything else that + corresponds to the local model for the representation of + some form of information. + + Step 2. Conversion to canonical form. + + The entire body part, including "out-of-band" information + such as record lengths and possibly file attribute + information, is converted to a universal canonical form. + The specific content type of the body part as well as its + associated attributes dictate the nature of the canonical + form that is used. Conversion to the proper canonical form + may involve character set conversion, transformation of + audio data, compression, or various other operations + specific to the various content types. + + For example, in the case of text/plain data, the text must + be converted to a supported character set and lines must be + delimited with CRLF delimiters in accordance with RFC822. + Note that the restriction on line lengths implied by RFC822 + is eliminated if the next step employs either quoted- + printable or base64 encoding. + + Step 3. Apply transfer encoding. + + A Content-Transfer-Encoding appropriate for this body part + is applied. Note that there is no fixed relationship + between the content type and the transfer encoding. In + particular, it may be appropriate to base the choice of + base64 or quoted-printable on character frequency counts + which are specific to a given instance of body part. + + + + Borenstein & Freed [Page 73] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Step 4. Insertion into message. + + The encoded object is inserted into a MIME message with + appropriate body part headers and boundary markers. + + It is vital to note that these steps are only a model; they + are specifically NOT a blueprint for how an actual system + would be built. In particular, the model fails to account + for two common designs: + + 1. In many cases the conversion to a canonical + form prior to encoding will be subsumed into the + encoder itself, which understands local formats + directly. For example, the local newline + convention for text bodyparts might be carried + through to the encoder itself along with knowledge + of what that format is. + + 2. The output of the encoders may have to pass + through one or more additional steps prior to + being transmitted as a message. As such, the + output of the encoder may not be compliant with + the formats specified by RFC822. In particular, + once again it may be appropriate for the + converter's output to be expressed using local + newline conventions rather than using the standard + RFC822 CRLF delimiters. + + Other implementation variations are conceivable as well. + The only important aspect of this discussion is that the + resulting messages are consistent with those produced by the + model described here. + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 74] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + References + + [US-ASCII] Coded Character Set--7-Bit American Standard Code + for Information Interchange, ANSI X3.4-1986. + + [ATK] Borenstein, Nathaniel S., Multimedia Applications + Development with the Andrew Toolkit, Prentice-Hall, 1990. + + [GIF] Graphics Interchange Format (Version 89a), Compuserve, + Inc., Columbus, Ohio, 1990. + + [ISO-2022] International Standard--Information Processing-- + ISO 7-bit and 8-bit coded character sets--Code extension + techniques, ISO 2022:1986. + + [ISO-8859] Information Processing -- 8-bit Single-Byte Coded + Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO + 8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2, + 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part + 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: + Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: + Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: + Latin/Greek alphabet, ISO 8859-7, 1987. Part 8: + Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin + alphabet No. 5, ISO 8859-9, 1990. + + [ISO-646] International Standard--Information Processing-- + ISO 7-bit coded character set for information interchange, + ISO 646:1983. + + [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO + IEC/TJC1/SC2/WG11 (Motion Picture Experts Group), May, 1991. + + [ODA] ISO 8613; Information Processing: Text and Office + System; Office Document Architecture (ODA) and Interchange + Format (ODIF), Part 1-8, 1989. + + [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva, + 1972, "Pulse Code Modulation (PCM) of Voice Frequencies". + + [POSTSCRIPT] Adobe Systems, Inc., PostScript Language + Reference Manual, Addison-Wesley, 1985. + + [X400] Schicker, Pietro, "Message Handling Systems, X.400", + Message Handling Systems and Distributed Applications, E. + Stefferud, O-j. Jacobsen, and P. Schicker, eds., North- + Holland, 1989, pp. 3-41. + + [RFC-783] Sollins, K.R. TFTP Protocol (revision 2). June, + 1981, MIT, RFC-783. + + [RFC-821] Postel, J.B. Simple Mail Transfer Protocol. + August, 1982, USC/Information Sciences Institute, RFC-821. + + + + + Borenstein & Freed [Page 75] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + [RFC-822] Crocker, D. Standard for the format of ARPA + Internet text messages. August, 1982, UDEL, RFC-822. + + [RFC-934] Rose, M.T.; Stefferud, E.A. Proposed standard + for message encapsulation. January, 1985, Delaware + and NMA, RFC-934. + + [RFC-959] Postel, J.B.; Reynolds, J.K. File Transfer + Protocol. October, 1985, USC/Information Sciences + Institute, RFC-959. + + [RFC-1049] Sirbu, M.A. Content-Type header field for + Internet messages. March, 1988, CMU, RFC-1049. + + [RFC-1113] Linn, J. Privacy enhancement for Internet + electronic mail: Part I - message encipherment and + authentication procedures. August, 1989, IAB Privacy Task + Force, RFC-1113. + + [RFC-1154] Robinson, D.; Ullmann, R. Encoding header field + for Internet messages. April, 1990, Prime Computer, + Inc., RFC-1154. + + [RFC-1342] Moore, Keith, Representation of Non-Ascii Text in + Internet Message Headers. June, 1992, University of + Tennessee, RFC-1342. + + Security Considerations + + Security issues are discussed in Section 7.4.2 and in + Appendix G. Implementors should pay special attention to + the security implications of any mail content-types that can + cause the remote execution of any actions in the recipient's + environment. In such cases, the discussion of the + applicaton/postscript content-type in Section 7.4.2 may + serve as a model for considering other content-types with + remote execution capabilities. + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 76] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + Authors' Addresses + + For more information, the authors of this document may be + contacted via Internet mail: + + Nathaniel S. Borenstein + MRE 2D-296, Bellcore + 445 South St. + Morristown, NJ 07962-1910 + + Phone: +1 201 829 4270 + Fax: +1 201 829 7019 + Email: nsb@bellcore.com + + + Ned Freed + Innosoft International, Inc. + 250 West First Street + Suite 240 + Claremont, CA 91711 + + Phone: +1 714 624 7907 + Fax: +1 714 621 5319 + Email: ned@innosoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page 77] + + + + + RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992 + + + + + + THIS PAGE INTENTIONALLY LEFT BLANK. + + Please discard this page and place the following table of + contents after the title page. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page i] + + + + + + + + + Table of Contents + + + 1 Introduction....................................... 1 + 2 Notations, Conventions, and Generic BNF Grammar.... 3 + 3 The MIME-Version Header Field...................... 5 + 4 The Content-Type Header Field...................... 6 + 5 The Content-Transfer-Encoding Header Field......... 10 + 5.1 Quoted-Printable Content-Transfer-Encoding......... 14 + 5.2 Base64 Content-Transfer-Encoding................... 17 + 6 Additional Optional Content- Header Fields......... 19 + 6.1 Optional Content-ID Header Field................... 19 + 6.2 Optional Content-Description Header Field.......... 19 + 7 The Predefined Content-Type Values................. 20 + 7.1 The Text Content-Type.............................. 20 + 7.1.1 The charset parameter.............................. 20 + 7.1.2 The Text/plain subtype............................. 23 + 7.1.3 The Text/richtext subtype.......................... 23 + 7.2 The Multipart Content-Type......................... 29 + 7.2.1 Multipart: The common syntax...................... 30 + 7.2.2 The Multipart/mixed (primary) subtype.............. 34 + 7.2.3 The Multipart/alternative subtype.................. 34 + 7.2.4 The Multipart/digest subtype....................... 36 + 7.2.5 The Multipart/parallel subtype..................... 36 + 7.3 The Message Content-Type........................... 37 + 7.3.1 The Message/rfc822 (primary) subtype............... 37 + 7.3.2 The Message/Partial subtype........................ 37 + 7.3.3 The Message/External-Body subtype.................. 40 + 7.4 The Application Content-Type....................... 46 + 7.4.1 The Application/Octet-Stream (primary) subtype..... 46 + 7.4.2 The Application/PostScript subtype................. 47 + 7.4.3 The Application/ODA subtype........................ 50 + 7.5 The Image Content-Type............................. 51 + 7.6 The Audio Content-Type............................. 51 + 7.7 The Video Content-Type............................. 51 + 7.8 Experimental Content-Type Values................... 51 + Summary............................................ 53 + Acknowledgements................................... 54 + Appendix A -- Minimal MIME-Conformance............. 56 + Appendix B -- General Guidelines For Sending Email Data59 + Appendix C -- A Complex Multipart Example.......... 62 + Appendix D -- A Simple Richtext-to-Text Translator in C64 + Appendix E -- Collected Grammar.................... 66 + Appendix F -- IANA Registration Procedures......... 68 + F.1 Registration of New Content-type/subtype Values..68 + F.2 Registration of New Character Set Values...... 69 + F.3 Registration of New Access-type Values for Message/external-body69 + F.4 Registration of New Conversions Values for Application69 + Appendix G -- Summary of the Seven Content-types... 71 + Appendix H -- Canonical Encoding Model............. 73 + References......................................... 75 + Security Considerations............................ 76 + Authors' Addresses................................. 77 + + + + Borenstein & Freed [Page ii] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borenstein & Freed [Page iii] + diff --git a/Documentation/en/rfc/rfc1342.txt b/Documentation/en/rfc/rfc1342.txt new file mode 100644 index 00000000..5315aff5 --- /dev/null +++ b/Documentation/en/rfc/rfc1342.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 1342 University of Tennessee + June 1992 + + + Representation of Non-ASCII Text in Internet Message Headers + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + This memo describes an extension to the message format defined in [1] + (known to the IETF Mail Extensions Working Group as "RFC 1341"), to + allow the representation of character sets other than ASCII in RFC + 822 message headers. The extensions described were designed to be + highly compatible with existing Internet mail handling software, and + to be easily implemented in mail readers that support RFC 1341. + +Introduction + + RFC 1341 describes a mechanism for denoting textual body parts which + are coded in various character sets, as well as methods for encoding + such body parts as sequences of printable ASCII characters. This + memo describes similar techniques to allow the encoding of non-ASCII + text in various portions of a RFC 822 [2] message header, in a manner + which is unlikely to confuse existing message handling software. + + Like the encoding techniques described in RFC 1341, the techniques + outlined here were designed to allow the use of non-ASCII characters + in message headers in a way which is unlikely to be disturbed by the + quirks of existing Internet mail handling programs. In particular, + some mail relaying programs are known to (a) delete some message + header fields while retaining others, (b) rearrange the order of + addresses in To or Cc fields, (c) rearrange the (vertical) order of + header fields, and/or (d) "wrap" message headers at different places + than those in the original message. In addition, some mail reading + programs are known to have difficulty correctly parsing message + headers which, while legal according to RFC 822, make use of + backslash-quoting to "hide" special characters such as "<", ",", or + or which exploit other infrequently-used features of that + specification. + + + + +Moore [Page 1] + +RFC 1342 Non-ASCII Mail Headers June 1992 + + + While it is unfortunate that these programs do not correctly + interpret RFC 822 headers, to "break" these programs would cause + severe operational problems for the Internet mail system. The + extensions described in this memo therefore do not rely on little- + used features of RFC 822. Instead, certain sequences of "ordinary" + printable ASCII characters (which are assumed to be unlikely to + otherwise appear in message headers) are reserved for use as encoded + data. The characters used in these encodings are restricted to those + which do not have special meanings in the context in which the + encoded text appears. + +Encodings + + An "encoded-word" is a sequence of printable ASCII characters that + begins with "=?", ends with "?=", and has two "?"s in between. It + specifies a character set and an encoding method, and also includes + the original text encoded as ASCII characters, according to the rules + for that encoding method. + + A mail composer that implements this specification will provide a + means of inputing non-ASCII text in header fields, but will translate + these fields (or appropriate portions of these fields) into encoded- + words before inserting them into the message header. + + A mail reader that implements this specification will recognize + encoded-words when they appear in certain portions of the message + header. Instead of displaying the encoded-word "as is", it will + reverse the encoding and display the original text in the designated + character set. + + An "encoded-word" is more precisely defined by the following EBNF + grammar, using the notation of RFC 822: + + encoded-word = "=" "?" charset "?" encoding "?" encoded-text "?" "=" + + charset = token ; legal charsets defined by RFC 1341 + + encoding = token ; Either "B" or "Q" + + token = 1*<Any CHAR except SPACE, CTLs, and tspecials> + + tspecials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / + <"> / "/" / "[" / "]" / "?" / "." / "=" + + encoded-text = 1*<Any printable ASCII character other than "?" or + ; SPACE> (but see "Use of encoded-words in message + ; headers", below) + + + + +Moore [Page 2] + +RFC 1342 Non-ASCII Mail Headers June 1992 + + + An encoded-word may not be more than 75 characters long, including + charset, encoding, encoded-text, and delimiters. If it is desirable + to encode more text than will fit in an encoded-word of 75 + characters, multiple encoded-words (separated by SPACE or newline) + may be used. Message header lines that contain one or more encoded- + words should be no more than 76 characters long. NOTE: These + restrictions are included not only to ease interoperbility through + internetwork mail gateways, but also to impose a limit on the amount + of lookahead a header parser must employ (while looking for a final + ?= delimiter) before it can decide whether a token is an encoded-word + or something else. + + Initially, the legal values for "encoding" are "Q" and "B". These + encodings are described below. The "Q" encoding is recommended for + use with Latin character sets, and the "B" encoding for all others. + Nevertheless, a mail reader which claims to recognize encoded-words + MUST be able to accept either encoding for any character set which it + supports. + + Only a subset of the printable ASCII characters may be used in + encoded-text. The SPACE character is not allowed, so that the + beginning and end of an encoded-word are obvious. The "?" character + is used within an encoded-word to separate the various portions of + the encoded-word from one another, and thus cannot appear in the + encoded-text portion. Other characters are also illegal in certain + contexts. For example, an encoded-word in a "phrase" preceeding an + address in a From header field may not contain any of the "specials" + defined in RFC 822. Finally, certain other characters are disallowed + in some contexts, to ensure reliability for messages that pass + through internetwork mail gateways. + + The "B" encoding automatically meets these requirements. The "Q" + encoding allows a wide range of printable characters to be used in + non-critical locations in the message header (e.g., Subject), with + fewer characters available for use in other locations. + +The "B" encoding + + The "B" encoding is identical to the "BASE64" encoding defined by RFC + 1341. + +The "Q" encoding + + The "Q" encoding is similar to the "Quoted-Printable" content- + transfer-encoding defined in RFC 1341. It is designed to allow text + containing mostly ASCII characters to be decipherable on an ASCII + terminal without decoding. + + + + +Moore [Page 3] + +RFC 1342 Non-ASCII Mail Headers June 1992 + + + 1. Any 8-bit value may be represented by a "=" followed by two + hexadecimal digits. For example, if the character set in use + were ISO-8859-1, the "=" character would thus be encoded as + "=3D", and a SPACE by "=20". + + 2. The 8-bit hexadecimal value 20 (e.g., IS0-8859-1 SPACE) may be + represented as "_" (underscore, ASCII 95.). (This character may + not pass through some internetwork mail gateways, but its use + will greatly enhance readability of "Q" encoded data with mail + readers that do not support this encoding.) Note that the "_" + always represents hexadecimal 20, even if the SPACE character + occupies a different code position in the character set in use. + + 3. 8-bit values which correspond to printable ASCII characters other + than "=", "?", "_" (underscore), and SPACE may be represented as + those characters. (But see "Use of encoded-words in message + headers", below). + +Character sets + + In an encoded-word, the character set associated with the unencoded + text is specified by a charset. A charset can be any of the + character set names allowed in an RFC 1341 "charset" parameter of a + "text/plain" body part. (See section 7.1.1 of RFC 1341 for a list of + valid charset parameters). + + When there is a possibility of using more than one character set to + represent the text in an encoded-word, and in the absence of private + agreements between sender and recipients of a message, it is + recommended that members of the ISO-8859-* series be used in + preference to other character sets. Among the various ISO-8859-* + character sets, the lowest-numbered set which contains all of the + required characters should be used. + +Use of encoded-words in message headers + + A sequence of one or more encoded-words is used to represent non- + ASCII textual data within a header field. An encoded-word must be + separated from an adjacent encoded-word, "word", "text", "ctext", or + "special" by a linear white-space character or a newline. When + displaying a particular header field" (in the RFC 822 sense) + containing one or more encoded-words, an unencoded SPACE character + that immediately follows the encoded-word is not displayed. A + newline that immediately follows an encoded-word is not displayed + unless the encoded-word is the last token in that "field". (This is + to allow the use of multiple encoded-words to represent long strings + of unencoded text, without having to separate encoded-words where + spaces occur in the unencoded text.) + + + +Moore [Page 4] + +RFC 1342 Non-ASCII Mail Headers June 1992 + + + An encoded-word may appear in a message header or body part header + according to the following rules: + +- An encoded-word may replace a "text" token (as defined by RFC 822) in: + (1) a Subject or Comments header field, (2) any extension message + header field, (3) any user-defined message header field, or (4) any + RFC 1341 body part header field (such as Content-Description) for + which the field body contains only "text"s. + +- An encoded-word may appear within a comment delimited by "(" and ")", + i.e., wherever a "ctext" is allowed. More precisely, the RFC 822 EBNF + definition for "comment" is amended as follows: + + comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" + + A "Q"-encoded encoded-word which appears in a comment MUST NOT contain + the characters "(", ")" or "\". + +- As a replacement for a "word" entity within a "phrase", for example, + one that precedes an address in a From, To, or Cc header. The EBNF + definition for phrase from RFC 822 thus becomes: + + phrase = 1*(encoded-word / word) + + In this case the set of characters that may be used in a "Q"-encoded + encoded-word is restricted to: <upper and lower case ASCII letters, + decimal digits, "!", "*", "+", "-", "/", "=", and "_" (underscore, + ASCII 95.)>. + + These are the ONLY locations where an encoded-word may appear. In + particular, an encoded-word MUST NOT appear in any portion of an + "address". In addition, an encoded-word MUST NOT be used in a + Received header field. + + Whenever such words appear in a header being displayed, an enlightened + mail reader will decode the text and render it appropriately. + + Only textual data (printable and white space characters) should be + encoded using this scheme. However, since these encoding schemes + allow the encoding of arbitrary 8-bit values, mail readers that + implement this decoding should also ensure that display of the + decoded data on the recipient's terminal will not cause unwanted + side-effects. + + Use of these methods to encode non-textual data (e.g., pictures or + sounds) is not defined by this memo. Use of encoded-words to + represent strings of purely ASCII characters is allowed, but + discouraged. + + + +Moore [Page 5] + +RFC 1342 Non-ASCII Mail Headers June 1992 + + +Recognition of encoded-words in message headers. + + An encoded-word may be distinguished from an ordinary "word", "text", + or "ctext", as follows: An encoded-word begins with "=?", ends with + "?=", contains exactly four "?" characters including the delimiters, + and is followed by a SPACE or newline. If the "word", "text", or + "ctext" does not meet the above tests, it should be displayed as it + appears in the message header. + + If the mail reader does not support the character set used, it may + either display the encoded-word as ordinary text (i.e., as it appears + in the header), or it may substitute an appropriate message + indicating that the decoded text could not be displayed. + +Conformance + + A mail composing program claiming compliance with this specification + MUST ensure that any string of printable ASCII characters in a + message header that begins with "=?" and ends with "?=" be a valid + encoded-word. + + A mail reading program claiming compliance with this specification + must be able to distinguish encoded-words from "text", "ctext", or + "word"s anytime they appear in appropriate places in message headers. + The program must be able to display unencoded text if the character + set is "US-ASCII". For the ISO-8859-* character sets, the mail + reading program must at least be able to display the characters which + are also in the ASCII set. + +Examples + + From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu> + To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk> + CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <PIRARD@vm1.ulg.ac.be> + Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= + =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= + + From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <ojarnef@admin.kth.se> + To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se + Subject: Time for ISO 10646? + + To: Dave Crocker <dcrocker@mordor.stanford.edu> + Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se + From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@nada.kth.se> + Subject: Re: RFC-HDR care and feeding + + + + + + +Moore [Page 6] + +RFC 1342 Non-ASCII Mail Headers June 1992 + + + From: Nathaniel Borenstein <nsb@thumper.bellcore.com> + (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=) + To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed + <ned@innosoft.com>, + Keith Moore <moore@cs.utk.edu> + Subject: Test of new header generator + MIME-Version: 1.0 + Content-type: text/plain; charset=ISO-8859-1 + +References + + [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail + Extensions): Mechanisms for Specifying and Describing the Format + of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, + June 1992. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", RFC 822, UDEL, August 1982. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville TN 37996-1301 + + EMail: moore@cs.utk.edu + + + + + + + + + + + + + + + + + + + + +Moore [Page 7] +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc1348.txt b/Documentation/en/rfc/rfc1348.txt new file mode 100644 index 00000000..d9e5dea0 --- /dev/null +++ b/Documentation/en/rfc/rfc1348.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group B. Manning +Request for Comments: 1348 Rice University +Updates: RFCs 1034, 1035 July 1992 + + + DNS NSAP RRs + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. Discussion and suggestions for improvement are requested. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Table of Contents + + Introduction ..................................................... 1 + Background ....................................................... 1 + NSAP RR .......................................................... 2 + NSAP-PTR RR ...................................................... 2 + REFERENCES and BIBLIOGRAPHY ...................................... 3 + Security Considerations .......................................... 4 + Author's Address ................................................. 4 + +Introduction + + This RFC defines the format of two new Resource Records (RRs) for the + Domain Name System (DNS), and reserves corresponding DNS type + mnemonic and numerical codes. This format may be used with the any + proposal that has variable length addresses, but is targeted for CLNP + use. + + This memo assumes that the reader is familiar with the DNS [3,4]. + +Background + + This section describes an experimental representation of NSAP + addresses in the DNS. There are several reasons to take this approch. + First, it provides simple documentation of the correct addresses to + use in static configurations of CLNP compliant hosts and routers. + + NSAP support requires that a new DNS resource record entry type + ("NSAP") be defined, to store longer Internet (i.e., NSAP) addresses. + This resource record allows mapping from DNS names to NSAP addresses, + and will contain entries for systems which are able to run Internet + applications, over TCP or UDP, over CLNP. + + + + +Manning [Page 1] + +RFC 1348 DNS NSAP RRs July 1992 + + + The backward translation (from NSAP address to DNS name) is + facilitated by definition of an associated resource record. This + resource record is known as "NSAP-PTR", and is used in a manner + analogous to the existing "in-addr.arpa". + + These RRs are intended for use in a proposal [6] by one of the + members of the NOOP WG to address the next-generation internet. + +The NSAP RR + + The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal). + + An NSAP (Network Service Access Protocol) number is a unique string + to OSI transport service. + + The numbering plan follows RFC 1237 and associated OSI definitions + for NSAP format. + + NSAP has the following format: + + <owner> <ttl> <class> NSAP <length> <NSAP-address> + + All fields are required. + + <length> identifies the number of octets in the <NSAP-address> as + defined by the various national and international authorities. + + <NSAP-address> enumerates the actual octet values assigned by the + assigning authority. Its format in master files is a <character- + string> syntactically identical to that used in TXT and HINFO. + + The format of NSAP is class insensitive. NSAP RR causes no + additional section processing. + + For example: + +foo.bar.com. IN NSAP 21 47000580ffff000000321099991111222233334444 +host.school.de IN NSAP 17 39276f3100111100002222333344449876 + + The RR data is the ASCII representation of the digits. It is encoded + as two <character-strings>, i.e., count followed by characters. + +The NSAP-PTR RR + + The NSAP-PTR RR is defined with mnemonic NSAP-PTR and a type code 23 + (decimal). + + Its function is analogous to the PTR record used for IP addresses + + + +Manning [Page 2] + +RFC 1348 DNS NSAP RRs July 1992 + + + [4,7]. + + NSAP-PTR has the following format: + + <NSAP-suffix> <ttl> <class> NSAP-PTR <owner> + + All fields are required. + + <NSAP-suffix> enumerates the actual octet values assigned by the + assigning authority for the LOCAL network. Its format in master + files is a <character-string> syntactically identical to that used in + TXT and HINFO. + + The format of NSAP-PTR is class insensitive. NSAP-PTR RR causes no + additional section processing. + + For example: + + In net ff08000574.nsap-in-addr.arpa: + + 444433332222111199990123000000ff NSAP-PTR foo.bar.com. + + Or in net 11110031f67293.nsap-in-addr.arpa: + + 67894444333322220000 NSAP-PTR host.school.de. + + The RR data is the ASCII representation of the digits. It is encoded + as a <character-string>. + +REFERENCES and BIBLIOGRAPHY + + [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network + Information Center, SRI International, November 1987. + + [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, + Network Information Center, SRI International, November, 1987. + + [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC + 1034, USC/Information Sciences Institute, November 1987. + + [4] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, USC/Information Sciences Institute, + November 1987. + + [5] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI + NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, + July 1991. + + + + +Manning [Page 3] + +RFC 1348 DNS NSAP RRs July 1992 + + + [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), + A Simple Proposal for Internet Addressing and Routing", + Digital Equipment Corporation, RFC 1347, June 1992. + + [7] Mockapetris, P., "DNS Encoding of Network Names and Other Types", + RFC 1101, USC/Information Sciences Institute, April 1989. + + [8] ISO/IEC. Information Processing Systems -- Data Communications + -- Network Service Definition Addendum 2: Network Layer Address- + ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1, + Switzerland, 1988. + + [9] Bryant, P., "NSAPs", PB660, IPTAG/92/23, SCIENCE AND ENGINEERING + RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992. + +Security Considerations + + Security issues are not addressed in this memo. + +Author's Address + + Bill Manning + Rice University - ONCS + PO Box 1892 + 6100 South Main + Houston, Texas 77251-1892 + + Phone: +1.713.285.5415 + EMail: bmanning@rice.edu + + + + + + + + + + + + + + + + + + + + + + +Manning [Page 4] +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc1425.txt b/Documentation/en/rfc/rfc1425.txt new file mode 100644 index 00000000..a1182655 --- /dev/null +++ b/Documentation/en/rfc/rfc1425.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group J. Klensin, WG Chair +Request for Comments: 1425 United Nations University + N. Freed, Editor + Innosoft International, Inc. + M. Rose + Dover Beach Consulting, Inc. + E. Stefferud + Network Management Associates, Inc. + D. Crocker + The Branch Office + February 1993 + + + SMTP Service Extensions + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +1. Abstract + + This memo defines a framework for extending the SMTP service by + defining a means whereby a server SMTP can inform a client SMTP as to + the service extensions it supports. Standard extensions to the SMTP + service are registered with the Internet Assigned Numbers Authority + (IANA). This framework does not require modification of existing + SMTP clients or servers unless the features of the service extensions + are to be requested or provided. + +2. Introduction + + The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable, + effective basis for the relay function of message transfer agents. + Although a decade old, SMTP has proven remarkably resilient. + Nevertheless, the need for a number of protocol extensions has become + evident. Rather than describing these extensions as separate and + haphazard entities, this document enhances SMTP in a straightforward + fashion that provides a framework in which all future extensions can + be built in a single consistent way. + +3. Framework for SMTP Extensions + + For the purpose of service extensions to SMTP, SMTP relays a mail + object containing an envelope and a content. + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 1] + +RFC 1425 SMTP Service Extensions February 1993 + + + (1) The SMTP envelope is straightforward, and is sent as a + series of SMTP protocol units: it consists of an + originator address (to which error reports should be + directed); a delivery mode (e.g., deliver to recipient + mailboxes); and, one or more recipient addresses. + + (2) The SMTP content is sent in the SMTP DATA protocol unit + and has two parts: the headers and the body. The headers + form a collection of field/value pairs structured + according to RFC 822 [2], whilst the body, if structured, + is defined according to MIME [3]. The content is textual + in nature, expressed using the US ASCII repertoire (ANSI + X3.4-1986). Although extensions (such as MIME) may relax + this restriction for the content body, the content + headers are always encoded using the US ASCII repertoire. + The algorithm defined in [4] is used to represent header + values outside the US ASCII repertoire, whilst still + encoding them using the US ASCII repertoire. + + Although SMTP is widely and robustly deployed, some parts of the + Internet community might wish to extend the SMTP service. This memo + defines a means whereby both an extended SMTP client and server may + recognize each other as such and the server can inform the client as + to the service extensions that it supports. + + It must be emphasized that any extension to the SMTP service should + not be considered lightly. SMTP's strength comes primarily from its + simplicity. Experience with many protocols has shown that: + + protocols with few options tend towards ubiquity, whilst + protocols with many options tend towards obscurity. + + This means that each and every extension, regardless of its benefits, + must be carefully scrutinized with respect to its implementation, + deployment, and interoperability costs. In many cases, the cost of + extending the SMTP service will likely outweigh the benefit. + + Given this environment, the framework for the extensions described in + this memo consists of: + + (1) a new SMTP command (section 4) + + (2) a registry of SMTP service extensions (section 5) + + (3) additional parameters to the SMTP MAIL FROM and RCPT TO + commands (section 6). + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 2] + +RFC 1425 SMTP Service Extensions February 1993 + + +4. The EHLO command + + A client SMTP supporting SMTP service extensions should start an SMTP + session by issuing the EHLO command instead of the HELO command. If + the SMTP server supports the SMTP service extensions it will give a + successful response (see section 4.1), a failure response (see 4.2), + or an error response (4.3). If the SMTP server does not support any + SMTP service extensions it will generate an error response (see + section 4.4). + + The syntax for this command, using the ABNF notation of [2], is: + + ehlo-cmd ::= "EHLO" SP domain CR LF + + If successful, the server SMTP responds with code 250. On failure, + the server SMTP responds with code 550. On error, the server SMTP + responds with one of codes 500, 501, 502, 504, or 421. + + This command is issued instead of the HELO command, and may be issued + at any time that a HELO command would be appropriate. That is, if + the EHLO command is issued, and a successful response is returned, + then a subsequent HELO or EHLO command will result in the server SMTP + replying with code 503. A client SMTP must not cache any information + returned if the EHLO command succeeds. That is, a client SMTP must + issue the EHLO command at the start of each SMTP session if + information about extended facilities is needed. + +4.1. Successful response + + If the server SMTP implements and is able to perform the EHLO + command, it will return code 250. This indicates that both the + server and client SMTP are in the initial state, that is, there is no + transaction in progress and all state tables and buffers are cleared. + + Normally, this response will be a multiline reply. Each line of the + response contains a keyword and, optionally, one or more parameters. + The syntax for a positive response, using the ABNF notation of [2], + is: + + + + + + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 3] + +RFC 1425 SMTP Service Extensions February 1993 + + + ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF + / ( "250-" domain [ SP greeting ] CR LF + *( "250-" ehlo-line CR LF ) + "250" SP ehlo-line CR LF ) + + ; the usual HELO chit-chat + greeting ::= 1*<any character other than CR or LF> + + ehlo-line ::= ehlo-keyword *( SP ehlo-param ) + + ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on ehlo-keyword + ehlo-param ::= 1*<any CHAR excluding SP and all + control characters (US ASCII 0-31 + inclusive)> + + ALPHA ::= <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 10 numeric characters + (0 through 9)> + + CR ::= <the carriage-return character + (ASCII decimal code 13)> + LF ::= <the line-feed character + (ASCII decimal code 10)> + SP ::= <the space character + (ASCII decimal code 32)> + + Although EHLO keywords may be specified in upper, lower, or mixed + case, they must always be recognized and processed in a case- + insensitive manner. This is simply an extension of practices begun in + RFC 821. + + The IANA maintains a registry of standard SMTP service extensions. + Associated with each such extension is a corresponding EHLO keyword + value. Each service extension registered with the IANA is defined by + a standards-track RFC, and such a definition includes: + + (1) the textual name of the SMTP service extension; + + (2) the EHLO keyword value associated with the extension; + + (3) the syntax and possible values of parameters associated + with the EHLO keyword value; + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 4] + +RFC 1425 SMTP Service Extensions February 1993 + + + (4) any additional SMTP verbs associated with the extension + (additional verbs will usually be, but are not required + to be, the same as the EHLO keyword value); + + (5) any new parameters the extension associates with the MAIL + FROM or RCPT TO verbs; and, + + (6) how support for the extension affects the behavior of a + server and client SMTP. + + In addition, any EHLO keyword value that starts with an upper or + lower case "X" refers to a local SMTP service extension, which is + used through bilateral, rather than standardized, agreement. Keywords + beginning with "X" may not be used in a registered service extension. + + Any keyword values presented in the EHLO response that do not begin + with "X" must correspond to an SMTP service extension registered with + IANA. A conforming server must not offer non "X" prefixed keyword + values that are not described in a registered extension. + + Additional verbs are bound by the same rules as EHLO keywords; + specifically, verbs begining with "X" are local extensions that may + not be standardized and verbs not beginning with "X" must always be + registered. + +4.2. Failure response + + If for some reason the server SMTP is unable to list the service + extensions it supports, it will return code 554. + + In the case of a failure response, the client SMTP should issue + either the HELO or QUIT command. + +4.3. Error responses from extended servers + + If the server SMTP recognizes the EHLO command, but the command + argument is unacceptable, it will return code 501. + + If the server SMTP recognizes, but does not implement, the EHLO + command, it will return code 502. + + If the server SMTP determines that the SMTP service is no longer + available (e.g., due to imminent system shutdown), it will return + code 421. + + In the case of any error response, the client SMTP should issue + either the HELO or QUIT command. + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 5] + +RFC 1425 SMTP Service Extensions February 1993 + + +4.4. Responses from servers without extensions + + A server SMTP that conforms to RFC 821 but does not support the + extensions specified here will not recognize the EHLO command and + will consequently return code 500, as specified in RFC 821. + +5. Initial IANA Registry + + The IANA's initial registry of SMTP service extensions consists of + these entries: + + Service Ext EHLO Keyword Parameters Verb Added Behavior + ------------- ------------ ---------- ---------- ------------------ + Send SEND none SEND defined in RFC 821 + Send or Mail SOML none SOML defined in RFC 821 + Send and Mail SAML none SAML defined in RFC 821 + Expand EXPN none EXPN defined in RFC 821 + Help HELP none HELP defined in RFC 821 + Turn TURN none TURN defined in RFC 821 + + which correspond to those SMTP commands which are defined as optional + in [5]. (The mandatory SMTP commands, according to [5], are HELO, + MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.) + +6. MAIL FROM and RCPT TO Parameters + + It is recognized that several of the extensions planned for SMTP will + make use of additional parameters associated with the MAIL FROM and + RCPT TO command. The syntax for these commands, again using the ABNF + notation of [2] as well as underlying definitions from [1], is: + + esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF + esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) + esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] + esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on esmtp-keyword + esmtp-value ::= 1*<any CHAR excluding "=", SP, and all + control characters (US ASCII 0-31 + inclusive)> + + ; The following commands are extended to + ; accept extended parameters. + inner-esmtp-cmd ::= ("MAIL FROM:<" reverse-path ">") / + ("RCPT TO:<" forward-path ">") + + All esmtp-keyword values must be registered as part of the IANA + registration process described above. This definition only provides + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 6] + +RFC 1425 SMTP Service Extensions February 1993 + + + the framework for future extension; no extended MAIL FROM or RCPT TO + parameters are defined by this RFC. + +6.1. Error responses + + If the server SMTP does not recognize or cannot implement one or more + of the parameters associated with a particular MAIL FROM or RCPT TO + command, it will return code 555. + + If for some reason the server is temporarily unable to accomodate one + or more of the parameters associated with a MAIL FROM or RCPT TO + command, and if the definition of the specific parameter does not + mandate the use of another code, it should return code 455. + + Errors specific to particular parameters and their values will be + specified in the parameter's defining RFC. + +7. Received: Header Field Annotation + + SMTP servers are required to add an appropriate Received: field to + the headers of all messages they receive. A "with ESMTP" clause + should be added to this field when any SMTP service extensions are + used. "ESMTP" is hereby added to the list of standard protocol names + registered with IANA. + +8. Usage Examples + + (1) An interaction of the form: + + S: <wait for connection on TCP port 25> + C: <open connection to server> + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250 dbc.mtview.ca.us says hello + ... + + indicates that the server SMTP implements only those SMTP + commands which are defined as mandatory in [5]. + + (2) In contrast, an interaction of the form: + + S: <wait for connection on TCP port 25> + C: <open connection to server> + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250-dbc.mtview.ca.us says hello + S: 250-EXPN + S: 250-HELP + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 7] + +RFC 1425 SMTP Service Extensions February 1993 + + + S: 250-8BITMIME + S: 250-XONE + S: 250 XVRB + ... + + indicates that the server SMTP also implements the SMTP + EXPN and HELP commands, one standard service extension + (8BITMIME), and two non-standard service extensions (XONE + and XVRB). + + (3) Finally, a server that does not support SMTP service + extensions would act as follows: + + S: <wait for connection on TCP port 25> + C: <open connection to server> + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 500 Command not recognized: EHLO + ... + + The 500 response indicates that the server SMTP does not + implement the extensions specified here. The client + would normally send RSET to reset the connection, and, + after getting a successful reply, send a HELO command and + proceed as specified in RFC 821. + +9. Security Considerations + + This RFC does not discuss security issues and is not believed to + raise any security issues not already endemic in electronic mail and + present in fully conforming implementations of RFC-821. It does + provide an announcement of server mail capabilities via the response + to the EHLO verb. However, all information provided by announcement + of any of the initial set of service extensions defined by this RFC + can be readily deduced by selective probing of the verbs required to + transport and deliver mail. The security implications of service + extensions described in other RFCs should be dealt with in those + RFCs. + +10. Acknowledgements + + This document represents a synthesis of the ideas of many people and + reactions to the ideas and proposals of others. Randall Atkinson, + Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas + and text sufficient to be considered co-authors. Other important + suggestions, text, or encouragement came from Harald Alvestrand, Jim + Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per + Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 8] + +RFC 1425 SMTP Service Extensions February 1993 + + + Miller, Dan Oscarsson, Julian Onions, Rayan Zachariassen, and the + contributions of the entire IETF SMTP Working Group. Of course, none + of the individuals are necessarily responsible for the combination of + ideas represented here. Indeed, in some cases, the response to a + particular criticism was to accept the problem identification but to + include an entirely different solution from the one originally + proposed. + +11. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1341, Bellcore, Innosoft, June 1992. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1342, University of Tennessee, June 1992. + + [5] Braden, R., "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, USC/Information Sciences Institute, + October 1989. + +12. Chair, Editor, and Authors' Addresses + + John Klensin, WG Chair + United Nations University + PO Box 500, Charles Street Station + Boston, MA 02114-0500 USA + + Phone: +1 617 227 8747 + Fax: +1 617 491 6266 + Email: klensin@infoods.unu.edu + + + Ned Freed, Editor + Innosoft International, Inc. + 250 West First Street, Suite 240 + Claremont, CA 91711 USA + + Phone: +1 909 624 7907 + Fax: +1 909 621 5319 + Email: ned@innosoft.com + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 9] + +RFC 1425 SMTP Service Extensions February 1993 + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Moutain View, CA 94043-2186 USA + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + Email: mrose@dbc.mtview.ca.us + + + Einar A. Stefferud + Network Management Associates, Inc. + 17301 Drey Lane + Huntington Beach, CA, 92647-5615 USA + + Phone: +1 714 842 3711 + Fax: +1 714 848 2091 + Email: stef@nma.com + + + David H. Crocker + The Branch Office + USA + + Email: dcrocker@mordor.stanford.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 10] +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc1426.txt b/Documentation/en/rfc/rfc1426.txt new file mode 100644 index 00000000..6569f4c8 --- /dev/null +++ b/Documentation/en/rfc/rfc1426.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group J. Klensin, WG Chair +Request for Comments: 1426 United Nations University + N. Freed, Editor + Innosoft International, Inc. + M. Rose + Dover Beach Consulting, Inc. + E. Stefferud + Network Management Associates, Inc. + D. Crocker + The Branch Office + February 1993 + + + SMTP Service Extension + for 8bit-MIMEtransport + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +1. Abstract + + This memo defines an extension to the SMTP service whereby an SMTP + content body containing octets outside of the US ASCII octet range + (hex 00-7F) may be relayed using SMTP. + +2. Introduction + + Although SMTP is widely and robustly deployed, various extensions + have been requested by parts of the Internet community. In + particular, a significant portion of the Internet community wishes to + exchange messages in which the content body consists of a MIME + message [3] containing arbitrary octet-aligned material. This memo + uses the mechanism described in [5] to define an extension to the + SMTP service whereby such contents may be exchanged. Note that this + extension does NOT eliminate the possibility of an SMTP server + limiting line length; servers are free to implement this extension + but nevertheless set a line length limit no lower than 1000 octets. + +3. Framework for the 8bit MIME Transport Extension + + The 8bit MIME transport extension is laid out as follows: + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 1] + +RFC 1426 SMTP 8bit-MIMEtransport February 1993 + + + (1) the name of the SMTP service extension defined here is + 8bit-MIMEtransport; + + (2) the EHLO keyword value associated with the extension is + 8BITMIME; + + (3) no parameter is used with the 8BITMIME EHLO keyword; + + (4) one optional parameter using the keyword BODY is added to + the MAIL FROM command. The value associated with this + parameter is a keyword indicating whether a 7bit message + (in strict compliance with [1]) or a MIME message (in + strict compliance with [3]) with arbitrary octet content + is being sent. The syntax of the value is as follows, + using the ABNF notation of [2]: + + body-value ::= "7BIT" / "8BITMIME" + + (5) no additional SMTP verbs are defined by this extension; + and, + + (6) the next section specifies how support for the extension + affects the behavior of a server and client SMTP. + +4. The 8bit-MIMEtransport service extension + + When a client SMTP wishes to submit (using the MAIL command) a + content body consisting of a MIME message containing arbitrary + octet-aligned material, it first issues the EHLO command to the + server SMTP. If the server SMTP responds with code 250 to the EHLO + command, and the response includes the EHLO keyword value 8BITMIME, + then the server SMTP is indicating that it supports the extended MAIL + command and will accept MIME messages containing arbitrary octet- + aligned material. + + The extended MAIL command is issued by a client SMTP when it wishes + to transmit a content body consisting of a MIME message containing + arbitrary octet-aligned material. The syntax for this command is + identical to the MAIL command in [1], except that a BODY parameter + must appear after the address. + + The complete syntax of this extended command is defined in [5]. The + esmtp-keyword is BODY and the syntax for esmtp-value is given by the + syntax for body-value shown above. + + The value associated with the BODY parameter indicates whether the + content body which will be passed using the DATA command consists of + a MIME message containing some arbitrary octet-aligned material + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 2] + +RFC 1426 SMTP 8bit-MIMEtransport February 1993 + + + ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT"). + + A server which supports the 8-bit MIME transport service extension + shall preserve all bits in each octet passed using the DATA command. + + Naturally, the usual SMTP data-stuffing algorithm applies so that a + content which contains the five-character sequence of + + <CR> <LF> <DOT> <CR> <LF> + + or a content that begins with the three-character sequence of + + <DOT> <CR> <LF> + + does not prematurely terminate the transfer of the content. Further, + it should be noted that the CR-LF pair immediately preceeding the + final dot is considered part of the content. Finally, although the + content body contains arbitrary octet-aligned material, the length of + each line (number of octets between two CR-LF pairs), is still + subject to SMTP server line length restrictions (which may allow as + few as 1000 octets on a single line). + + Once a server SMTP supporting the 8bit-MIMEtransport service + extension accepts a content body containing octets with the high- + order (8th) bit set, the server SMTP must deliver or relay the + content in such a way as to preserve all bits in each octet. + + If a server SMTP does not support the 8-bit MIME transport extension + (either by not responding with code 250 to the EHLO command, or by + not including the EHLO keyword value 8BITMIME in its response), then + the client SMTP must not, under any circumstances, attempt to + transfer a content which contains characters outside the US ASCII + octet range (hex 00-7F). + + A client SMTP has two options in this case: first, it may implement + a gateway transformation to convert the message into valid 7bit MIME, + or second, or may treat this as a permanent error and handle it in + the usual manner for delivery failures. The specifics of the + transformation from 8bit MIME to 7bit MIME are not described by this + RFC; the conversion is nevertheless constrained in the following + ways: + + (1) it must cause no loss of information; MIME transport + encodings must be employed as needed to insure this is + the case, and + + (2) the resulting message must be valid 7bit MIME. + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 3] + +RFC 1426 SMTP 8bit-MIMEtransport February 1993 + + +5. Usage Example + + The following dialogue illustrates the use of the 8bit-MIMEtransport + service extension: + + S: <wait for connection on TCP port 25> + C: <open connection to server> + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250-dbc.mtview.ca.us says hello + S: 250 8BITMIME + C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME + S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok + C: RCPT TO:<mrose@dbc.mtview.ca.us> + S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok + C: DATA + S: 354 Send 8BITMIME message, ending in CRLF.CRLF. + ... + C: . + S: 250 OK + C: QUIT + S: 250 Goodbye + +6. Security Considerations + + This RFC does not discuss security issues and is not believed to + raise any security issues not already endemic in electronic mail and + present in fully conforming implementations of [1]. + +7. Acknowledgements + + This document represents a synthesis of the ideas of many people and + reactions to the ideas and proposals of others. Randall Atkinson, + Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas + and text sufficient to be considered co-authors. Other important + suggestions, text, or encouragement came from Harald Alvestrand, Jim + Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per + Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. + Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John + Wagner, Rayan Zachariassen, and the contributions of the entire IETF + SMTP Working Group. Of course, none of the individuals are + necessarily responsible for the combination of ideas represented + here. Indeed, in some cases, the response to a particular criticism + was to accept the problem identification but to include an entirely + different solution from the one originally proposed. + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 4] + +RFC 1426 SMTP 8bit-MIMEtransport February 1993 + + +8. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1341, Bellcore, Innosoft, June 1992. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1342, University of Tennessee, June 1992. + + [5] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, + E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United + Nations University, Innosoft International, Inc., Dover Beach + Consulting, Inc., Network Management Associates, Inc., The Branch + Office, February 1993. + + [6] Partridge, C., "Mail Routing and the Domain System", RFC 974, + BBN, January 1986. + +9. Chair, Editor, and Authors' Addresses + + John Klensin, WG Chair + United Nations University + PO Box 500, Charles Street Station + Boston, MA 02114-0500 USA + + Phone: +1 617 227 8747 + Fax: +1 617 491 6266 + Email: klensin@infoods.unu.edu + + + Ned Freed, Editor + Innosoft International, Inc. + 250 West First Street, Suite 240 + Claremont, CA 91711 USA + + Phone: +1 909 624 7907 + Fax: +1 909 621 5319 + Email: ned@innosoft.com + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 5] + +RFC 1426 SMTP 8bit-MIMEtransport February 1993 + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Moutain View, CA 94043-2186 USA + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + Email: mrose@dbc.mtview.ca.us + + + Einar A. Stefferud + Network Management Associates, Inc. + 17301 Drey Lane + Huntington Beach, CA, 92647-5615 USA + + Phone: +1 714 842 3711 + Fax: +1 714 848 2091 + Email: stef@nma.com + + + David H. Crocker + The Branch Office + USA + + Email: dcrocker@mordor.stanford.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 6] +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc1522.txt b/Documentation/en/rfc/rfc1522.txt new file mode 100644 index 00000000..25bfd6bc --- /dev/null +++ b/Documentation/en/rfc/rfc1522.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 1522 University of Tennessee +Obsoletes: 1342 September 1993 +Category: Standards Track + + + MIME (Multipurpose Internet Mail Extensions) Part Two: + Message Header Extensions for Non-ASCII Text + +Status of this Memo + + This RFC specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" for the standardization state and status + of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo describes an extension to the message format defined in RFC + 1521 [1], to allow the representation of character sets other than + ASCII in RFC 822 (STD 11) message headers. The extensions described + were designed to be highly compatible with existing Internet mail + handling software, and to be easily implemented in mail readers that + support RFC 1521. + +1. Introduction + + RFC 1521 describes a mechanism for denoting textual body parts which + are coded in various character sets, as well as methods for encoding + such body parts as sequences of printable ASCII characters. This + memo describes similar techniques to allow the encoding of non-ASCII + text in various portions of a RFC 822 [2] message header, in a manner + which is unlikely to confuse existing message handling software. + + Like the encoding techniques described in RFC 1521, the techniques + outlined here were designed to allow the use of non-ASCII characters + in message headers in a way which is unlikely to be disturbed by the + quirks of existing Internet mail handling programs. In particular, + some mail relaying programs are known to (a) delete some message + header fields while retaining others, (b) rearrange the order of + addresses in To or Cc fields, (c) rearrange the (vertical) order of + header fields, and/or (d) "wrap" message headers at different places + than those in the original message. In addition, some mail reading + programs are known to have difficulty correctly parsing message + headers which, while legal according to RFC 822, make use of + backslash-quoting to "hide" special characters such as "<", ",", or + ":", or which exploit other infrequently-used features of that + + + +Moore [Page 1] + +RFC 1522 MIME Part Two September 1993 + + + specification. + + While it is unfortunate that these programs do not correctly + interpret RFC 822 headers, to "break" these programs would cause + severe operational problems for the Internet mail system. The + extensions described in this memo therefore do not rely on little- + used features of RFC 822. + + Instead, certain sequences of "ordinary" printable ASCII characters + (known as "encoded-words") are reserved for use as encoded data. The + syntax of encoded-words is such that they are unlikely to + "accidentally" appear as normal text in message headers. + Furthermore, the characters used in encoded-words are restricted to + those which do not have special meanings in the context in which the + encoded-word appears. + + Generally, an "encoded-word" is a sequence of printable ASCII + characters that begins with "=?", ends with "?=", and has two "?"s in + between. It specifies a character set and an encoding method, and + also includes the original text encoded as graphic ASCII characters, + according to the rules for that encoding method. + + A mail composer that implements this specification will provide a + means of inputting non-ASCII text in header fields, but will + translate these fields (or appropriate portions of these fields) into + encoded-words before inserting them into the message header. + + A mail reader that implements this specification will recognize + encoded-words when they appear in certain portions of the message + header. Instead of displaying the encoded-word "as is", it will + reverse the encoding and display the original text in the designated + character set. + + NOTES + + This memo relies heavily on notation and terms defined STD 11, RFC + 822 and RFC 1521. In particular, the syntax for the ABNF used in + this memo is defined in STD 11, RFC 822, as well as many of the + terms used in the grammar for the header extensions defined here. + Successful implementation of this protocol extension requires + careful attention to the details of both STD 11, RFC 822 and RFC + 1521. + + When the term "ASCII" appears in this memo, it refers to the "7- + Bit American Standard Code for Information Interchange", ANSI + X3.4-1986. The MIME charset name for this character set is "US- + ASCII". When not specifically referring to the MIME charset name, + this document uses the term "ASCII", both for brevity and for + + + +Moore [Page 2] + +RFC 1522 MIME Part Two September 1993 + + + consistency with STD 11, RFC 822. However, implementors are + warned that the character set name must be spelled "US-ASCII" in + MIME message and body part headers. + +2. Syntax of encoded-words + + An "encoded-word" is defined by the following ABNF grammar. The + notation of RFC 822 is used, with the exception that white space + characters MAY NOT appear between components of an encoded-word. + + encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" + + charset = token ; see section 3 + + encoding = token ; see section 4 + + token = 1*<Any CHAR except SPACE, CTLs, and especials> + + especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " + <"> / "/" / "[" / "]" / "?" / "." / "=" + + encoded-text = 1*<Any printable ASCII character other + than "?" or SPACE> + ; (but see "Use of encoded-words in message + ; headers", section 5) + + Both "encoding" and "charset" names are case-independent. Thus the + charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the + encoding named "Q" may be spelled either "Q" or "q". + + An encoded-word may not be more than 75 characters long, including + charset, encoding, encoded-text, and delimiters. If it is desirable + to encode more text than will fit in an encoded-word of 75 + characters, multiple encoded-words (separated by CRLF SPACE) may be + used. + + While there is no limit to the length of a multiple-line header + field, each line of a header field that contains one or more + encoded-words is limited to 76 characters. + + The length restrictions are included not only to ease + interoperability through internetwork mail gateways, but also to + impose a limit on the amount of lookahead a header parser must employ + (while looking for a final ?= delimiter) before it can decide whether + a token is an encoded-word or something else. + + The characters which may appear in encoded-text are further + restricted by the rules in section 5. + + + +Moore [Page 3] + +RFC 1522 MIME Part Two September 1993 + + +3. Character sets + + The "charset" portion of an encoded-word specifies the character set + associated with the unencoded text. A charset can be any of the + character set names allowed in an RFC 1521 "charset" parameter of a + "text/plain" body part, or any character set name registered with + IANA for use with the MIME text/plain content-type [3]. (See section + 7.1.1 of RFC 1521 for a list of charsets defined in that document). + + Some character sets use code-switching techniques to switch between + "ASCII mode" and other modes. If unencoded text in an encoded-word + contains control codes to switch out of ASCII mode, it must also + contain additional control codes such that ASCII mode is again + selected at the end of the encoded-word. (This rule applies + separately to each encoded-word, including adjacent encoded-words + within a single header field.) + + When there is a possibility of using more than one character set to + represent the text in an encoded-word, and in the absence of private + agreements between sender and recipients of a message, it is + recommended that members of the ISO-8859-* series be used in + preference to other character sets. + +4. Encodings + + Initially, the legal values for "encoding" are "Q" and "B". These + encodings are described below. The "Q" encoding is recommended for + use when most of the characters to be encoded are in the ASCII + character set; otherwise, the "B" encoding should be used. + Nevertheless, a mail reader which claims to recognize encoded-words + MUST be able to accept either encoding for any character set which it + supports. + + Only a subset of the printable ASCII characters may be used in + encoded-text. Space and tab characters are not allowed, so that the + beginning and end of an encoded-word are obvious. The "?" character + is used within an encoded-word to separate the various portions of + the encoded-word from one another, and thus cannot appear in the + encoded-text portion. Other characters are also illegal in certain + contexts. For example, an encoded-word in a "phrase" preceding an + address in a From header field may not contain any of the "specials" + defined in RFC 822. Finally, certain other characters are disallowed + in some contexts, to ensure reliability for messages that pass + through internetwork mail gateways. + + The "B" encoding automatically meets these requirements. The "Q" + encoding allows a wide range of printable characters to be used in + non-critical locations in the message header (e.g., Subject), with + + + +Moore [Page 4] + +RFC 1522 MIME Part Two September 1993 + + + fewer characters available for use in other locations. + +4.1. The "B" encoding + + The "B" encoding is identical to the "BASE64" encoding defined by RFC + 1521. + +4.2. The "Q" encoding + + The "Q" encoding is similar to the "Quoted-Printable" content- + transfer-encoding defined in RFC 1521. It is designed to allow text + containing mostly ASCII characters to be decipherable on an ASCII + terminal without decoding. + + (1) Any 8-bit value may be represented by a "=" followed by two + hexadecimal digits. For example, if the character set in use + were ISO-8859-1, the "=" character would thus be encoded as + "=3D", and a SPACE by "=20". (Upper case should be used for + hexadecimal digits "A" through "F".) + + (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be + represented as "_" (underscore, ASCII 95.). (This character may + not pass through some internetwork mail gateways, but its use + will greatly enhance readability of "Q" encoded data with mail + readers that do not support this encoding.) Note that the "_" + always represents hexadecimal 20, even if the SPACE character + occupies a different code position in the character set in use. + + (3) 8-bit values which correspond to printable ASCII characters other + than "=", "?", "_" (underscore), and SPACE may be represented as + those characters. (But see section 5 for restrictions.) + +5. Use of encoded-words in message headers + + An encoded-word may appear in a message header or body part header + according to the following rules: + + (1) An encoded-word may replace a "text" token (as defined by RFC + 822) in any Subject or Comments header field, any extension + message header field, or any RFC 1521 body part field for which + the field body is defined as "*text". An encoded-word may also + appear in any user-defined ("X-") message or body part header + field. + + Ordinary ASCII text and encoded-words may appear together in the + same header field. However, an encoded-word that appears in a + header field defined as "*text" MUST be separated from any + adjacent encoded-word or "text" by linear-white-space. + + + +Moore [Page 5] + +RFC 1522 MIME Part Two September 1993 + + + (2) An encoded-word may appear within a comment delimited by "(" and + ")", i.e., wherever a "ctext" is allowed. More precisely, the + RFC 822 ABNF definition for "comment" is amended as follows: + + comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" + + A "Q"-encoded encoded-word which appears in a comment MUST NOT + contain the characters "(", ")" or " encoded-word that appears in + a "comment" MUST be separated from any adjacent encoded-word or + "ctext" by linear-white-space. + + (3) As a replacement for a "word" entity within a "phrase", for + example, one that precedes an address in a From, To, or Cc + header. The ABNF definition for phrase from RFC 822 thus + becomes: + + phrase = 1*(encoded-word / word) + + In this case the set of characters that may be used in a "Q"- + encoded encoded-word is restricted to: <upper and lower case + ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=", and + "_" (underscore, ASCII 95.)>. An encoded-word that appears + within a "phrase" MUST be separated from any adjacent "word", + "text" or "special" by linear-white-space. + + These are the ONLY locations where an encoded-word may appear. In + particular, an encoded-word MUST NOT appear in any portion of an + "addr-spec". In addition, an encoded-word MUST NOT be used in a + Received header field. + + Each encoded-word MUST encode an integral number of octets. The + encoded-text in each encoded-word must be well-formed according to + the encoding specified; the encoded-text may not be continued in the + next encoded-word. (For example, "=?charset?Q?=?= =?charset?Q?AB?=" + would be illegal, because the two hex digits "AB" must follow the "=" + in the same encoded-word.) + + Each encoded-word MUST represent an integral number of characters. A + multi-octet character may not be split across adjacent encoded-words. + + Only printable and white space character data should be encoded using + this scheme. However, since these encoding schemes allow the + encoding of arbitrary octet values, mail readers that implement this + decoding should also ensure that display of the decoded data on the + recipient's terminal will not cause unwanted side-effects. + + Use of these methods to encode non-textual data (e.g., pictures or + sounds) is not defined by this memo. Use of encoded-words to + + + +Moore [Page 6] + +RFC 1522 MIME Part Two September 1993 + + + represent strings of purely ASCII characters is allowed, but + discouraged. In rare cases it may be necessary to encode ordinary + text that looks like an encoded-word. + +6. Support of encoded-words by mail readers + +6.1. Recognition of encoded-words in message headers + + A mail reader must parse the message and body part headers according + to the rules in RFC 822 to correctly recognize encoded-words. + + Encoded-words are to be recognized as follows: + + (1) Any message or body part header field defined as "*text", or any + user-defined header field, should be parsed as follows: Beginning + at the start of the field-body and immediately following each + occurrence of linear-white-space, each sequence of up to 75 + printable characters (not containing any linear-white-space) + should be examined to see if it is an encoded-word according to + the syntax rules in section 2. Any other sequence of printable + characters should be treated as ordinary ASCII text. + + (2) Any header field not defined as "*text" should be parsed + according to the syntax rules for that header field. However, + any "word" that appears within a "phrase" should be treated as an + encoded-word if it meets the syntax rules in section 2. + Otherwise it should be treated as an ordinary "word". + + (3) Within a "comment", any sequence of up to 75 printable characters + (not containing linear-white-space), that meets the syntax rules + in section 2, should be treated as an encoded-word. Otherwise it + should be treated as normal comment text. + +6.2. Display of encoded-words + + Any encoded-words so recognized are decoded, and if possible, the + resulting unencoded text is displayed in the original character set. + + When displaying a particular header field that contains multiple + encoded-words, any linear-white-space that separates a pair of + adjacent encoded-words is ignored. (This is to allow the use of + multiple encoded-words to represent long strings of unencoded text, + without having to separate encoded-words where spaces occur in the + unencoded text.) + + In the event other encodings are defined in the future, and the mail + reader does not support the encoding used, it may either (a) display + the encoded-word as ordinary text, or (b) substitute an appropriate + + + +Moore [Page 7] + +RFC 1522 MIME Part Two September 1993 + + + message indicating that the text could not be decoded. + + If the mail reader does not support the character set used, it may + (a) display the encoded-word as ordinary text (i.e., as it appears in + the header), (b) make a "best effort" to display using such + characters as are available, or (c) substitute an appropriate message + indicating that the decoded text could not be displayed. + + If the character set being used employs code-switching techniques, + display of the encoded text implicitly begins in "ASCII mode". In + addition, the mail reader must ensure that the output device is once + again in "ASCII mode" after the encoded-word is displayed. + +6.3. Mail reader handling of incorrectly formed encoded-words + + It is possible that an encoded-word that is legal according to the + syntax defined in section 2, is incorrectly formed according to the + rules for the encoding being used. For example: + + (1) An encoded-word which contains characters which are not legal for + a particular encoding (for example, a '-' in the "B" encoding), + is incorrectly formed. + + (2) Any encoded-word which encodes a non-integral number of + characters or octets is incorrectly formed. + + A mail reader need not attempt to display the text associated with an + encoded-word that is incorrectly formed. However, a mail reader MUST + NOT prevent the display or handling of a message because an encoded- + word is incorrectly formed. + +7. Conformance + + A mail composing program claiming compliance with this specification + MUST ensure that any string of non-white-space printable ASCII + characters within a "*text" or "*ctext" that begins with "=?" and + ends with "?=" be a valid encoded-word. ("begins" means: at the + start of the field-body or immediately following linear-white-space; + "ends" means: at the end of the field-body or immediately preceding + linear-white-space.) In addition, any "word" within a "phrase" that + begins with "=?" and ends with "?=" must be a valid encoded-word. + + A mail reading program claiming compliance with this specification + must be able to distinguish encoded-words from "text", "ctext", or + "word"s, according to the rules in section 6, anytime they appear in + appropriate places in message headers. It must support both the "B" + and "Q" encodings for any character set which it supports. The + program must be able to display the unencoded text if the character + + + +Moore [Page 8] + +RFC 1522 MIME Part Two September 1993 + + + set is "US-ASCII". For the ISO-8859-* character sets, the mail + reading program must at least be able to display the characters which + are also in the ASCII set. + +8. Examples + + From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu> + To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk> + CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <PIRARD@vm1.ulg.ac.be> + Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= + =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= + + From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <ojarnef@admin.kth.se> + To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se + Subject: Time for ISO 10646? + + To: Dave Crocker <dcrocker@mordor.stanford.edu> + Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se + From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@nada.kth.se> + Subject: Re: RFC-HDR care and feeding + + From: Nathaniel Borenstein <nsb@thumper.bellcore.com> + (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=) + To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed + <ned@innosoft.com>, Keith Moore <moore@cs.utk.edu> + Subject: Test of new header generator + MIME-Version: 1.0 + Content-type: text/plain; charset=ISO-8859-1 + +9. References + + [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail + Extensions) Part One: Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1521, Bellcore, + Innosoft, September 1993. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, + RFC 1340, USC/Information Sciences Institute, July 1992. + + + + + + + + + + +Moore [Page 9] + +RFC 1522 MIME Part Two September 1993 + + +10. Security Considerations + + Security issues are not discussed in this memo. + +11. Author's Address + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville TN 37996-1301 + + EMail: moore@cs.utk.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore [Page 10] +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc1558.txt b/Documentation/en/rfc/rfc1558.txt new file mode 100644 index 00000000..1bb5bd96 --- /dev/null +++ b/Documentation/en/rfc/rfc1558.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group T. Howes +Request for Comments: 1558 University of Michigan +Category: Informational December 1993 + + + A String Representation of LDAP Search Filters + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + The Lightweight Directory Access Protocol (LDAP) [1] defines a + network representation of a search filter transmitted to an LDAP + server. Some applications may find it useful to have a common way of + representing these search filters in a human-readable form. This + document defines a human-readable string format for representing LDAP + search filters. + +1. LDAP Search Filter Definition + + An LDAP search filter is defined in [1] as follows: + + Filter ::= CHOICE { + and [0] SET OF Filter, + or [1] SET OF Filter, + not [2] Filter, + equalityMatch [3] AttributeValueAssertion, + substrings [4] SubstringFilter, + greaterOrEqual [5] AttributeValueAssertion, + lessOrEqual [6] AttributeValueAssertion, + present [7] AttributeType, + approxMatch [8] AttributeValueAssertion + } + + SubstringFilter ::= SEQUENCE { + type AttributeType, + SEQUENCE OF CHOICE { + initial [0] LDAPString, + any [1] LDAPString, + final [2] LDAPString + } + } + + + + + +Howes [Page 1] + +RFC 1558 Representation of LDAP Filters December 1993 + + + AttributeValueAssertion ::= SEQUENCE + attributeType AttributeType, + attributeValue AttributeValue + } + + AttributeType ::= LDAPString + + AttributeValue ::= OCTET STRING + + LDAPString ::= OCTET STRING + + where the LDAPString above is limited to the IA5 character set. The + AttributeType is a string representation of the attribute object + identifier in dotted OID format (e.g., "2.5.4.10"), or the shorter + string name of the attribute (e.g., "organizationName", or "o"). The + AttributeValue OCTET STRING has the form defined in [2]. The Filter + is encoded for transmission over a network using the Basic Encoding + Rules defined in [3], with simplifications described in [1]. + +2. String Search Filter Definition + + The string representation of an LDAP search filter is defined by the + following BNF. It uses a prefix format. + + <filter> ::= '(' <filtercomp> ')' + <filtercomp> ::= <and> | <or> | <not> | <item> + <and> ::= '&' <filterlist> + <or> ::= '|' <filterlist> + <not> ::= '!' <filter> + <filterlist> ::= <filter> | <filter> <filterlist> + <item> ::= <simple> | <present> | <substring> + <simple> ::= <attr> <filtertype> <value> + <filtertype> ::= <equal> | <approx> | <greater> | <less> + <equal> ::= '=' + <approx> ::= '~=' + <greater> ::= '>=' + <less> ::= '<=' + <present> ::= <attr> '=*' + <substring> ::= <attr> '=' <initial> <any> <final> + <initial> ::= NULL | <value> + <any> ::= '*' <starval> + <starval> ::= NULL | <value> '*' <starval> + <final> ::= NULL | <value> + + <attr> is a string representing an AttributeType, and has the format + defined in [1]. <value> is a string representing an AttributeValue, + or part of one, and has the form defined in [2]. If a <value> must + contain one of the characters '*' or '(' or ')', these characters + + + +Howes [Page 2] + +RFC 1558 Representation of LDAP Filters December 1993 + + + should be escaped by preceding them with the backslash '\' character. + +3. Examples + + This section gives a few examples of search filters written using + this notation. + + (cn=Babs Jensen) + (!(cn=Tim Howes)) + (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) + (o=univ*of*mich*) + +4. Security Considerations + + Security issues are not discussed in this memo. + +5. References + + [1] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access + Protocol", RFC 1487, Performance Systems International, + University of Michigan, ISODE Consortium, July 1993. + + [2] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The String + Representation of Standard Attribute Syntaxes", RFC 1488, + University of Michigan, ISODE Consortium, Performance Systems + International, NeXor Ltd., July 1993. + + [3] "Specification of Basic Encoding Rules for Abstract Syntax + Notation One (ASN.1)", CCITT Recommendation X.209, 1988. + +6. Author's Address + + Tim Howes + University of Michigan + ITD Research Systems + 535 W William St. + Ann Arbor, MI 48103-4943 + USA + + Phone: +1 313 747-4454 + EMail: tim@umich.edu + + + + + + + + + + +Howes [Page 3] +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc1590.txt b/Documentation/en/rfc/rfc1590.txt new file mode 100644 index 00000000..02629b71 --- /dev/null +++ b/Documentation/en/rfc/rfc1590.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group J. Postel +Request for Comments: 1590 ISI +Updates: 1521 March 1994 +Category: Informational + + + Media Type Registration Procedure + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + Several protocols allow the use of data representing different + "media" such as text, images, audio, and video, and within such media + different encoding styles, such as (in video) jpeg, gif, ief, and + tiff. The Multimedia Internet Message Extensions (MIME) protocol [1] + defined several initial types of multimedia data objects, and a + procedure for registering additional types with the Internet Assigned + Numbers Authority (IANA). Several questions have been raised about + the requirements and administrative procedure for registering MIME + content-type and subtypes, and the use of these Media Types for other + applications. This document addresses these issues and specifies a + procedure for the registration of new Media Types (content- + type/subtypes). It also generalizes the scope of use of these Media + Types to make it appropriate to use the same registrations and + specifications with other applications. + +1. Introduction + + RFC 1521 [1] defines a procedure for the registration of new data + types for use with the Multimedia Internet Message Extensions (MIME). + This registration mechanism was designed to make the identifiers for + a given data type available for use and to prevent naming conflicts. + With the growth of new multi-media protocols and access mechanisms, + this process has the promise of forming a unified general + registration service for Internet Protocols. These types, previously + called "MIME Types", are now called "Media Types". + + The registration process for Media Types (content-type/subtypes) was + initially defined in the context of the asynchronous mail + environments. In this mail environment, there is a need to limit the + number of possible Media Types to increase the likelihood of + interoperability when the capabilities of the remote mail system are + not known. As Media Types are used in new environments, where the + + + +IANA [Page 1] + +RFC 1590 Media Type Registration Procedure March 1994 + + + proliferation of Media Types is not a hindrance to interoperability, + the original procedure is excessively restrictive and needs to be + generalized. + + This document addresses the specific questions raised and provides an + administrative procedure for the registration of Media Types. This + procedure also address the registration requirements needed for the + mapping of Object Identifiers (OIDs) for X.400 MHS use to Media + Types. + +2. Media Type Registration Procedure + + The following procedure has been implemented by the IANA for review + and approval of new Media Types. This is not a formal standards + process, but rather an administrative procedure intended to allow + community comment and sanity checking without excessive time delay. + +2.1 Present the Request for Registration to the Community + + Send a proposed Media Type (content-type/subtype) to the "ietf- + types@cs.utk.edu" mailing list. This mailing list has been + established for the sole purpose of reviewing proposed Media Types. + Proposed content-types are not formally registered and must use the + "x-" notation for the subtype name. + + The intent of the public posting is to solicit comments and feedback + on the choice of content-type/subtype name, the unambiguity of the + references with respect to versions and external profiling + information, the choice of which OIDs to use, and a review of the + security considerations section. It should be noted that the + proposed Media Type does not need to make sense for every possible + application. If the Media Type is intended for a limited or specific + use, this should be noted in the submission. + +2.2 Submit the Content Type to the IANA for Registration + + After two weeks, submit the proposed Media Type to the IANA for + registration. The request and supporting documentation should be + sent to "iana@isi.edu". Provided a reasonable review period has + elapsed, the IANA will register the Media Type, assign an OID under + the IANA branch, and make the Media Type registration available to + the community. + + + + + + + + + +IANA [Page 2] + +RFC 1590 Media Type Registration Procedure March 1994 + + + The Media Type registrations will be posted in the anonymous FTP + directory "ftp.isi.edu:in-notes/media-types" and the Media Type will + be listed in the periodically issued "Assigned Numbers" RFC [2]. The + Media Type description may be published as an Informational RFC by + sending it to "rfc-editor@isi.edu" (please follow the instructions to + RFC authors [3]). + +3. Clarifications On Specific Issues + +3.1 MIME Requirements for a Limited Number of Content-Types + + Issue: In the asynchronous mail environment, where information on + the capabilities of the remote mail agent is not available to the + sender, maximum interoperability is attained by restricting the + number of content-types used to those "common" content-types expected + to be widely implemented. This was asserted as a reason to limit the + number of possible content-types and resulted in a registration + process with a significant hurdle and delay for those registering + content-types. + + Comment: The need for "common" content-types formats does not + require limiting the registration of new content-types. This + restriction may, in fact, hinder interoperability by causing separate + registration authorities for specific applications which may register + values in conflict with or otherwise incompatible with each other. + If a limited set of content-types recommended for a particular + application, that should be asserted by a separate applicability + statement specific for the application and/or environment. + +3.2 Requirements for a Published Specification + + Issue: Content-Type registration requires an RFC specifying the data + format or a reference to a published specification of the data + stream. This requirement may be overly restrictive for the use of + content-type registration for file attachments and distribution + because a public specification may not be available for a number of + widely used and exchanged objects. + + Comment: MIME required the documentation of a specific content-type + to allow the unambiguous identification of a defined type. This + intent is met by the identification of a particular software package + and version when registering the content-type and is allowed for + registration. The appropriateness of using a Media Type with an + unavailable specification should not be an issue in the registration. + + + + + + + +IANA [Page 3] + +RFC 1590 Media Type Registration Procedure March 1994 + + +3.3 Identification of Security Considerations + + Issue: The registration process requires the identification of any + known security problems with the content-type. + + Comment: It is not required that the content-type be secure or that + it be free from risks, but that the known risks be identified. + Publication of a content-type does not require an exhaustive security + review, and the security considerations section is subject to + continuing evaluation. Additional security considerations should be + periodically published in an RFC by IANA. + +3.4. Recommendations and Standards Status + + Issue: The registration of a data type does not imply endorsement, + approval, or recommendation by IANA or IETF or even certification + that the specification is adequate. + + Comment: To become Internet Standards, protocol, data objects, or + whatever must go through the IETF standards process. This is too + difficult and to lengthly a process for the convenient and practical + need to register Media Types. It is expected that applicability + statements for particular applications will be published from time to + time that recommend implementation of, and support for, data types + that have proven particularly useful in those contexts. + +4. Security Considerations + + This memo does not address specific security issues but outlines a + security review process for Media Types. + +5. Acknowledgements + + Most of the words in this RFC were written by other people -- + primarily John Klensin and Greg Vaudreuil -- and my contribution has + been to slightly modify some sentences, delete some phrases, and to + rearrange some paragraphs. This means that i am responsible for all + the bad ideas and mangled English, and they deserve the credit (and + rightly) all the good ideas. + + + + + + + + + + + + +IANA [Page 4] + +RFC 1590 Media Type Registration Procedure March 1994 + + +6. Author's Address + + Jon Postel + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292 + + Phone: 310-822-1511 + Fax: 310-823-6714 + EMail: Postel@ISI.EDU + +7. References + + [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail + Extensions) Part One: Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1521, Bellcore, + Innosoft, September 1993. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, + USC/Information Sciences Institute, July 1992. + + [3] Postel,J., "Instructions to RFC Authors", RFC 1543, + USC/Information Sciences Institute, October 1993. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +IANA [Page 5] + +RFC 1590 Media Type Registration Procedure March 1994 + + +Appendix A -- IANA Registration Procedures for Media Types + + MIME has been carefully designed to have extensible mechanisms, and + it is expected that the set of content-type/subtype pairs and their + associated parameters will grow significantly with time. Several + other MIME fields, notably character set names, access-type + parameters for the message/external-body type, and possibly even + Content-Transfer-Encoding values, are likely to have new values + defined over time. + + In general, parameters in the content-type header field are used to + convey supplemental information for various content types, and their + use is defined when the content-type and subtype are defined. New + parameters should not be defined as a way to introduce new + functionality. + + In order to ensure that the content-type and subtype (that is Media + Type) values are developed in an orderly, well-specified, and public + manner, MIME and other applications use the registration process for + Media Types defined in this RFC which uses the Internet Assigned + Numbers Authority (IANA) as a central registry for such values. + + In order to simplify and standardize this Media Type registration + process, this appendix gives templates for the registration of new + values with IANA. Each of these is given in the form of an email + message template, to be filled in by the registering party. + + Registration of New Content-type/subtype Values: + + Note that MIME is generally expected to be extended by subtypes. If + a new fundamental top-level type is needed, its specification must be + published as an RFC or submitted in a form suitable to become an RFC, + and be subject to the Internet standards process. + + + + + + + + + + + + + + + + + + +IANA [Page 6] + +RFC 1590 Media Type Registration Procedure March 1994 + + + ================================================================== + + To: IANA@isi.edu + Subject: Registration of new Media Type content-type/subtype + + Media Type name: + + (If the above is not an existing top-level Media Type, please + explain why an existing type cannot be used.) + + Media subtype name: + + Required parameters: + + Optional parameters: + + Encoding considerations: + + Security considerations: + + Published specification: + + (The published specification must be an Internet RFC or RFC-to-be + if a new top-level type is being defined, and must be a publicly + available specification in any case.) + + Person & email address to contact for further information: + + ================================================================== + + + + + + + + + + + + + + + + + + + + + + +IANA [Page 7] +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc1637.txt b/Documentation/en/rfc/rfc1637.txt new file mode 100644 index 00000000..24f18b73 --- /dev/null +++ b/Documentation/en/rfc/rfc1637.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group B. Manning +Request for Comments: 1637 Rice University +Obsoletes: 1348 R. Colella +Category: Experimental NIST + June 1994 + + + DNS NSAP Resource Records + + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Abstract + + The Internet is moving towards the deployment of an OSI lower layers + infrastructure. This infrastructure comprises the connectionless + network protocol (CLNP) and supporting routing protocols. Also + required as part of this infrastructure is support in the Domain Name + System (DNS) for mapping between names and NSAP addresses. + + This document defines the format of one new Resource Record (RR) for + the DNS for domain name-to-NSAP mapping. The RR may be used with any + NSAP address format. This document supercedes RFC 1348. + + NSAP-to-name translation is accomplished through use of the PTR RR + (see STD 13, RFC 1035 for a description of the PTR RR). This paper + describes how PTR RRs are used to support this translation. + + + + + + + + + + + + + + + + + + + +Manning & Colella [Page 1] + +RFC 1637 DNS NSAP RRs June 1994 + + +1. Introduction + + The Internet is moving towards the deployment of an OSI lower layers + infrastructure. This infrastructure comprises the connectionless + network protocol (CLNP) [6] and supporting routing protocols. Also + required as part of this infrastructure is support in the Domain Name + System (DNS) [8] [9] for mapping between domain names and OSI Network + Service Access Point (NSAP) addresses [7] [Note: NSAP and NSAP + address are used interchangeably throughout this memo]. + + This document defines the format of one new Resource Record (RR) for + the DNS for domain name-to-NSAP mapping. The RR may be used with any + NSAP address format. + + NSAP-to-name translation is accomplished through use of the PTR RR + (see RFC 1035 for a description of the PTR RR). This paper describes + how PTR RRs are used to support this translation. + + This memo assumes that the reader is familiar with the DNS. Some + familiarity with NSAPs is useful; see [2] or [7] for additional + information. + +2. Background + + The reason for defining DNS mappings for NSAPs is to support CLNP in + the Internet. Debugging with CLNP ping and traceroute is becoming + more difficult with only numeric NSAPs as the scale of deployment + increases. Current debugging is supported by maintaining and + exchanging a configuration file with name/NSAP mappings similar in + function to hosts.txt. This suffers from the lack of a central + coordinator for this file and also from the perspective of scaling. + The former is the most serious short-term problem. Scaling of a + hosts.txt-like solution has well-known long-term scaling + difficiencies. + + A second reason for this work is the proposal to use CLNP as an + alternative to IP: "TCP and UDP with Bigger Addresses (TUBA), A + Simple Proposal for Internet Addressing and Routing" [1]. For this to + be practical, the DNS must be capable of supporting CLNP addresses. + +3. Scope + + The methods defined in this paper are applicable to all NSAP formats. + This includes support for the notion of a custom-defined NSAP format + based on an AFI obtained by the IAB for use in the Internet. + + As a point of reference, there is a distinction between registration + and publication of addresses. For IP addresses, the IANA is the root + + + +Manning & Colella [Page 2] + +RFC 1637 DNS NSAP RRs June 1994 + + + registration authority and the DNS a publication method. For NSAPs, + addendum two of the network service definition, ISO8348/Ad2 [7] is + the root registration authority and this memo defines how the DNS is + used as a publication method. + +4. Structure of NSAPs + + NSAPs are hierarchically structured to allow distributed + administration and efficient routing. Distributed administration + permits subdelegated addressing authorities to, as allowed by the + delegator, further structure the portion of the NSAP space under + their delegated control. Accomodating this distributed authority + requires that there be little or no a priori knowledge of the + structure of NSAPs built into DNS resolvers and servers. + + For the purposes of this memo, NSAPs can be thought of as a tree of + identifiers. The root of the tree is ISO8348/Ad2 [7], and has as its + immediately registered subordinates the one-octet Authority and + Format Identifiers (AFIs) defined there. The size of subsequently- + defined fields depends on which branch of the tree is taken. The + depth of the tree varies according to the authority responsible for + defining subsequent fields. + + An example is the authority under which U.S. GOSIP defines NSAPs [3]. + Under the AFI of 47, NIST (National Institute of Standards and + Technology) obtained a value of 0005 (the AFI of 47 defines the next + field as being two octets consisting of four BCD digits from the + International Code Designator space [4]). NIST defined the subsequent + fields in [3], as shown in Figure 1. The field immediately following + 0005 is a format identifier for the rest of the U.S. GOSIP NSAP + structure, with a hex value of 80. Following this is the three-octet + field, values for which are allocated to network operators; the + registration authority for this field is delegated to GSA (General + Services Administration). + + The last octet of the NSAP is the NSelector (NSel). In practice, the + NSAP minus the NSel identifies the CLNP protocol machine on a given + system, and the NSel identifies the CLNP user. Since there can be + more than one CLNP user (meaning multiple NSel values for a given + "base" NSAP), the representation of the NSAP should be CLNP-user + independent. To achieve this, an NSel value of zero shall be used + with all NSAP values stored in the DNS. An NSAP with NSel=0 + identifies the network layer itself. It is left to the application + retrieving the NSAP to determine the appropriate value to use in that + instance of communication. + + + + + + +Manning & Colella [Page 3] + +RFC 1637 DNS NSAP RRs June 1994 + + + |--------------| + | <-- IDP --> | + |--------------|-------------------------------------| + | AFI | IDI | <-- DSP --> | + |-----|--------|-------------------------------------| + | 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel | + |-----|--------|-----|----|-----|----|-----|----|----| + octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 | + |-----|--------|-----|----|-----|----|-----|----|----| + + IDP Initial Domain Part + AFI Authority and Format Identifier + IDI Initial Domain Identifier + DSP Domain Specific Part + DFI DSP Format Identifier + AA Administrative Authority + Rsvd Reserved + RD Routing Domain Identifier + Area Area Identifier + ID System Identifier + SEL NSAP Selector + + Figure 1: GOSIP Version 2 NSAP structure. + + + When CLNP is used to support TCP and UDP services, the NSel value + used is the appropriate IP PROTO value as registered with the IANA. + For "standard" OSI, the selection of NSel values is left as a matter + of local administration. Administrators of systems that support the + OSI transport protocol [5] in addition to TCP/UDP must select NSels + for use by OSI Transport that do not conflict with the IP PROTO + values. + + In the NSAP RRs in Master Files and in the printed text in this memo, + NSAPs are often represented as a string of "."-separated hex values. + The values correspond to convenient divisions of the NSAP to make it + more readable. For example, the "."-separated fields might correspond + to the NSAP fields as defined by the appropriate authority (ISOC, + RARE, U.S. GOSIP, ANSI, etc.). The use of this notation is strictly + for readability. The "."s do not appear in DNS packets and DNS + servers can ignore them when reading Master Files. For example, a + printable representation of the first four fields of a U.S. GOSIP + NSAP might look like + + 47.0005.80.005a00 + + + + + + +Manning & Colella [Page 4] + +RFC 1637 DNS NSAP RRs June 1994 + + + and a full U.S. GOSIP NSAP might appear as + + 47.0005.80.005a00.0000.1000.0020.00800a123456.00. + + Other NSAP formats have different lengths and different + administratively defined field widths to accomodate different + requirements. For more information on NSAP formats in use see RFC + 1629 [2]. + +5. The NSAP RR + + The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22 + (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP + mapping in the DNS using the NSAP RR operates analogously to IP + address lookup. A query is generated by the resolver requesting an + NSAP RR for a provided domain name. + + NSAP RRs conform to the top level RR format and semantics as defined + in Section 3.2.1 of RFC 1035. + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE = NSAP | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS = IN | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + * NAME: an owner name, i.e., the name of the node to which this + resource record pertains. + + * TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal). + + + + +Manning & Colella [Page 5] + +RFC 1637 DNS NSAP RRs June 1994 + + + * CLASS: two octets containing the RR IN CLASS code of 1. + + * TTL: a 32 bit signed integer that specifies the time interval in + seconds that the resource record may be cached before the source + of the information should again be consulted. Zero values are + interpreted to mean that the RR can only be used for the + transaction in progress, and should not be cached. For example, + SOA records are always distributed with a zero TTL to prohibit + caching. Zero values can also be used for extremely volatile data. + + * RDLENGTH: an unsigned 16 bit integer that specifies the length in + octets of the RDATA field. + + * RDATA: a variable length string of octets containing the NSAP. + The value is the binary encoding of the NSAP as it would appear in + the CLNP source or destination address field. A typical example of + such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is + 20 (decimal); "."s have been omitted to emphasize that they don't + appear in the DNS packets. + + 39840f80005a0000000001e13708002010726e00 + +5.1 Additional Section Processing + + [The specification in this section is necessary for completeness in + describing name server support for TUBA. For the time being, name + servers participating in TUBA demonstrations MAY ELECT to implement + this behavior; it SHOULD NOT be the default behavior of name servers + because the IPng sweepstakes are still outstanding and further + consideration is required for truncation and other issues.] + + RFC 1035 describes the additional section processing (ASP) required + when servers encounter NS records during query processing. From + Section 3.3.11, "NS RDATA format": + + NS records cause both the usual additional section processing to + locate a type A record, and, when used in a referral, a special + search of the zone in which they reside for glue information. + + For TUBA, identical ASP is required on type NSAP records to support + servers and resolvers that use CLNP, either because of preference or + because it is the only internetworking protocol available (i.e., in + the absense of IPv4). Thus, NS records cause ASP which locates a type + NSAP record in addition to a type A record. Both type A and NSAP + records should be returned, if available. + + + + + + +Manning & Colella [Page 6] + +RFC 1637 DNS NSAP RRs June 1994 + + +6. NSAP-to-name Mapping Using the PTR RR + + The PTR RR is defined in RFC 1035. This RR is typically used under + the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names. + + Similarly, the PTR RR is used to map from NSAPs to domain names under + the "NSAP.INT" domain. A domain name is generated from the NSAP + according to the rules described below. A query is sent by the + resolver requesting a PTR RR for the provided domain name. + + A domain name is generated from an NSAP by reversing the hex nibbles + of the NSAP, treating each nibble as a separate subdomain, and + appending the top-level subdomain name "NSAP.INT" to it. For example, + the domain name used in the reverse lookup for the NSAP + + 47.0005.80.005a00.0000.0001.e133.ffffff000162.00 + + would appear as + + 0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \ + 0.8.5.0.0.0.7.4.NSAP.INT. + + [Implementation note: For sanity's sake user interfaces should be + designed to allow users to enter NSAPs using their natural order, + i.e., as they are typically written on paper. Also, arbitrary "."s + should be allowed (and ignored) on input.] + +7. Master File Format + + The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files + conforms to Section 5, "Master Files," of RFC 1035. Below are + examples of the use of these RRs in Master Files to support name-to- + NSAP and NSAP-to-name mapping. + + The NSAP RR introduces a new hex string format for the RDATA field. + The format is "0x" (i.e., a zero followed by an 'x' character) + followed by a variable length string of hex characters (0 to 9, a to + f). The hex string is case-insensitive. "."s (i.e., periods) may be + inserted in the hex string anywhere after the "0x" for readability. + The "."s have no significance other than for readability and are not + propagated in the protocol (e.g., queries or zone transfers). + + + + + + + + + + +Manning & Colella [Page 7] + +RFC 1637 DNS NSAP RRs June 1994 + + + ;;;;;; + ;;;;;; Master File for domain nsap.nist.gov. + ;;;;;; + + + @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( + 1994041800 ; Serial - date + 1800 ; Refresh - 30 minutes + 300 ; Retry - 5 minutes + 604800 ; Expire - 7 days + 3600 ) ; Minimum - 1 hour + IN NS emu.ncsl.nist.gov. + IN NS tuba.nsap.lanl.gov. + ; + ; + $ORIGIN nsap.nist.gov. + ; + ; hosts + ; + bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00 + IN A 129.6.224.161 + IN HINFO PC_486 BSDi1.1(TUBA) + ; + bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00 + IN A 129.6.224.162 + IN HINFO PC_486 BSDi1.1(TUBA) + ; + cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00 + IN A 129.6.224.171 + IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA) + ; + infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00 + IN A 129.6.55.164 + IN HINFO PC/486 BSDi1.0(TUBA) + ; + ; routers + ; + cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00 + IN A 129.6.224.151 + IN A 129.6.225.151 + IN A 129.6.229.151 + ; + 3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00 + IN A 129.6.224.111 + IN A 129.6.225.111 + IN A 129.6.228.111 + + + + + +Manning & Colella [Page 8] + +RFC 1637 DNS NSAP RRs June 1994 + + + ;;;;;; + ;;;;;; Master File for reverse mapping of NSAPs under the + ;;;;;; NSAP prefix: + ;;;;;; + ;;;;;; 47.0005.80.005a00.0000.0001.e133 + ;;;;;; + + + @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( + 1994041800 ; Serial - date + 1800 ; Refresh - 30 minutes + 300 ; Retry - 5 minutes + 604800 ; Expire - 7 days + 3600 ) ; Minimum - 1 hour + IN NS emu.ncsl.nist.gov. + IN NS tuba.nsap.lanl.gov. + ; + ; + $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. + ; + 0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov. + ; + 0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov. + ; + 0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov. + ; + 0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov. + ; + 0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov. + ; + 0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov. + +8. Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + +Manning & Colella [Page 9] + +RFC 1637 DNS NSAP RRs June 1994 + + +9. Authors' Addresses + + Bill Manning + Rice University -- ONCS + P.O. Box 1892 + 6100 South Main + Houston, Texas 77251-1892 + USA + + Phone: +1.713.285.5415 + EMail: bmanning@rice.edu + + + Richard Colella + National Institute of Standards and Technology + Technology/B217 + Gaithersburg, MD 20899 + USA + + Phone: +1 301-975-3627 + Fax: +1 301 590-0932 + EMail: colella@nist.gov + +10. References + + [1] Callon R., "TCP and UDP with Bigger Addresses (TUBA), A Simple + Proposal for Internet Addressing and Routing", RFC 1347, DEC, + June 1992. + + [2] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines + for OSI NSAP Allocation inh the Internet", RFC 1629, NIST, + Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May + 1994. + + [3] GOSIP Advanced Requirements Group. Government Open Systems + Interconnection Profile (GOSIP) Version 2. Federal Information + Processing Standard 146-1, U.S. Department of Commerce, National + Institute of Standards and Technology, Gaithersburg, MD, April + 1991. + + [4] ISO/IEC. Data interchange - structures for the identification of + organization. International Standard 6523, ISO/IEC JTC 1, + Switzerland, 1984. + + [5] ISO/IEC. Connection oriented transport protocol specification. + International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986. + + + + + +Manning & Colella [Page 10] + +RFC 1637 DNS NSAP RRs June 1994 + + + [6] ISO/IEC. Protocol for Providing the Connectionless-mode Network + Service. International Standard 8473, ISO/IEC JTC 1, + Switzerland, 1986. + + [7] ISO/IEC. Information Processing Systems -- Data Communications -- + Network Service Definition Addendum 2: Network Layer Addressing. + International Standard 8348/Addendum 2, ISO/IEC JTC 1, + Switzerland, 1988. + + [8] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD + 13, RFC 1034, USC/Information Sciences Institute, November 1987. + + [9] Mockapetris, P., "Domain Names -- Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Manning & Colella [Page 11] + diff --git a/Documentation/en/rfc/rfc1706.txt b/Documentation/en/rfc/rfc1706.txt new file mode 100644 index 00000000..5b5d8219 --- /dev/null +++ b/Documentation/en/rfc/rfc1706.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group B. Manning +Request for Comments: 1706 ISI +Obsoletes: 1637, 1348 R. Colella +Category: Informational NIST + October 1994 + + + DNS NSAP Resource Records + + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + OSI lower layer protocols, comprising the connectionless network + protocol (CLNP) and supporting routing protocols, are deployed in + some parts of the global Internet. Maintenance and debugging of CLNP + connectivity is greatly aided by support in the Domain Name System + (DNS) for mapping between names and NSAP addresses. + + This document defines the format of one new Resource Record (RR) for + the DNS for domain name-to-NSAP mapping. The RR may be used with any + NSAP address format. + + NSAP-to-name translation is accomplished through use of the PTR RR + (see STD 13, RFC 1035 for a description of the PTR RR). This paper + describes how PTR RRs are used to support this translation. + + This document obsoletes RFC 1348 and RFC 1637. + + + + + + + + + + + + + + + + + + +Manning & Colella [Page 1] + +RFC 1706 DNS NSAP RRs October 1994 + + +1. Introduction + + OSI lower layer protocols, comprising the connectionless network + protocol (CLNP) [5] and supporting routing protocols, are deployed in + some parts of the global Internet. Maintenance and debugging of CLNP + connectivity is greatly aided by support in the Domain Name System + (DNS) [7] [8] for mapping between names and NSAP (network service + access point) addresses [6] [Note: NSAP and NSAP address are used + interchangeably throughout this memo]. + + This document defines the format of one new Resource Record (RR) for + the DNS for domain name-to-NSAP mapping. The RR may be used with any + NSAP address format. + + NSAP-to-name translation is accomplished through use of the PTR RR + (see RFC 1035 for a description of the PTR RR). This paper describes + how PTR RRs are used to support this translation. + + This memo assumes that the reader is familiar with the DNS. Some + familiarity with NSAPs is useful; see [1] or Annex A of [6] for + additional information. + +2. Background + + The reason for defining DNS mappings for NSAPs is to support the + existing CLNP deployment in the Internet. Debugging with CLNP ping + and traceroute has become more difficult with only numeric NSAPs as + the scale of deployment has increased. Current debugging is supported + by maintaining and exchanging a configuration file with name/NSAP + mappings similar in function to hosts.txt. This suffers from the lack + of a central coordinator for this file and also from the perspective + of scaling. The former describes the most serious short-term + problem. Scaling of a hosts.txt-like solution has well-known long- + term scaling difficiencies. + +3. Scope + + The methods defined in this paper are applicable to all NSAP formats. + + As a point of reference, there is a distinction between registration + and publication of addresses. For IP addresses, the IANA is the root + registration authority and the DNS a publication method. For NSAPs, + Annex A of the network service definition, ISO8348 [6], describes the + root registration authority and this memo defines how the DNS is used + as a publication method. + + + + + + +Manning & Colella [Page 2] + +RFC 1706 DNS NSAP RRs October 1994 + + +4. Structure of NSAPs + + NSAPs are hierarchically structured to allow distributed + administration and efficient routing. Distributed administration + permits subdelegated addressing authorities to, as allowed by the + delegator, further structure the portion of the NSAP space under + their delegated control. Accomodating this distributed authority + requires that there be little or no a priori knowledge of the + structure of NSAPs built into DNS resolvers and servers. + + For the purposes of this memo, NSAPs can be thought of as a tree of + identifiers. The root of the tree is ISO8348 [6], and has as its + immediately registered subordinates the one-octet Authority and + Format Identifiers (AFIs) defined there. The size of subsequently- + defined fields depends on which branch of the tree is taken. The + depth of the tree varies according to the authority responsible for + defining subsequent fields. + + An example is the authority under which U.S. GOSIP defines NSAPs [2]. + Under the AFI of 47, NIST (National Institute of Standards and + Technology) obtained a value of 0005 (the AFI of 47 defines the next + field as being two octets consisting of four BCD digits from the + International Code Designator space [3]). NIST defined the subsequent + fields in [2], as shown in Figure 1. The field immediately following + 0005 is a format identifier for the rest of the U.S. GOSIP NSAP + structure, with a hex value of 80. Following this is the three-octet + field, values for which are allocated to network operators; the + registration authority for this field is delegated to GSA (General + Services Administration). + + The last octet of the NSAP is the NSelector (NSel). In practice, the + NSAP minus the NSel identifies the CLNP protocol machine on a given + system, and the NSel identifies the CLNP user. Since there can be + more than one CLNP user (meaning multiple NSel values for a given + "base" NSAP), the representation of the NSAP should be CLNP-user + independent. To achieve this, an NSel value of zero shall be used + with all NSAP values stored in the DNS. An NSAP with NSel=0 + identifies the network layer itself. It is left to the application + retrieving the NSAP to determine the appropriate value to use in that + instance of communication. + + When CLNP is used to support TCP and UDP services, the NSel value + used is the appropriate IP PROTO value as registered with the IANA. + For "standard" OSI, the selection of NSel values is left as a matter + of local administration. Administrators of systems that support the + OSI transport protocol [4] in addition to TCP/UDP must select NSels + for use by OSI Transport that do not conflict with the IP PROTO + values. + + + +Manning & Colella [Page 3] + +RFC 1706 DNS NSAP RRs October 1994 + + + |--------------| + | <-- IDP --> | + |--------------|-------------------------------------| + | AFI | IDI | <-- DSP --> | + |-----|--------|-------------------------------------| + | 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel | + |-----|--------|-----|----|-----|----|-----|----|----| + octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 | + |-----|--------|-----|----|-----|----|-----|----|----| + + IDP Initial Domain Part + AFI Authority and Format Identifier + IDI Initial Domain Identifier + DSP Domain Specific Part + DFI DSP Format Identifier + AA Administrative Authority + Rsvd Reserved + RD Routing Domain Identifier + Area Area Identifier + ID System Identifier + SEL NSAP Selector + + Figure 1: GOSIP Version 2 NSAP structure. + + + In the NSAP RRs in Master Files and in the printed text in this memo, + NSAPs are often represented as a string of "."-separated hex values. + The values correspond to convenient divisions of the NSAP to make it + more readable. For example, the "."-separated fields might correspond + to the NSAP fields as defined by the appropriate authority (RARE, + U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for + readability. The "."s do not appear in DNS packets and DNS servers + can ignore them when reading Master Files. For example, a printable + representation of the first four fields of a U.S. GOSIP NSAP might + look like + + 47.0005.80.005a00 + + and a full U.S. GOSIP NSAP might appear as + + 47.0005.80.005a00.0000.1000.0020.00800a123456.00. + + Other NSAP formats have different lengths and different + administratively defined field widths to accomodate different + requirements. For more information on NSAP formats in use see RFC + 1629 [1]. + + + + + +Manning & Colella [Page 4] + +RFC 1706 DNS NSAP RRs October 1994 + + +5. The NSAP RR + + The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22 + (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP + mapping in the DNS using the NSAP RR operates analogously to IP + address lookup. A query is generated by the resolver requesting an + NSAP RR for a provided domain name. + + NSAP RRs conform to the top level RR format and semantics as defined + in Section 3.2.1 of RFC 1035. + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE = NSAP | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS = IN | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + * NAME: an owner name, i.e., the name of the node to which this + resource record pertains. + + * TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal). + + * CLASS: two octets containing the RR IN CLASS code of 1. + + * TTL: a 32 bit signed integer that specifies the time interval in + seconds that the resource record may be cached before the source + of the information should again be consulted. Zero values are + interpreted to mean that the RR can only be used for the + transaction in progress, and should not be cached. For example, + SOA records are always distributed with a zero TTL to prohibit + caching. Zero values can also be used for extremely volatile data. + + + +Manning & Colella [Page 5] + +RFC 1706 DNS NSAP RRs October 1994 + + + * RDLENGTH: an unsigned 16 bit integer that specifies the length in + octets of the RDATA field. + + * RDATA: a variable length string of octets containing the NSAP. + The value is the binary encoding of the NSAP as it would appear in + the CLNP source or destination address field. A typical example of + such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is + 20 (decimal); "."s have been omitted to emphasize that they don't + appear in the DNS packets. + + 39840f80005a0000000001e13708002010726e00 + + NSAP RRs cause no additional section processing. + +6. NSAP-to-name Mapping Using the PTR RR + + The PTR RR is defined in RFC 1035. This RR is typically used under + the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names. + + Similarly, the PTR RR is used to map from NSAPs to domain names under + the "NSAP.INT" domain. A domain name is generated from the NSAP + according to the rules described below. A query is sent by the + resolver requesting a PTR RR for the provided domain name. + + A domain name is generated from an NSAP by reversing the hex nibbles + of the NSAP, treating each nibble as a separate subdomain, and + appending the top-level subdomain name "NSAP.INT" to it. For example, + the domain name used in the reverse lookup for the NSAP + + 47.0005.80.005a00.0000.0001.e133.ffffff000162.00 + + would appear as + + 0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \ + 0.8.5.0.0.0.7.4.NSAP.INT. + + [Implementation note: For sanity's sake user interfaces should be + designed to allow users to enter NSAPs using their natural order, + i.e., as they are typically written on paper. Also, arbitrary "."s + should be allowed (and ignored) on input.] + +7. Master File Format + + The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files + conforms to Section 5, "Master Files," of RFC 1035. Below are + examples of the use of these RRs in Master Files to support name-to- + NSAP and NSAP-to-name mapping. + + + + +Manning & Colella [Page 6] + +RFC 1706 DNS NSAP RRs October 1994 + + + The NSAP RR introduces a new hex string format for the RDATA field. + The format is "0x" (i.e., a zero followed by an 'x' character) + followed by a variable length string of hex characters (0 to 9, a to + f). The hex string is case-insensitive. "."s (i.e., periods) may be + inserted in the hex string anywhere after the "0x" for readability. + The "."s have no significance other than for readability and are not + propagated in the protocol (e.g., queries or zone transfers). + + + ;;;;;; + ;;;;;; Master File for domain nsap.nist.gov. + ;;;;;; + + + @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( + 1994041800 ; Serial - date + 1800 ; Refresh - 30 minutes + 300 ; Retry - 5 minutes + 604800 ; Expire - 7 days + 3600 ) ; Minimum - 1 hour + IN NS emu.ncsl.nist.gov. + IN NS tuba.nsap.lanl.gov. + ; + ; + $ORIGIN nsap.nist.gov. + ; + ; hosts + ; + bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00 + IN A 129.6.224.161 + IN HINFO PC_486 BSDi1.1 + ; + bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00 + IN A 129.6.224.162 + IN HINFO PC_486 BSDi1.1 + ; + cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00 + IN A 129.6.224.171 + IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA) + ; + infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00 + IN A 129.6.55.164 + IN HINFO PC/486 BSDi1.0(TUBA) + ; + ; routers + ; + cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00 + IN A 129.6.224.151 + + + +Manning & Colella [Page 7] + +RFC 1706 DNS NSAP RRs October 1994 + + + IN A 129.6.225.151 + IN A 129.6.229.151 + ; + 3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00 + IN A 129.6.224.111 + IN A 129.6.225.111 + IN A 129.6.228.111 + + + + + ;;;;;; + ;;;;;; Master File for reverse mapping of NSAPs under the + ;;;;;; NSAP prefix: + ;;;;;; + ;;;;;; 47.0005.80.005a00.0000.0001.e133 + ;;;;;; + + + @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( + 1994041800 ; Serial - date + 1800 ; Refresh - 30 minutes + 300 ; Retry - 5 minutes + 604800 ; Expire - 7 days + 3600 ) ; Minimum - 1 hour + IN NS emu.ncsl.nist.gov. + IN NS tuba.nsap.lanl.gov. + ; + ; + $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. + ; + 0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov. + ; + 0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov. + ; + 0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov. + ; + 0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov. + ; + 0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov. + ; + 0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov. + +8. Security Considerations + + Security issues are not discussed in this memo. + + + + + +Manning & Colella [Page 8] + +RFC 1706 DNS NSAP RRs October 1994 + + +9. Authors' Addresses + + Bill Manning + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA. 90292 + USA + + Phone: +1.310.822.1511 + EMail: bmanning@isi.edu + + + Richard Colella + National Institute of Standards and Technology + Technology/B217 + Gaithersburg, MD 20899 + USA + + Phone: +1 301-975-3627 + Fax: +1 301 590-0932 + EMail: colella@nist.gov + +10. References + + [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines + for OSI NSAP Allocation inh the Internet", RFC 1629, NIST, + Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May + 1994. + + [2] GOSIP Advanced Requirements Group. Government Open Systems + Interconnection Profile (GOSIP) Version 2. Federal Information + Processing Standard 146-1, U.S. Department of Commerce, National + Institute of Standards and Technology, Gaithersburg, MD, April + 1991. + + [3] ISO/IEC. Data interchange - structures for the identification of + organization. International Standard 6523, ISO/IEC JTC 1, + Switzerland, 1984. + + [4] ISO/IEC. Connection oriented transport protocol specification. + International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986. + + [5] ISO/IEC. Protocol for Providing the Connectionless-mode Network + Service. International Standard 8473, ISO/IEC JTC 1, + Switzerland, 1986. + + + + + + +Manning & Colella [Page 9] + +RFC 1706 DNS NSAP RRs October 1994 + + + [6] ISO/IEC. Information Processing Systems -- Data Communications -- + Network Service Definition. International Standard 8348, ISO/IEC + JTC 1, Switzerland, 1993. + + [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD + 13, RFC 1034, USC/Information Sciences Institute, November 1987. + + [8] Mockapetris, P., "Domain Names -- Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Manning & Colella [Page 10] + diff --git a/Documentation/en/rfc/rfc1806.txt b/Documentation/en/rfc/rfc1806.txt new file mode 100644 index 00000000..2b483175 --- /dev/null +++ b/Documentation/en/rfc/rfc1806.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group R. Troost +Request for Comments: 1806 New Century Systems +Category: Experimental S. Dorner + QUALCOMM Incorporated + June 1995 + + + Communicating Presentation Information in + Internet Messages: + The Content-Disposition Header + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Abstract + + This memo provides a mechanism whereby messages conforming to the + [RFC 1521] ("MIME") specification can convey presentational + information. It specifies a new "Content-Disposition" header, + optional and valid for any [RFC 1521] entity ("message" or "body + part"). Two values for this header are described in this memo; one + for the ordinary linear presentation of the body part, and another to + facilitate the use of mail to transfer files. It is expected that + more values will be defined in the future, and procedures are defined + for extending this set of values. + + This document is intended as an extension to [RFC 1521]. As such, the + reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The + information presented herein supplements but does not replace that + found in those documents. + +1. Introduction + + [RFC 1521] specifies a standard format for encapsulating multiple + pieces of data into a single Internet message. That document does not + address the issue of presentation styles; it provides a framework for + the interchange of message content, but leaves presentation issues + solely in the hands of mail user agent (MUA) implementors. + + Two common ways of presenting multipart electronic messages are as a + main document with a list of separate attachments, and as a single + document with the various parts expanded (displayed) inline. The + display of an attachment is generally construed to require positive + action on the part of the recipient, while inline message components + + + +Troost & Dorner Experimental [Page 1] + +RFC 1806 Content-Disposition June 1995 + + + are displayed automatically when the message is viewed. A mechanism + is needed to allow the sender to transmit this sort of presentational + information to the recipient; the Content-Disposition header provides + this mechanism, allowing each component of a message to be tagged + with an indication of its desired presentation semantics. + + Tagging messages in this manner will often be sufficient for basic + message formatting. However, in many cases a more powerful and + flexible approach will be necessary. The definition of such + approaches is beyond the scope of this memo; however, such approaches + can benefit from additional Content-Disposition values and + parameters, to be defined at a later date. + + In addition to allowing the sender to specify the presentational + disposition of a message component, it is desirable to allow her to + indicate a default archival disposition; a filename. The optional + "filename" parameter provides for this. + +2. The Content-Disposition Header Field + + Content-Disposition is an optional header; in its absence, the MUA + may use whatever presentation method it deems suitable. + + It is desirable to keep the set of possible disposition types small + and well defined, to avoid needless complexity. Even so, evolving + usage will likely require the definition of additional disposition + types or parameters, so the set of disposition values is extensible; + see below. + + In the extended BNF notation of [RFC 822], the Content-Disposition + header field is defined as follows: + + disposition := "Content-Disposition" ":" + disposition-type + *(";" disposition-parm) + + disposition-type := "inline" + / "attachment" + / extension-token + ; values are not case-sensitive + + disposition-parm := filename-parm / parameter + + filename-parm := "filename" "=" value; + + `Extension-token', `parameter' and `value' are defined according to + [RFC 822] and [RFC 1521]. + + + + +Troost & Dorner Experimental [Page 2] + +RFC 1806 Content-Disposition June 1995 + + +2.1 The Inline Disposition Type + + A bodypart should be marked `inline' if it is intended to be + displayed automatically upon display of the message. Inline bodyparts + should be presented in the order in which they occur, subject to the + normal semantics of multipart messages. + +2.2 The Attachment Disposition Type + + Bodyparts can be designated `attachment' to indicate that they are + separate from the main body of the mail message, and that their + display should not be automatic, but contingent upon some further + action of the user. The MUA might instead present the user of a + bitmap terminal with an iconic representation of the attachments, or, + on character terminals, with a list of attachments from which the + user could select for viewing or storage. + +2.3 The Filename Parameter + + The sender may want to suggest a filename to be used if the entity is + detached and stored in a separate file. If the receiving MUA writes + the entity to a file, the suggested filename should be used as a + basis for the actual filename, where possible. + + It is important that the receiving MUA not blindly use the suggested + filename. The suggested filename should be checked (and possibly + changed) to see that it conforms to local filesystem conventions, + does not overwrite an existing file, and does not present a security + problem (see Security Considerations below). + + The receiving MUA should not respect any directory path information + that may seem to be present in the filename parameter. The filename + should be treated as a terminal component only. Portable + specification of directory paths might possibly be done in the future + via a separate Content-Disposition parameter, but no provision is + made for it in this draft. + + Current [RFC 1521] grammar restricts parameter values (and hence + Content-Disposition filenames) to US-ASCII. We recognize the great + desirability of allowing arbitrary character sets in filenames, but + it is beyond the scope of this document to define the necessary + mechanisms. We expect that the basic [RFC 1521] `value' + specification will someday be amended to allow use of non-US-ASCII + characters, at which time the same mechanism should be used in the + Content-Disposition filename parameter. + + + + + + +Troost & Dorner Experimental [Page 3] + +RFC 1806 Content-Disposition June 1995 + + + Beyond the limitation to US-ASCII, the sending MUA may wish to bear + in mind the limitations of common filesystems. Many have severe + length and character set restrictions. Short alphanumeric filenames + are least likely to require modification by the receiving system. + + The presence of the filename parameter does not force an + implementation to write the entity to a separate file. It is + perfectly acceptable for implementations to leave the entity as part + of the normal mail stream unless the user requests otherwise. As a + consequence, the parameter may be used on any MIME entity, even + `inline' ones. These will not normally be written to files, but the + parameter could be used to provide a filename if the receiving user + should choose to write the part to a file. + +2.4 Future Extensions and Unrecognized Disposition Types + + In the likely event that new parameters or disposition types are + needed, they should be registered with the IANA, in the manner + specified in [RFC 1521], appendix E. + + Once new disposition types and parameters are defined, there is of + course the likelihood that implementations will see disposition types + and parameters they do not understand. Furthermore, since x-tokens + are allowed, implementations may also see entirely unregistered + disposition types and parameters. + + Unrecognized parameters should be ignored. Unrecognized disposition + types should be treated as `attachment'. The choice of `attachment' + for unrecognized types is made because a sender who goes to the + trouble of producing a Content-Disposition header with a new + disposition type is more likely aiming for something more elaborate + than inline presentation. + + Unless noted otherwise in the definition of a parameter, Content- + Disposition parameters are valid for all dispositions. (In contrast + to [RFC 1521] content-type parameters, which are defined on a per- + content-type basis.) Thus, for example, the `filename' parameter + still means the name of the file to which the part should be written, + even if the disposition itself is unrecognized. + +2.5 Content-Disposition and Multipart + + If a Content-Disposition header is used on a multipart body part, it + applies to the multipart as a whole, not the individual subparts. + The disposition types of the subparts do not need to be consulted + until the multipart itself is presented. When the multipart is + displayed, then the dispositions of the subparts should be respected. + + + + +Troost & Dorner Experimental [Page 4] + +RFC 1806 Content-Disposition June 1995 + + + If the `inline' disposition is used, the multipart should be + displayed as normal; however, an `attachment' subpart should require + action from the user to display. + + If the `attachment' disposition is used, presentation of the + multipart should not proceed without explicit user action. Once the + user has chosen to display the multipart, the individual subpart + dispositions should be consulted to determine how to present the + subparts. + +2.6 Content-Disposition and the Main Message + + It is permissible to use Content-Disposition on the main body of an + [RFC 822] message. + +3. Examples + + Here is a an example of a body part containing a JPEG image that is + intended to be viewed by the user immediately: + + Content-Type: image/jpeg + Content-Disposition: inline + Content-Description: just a small picture of me + + <jpeg data> + + The following body part contains a JPEG image that should be + displayed to the user only if the user requests it. If the JPEG is + written to a file, the file should be named "genome.jpg": + + Content-Type: image/jpeg + Content-Disposition: attachment; filename=genome.jpeg + Content-Description: a complete map of the human genome + + <jpeg data> + + The following is an example of the use of the `attachment' + disposition with a multipart body part. The user should see text- + part-1 immediately, then take some action to view multipart-2. After + taking action to view multipart-2, the user will see text-part-2 + right away, and be required to take action to view jpeg-1. Subparts + are indented for clarity; they would not be so indented in a real + message. + + Content-Type: multipart/mixed; boundary=outer + Content-Description: multipart-1 + + --outer + + + +Troost & Dorner Experimental [Page 5] + +RFC 1806 Content-Disposition June 1995 + + + Content-Type: text/plain + Content-Disposition: inline + Content-Description: text-part-1 + + Some text goes here + + --outer + Content-Type: multipart/mixed; boundary=inner + Content-Disposition: attachment + Content-Description: multipart-2 + + --inner + Content-Type: text/plain + Content-Disposition: inline + Content-Description: text-part-2 + + Some more text here. + + --inner + Content-Type: image/jpeg + Content-Disposition: attachment + Content-Description: jpeg-1 + + <jpeg data> + --inner-- + --outer-- + +4. Summary + + Content-Disposition takes one of two values, `inline' and + `attachment'. 'Inline' indicates that the entity should be + immediately displayed to the user, whereas `attachment' means that + the user should take additional action to view the entity. + + The `filename' parameter can be used to suggest a filename for + storing the bodypart, if the user wishes to store it in an external + file. + +5. Security Considerations + + There are security issues involved any time users exchange data. + While these are not to be minimized, neither does this memo change + the status quo in that regard, except in one instance. + + Since this memo provides a way for the sender to suggest a filename, + a receiving MUA must take care that the sender's suggested filename + does not represent a hazard. Using UNIX as an example, some hazards + would be: + + + +Troost & Dorner Experimental [Page 6] + +RFC 1806 Content-Disposition June 1995 + + + + Creating startup files (e.g., ".login"). + + + Creating or overwriting system files (e.g., + "/etc/passwd"). + + + Overwriting any existing file. + + + Placing executable files into any command search path + (e.g., "~/bin/more"). + + + Sending the file to a pipe (e.g., "| sh"). + + In general, the receiving MUA should never name or place the file + such that it will get interpreted or executed without the user + explicitly initiating the action. + + It is very important to note that this is not an exhaustive list; it + is intended as a small set of examples only. Implementors must be + alert to the potential hazards on their target systems. + +6. References + + [RFC 1521] + Borenstein N., and N. Freed, "MIME (Multipurpose Internet + Mail Extensions) Part One: Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", + RFC 1521, Bellcore, Innosoft, September 1993. + + [RFC 822] + Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822, UDEL, August 1982. + +7. Acknowledgements + +We gratefully acknowledge the help these people provided +during the preparation of this draft: + + Nathaniel Borenstein + Ned Freed + Keith Moore + Dave Crocker + Dan Pritchett + + + + + + + + + +Troost & Dorner Experimental [Page 7] + +RFC 1806 Content-Disposition June 1995 + + +8. Authors' Addresses + + Rens Troost + New Century Systems + 324 East 41st Street #804 + New York, NY, 10017 USA + + Phone: +1 (212) 557-2050 + Fax: +1 (212) 557-2049 + EMail: rens@century.com + + + Steve Dorner + QUALCOMM Incorporated + 6455 Lusk Boulevard + San Diego, CA 92121 + USA + + EMail: sdorner@qualcomm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Troost & Dorner Experimental [Page 8] + diff --git a/Documentation/en/rfc/rfc1876.txt b/Documentation/en/rfc/rfc1876.txt new file mode 100644 index 00000000..a289cffe --- /dev/null +++ b/Documentation/en/rfc/rfc1876.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group C. Davis +Request for Comments: 1876 Kapor Enterprises +Updates: 1034, 1035 P. Vixie +Category: Experimental Vixie Enterprises + T. Goodwin + FORE Systems + I. Dickinson + University of Warwick + January 1996 + + + A Means for Expressing Location Information in the Domain Name System + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +1. Abstract + + This memo defines a new DNS RR type for experimental purposes. This + RFC describes a mechanism to allow the DNS to carry location + information about hosts, networks, and subnets. Such information for + a small subset of hosts is currently contained in the flat-file UUCP + maps. However, just as the DNS replaced the use of HOSTS.TXT to + carry host and network address information, it is possible to replace + the UUCP maps as carriers of location information. + + This RFC defines the format of a new Resource Record (RR) for the + Domain Name System (DNS), and reserves a corresponding DNS type + mnemonic (LOC) and numerical code (29). + + This RFC assumes that the reader is familiar with the DNS [RFC 1034, + RFC 1035]. The data shown in our examples is for pedagogical use and + does not necessarily reflect the real Internet. + + + + + + + + + + + + + + +Davis, et al Experimental [Page 1] + +RFC 1876 Location Information in the DNS January 1996 + + +2. RDATA Format + + MSB LSB + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 0| VERSION | SIZE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 2| HORIZ PRE | VERT PRE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 4| LATITUDE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 6| LATITUDE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 8| LONGITUDE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 10| LONGITUDE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 12| ALTITUDE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 14| ALTITUDE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + (octet) + +where: + +VERSION Version number of the representation. This must be zero. + Implementations are required to check this field and make + no assumptions about the format of unrecognized versions. + +SIZE The diameter of a sphere enclosing the described entity, in + centimeters, expressed as a pair of four-bit unsigned + integers, each ranging from zero to nine, with the most + significant four bits representing the base and the second + number representing the power of ten by which to multiply + the base. This allows sizes from 0e0 (<1cm) to 9e9 + (90,000km) to be expressed. This representation was chosen + such that the hexadecimal representation can be read by + eye; 0x15 = 1e5. Four-bit values greater than 9 are + undefined, as are values with a base of zero and a non-zero + exponent. + + Since 20000000m (represented by the value 0x29) is greater + than the equatorial diameter of the WGS 84 ellipsoid + (12756274m), it is therefore suitable for use as a + "worldwide" size. + +HORIZ PRE The horizontal precision of the data, in centimeters, + expressed using the same representation as SIZE. This is + the diameter of the horizontal "circle of error", rather + + + +Davis, et al Experimental [Page 2] + +RFC 1876 Location Information in the DNS January 1996 + + + than a "plus or minus" value. (This was chosen to match + the interpretation of SIZE; to get a "plus or minus" value, + divide by 2.) + +VERT PRE The vertical precision of the data, in centimeters, + expressed using the sane representation as for SIZE. This + is the total potential vertical error, rather than a "plus + or minus" value. (This was chosen to match the + interpretation of SIZE; to get a "plus or minus" value, + divide by 2.) Note that if altitude above or below sea + level is used as an approximation for altitude relative to + the [WGS 84] ellipsoid, the precision value should be + adjusted. + +LATITUDE The latitude of the center of the sphere described by the + SIZE field, expressed as a 32-bit integer, most significant + octet first (network standard byte order), in thousandths + of a second of arc. 2^31 represents the equator; numbers + above that are north latitude. + +LONGITUDE The longitude of the center of the sphere described by the + SIZE field, expressed as a 32-bit integer, most significant + octet first (network standard byte order), in thousandths + of a second of arc, rounded away from the prime meridian. + 2^31 represents the prime meridian; numbers above that are + east longitude. + +ALTITUDE The altitude of the center of the sphere described by the + SIZE field, expressed as a 32-bit integer, most significant + octet first (network standard byte order), in centimeters, + from a base of 100,000m below the [WGS 84] reference + spheroid used by GPS (semimajor axis a=6378137.0, + reciprocal flattening rf=298.257223563). Altitude above + (or below) sea level may be used as an approximation of + altitude relative to the the [WGS 84] spheroid, though due + to the Earth's surface not being a perfect spheroid, there + will be differences. (For example, the geoid (which sea + level approximates) for the continental US ranges from 10 + meters to 50 meters below the [WGS 84] spheroid. + Adjustments to ALTITUDE and/or VERT PRE will be necessary + in most cases. The Defense Mapping Agency publishes geoid + height values relative to the [WGS 84] ellipsoid. + + + + + + + + + +Davis, et al Experimental [Page 3] + +RFC 1876 Location Information in the DNS January 1996 + + +3. Master File Format + + The LOC record is expressed in a master file in the following format: + + <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]] + {"E"|"W"} alt["m"] [siz["m"] [hp["m"] + [vp["m"]]]] ) + + (The parentheses are used for multi-line data as specified in [RFC + 1035] section 5.1.) + + where: + + d1: [0 .. 90] (degrees latitude) + d2: [0 .. 180] (degrees longitude) + m1, m2: [0 .. 59] (minutes latitude/longitude) + s1, s2: [0 .. 59.999] (seconds latitude/longitude) + alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters) + siz, hp, vp: [0 .. 90000000.00] (size/precision in meters) + + If omitted, minutes and seconds default to zero, size defaults to 1m, + horizontal precision defaults to 10000m, and vertical precision + defaults to 10m. These defaults are chosen to represent typical + ZIP/postal code area sizes, since it is often easy to find + approximate geographical location by ZIP/postal code. + +4. Example Data + +;;; +;;; note that these data would not all appear in one zone file +;;; + +;; network LOC RR derived from ZIP data. note use of precision defaults +cambridge-net.kei.com. LOC 42 21 54 N 71 06 18 W -24m 30m + +;; higher-precision host LOC RR. note use of vertical precision default +loiosh.kei.com. LOC 42 21 43.952 N 71 5 6.344 W + -24m 1m 200m + +pipex.net. LOC 52 14 05 N 00 08 50 E 10m + +curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10m + +rwy04L.logan-airport.boston. LOC 42 21 28.764 N 71 00 51.617 W + -44m 2000m + + + + + + +Davis, et al Experimental [Page 4] + +RFC 1876 Location Information in the DNS January 1996 + + +5. Application use of the LOC RR + +5.1 Suggested Uses + + Some uses for the LOC RR have already been suggested, including the + USENET backbone flow maps, a "visual traceroute" application showing + the geographical path of an IP packet, and network management + applications that could use LOC RRs to generate a map of hosts and + routers being managed. + +5.2 Search Algorithms + + This section specifies how to use the DNS to translate domain names + and/or IP addresses into location information. + + If an application wishes to have a "fallback" behavior, displaying a + less precise or larger area when a host does not have an associated + LOC RR, it MAY support use of the algorithm in section 5.2.3, as + noted in sections 5.2.1 and 5.2.2. If fallback is desired, this + behaviour is the RECOMMENDED default, but in some cases it may need + to be modified based on the specific requirements of the application + involved. + + This search algorithm is designed to allow network administrators to + specify the location of a network or subnet without requiring LOC RR + data for each individual host. For example, a computer lab with 24 + workstations, all of which are on the same subnet and in basically + the same location, would only need a LOC RR for the subnet. + (However, if the file server's location has been more precisely + measured, a separate LOC RR for it can be placed in the DNS.) + +5.2.1 Searching by Name + + If the application is beginning with a name, rather than an IP + address (as the USENET backbone flow maps do), it MUST check for a + LOC RR associated with that name. (CNAME records should be followed + as for any other RR type.) + + If there is no LOC RR for that name, all A records (if any) + associated with the name MAY be checked for network (or subnet) LOC + RRs using the "Searching by Network or Subnet" algorithm (5.2.3). If + multiple A records exist and have associated network or subnet LOC + RRs, the application may choose to use any, some, or all of the LOC + RRs found, possibly in combination. It is suggested that multi-homed + hosts have LOC RRs for their name in the DNS to avoid any ambiguity + in these cases. + + + + + +Davis, et al Experimental [Page 5] + +RFC 1876 Location Information in the DNS January 1996 + + + Note that domain names that do not have associated A records must + have a LOC RR associated with their name in order for location + information to be accessible. + +5.2.2 Searching by Address + + If the application is beginning with an IP address (as a "visual + traceroute" application might be) it MUST first map the address to a + name using the IN-ADDR.ARPA namespace (see [RFC 1034], section + 5.2.1), then check for a LOC RR associated with that name. + + If there is no LOC RR for the name, the address MAY be checked for + network (or subnet) LOC RRs using the "Searching by Network or + Subnet" algorithm (5.2.3). + +5.2.3 Searching by Network or Subnet + + Even if a host's name does not have any associated LOC RRs, the + network(s) or subnet(s) it is on may. If the application wishes to + search for such less specific data, the following algorithm SHOULD be + followed to find a network or subnet LOC RR associated with the IP + address. This algorithm is adapted slightly from that specified in + [RFC 1101], sections 4.3 and 4.4. + + Since subnet LOC RRs are (if present) more specific than network LOC + RRs, it is best to use them if available. In order to do so, we + build a stack of network and subnet names found while performing the + [RFC 1101] search, then work our way down the stack until a LOC RR is + found. + + 1. create a host-zero address using the network portion of the IP + address (one, two, or three bytes for class A, B, or C networks, + respectively). For example, for the host 128.9.2.17, on the class + B network 128.9, this would result in the address "128.9.0.0". + + 2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A + records. Retrieve: + + 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu. + A 255.255.255.0 + + Push the name "isi-net.isi.edu" onto the stack of names to be + searched for LOC RRs later. + + + + + + + + +Davis, et al Experimental [Page 6] + +RFC 1876 Location Information in the DNS January 1996 + + + 3. Since an A RR was found, repeat using mask from RR + (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA. + Retrieve: + + 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu. + A 255.255.255.240 + + Push the name "div2-subnet.isi.edu" onto the stack of names to be + searched for LOC RRs later. + + 4. Since another A RR was found, repeat using mask 255.255.255.240 + (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA. + Retrieve: + + 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu. + + Push the name "inc-subsubnet.isi.edu" onto the stack of names to + be searched for LOC RRs later. + + 5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no + more subnet levels to search. We now pop the top name from the + stack and check for an associated LOC RR. Repeat until a LOC RR + is found. + + In this case, assume that inc-subsubnet.isi.edu does not have an + associated LOC RR, but that div2-subnet.isi.edu does. We will + then use div2-subnet.isi.edu's LOC RR as an approximation of this + host's location. (Note that even if isi-net.isi.edu has a LOC RR, + it will not be used if a subnet also has a LOC RR.) + +5.3 Applicability to non-IN Classes and non-IP Addresses + + The LOC record is defined for all RR classes, and may be used with + non-IN classes such as HS and CH. The semantics of such use are not + defined by this memo. + + The search algorithm in section 5.2.3 may be adapted to other + addressing schemes by extending [RFC 1101]'s encoding of network + names to cover those schemes. Such extensions are not defined by + this memo. + + + + + + + + + + + +Davis, et al Experimental [Page 7] + +RFC 1876 Location Information in the DNS January 1996 + + +6. References + + [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, USC/Information Sciences Institute, + November 1987. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other + Types", RFC 1101, USC/Information Sciences Institute, + April 1989. + + [WGS 84] United States Department of Defense; DoD WGS-1984 - Its + Definition and Relationships with Local Geodetic Systems; + Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R- + 138-R; CV, KV; + +7. Security Considerations + + High-precision LOC RR information could be used to plan a penetration + of physical security, leading to potential denial-of-machine attacks. + To avoid any appearance of suggesting this method to potential + attackers, we declined the opportunity to name this RR "ICBM". + +8. Authors' Addresses + + The authors as a group can be reached as <loc@pipex.net>. + + Christopher Davis + Kapor Enterprises, Inc. + 238 Main Street, Suite 400 + Cambridge, MA 02142 + + Phone: +1 617 576 4532 + EMail: ckd@kei.com + + + Paul Vixie + Vixie Enterprises + Star Route Box 159A + Woodside, CA 94062 + + Phone: +1 415 747 0204 + EMail: paul@vix.com + + + + + +Davis, et al Experimental [Page 8] + +RFC 1876 Location Information in the DNS January 1996 + + + Tim Goodwin + Public IP Exchange Ltd (PIPEX) + 216 The Science Park + Cambridge CB4 4WA + UK + + Phone: +44 1223 250250 + EMail: tim@pipex.net + + + Ian Dickinson + FORE Systems + 2475 The Crescent + Solihull Parkway + Birmingham Business Park + B37 7YE + UK + + Phone: +44 121 717 4444 + EMail: idickins@fore.co.uk + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Davis, et al Experimental [Page 9] + +RFC 1876 Location Information in the DNS January 1996 + + +Appendix A: Sample Conversion Routines + +/* + * routines to convert between on-the-wire RR format and zone file + * format. Does not contain conversion to/from decimal degrees; + * divide or multiply by 60*60*1000 for that. + */ + +static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000, + 1000000,10000000,100000000,1000000000}; + +/* takes an XeY precision/size value, returns a string representation.*/ +static const char * +precsize_ntoa(prec) + u_int8_t prec; +{ + static char retbuf[sizeof("90000000.00")]; + unsigned long val; + int mantissa, exponent; + + mantissa = (int)((prec >> 4) & 0x0f) % 10; + exponent = (int)((prec >> 0) & 0x0f) % 10; + + val = mantissa * poweroften[exponent]; + + (void) sprintf(retbuf,"%d.%.2d", val/100, val%100); + return (retbuf); +} + +/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/ +static u_int8_t +precsize_aton(strptr) + char **strptr; +{ + unsigned int mval = 0, cmval = 0; + u_int8_t retval = 0; + register char *cp; + register int exponent; + register int mantissa; + + cp = *strptr; + + while (isdigit(*cp)) + mval = mval * 10 + (*cp++ - '0'); + + if (*cp == '.') { /* centimeters */ + cp++; + if (isdigit(*cp)) { + + + +Davis, et al Experimental [Page 10] + +RFC 1876 Location Information in the DNS January 1996 + + + cmval = (*cp++ - '0') * 10; + if (isdigit(*cp)) { + cmval += (*cp++ - '0'); + } + } + } + cmval = (mval * 100) + cmval; + + for (exponent = 0; exponent < 9; exponent++) + if (cmval < poweroften[exponent+1]) + break; + + mantissa = cmval / poweroften[exponent]; + if (mantissa > 9) + mantissa = 9; + + retval = (mantissa << 4) | exponent; + + *strptr = cp; + + return (retval); +} + +/* converts ascii lat/lon to unsigned encoded 32-bit number. + * moves pointer. */ +static u_int32_t +latlon2ul(latlonstrptr,which) + char **latlonstrptr; + int *which; +{ + register char *cp; + u_int32_t retval; + int deg = 0, min = 0, secs = 0, secsfrac = 0; + + cp = *latlonstrptr; + + while (isdigit(*cp)) + deg = deg * 10 + (*cp++ - '0'); + + while (isspace(*cp)) + cp++; + + if (!(isdigit(*cp))) + goto fndhemi; + + while (isdigit(*cp)) + min = min * 10 + (*cp++ - '0'); + + + + +Davis, et al Experimental [Page 11] + +RFC 1876 Location Information in the DNS January 1996 + + + while (isspace(*cp)) + cp++; + + if (!(isdigit(*cp))) + goto fndhemi; + + while (isdigit(*cp)) + secs = secs * 10 + (*cp++ - '0'); + + if (*cp == '.') { /* decimal seconds */ + cp++; + if (isdigit(*cp)) { + secsfrac = (*cp++ - '0') * 100; + if (isdigit(*cp)) { + secsfrac += (*cp++ - '0') * 10; + if (isdigit(*cp)) { + secsfrac += (*cp++ - '0'); + } + } + } + } + + while (!isspace(*cp)) /* if any trailing garbage */ + cp++; + + while (isspace(*cp)) + cp++; + + fndhemi: + switch (*cp) { + case 'N': case 'n': + case 'E': case 'e': + retval = ((unsigned)1<<31) + + (((((deg * 60) + min) * 60) + secs) * 1000) + + secsfrac; + break; + case 'S': case 's': + case 'W': case 'w': + retval = ((unsigned)1<<31) + - (((((deg * 60) + min) * 60) + secs) * 1000) + - secsfrac; + break; + default: + retval = 0; /* invalid value -- indicates error */ + break; + } + + switch (*cp) { + + + +Davis, et al Experimental [Page 12] + +RFC 1876 Location Information in the DNS January 1996 + + + case 'N': case 'n': + case 'S': case 's': + *which = 1; /* latitude */ + break; + case 'E': case 'e': + case 'W': case 'w': + *which = 2; /* longitude */ + break; + default: + *which = 0; /* error */ + break; + } + + cp++; /* skip the hemisphere */ + + while (!isspace(*cp)) /* if any trailing garbage */ + cp++; + + while (isspace(*cp)) /* move to next field */ + cp++; + + *latlonstrptr = cp; + + return (retval); +} + +/* converts a zone file representation in a string to an RDATA + * on-the-wire representation. */ +u_int32_t +loc_aton(ascii, binary) + const char *ascii; + u_char *binary; +{ + const char *cp, *maxcp; + u_char *bcp; + + u_int32_t latit = 0, longit = 0, alt = 0; + u_int32_t lltemp1 = 0, lltemp2 = 0; + int altmeters = 0, altfrac = 0, altsign = 1; + u_int8_t hp = 0x16; /* default = 1e6 cm = 10000.00m = 10km */ + u_int8_t vp = 0x13; /* default = 1e3 cm = 10.00m */ + u_int8_t siz = 0x12; /* default = 1e2 cm = 1.00m */ + int which1 = 0, which2 = 0; + + cp = ascii; + maxcp = cp + strlen(ascii); + + lltemp1 = latlon2ul(&cp, &which1); + + + +Davis, et al Experimental [Page 13] + +RFC 1876 Location Information in the DNS January 1996 + + + lltemp2 = latlon2ul(&cp, &which2); + + switch (which1 + which2) { + case 3: /* 1 + 2, the only valid combination */ + if ((which1 == 1) && (which2 == 2)) { /* normal case */ + latit = lltemp1; + longit = lltemp2; + } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/ + longit = lltemp1; + latit = lltemp2; + } else { /* some kind of brokenness */ + return 0; + } + break; + default: /* we didn't get one of each */ + return 0; + } + + /* altitude */ + if (*cp == '-') { + altsign = -1; + cp++; + } + + if (*cp == '+') + cp++; + + while (isdigit(*cp)) + altmeters = altmeters * 10 + (*cp++ - '0'); + + if (*cp == '.') { /* decimal meters */ + cp++; + if (isdigit(*cp)) { + altfrac = (*cp++ - '0') * 10; + if (isdigit(*cp)) { + altfrac += (*cp++ - '0'); + } + } + } + + alt = (10000000 + (altsign * (altmeters * 100 + altfrac))); + + while (!isspace(*cp) && (cp < maxcp)) + /* if trailing garbage or m */ + cp++; + + while (isspace(*cp) && (cp < maxcp)) + cp++; + + + +Davis, et al Experimental [Page 14] + +RFC 1876 Location Information in the DNS January 1996 + + + if (cp >= maxcp) + goto defaults; + + siz = precsize_aton(&cp); + + while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/ + cp++; + + while (isspace(*cp) && (cp < maxcp)) + cp++; + + if (cp >= maxcp) + goto defaults; + + hp = precsize_aton(&cp); + + while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/ + cp++; + + while (isspace(*cp) && (cp < maxcp)) + cp++; + + if (cp >= maxcp) + goto defaults; + + vp = precsize_aton(&cp); + + defaults: + + bcp = binary; + *bcp++ = (u_int8_t) 0; /* version byte */ + *bcp++ = siz; + *bcp++ = hp; + *bcp++ = vp; + PUTLONG(latit,bcp); + PUTLONG(longit,bcp); + PUTLONG(alt,bcp); + + return (16); /* size of RR in octets */ +} + +/* takes an on-the-wire LOC RR and prints it in zone file + * (human readable) format. */ +char * +loc_ntoa(binary,ascii) + const u_char *binary; + char *ascii; +{ + + + +Davis, et al Experimental [Page 15] + +RFC 1876 Location Information in the DNS January 1996 + + + static char tmpbuf[255*3]; + + register char *cp; + register const u_char *rcp; + + int latdeg, latmin, latsec, latsecfrac; + int longdeg, longmin, longsec, longsecfrac; + char northsouth, eastwest; + int altmeters, altfrac, altsign; + + const int referencealt = 100000 * 100; + + int32_t latval, longval, altval; + u_int32_t templ; + u_int8_t sizeval, hpval, vpval, versionval; + + char *sizestr, *hpstr, *vpstr; + + rcp = binary; + if (ascii) + cp = ascii; + else { + cp = tmpbuf; + } + + versionval = *rcp++; + + if (versionval) { + sprintf(cp,"; error: unknown LOC RR version"); + return (cp); + } + + sizeval = *rcp++; + + hpval = *rcp++; + vpval = *rcp++; + + GETLONG(templ,rcp); + latval = (templ - ((unsigned)1<<31)); + + GETLONG(templ,rcp); + longval = (templ - ((unsigned)1<<31)); + + GETLONG(templ,rcp); + if (templ < referencealt) { /* below WGS 84 spheroid */ + altval = referencealt - templ; + altsign = -1; + } else { + + + +Davis, et al Experimental [Page 16] + +RFC 1876 Location Information in the DNS January 1996 + + + altval = templ - referencealt; + altsign = 1; + } + + if (latval < 0) { + northsouth = 'S'; + latval = -latval; + } + else + northsouth = 'N'; + + latsecfrac = latval % 1000; + latval = latval / 1000; + latsec = latval % 60; + latval = latval / 60; + latmin = latval % 60; + latval = latval / 60; + latdeg = latval; + + if (longval < 0) { + eastwest = 'W'; + longval = -longval; + } + else + eastwest = 'E'; + + longsecfrac = longval % 1000; + longval = longval / 1000; + longsec = longval % 60; + longval = longval / 60; + longmin = longval % 60; + longval = longval / 60; + longdeg = longval; + + altfrac = altval % 100; + altmeters = (altval / 100) * altsign; + + sizestr = savestr(precsize_ntoa(sizeval)); + hpstr = savestr(precsize_ntoa(hpval)); + vpstr = savestr(precsize_ntoa(vpval)); + + sprintf(cp, + "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm + %sm %sm %sm", + latdeg, latmin, latsec, latsecfrac, northsouth, + longdeg, longmin, longsec, longsecfrac, eastwest, + altmeters, altfrac, sizestr, hpstr, vpstr); + + + + +Davis, et al Experimental [Page 17] + +RFC 1876 Location Information in the DNS January 1996 + + + free(sizestr); + free(hpstr); + free(vpstr); + + return (cp); +} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Davis, et al Experimental [Page 18] + diff --git a/Documentation/en/rfc/rfc1960.txt b/Documentation/en/rfc/rfc1960.txt new file mode 100644 index 00000000..8e09abdd --- /dev/null +++ b/Documentation/en/rfc/rfc1960.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group T. Howes +Request for Comments: 1960 University of Michigan +Obsoletes: 1558 June 1996 +Category: Standards Track + + A String Representation of LDAP Search Filters + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The Lightweight Directory Access Protocol (LDAP) [1] defines a + network representation of a search filter transmitted to an LDAP + server. Some applications may find it useful to have a common way of + representing these search filters in a human-readable form. This + document defines a human-readable string format for representing LDAP + search filters. + +2. LDAP Search Filter Definition + + An LDAP search filter is defined in [1] as follows: + + Filter ::= CHOICE { + and [0] SET OF Filter, + or [1] SET OF Filter, + not [2] Filter, + equalityMatch [3] AttributeValueAssertion, + substrings [4] SubstringFilter, + greaterOrEqual [5] AttributeValueAssertion, + lessOrEqual [6] AttributeValueAssertion, + present [7] AttributeType, + approxMatch [8] AttributeValueAssertion + } + + SubstringFilter ::= SEQUENCE { + type AttributeType, + SEQUENCE OF CHOICE { + initial [0] LDAPString, + any [1] LDAPString, + final [2] LDAPString + } + } + + + +Howes Standards Track [Page 1] + +RFC 1960 LDAP Search Filters June 1996 + + + AttributeValueAssertion ::= SEQUENCE { + attributeType AttributeType, + attributeValue AttributeValue + } + + AttributeType ::= LDAPString + + AttributeValue ::= OCTET STRING + + LDAPString ::= OCTET STRING + + where the LDAPString above is limited to the IA5 character set. The + AttributeType is a string representation of the attribute type name + and is defined in [1]. The AttributeValue OCTET STRING has the form + defined in [2]. The Filter is encoded for transmission over a + network using the Basic Encoding Rules defined in [3], with + simplifications described in [1]. + +3. String Search Filter Definition + + The string representation of an LDAP search filter is defined by the + following grammar. It uses a prefix format. + + <filter> ::= '(' <filtercomp> ')' + <filtercomp> ::= <and> | <or> | <not> | <item> + <and> ::= '&' <filterlist> + <or> ::= '|' <filterlist> + <not> ::= '!' <filter> + <filterlist> ::= <filter> | <filter> <filterlist> + <item> ::= <simple> | <present> | <substring> + <simple> ::= <attr> <filtertype> <value> + <filtertype> ::= <equal> | <approx> | <greater> | <less> + <equal> ::= '=' + <approx> ::= '~=' + <greater> ::= '>=' + <less> ::= '<=' + <present> ::= <attr> '=*' + <substring> ::= <attr> '=' <initial> <any> <final> + <initial> ::= NULL | <value> + <any> ::= '*' <starval> + <starval> ::= NULL | <value> '*' <starval> + <final> ::= NULL | <value> + + <attr> is a string representing an AttributeType, and has the format + defined in [1]. <value> is a string representing an AttributeValue, + or part of one, and has the form defined in [2]. If a <value> must + contain one of the characters '*' or '(' or ')', these characters + should be escaped by preceding them with the backslash '\' character. + + + +Howes Standards Track [Page 2] + +RFC 1960 LDAP Search Filters June 1996 + + + Note that although both the <substring> and <present> productions can + produce the 'attr=*' construct, this construct is used only to denote + a presence filter. + +4. Examples + + This section gives a few examples of search filters written using + this notation. + + (cn=Babs Jensen) + (!(cn=Tim Howes)) + (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) + (o=univ*of*mich*) + +5. Security Considerations + + Security considerations are not discussed in this memo. + +6. Bibliography + + [1] Yeong, W., Howes, T., and S. Kille, "Lightweight + Directory Access Protocol", RFC 1777, March 1995. + + [2] Howes, R., Kille, S., Yeong, W., and C. Robbins, "The String + Representation of Standard Attribute Syntaxes", RFC 1778, + March 1995. + + [3] Specification of Basic Encoding Rules for Abstract Syntax + Notation One (ASN.1). CCITT Recommendation X.209, 1988. + +7. Author's Address + + Tim Howes + University of Michigan + ITD Research Systems + 535 W William St. + Ann Arbor, MI 48103-4943 + USA + + Phone: +1 313 747-4454 + EMail: tim@umich.edu + + + + + + + + + + +Howes Standards Track [Page 3] + diff --git a/Documentation/en/rfc/rfc1982.txt b/Documentation/en/rfc/rfc1982.txt new file mode 100644 index 00000000..5a34bc42 --- /dev/null +++ b/Documentation/en/rfc/rfc1982.txt @@ -0,0 +1,394 @@ + + + + + + +Network Working Group R. Elz +Request for Comments: 1982 University of Melbourne +Updates: 1034, 1035 R. Bush +Category: Standards Track RGnet, Inc. + August 1996 + + + Serial Number Arithmetic + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines serial number arithmetic, as used in the Domain + Name System. The DNS has long relied upon serial number arithmetic, + a concept which has never really been defined, certainly not in an + IETF document, though which has been widely understood. This memo + supplies the missing definition. It is intended to update RFC1034 + and RFC1035. + +1. Introduction + + The serial number field of the SOA resource record is defined in + RFC1035 as + + SERIAL The unsigned 32 bit version number of the original copy of + the zone. Zone transfers preserve this value. This value + wraps and should be compared using sequence space + arithmetic. + + RFC1034 uses the same terminology when defining secondary server zone + consistency procedures. + + Unfortunately the term "sequence space arithmetic" is not defined in + either RFC1034 or RFC1035, nor do any of their references provide + further information. + + This phrase seems to have been intending to specify arithmetic as + used in TCP sequence numbers [RFC793], and defined in [IEN-74]. + + Unfortunately, the arithmetic defined in [IEN-74] is not adequate for + the purposes of the DNS, as no general comparison operator is + + + +Elz & Bush Standards Track [Page 1] + +RFC 1982 Serial Number Arithmetic August 1996 + + + defined. + + To avoid further problems with this simple field, this document + defines the field and the operations available upon it. This + definition is intended merely to clarify the intent of RFC1034 and + RFC1035, and is believed to generally agree with current + implementations. However, older, superseded, implementations are + known to have treated the serial number as a simple unsigned integer, + with no attempt to implement any kind of "sequence space arithmetic", + however that may have been interpreted, and further, ignoring the + requirement that the value wraps. Nothing can be done with these + implementations, beyond extermination. + +2. Serial Number Arithmetic + + Serial numbers are formed from non-negative integers from a finite + subset of the range of all integer values. The lowest integer in + every subset used for this purpose is zero, the maximum is always one + less than a power of two. + + When considered as serial numbers however no value has any particular + significance, there is no minimum or maximum serial number, every + value has a successor and predecessor. + + To define a serial number to be used in this way, the size of the + serial number space must be given. This value, called "SERIAL_BITS", + gives the power of two which results in one larger than the largest + integer corresponding to a serial number value. This also specifies + the number of bits required to hold every possible value of a serial + number of the defined type. The operations permitted upon serial + numbers are defined in the following section. + +3. Operations upon the serial number + + Only two operations are defined upon serial numbers, addition of a + positive integer of limited range, and comparison with another serial + number. + +3.1. Addition + + Serial numbers may be incremented by the addition of a positive + integer n, where n is taken from the range of integers + [0 .. (2^(SERIAL_BITS - 1) - 1)]. For a sequence number s, the + result of such an addition, s', is defined as + + s' = (s + n) modulo (2 ^ SERIAL_BITS) + + + + + +Elz & Bush Standards Track [Page 2] + +RFC 1982 Serial Number Arithmetic August 1996 + + + where the addition and modulus operations here act upon values that + are non-negative values of unbounded size in the usual ways of + integer arithmetic. + + Addition of a value outside the range + [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined. + +3.2. Comparison + + Any two serial numbers, s1 and s2, may be compared. The definition + of the result of this comparison is as follows. + + For the purposes of this definition, consider two integers, i1 and + i2, from the unbounded set of non-negative integers, such that i1 and + s1 have the same numeric value, as do i2 and s2. Arithmetic and + comparisons applied to i1 and i2 use ordinary unbounded integer + arithmetic. + + Then, s1 is said to be equal to s2 if and only if i1 is equal to i2, + in all other cases, s1 is not equal to s2. + + s1 is said to be less than s2 if, and only if, s1 is not equal to s2, + and + + (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or + (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1)) + + s1 is said to be greater than s2 if, and only if, s1 is not equal to + s2, and + + (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or + (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1)) + + Note that there are some pairs of values s1 and s2 for which s1 is + not equal to s2, but for which s1 is neither greater than, nor less + than, s2. An attempt to use these ordering operators on such pairs + of values produces an undefined result. + + The reason for this is that those pairs of values are such that any + simple definition that were to define s1 to be less than s2 where + (s1, s2) is such a pair, would also usually cause s2 to be less than + s1, when the pair is (s2, s1). This would mean that the particular + order selected for a test could cause the result to differ, leading + to unpredictable implementations. + + While it would be possible to define the test in such a way that the + inequality would not have this surprising property, while being + defined for all pairs of values, such a definition would be + + + +Elz & Bush Standards Track [Page 3] + +RFC 1982 Serial Number Arithmetic August 1996 + + + unnecessarily burdensome to implement, and difficult to understand, + and would still allow cases where + + s1 < s2 and (s1 + 1) > (s2 + 1) + + which is just as non-intuitive. + + Thus the problem case is left undefined, implementations are free to + return either result, or to flag an error, and users must take care + not to depend on any particular outcome. Usually this will mean + avoiding allowing those particular pairs of numbers to co-exist. + + The relationships greater than or equal to, and less than or equal + to, follow in the natural way from the above definitions. + +4. Corollaries + + These definitions give rise to some results of note. + +4.1. Corollary 1 + + For any sequence number s and any integer n such that addition of n + to s is well defined, (s + n) >= s. Further (s + n) == s only when + n == 0, in all other defined cases, (s + n) > s. + +4.2. Corollary 2 + + If s' is the result of adding the non-zero integer n to the sequence + number s, and m is another integer from the range defined as able to + be added to a sequence number, and s" is the result of adding m to + s', then it is undefined whether s" is greater than, or less than s, + though it is known that s" is not equal to s. + +4.3. Corollary 3 + + If s" from the previous corollary is further incremented, then there + is no longer any known relationship between the result and s. + +4.4. Corollary 4 + + If in corollary 2 the value (n + m) is such that addition of the sum + to sequence number s would produce a defined result, then corollary 1 + applies, and s" is known to be greater than s. + + + + + + + + +Elz & Bush Standards Track [Page 4] + +RFC 1982 Serial Number Arithmetic August 1996 + + +5. Examples + +5.1. A trivial example + + The simplest meaningful serial number space has SERIAL_BITS == 2. In + this space, the integers that make up the serial number space are 0, + 1, 2, and 3. That is, 3 == 2^SERIAL_BITS - 1. + + In this space, the largest integer that it is meaningful to add to a + sequence number is 2^(SERIAL_BITS - 1) - 1, or 1. + + Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0. + Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3. It is undefined whether + 2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1. + +5.2. A slightly larger example + + Consider the case where SERIAL_BITS == 8. In this space the integers + that make up the serial number space are 0, 1, 2, ... 254, 255. + 255 == 2^SERIAL_BITS - 1. + + In this space, the largest integer that it is meaningful to add to a + sequence number is 2^(SERIAL_BITS - 1) - 1, or 127. + + Addition is as expected in this space, for example: 255+1 == 0, + 100+100 == 200, and 200+100 == 44. + + Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44, + 200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200. + + Note that 100+100 > 100, but that (100+100)+100 < 100. Incrementing + a serial number can cause it to become "smaller". Of course, + incrementing by a smaller number will allow many more increments to + be made before this occurs. However this is always something to be + aware of, it can cause surprising errors, or be useful as it is the + only defined way to actually cause a serial number to decrease. + + The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and + 255 are not equal, but in each pair, neither number is defined as + being greater than, or less than, the other. + + It could be defined (arbitrarily) that 128 > 0, 129 > 1, + 130 > 2, ..., 255 > 127, by changing the comparison operator + definitions, as mentioned above. However note that that would cause + 255 > 127, while (255 + 1) < (127 + 1), as 0 < 128. Such a + definition, apart from being arbitrary, would also be more costly to + implement. + + + + +Elz & Bush Standards Track [Page 5] + +RFC 1982 Serial Number Arithmetic August 1996 + + +6. Citation + + As this defined arithmetic may be useful for purposes other than for + the DNS serial number, it may be referenced as Serial Number + Arithmetic from RFC1982. Any such reference shall be taken as + implying that the rules of sections 2 to 5 of this document apply to + the stated values. + +7. The DNS SOA serial number + + The serial number in the DNS SOA Resource Record is a Serial Number + as defined above, with SERIAL_BITS being 32. That is, the serial + number is a non negative integer with values taken from the range + [0 .. 4294967295]. That is, a 32 bit unsigned integer. + + The maximum defined increment is 2147483647 (2^31 - 1). + + Care should be taken that the serial number not be incremented, in + one or more steps, by more than this maximum within the period given + by the value of SOA.expire. Doing so may leave some secondary + servers with out of date copies of the zone, but with a serial number + "greater" than that of the primary server. Of course, special + circumstances may require this rule be set aside, for example, when + the serial number needs to be set lower for some reason. If this + must be done, then take special care to verify that ALL servers have + correctly succeeded in following the primary server's serial number + changes, at each step. + + Note that each, and every, increment to the serial number must be + treated as the start of a new sequence of increments for this + purpose, as well as being the continuation of all previous sequences + started within the period specified by SOA.expire. + + Caution should also be exercised before causing the serial number to + be set to the value zero. While this value is not in any way special + in serial number arithmetic, or to the DNS SOA serial number, many + DNS implementations have incorrectly treated zero as a special case, + with special properties, and unusual behaviour may be expected if + zero is used as a DNS SOA serial number. + + + + + + + + + + + + +Elz & Bush Standards Track [Page 6] + +RFC 1982 Serial Number Arithmetic August 1996 + + +8. Document Updates + + RFC1034 and RFC1035 are to be treated as if the references to + "sequence space arithmetic" therein are replaced by references to + serial number arithmetic, as defined in this document. + +9. Security Considerations + + This document does not consider security. + + It is not believed that anything in this document adds to any + security issues that may exist with the DNS, nor does it do anything + to lessen them. + +References + + [RFC1034] Domain Names - Concepts and Facilities, + P. Mockapetris, STD 13, ISI, November 1987. + + [RFC1035] Domain Names - Implementation and Specification + P. Mockapetris, STD 13, ISI, November 1987 + + [RFC793] Transmission Control protocol + Information Sciences Institute, STD 7, USC, September 1981 + + [IEN-74] Sequence Number Arithmetic + William W. Plummer, BB&N Inc, September 1978 + +Acknowledgements + + Thanks to Rob Austein for suggesting clarification of the undefined + comparison operators, and to Michael Patton for attempting to locate + another reference for this procedure. Thanks also to members of the + IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris. + +Authors' Addresses + + Robert Elz Randy Bush + Computer Science RGnet, Inc. + University of Melbourne 10361 NE Sasquatch Lane + Parkville, Vic, 3052 Bainbridge Island, Washington, 98110 + Australia. United States. + + EMail: kre@munnari.OZ.AU EMail: randy@psg.com + + + + + + + +Elz & Bush Standards Track [Page 7] diff --git a/Documentation/en/rfc/rfc1995.txt b/Documentation/en/rfc/rfc1995.txt new file mode 100644 index 00000000..b50bdc60 --- /dev/null +++ b/Documentation/en/rfc/rfc1995.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group M. Ohta +Request for Comments: 1995 Tokyo Institute of Technology +Updates: 1035 August 1996 +Category: Standards Track + + + Incremental Zone Transfer in DNS + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document proposes extensions to the DNS protocols to provide an + incremental zone transfer (IXFR) mechanism. + +1. Introduction + + For rapid propagation of changes to a DNS database [STD13], it is + necessary to reduce latency by actively notifying servers of the + change. This is accomplished by the NOTIFY extension of the DNS + [NOTIFY]. + + The current full zone transfer mechanism (AXFR) is not an efficient + means to propagate changes to a small part of a zone, as it transfers + the entire zone file. + + Incremental transfer (IXFR) as proposed is a more efficient + mechanism, as it transfers only the changed portion(s) of a zone. + + In this document, a secondary name server which requests IXFR is + called an IXFR client and a primary or secondary name server which + responds to the request is called an IXFR server. + +2. Brief Description of the Protocol + + If an IXFR client, which likely has an older version of a zone, + thinks it needs new information about the zone (typically through SOA + refresh timeout or the NOTIFY mechanism), it sends an IXFR message + containing the SOA serial number of its, presumably outdated, copy of + the zone. + + + + + +Ohta Standards Track [Page 1] + +RFC 1995 Incremental Zone Transfer in DNS August 1996 + + + An IXFR server should keep record of the newest version of the zone + and the differences between that copy and several older versions. + When an IXFR request with an older version number is received, the + IXFR server needs to send only the differences required to make that + version current. Alternatively, the server may choose to transfer + the entire zone just as in a normal full zone transfer. + + When a zone has been updated, it should be saved in stable storage + before the new version is used to respond to IXFR (or AXFR) queries. + Otherwise, if the server crashes, data which is no longer available + may have been distributed to secondary servers, which can cause + persistent database inconsistencies. + + If an IXFR query with the same or newer version number than that of + the server is received, it is replied to with a single SOA record of + the server's current version, just as in AXFR. + + Transport of a query may be by either UDP or TCP. If an IXFR query + is via UDP, the IXFR server may attempt to reply using UDP if the + entire response can be contained in a single DNS packet. If the UDP + reply does not fit, the query is responded to with a single SOA + record of the server's current version to inform the client that a + TCP query should be initiated. + + Thus, a client should first make an IXFR query using UDP. If the + query type is not recognized by the server, an AXFR (preceded by a + UDP SOA query) should be tried, ensuring backward compatibility. If + the query response is a single packet with the entire new zone, or if + the server does not have a newer version than the client, everything + is done. Otherwise, a TCP IXFR query should be tried. + + To ensure integrity, servers should use UDP checksums for all UDP + responses. A cautious client which receives a UDP packet with a + checksum value of zero should ignore the result and try a TCP IXFR + instead. + + The query type value of IXFR assigned by IANA is 251. + +3. Query Format + + The IXFR query packet format is the same as that of a normal DNS + query, but with the query type being IXFR and the authority section + containing the SOA record of client's version of the zone. + + + + + + + + +Ohta Standards Track [Page 2] + +RFC 1995 Incremental Zone Transfer in DNS August 1996 + + +4. Response Format + + If incremental zone transfer is not available, the entire zone is + returned. The first and the last RR of the response is the SOA + record of the zone. I.e. the behavior is the same as an AXFR + response except the query type is IXFR. + + If incremental zone transfer is available, one or more difference + sequences is returned. The list of difference sequences is preceded + and followed by a copy of the server's current version of the SOA. + + Each difference sequence represents one update to the zone (one SOA + serial change) consisting of deleted RRs and added RRs. The first RR + of the deleted RRs is the older SOA RR and the first RR of the added + RRs is the newer SOA RR. + + Modification of an RR is performed first by removing the original RR + and then adding the modified one. + + The sequences of differential information are ordered oldest first + newest last. Thus, the differential sequences are the history of + changes made since the version known by the IXFR client up to the + server's current version. + + RRs in the incremental transfer messages may be partial. That is, if + a single RR of multiple RRs of the same RR type changes, only the + changed RR is transferred. + + An IXFR client, should only replace an older version with a newer + version after all the differences have been successfully processed. + + An incremental response is different from that of a non-incremental + response in that it begins with two SOA RRs, the server's current SOA + followed by the SOA of the client's version which is about to be + replaced. + + 5. Purging Strategy + + An IXFR server can not be required to hold all previous versions + forever and may delete them anytime. In general, there is a trade-off + between the size of storage space and the possibility of using IXFR. + + Information about older versions should be purged if the total length + of an IXFR response would be longer than that of an AXFR response. + Given that the purpose of IXFR is to reduce AXFR overhead, this + strategy is quite reasonable. The strategy assures that the amount + of storage required is at most twice that of the current zone + information. + + + +Ohta Standards Track [Page 3] + +RFC 1995 Incremental Zone Transfer in DNS August 1996 + + + Information older than the SOA expire period may also be purged. + +6. Optional Condensation of Multiple Versions + + An IXFR server may optionally condense multiple difference sequences + into a single difference sequence, thus, dropping information on + intermediate versions. + + This may be beneficial if a lot of versions, not all of which are + useful, are generated. For example, if multiple ftp servers share a + single DNS name and the IP address associated with the name is + changed once a minute to balance load between the ftp servers, it is + not so important to keep track of all the history of changes. + + But, this feature may not be so useful if an IXFR client has access + to two IXFR servers: A and B, with inconsistent condensation results. + The current version of the IXFR client, received from server A, may + be unknown to server B. In such a case, server B can not provide + incremental data from the unknown version and a full zone transfer is + necessary. + + Condensation is completely optional. Clients can't detect from the + response whether the server has condensed the reply or not. + + For interoperability, IXFR servers, including those without the + condensation feature, should not flag an error even if it receives a + client's IXFR request with a unknown version number and should, + instead, attempt to perform a full zone transfer. + +7. Example + + Given the following three generations of data with the current serial + number of 3, + + JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. ( + 1 600 600 3600000 604800) + IN NS NS.JAIN.AD.JP. + NS.JAIN.AD.JP. IN A 133.69.136.1 + NEZU.JAIN.AD.JP. IN A 133.69.136.5 + + NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added. + + jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. ( + 2 600 600 3600000 604800) + IN NS NS.JAIN.AD.JP. + NS.JAIN.AD.JP. IN A 133.69.136.1 + JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 + IN A 192.41.197.2 + + + +Ohta Standards Track [Page 4] + +RFC 1995 Incremental Zone Transfer in DNS August 1996 + + + One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed. + + JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. ( + 3 600 600 3600000 604800) + IN NS NS.JAIN.AD.JP. + NS.JAIN.AD.JP. IN A 133.69.136.1 + JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 + IN A 192.41.197.2 + + The following IXFR query + + +---------------------------------------------------+ + Header | OPCODE=SQUERY | + +---------------------------------------------------+ + Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | + +---------------------------------------------------+ + Answer | <empty> | + +---------------------------------------------------+ + Authority | JAIN.AD.JP. IN SOA serial=1 | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + + could be replied to with the following full zone transfer message: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | + +---------------------------------------------------+ + Answer | JAIN.AD.JP. IN SOA serial=3 | + | JAIN.AD.JP. IN NS NS.JAIN.AD.JP. | + | NS.JAIN.AD.JP. IN A 133.69.136.1 | + | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | + | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | + | JAIN.AD.JP. IN SOA serial=3 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + + + + + + + + + + +Ohta Standards Track [Page 5] + +RFC 1995 Incremental Zone Transfer in DNS August 1996 + + + or with the following incremental message: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | + +---------------------------------------------------+ + Answer | JAIN.AD.JP. IN SOA serial=3 | + | JAIN.AD.JP. IN SOA serial=1 | + | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | + | JAIN.AD.JP. IN SOA serial=2 | + | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | + | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | + | JAIN.AD.JP. IN SOA serial=2 | + | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | + | JAIN.AD.JP. IN SOA serial=3 | + | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | + | JAIN.AD.JP. IN SOA serial=3 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + + or with the following condensed incremental message: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | + +---------------------------------------------------+ + Answer | JAIN.AD.JP. IN SOA serial=3 | + | JAIN.AD.JP. IN SOA serial=1 | + | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | + | JAIN.AD.JP. IN SOA serial=3 | + | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | + | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | + | JAIN.AD.JP. IN SOA serial=3 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + + + + + + + + +Ohta Standards Track [Page 6] + +RFC 1995 Incremental Zone Transfer in DNS August 1996 + + + or, if UDP packet overflow occurs, with the following message: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | + +---------------------------------------------------+ + Answer | JAIN.AD.JP. IN SOA serial=3 | + +---------------------------------------------------+ + Authority | <empty> | + +---------------------------------------------------+ + Additional | <empty> | + +---------------------------------------------------+ + +8. Acknowledgements + + The original idea of IXFR was conceived by Anant Kumar, Steve Hotz + and Jon Postel. + + For the refinement of the protocol and documentation, many people + have contributed including, but not limited to, Anant Kumar, Robert + Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the + members of the IETF DNSIND working group. + +9. References + + [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt + Notification of Zone Changes", RFC 1996, August 1996. + + [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and + RFC 1035), November 1987. + +10. Security Considerations + + Though DNS is related to several security problems, no attempt is + made to fix them in this document. + + This document is believed to introduce no additional security + problems to the current DNS protocol. + + + + + + + + + + + + +Ohta Standards Track [Page 7] + +RFC 1995 Incremental Zone Transfer in DNS August 1996 + + +11. Author's Address + + Masataka Ohta + Computer Center + Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN + + Phone: +81-3-5734-3299 + Fax: +81-3-5734-3415 + EMail: mohta@necom830.hpcl.titech.ac.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ohta Standards Track [Page 8] + diff --git a/Documentation/en/rfc/rfc1996.txt b/Documentation/en/rfc/rfc1996.txt new file mode 100644 index 00000000..b08f2007 --- /dev/null +++ b/Documentation/en/rfc/rfc1996.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group P. Vixie +Request for Comments: 1996 ISC +Updates: 1035 August 1996 +Category: Standards Track + + + A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo describes the NOTIFY opcode for DNS, by which a master + server advises a set of slave servers that the master's data has been + changed and that a query should be initiated to discover the new + data. + +1. Rationale and Scope + + 1.1. Slow propagation of new and changed data in a DNS zone can be + due to a zone's relatively long refresh times. Longer refresh times + are beneficial in that they reduce load on the master servers, but + that benefit comes at the cost of long intervals of incoherence among + authority servers whenever the zone is updated. + + 1.2. The DNS NOTIFY transaction allows master servers to inform slave + servers when the zone has changed -- an interrupt as opposed to poll + model -- which it is hoped will reduce propagation delay while not + unduly increasing the masters' load. This specification only allows + slaves to be notified of SOA RR changes, but the architechture of + NOTIFY is intended to be extensible to other RR types. + + 1.3. This document intentionally gives more definition to the roles + of "Master," "Slave" and "Stealth" servers, their enumeration in NS + RRs, and the SOA MNAME field. In that sense, this document can be + considered an addendum to [RFC1035]. + + + + + + + + + +Vixie Standards Track [Page 1] + +RFC 1996 DNS NOTIFY August 1996 + + +2. Definitions and Invariants + + 2.1. The following definitions are used in this document: + + Slave an authoritative server which uses zone transfer to + retrieve the zone. All slave servers are named in + the NS RRs for the zone. + + Master any authoritative server configured to be the source + of zone transfer for one or more slave servers. + + Primary Master master server at the root of the zone transfer + dependency graph. The primary master is named in the + zone's SOA MNAME field and optionally by an NS RR. + There is by definition only one primary master server + per zone. + + Stealth like a slave server except not listed in an NS RR for + the zone. A stealth server, unless explicitly + configured to do otherwise, will set the AA bit in + responses and be capable of acting as a master. A + stealth server will only be known by other servers if + they are given static configuration data indicating + its existence. + + Notify Set set of servers to be notified of changes to some + zone. Default is all servers named in the NS RRset, + except for any server also named in the SOA MNAME. + Some implementations will permit the name server + administrator to override this set or add elements to + it (such as, for example, stealth servers). + + 2.2. The zone's servers must be organized into a dependency graph + such that there is a primary master, and all other servers must use + AXFR or IXFR either from the primary master or from some slave which + is also a master. No loops are permitted in the AXFR dependency + graph. + +3. NOTIFY Message + + 3.1. When a master has updated one or more RRs in which slave servers + may be interested, the master may send the changed RR's name, class, + type, and optionally, new RDATA(s), to each known slave server using + a best efforts protocol based on the NOTIFY opcode. + + 3.2. NOTIFY uses the DNS Message Format, although it uses only a + subset of the available fields. Fields not otherwise described + herein are to be filled with binary zero (0), and implementations + + + +Vixie Standards Track [Page 2] + +RFC 1996 DNS NOTIFY August 1996 + + + must ignore all messages for which this is not the case. + + 3.3. NOTIFY is similar to QUERY in that it has a request message with + the header QR flag "clear" and a response message with QR "set". The + response message contains no useful information, but its reception by + the master is an indication that the slave has received the NOTIFY + and that the master can remove the slave from any retry queue for + this NOTIFY event. + + 3.4. The transport protocol used for a NOTIFY transaction will be UDP + unless the master has reason to believe that TCP is necessary; for + example, if a firewall has been installed between master and slave, + and only TCP has been allowed; or, if the changed RR is too large to + fit in a UDP/DNS datagram. + + 3.5. If TCP is used, both master and slave must continue to offer + name service during the transaction, even when the TCP transaction is + not making progress. The NOTIFY request is sent once, and a + "timeout" is said to have occurred if no NOTIFY response is received + within a reasonable interval. + + 3.6. If UDP is used, a master periodically sends a NOTIFY request to + a slave until either too many copies have been sent (a "timeout"), an + ICMP message indicating that the port is unreachable, or until a + NOTIFY response is received from the slave with a matching query ID, + QNAME, IP source address, and UDP source port number. + + Note: + The interval between transmissions, and the total number of + retransmissions, should be operational parameters specifiable by + the name server administrator, perhaps on a per-zone basis. + Reasonable defaults are a 60 second interval (or timeout if + using TCP), and a maximum of 5 retransmissions (for UDP). It is + considered reasonable to use additive or exponential backoff for + the retry interval. + + 3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, + ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an + unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A + slave receiving such a hint is free to treat equivilence of this + answer section with its local data as a "no further work needs to be + done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section + differs from the slave's local data, then the slave should query its + known masters to retrieve the new data. + + 3.8. In no case shall the answer section of a NOTIFY request be used + to update a slave's local data, or to indicate that a zone transfer + needs to be undertaken, or to change the slave's zone refresh timers. + + + +Vixie Standards Track [Page 3] + +RFC 1996 DNS NOTIFY August 1996 + + + Only a "data present; data same" condition can lead a slave to act + differently if ANCOUNT>0 than it would if ANCOUNT=0. + + 3.9. This version of the NOTIFY specification makes no use of the + authority or additional data sections, and so conforming + implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting + requests. Since a future revision of this specification may define a + backwards compatible use for either or both of these sections, + current implementations must ignore these sections, but not the + entire message, if AUCOUNT>0 and/or ADCOUNT>0. + + 3.10. If a slave receives a NOTIFY request from a host that is not a + known master for the zone containing the QNAME, it should ignore the + request and produce an error message in its operations log. + + Note: + This implies that slaves of a multihomed master must either know + their master by the "closest" of the master's interface + addresses, or must know all of the master's interface addresses. + Otherwise, a valid NOTIFY request might come from an address + that is not on the slave's state list of masters for the zone, + which would be an error. + + 3.11. The only defined NOTIFY event at this time is that the SOA RR + has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, + the slave should behave as though the zone given in the QNAME had + reached its REFRESH interval (see [RFC1035]), i.e., it should query + its masters for the SOA of the zone given in the NOTIFY QNAME, and + check the answer to see if the SOA SERIAL has been incremented since + the last time the zone was fetched. If so, a zone transfer (either + AXFR or IXFR) should be initiated. + + Note: + Because a deep server dependency graph may have multiple paths + from the primary master to any given slave, it is possible that + a slave will receive a NOTIFY from one of its known masters even + though the rest of its known masters have not yet updated their + copies of the zone. Therefore, when issuing a QUERY for the + zone's SOA, the query should be directed at the known master who + was the source of the NOTIFY event, and not at any of the other + known masters. This represents a departure from [RFC1035], + which specifies that upon expiry of the SOA REFRESH interval, + all known masters should be queried in turn. + + 3.12. If a NOTIFY request is received by a slave who does not + implement the NOTIFY opcode, it will respond with a NOTIMP + (unimplemented feature error) message. A master server who receives + such a NOTIMP should consider the NOTIFY transaction complete for + + + +Vixie Standards Track [Page 4] + +RFC 1996 DNS NOTIFY August 1996 + + + that slave. + +4. Details and Examples + + 4.1. Retaining query state information across host reboots is + optional, but it is reasonable to simply execute an SOA NOTIFY + transaction on each authority zone when a server first starts. + + 4.2. Each slave is likely to receive several copies of the same + NOTIFY request: One from the primary master, and one from each other + slave as that slave transfers the new zone and notifies its potential + peers. The NOTIFY protocol supports this multiplicity by requiring + that NOTIFY be sent by a slave/master only AFTER it has updated the + SOA RR or has determined that no update is necessary, which in + practice means after a successful zone transfer. Thus, barring + delivery reordering, the last NOTIFY any slave receives will be the + one indicating the latest change. Since a slave always requests SOAs + and AXFR/IXFRs only from its known masters, it will have an + opportunity to retry its QUERY for the SOA after each of its masters + have completed each zone update. + + 4.3. If a master server seeks to avoid causing a large number of + simultaneous outbound zone transfers, it may delay for an arbitrary + length of time before sending a NOTIFY message to any given slave. + It is expected that the time will be chosen at random, so that each + slave will begin its transfer at a unique time. The delay shall not + in any case be longer than the SOA REFRESH time. + + Note: + This delay should be a parameter that each primary master name + server can specify, perhaps on a per-zone basis. Random delays + of between 30 and 60 seconds would seem adequate if the servers + share a LAN and the zones are of moderate size. + + 4.4. A slave which receives a valid NOTIFY should defer action on any + subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has + completed the transaction begun by the first NOTIFY. This duplicate + rejection is necessary to avoid having multiple notifications lead to + pummeling the master server. + + + + + + + + + + + + +Vixie Standards Track [Page 5] + +RFC 1996 DNS NOTIFY August 1996 + + + 4.5 Zone has Updated on Primary Master + + Primary master sends a NOTIFY request to all servers named in Notify + Set. The NOTIFY request has the following characteristics: + + query ID: (new) + op: NOTIFY (4) + resp: NOERROR + flags: AA + qcount: 1 + qname: (zone name) + qclass: (zone class) + qtype: T_SOA + + 4.6 Zone has Updated on a Slave that is also a Master + + As above in 4.5, except that this server's Notify Set may be + different from the Primary Master's due to optional static + specification of local stealth servers. + + 4.7 Slave Receives a NOTIFY Request from a Master + + When a slave server receives a NOTIFY request from one of its locally + designated masters for the zone enclosing the given QNAME, with + QTYPE=SOA and QR=0, it should enter the state it would if the zone's + refresh timer had expired. It will also send a NOTIFY response back + to the NOTIFY request's source, with the following characteristics: + + query ID: (same) + op: NOTIFY (4) + resp: NOERROR + flags: QR AA + qcount: 1 + qname: (zone name) + qclass: (zone class) + qtype: T_SOA + + This is intended to be identical to the NOTIFY request, except that + the QR bit is also set. The query ID of the response must be the + same as was received in the request. + + 4.8 Master Receives a NOTIFY Response from Slave + + When a master server receives a NOTIFY response, it deletes this + query from the retry queue, thus completing the "notification + process" of "this" RRset change to "that" server. + + + + + +Vixie Standards Track [Page 6] + +RFC 1996 DNS NOTIFY August 1996 + + +5. Security Considerations + + We believe that the NOTIFY operation's only security considerations + are: + + 1. That a NOTIFY request with a forged IP/UDP source address can + cause a slave to send spurious SOA queries to its masters, + leading to a benign denial of service attack if the forged + requests are sent very often. + + 2. That TCP spoofing could be used against a slave server given + NOTIFY as a means of synchronizing an SOA query and UDP/DNS + spoofing as a means of forcing a zone transfer. + +6. References + + [RFC1035] + Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [IXFR] + Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996. + +7. Author's Address + + Paul Vixie + Internet Software Consortium + Star Route Box 159A + Woodside, CA 94062 + + Phone: +1 415 747 0204 + EMail: paul@vix.com + + + + + + + + + + + + + + + + + + + +Vixie Standards Track [Page 7] + diff --git a/Documentation/en/rfc/rfc2010.txt b/Documentation/en/rfc/rfc2010.txt new file mode 100644 index 00000000..7e43bfce --- /dev/null +++ b/Documentation/en/rfc/rfc2010.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group B. Manning +Request for Comments: 2010 ISI +Category: Informational P. Vixie + ISC + October 1996 + + + Operational Criteria for Root Name Servers + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document specifies the operational requirements of root name + servers, including host hardware capacities, name server software + revisions, network connectivity, and physical environment. + +1 - Rationale and Scope + + 1.1. Historically, the name servers responsible for the root (".") + zone have also been responsible for all international top-level + domains (iTLD's, for example: COM, EDU, INT, ARPA). These name + servers have been operated by a cadre of highly capable volunteers, + and their administration has been loosely coordinated by the NIC + (first SRI-NIC and now InterNIC). Ultimate responsibility for the + correct operation of these servers and for the content of the DNS + zones they served has always rested with the IANA. + + 1.2. As described in [Postel96], many new TLD's may be created + shortly. Servers for all new and existing iTLD's will be subject to + the operational requirements given in [Postel96]. The set of servers + for the root (".") zone is likely to become disjoint from the set of + servers for any TLD or group of TLD's, including those maintained by + the InterNIC. + + + + + + + + + + + + + +Manning & Vixie Informational [Page 1] + +RFC 2010 DNSSVR Criteria October 1996 + + + 1.3. In spite of the similarities in operational requirements between + the servers for the iTLD's and the servers for the root (".") zone, + they are in fact different server sets with different administrators + and slightly different operational requirements. It is likely that + many contry code tld servers will have even more divergent + operational requirements. That said, the requirements set down in + this document could be successfully applied to any name server + (whether root, top level, or any other level), but may be more + draconian than necessary for servers other than those of the root + (".") zone. + + Disclaimer: The selection of name server locations and + administrators, and the procedures for addressing + noncompliance with these stated operational + requirements, are outside the scope of this document. + + Definition: For the purpose of this document, the term "zone master" + shall be used to designate the administrative owner of + the content of a zone. This person is expected to have + final responsibility for the selection and correct + operation of all of the zone's servers. For the root + (".") zone, this is the IANA. + +2 - Operational Requirements + + 2.1. Name server software. The zone master shall initially and + periodically choose a name server package to run on all of the zone's + servers. It is expected that the BIND server will be used, at least + initially, and that new versions or other servers will be specified + from time to time. + + Rationale: This requirement is based on the wide and free + availability of BIND's source code, and the active + analysis and development it constantly receives from + several members of the IETF. + + Name server software upgrades will be specified and scheduled by the + zone master, and must occur on all of a zone's servers within a + specified 96 hour window. + + Rationale: In some cases it has proven necessary to "cold start" a + zone's servers in order to clear out oscillating bad + data. By forcing all software upgrades to happen at + about the same time, it will be possible to coordinate + a software change with a zone content change. + + + + + + +Manning & Vixie Informational [Page 2] + +RFC 2010 DNSSVR Criteria October 1996 + + + 2.2. UDP checksums. UDP checksums must be generated when sending + datagrams, and verified when receiving them. + + Rationale: Some vendors turn off UDP checksums for performance + reasons, citing the presence of MAC-level frame checks + (CRC, for example) as "strong enough." This has been + a disaster in actual practice. + + 2.3. Dedicated host. A name server host should have no other + function, and no login accounts other than for system or network + administrators. No other network protocols should be served by a + name server host (e.g., SMTP, NNTP, FTP, et al). If login is + permitted from other than the system console, then the login service + must be by encrypted channel (e.g., Kerberized and encrypted + rlogin/telnet, the secure shell (SSH), or an equivilent). + + Rationale: Each additional service performed by a host makes it + less reliable and potentially less secure, as well as + complicating fault isolation procedures. While name + service does not consume very much in the way of system + resources, it is thought best that a host do a few + things well rather than many things poorly. + + 2.4. Clock synchronization. A name server host should synchronize + its clock using the NTP protocol (currnet version) with + authentication. At least two NTP servers should be used. As an + exception to section 2.3 above, a name server host can be an NTP + server as well. + + Rationale: For distributed fault isolation reasons, synchronized + time stamps in system event logs are quite helpful. + NTP is easily spoofed by UDP blast attacks, thus the + requirement for authentication between the name server + host and its NTP servers. A name server host is + allowed to be an NTP server because it has been + observed that a single host running both name service + and stratum 1 NTP is still quite reliable and secure. + + 2.5. Network interfaces. Name servers must send UDP responses with + an IP source address (and UDP source port number) equal to the IP + destination address (and UDP destination port number) of the request. + Also, a name server might have multiple real interfaces, but only one + will be advertised in the zone's NS RRset and associated glue A RRs. + The advertised address should be that of the "best" interface on the + host, in terms of network performance and reliability to the largest + number of destinations. + + + + + +Manning & Vixie Informational [Page 3] + +RFC 2010 DNSSVR Criteria October 1996 + + + Rationale: While not required by [RFC1035], many extant DNS + implementations require the source address and port of + a reply to match the destination address and port to + which the request was sent. The number of advertised + addresses is limited to one (1) so that DNS delegation + responses containing this name server can be as short + as possible. + + 2.6. Physical environment. A name server host must be located in a + secure space such as a locked computer room or a data center with + restricted access. The power supply should be redundant, using + batteries, generators or some other means to protect against utility + power failures. Network connectivity should be redundant, so that a + single wide area line failure cannot completely isolate the name + server host from the rest of the network. + + 2.7. Network security. The system and network administrators should + educate themselves about potential threats, and stay current on CERT + bulletins regarding network breakins. The system staff should + periodically audit the name server host's activity logs and be able + to detect breakins during or after the fact. + + 2.8. Host performance. As of the time of this writing, a name server + must be able to answer 1,200 UDP transactions per second with less + than 5 milliseconds of average latency. Because the network is still + growing at a high rate, the ability to grow to 2,000 transactions per + second and still support a 5 millisecond latency is highly desirable. + Note that this requirement affects both the host and the network + infrastructure to which that host is attached. + + 2.9. Response time. The administrators responsible for a name server + will respond to e-mail trouble reports within 24 hours. Personnel + issues such as vacations and illness will cause responsibilities to + be delegated and/or reassigned rather than ignored. After hours + telephone numbers must be made available to the zone master for + nonpublished use in emergencies. An escalation contact name, e-mail + address, and telephone number will also be made available to the zone + master in the event of nonresponse through the normal channel. + + 2.10. Zone transfer access control. The name server shall be + configured so that outbound zone transfers are permitted only to + destinations on the server's local networks, and to whichever + networks the zone master designates for remote debugging purposes. + + + + + + + + +Manning & Vixie Informational [Page 4] + +RFC 2010 DNSSVR Criteria October 1996 + + + Rationale: Zone transfers can present a significant load on a name + server, especially if several transfers are started + simultaneously against the same server. There is no + operational reason to allow anyone outside the name + server's and zone's administrators to transfer the + entire zone. + + 2.11. Zone transfer protocol. DNS AXFR shall be used in preference + to FTP or any other non-DNS transfer protocol. DNS NOTIFY (see + [NOTIFY]) and DNS IXFR (see [IXFR]) shall be supported and enabled + when available. + + Rationale: Historically, the common implementations of DNS + (a.k.a., BIND) did not support zone transfer of the + root (".") zone due to programming errors. Thus, FTP + was used. In the future, DNS implementations which do + not support zone transfer of all zones will not be + considered suitable for use as root name servers. The + benefits of [IXFR] and [NOTIFY] should be obvious. + + 2.12. Recursion shall be disabled for queries. + + Rationale: Recursion is a major source of cache pollution, and can + be a major drain on name server performance. An + organization's recursive DNS needs should be served by + some other host than its root name server(s). An + exception is made for missing glue since it's possible + that glue needed for some delegations will not be + within or beneath any zone for which the server is + authoritative. Such glue must be fetched via + recursive lookups to other servers. + + 2.13. Outages shall be reported. All outages, scheduled or not, + shall be reported to the zone master via e-mail. If an outage is + unscheduled or if an outage is scheduled less than 24 hours in + advance, then an additional notification of the zone master shall be + made via telephone. Extended or repeated outages may beget special + handling by the zone master. + + 2.14. Inverse name lookups. The PTR RR associated with a server's + primary interface address (that is, the address shown in in the + zone's delegation) shall have its target specified by the zone + master. + + + + + + + + +Manning & Vixie Informational [Page 5] + +RFC 2010 DNSSVR Criteria October 1996 + + + Rationale: Since each organization has local control of their + network's PTR RRs, and since it is necessary for the + correct operation of some software that the forward and + reverse lookups have symmetrical results, it is left + up to the zone master to select the name for each + authority server's primary address. + +3 - Possible Selection Criteria + + 3.1. Host population. A server's location on the network should be + such that it has a low IP hop count to a high number of end hosts. + Duplication of service should be avoided, such that any given set of + end hosts needs to have a low IP hop count to at most one authority + server for any given zone. + + 3.2. Infrastructure diversity. A server's location on the network + should be such that most failures capable of isolating it from a + large number of end hosts are diverse from the failures capable of + similarly isolating other authority servers for the same zone(s). + +4 - Security Considerations + + See section 2.7. + +5 - References + + [RFC1035] + Mockapetris, P., "Domain Names - Implementation and Specification", + STD 13, RFC 1035, USC/Information Sciences Institute, November + 1987. + + [Postel96] + Postel, J., "New Registries and the Delegation of International Top + Level Domains", Work in Progress. + + [IXFR] + Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996. + + [NOTIFY] + Vixie, P., "A Mechanism for Prompt Notification of Zone Changes", + RFC 1996, August 1996. + +6 - Acknowledgements + + Constructive comments have been received from: Jon Postel, Michael + Patton, Andrew Partan, Michael Dillon, Don Mitchell Steven Doyle, + Owen DeLong and other members of the internet community. + + + + +Manning & Vixie Informational [Page 6] + +RFC 2010 DNSSVR Criteria October 1996 + + +7 - Authors' Addresses + + Bill Manning + USC/ISI + 4676 Admiralty Way + Marina del Rey, CA 90292 + + Phone: +1 310 822 1511 + EMail: bmanning@isi.edu + + + Paul Vixie + Internet Software Consortium + Star Route Box 159A + Woodside, CA 94062 + + Phone: +1 415 747 0204 + EMail: paul@vix.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Manning & Vixie Informational [Page 7] + diff --git a/Documentation/en/rfc/rfc2047.txt b/Documentation/en/rfc/rfc2047.txt new file mode 100644 index 00000000..ff9a744b --- /dev/null +++ b/Documentation/en/rfc/rfc2047.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 2047 University of Tennessee +Obsoletes: 1521, 1522, 1590 November 1996 +Category: Standards Track + + + MIME (Multipurpose Internet Mail Extensions) Part Three: + Message Header Extensions for Non-ASCII Text + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + STD 11, RFC 822, defines a message representation protocol specifying + considerable detail about US-ASCII message headers, and leaves the + message content, or message body, as flat US-ASCII text. This set of + documents, collectively called the Multipurpose Internet Mail + Extensions, or MIME, redefines the format of messages to allow for + + (1) textual message bodies in character sets other than US-ASCII, + + (2) an extensible set of different formats for non-textual message + bodies, + + (3) multi-part message bodies, and + + (4) textual header information in character sets other than US-ASCII. + + These documents are based on earlier work documented in RFC 934, STD + 11, and RFC 1049, but extends and revises them. Because RFC 822 said + so little about message bodies, these documents are largely + orthogonal to (rather than a revision of) RFC 822. + + This particular document is the third document in the series. It + describes extensions to RFC 822 to allow non-US-ASCII text data in + Internet mail header fields. + + + + + + + + + +Moore Standards Track [Page 1] + +RFC 2047 Message Header Extensions November 1996 + + + Other documents in this series include: + + + RFC 2045, which specifies the various headers used to describe + the structure of MIME messages. + + + RFC 2046, which defines the general structure of the MIME media + typing system and defines an initial set of media types, + + + RFC 2048, which specifies various IANA registration procedures + for MIME-related facilities, and + + + RFC 2049, which describes MIME conformance criteria and + provides some illustrative examples of MIME message formats, + acknowledgements, and the bibliography. + + These documents are revisions of RFCs 1521, 1522, and 1590, which + themselves were revisions of RFCs 1341 and 1342. An appendix in RFC + 2049 describes differences and changes from previous versions. + +1. Introduction + + RFC 2045 describes a mechanism for denoting textual body parts which + are coded in various character sets, as well as methods for encoding + such body parts as sequences of printable US-ASCII characters. This + memo describes similar techniques to allow the encoding of non-ASCII + text in various portions of a RFC 822 [2] message header, in a manner + which is unlikely to confuse existing message handling software. + + Like the encoding techniques described in RFC 2045, the techniques + outlined here were designed to allow the use of non-ASCII characters + in message headers in a way which is unlikely to be disturbed by the + quirks of existing Internet mail handling programs. In particular, + some mail relaying programs are known to (a) delete some message + header fields while retaining others, (b) rearrange the order of + addresses in To or Cc fields, (c) rearrange the (vertical) order of + header fields, and/or (d) "wrap" message headers at different places + than those in the original message. In addition, some mail reading + programs are known to have difficulty correctly parsing message + headers which, while legal according to RFC 822, make use of + backslash-quoting to "hide" special characters such as "<", ",", or + ":", or which exploit other infrequently-used features of that + specification. + + While it is unfortunate that these programs do not correctly + interpret RFC 822 headers, to "break" these programs would cause + severe operational problems for the Internet mail system. The + extensions described in this memo therefore do not rely on little- + used features of RFC 822. + + + +Moore Standards Track [Page 2] + +RFC 2047 Message Header Extensions November 1996 + + + Instead, certain sequences of "ordinary" printable ASCII characters + (known as "encoded-words") are reserved for use as encoded data. The + syntax of encoded-words is such that they are unlikely to + "accidentally" appear as normal text in message headers. + Furthermore, the characters used in encoded-words are restricted to + those which do not have special meanings in the context in which the + encoded-word appears. + + Generally, an "encoded-word" is a sequence of printable ASCII + characters that begins with "=?", ends with "?=", and has two "?"s in + between. It specifies a character set and an encoding method, and + also includes the original text encoded as graphic ASCII characters, + according to the rules for that encoding method. + + A mail composer that implements this specification will provide a + means of inputting non-ASCII text in header fields, but will + translate these fields (or appropriate portions of these fields) into + encoded-words before inserting them into the message header. + + A mail reader that implements this specification will recognize + encoded-words when they appear in certain portions of the message + header. Instead of displaying the encoded-word "as is", it will + reverse the encoding and display the original text in the designated + character set. + +NOTES + + This memo relies heavily on notation and terms defined RFC 822 and + RFC 2045. In particular, the syntax for the ABNF used in this memo + is defined in RFC 822, as well as many of the terminal or nonterminal + symbols from RFC 822 are used in the grammar for the header + extensions defined here. Among the symbols defined in RFC 822 and + referenced in this memo are: 'addr-spec', 'atom', 'CHAR', 'comment', + 'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair'. + 'quoted-string', 'SPACE', and 'word'. Successful implementation of + this protocol extension requires careful attention to the RFC 822 + definitions of these terms. + + When the term "ASCII" appears in this memo, it refers to the "7-Bit + American Standard Code for Information Interchange", ANSI X3.4-1986. + The MIME charset name for this character set is "US-ASCII". When not + specifically referring to the MIME charset name, this document uses + the term "ASCII", both for brevity and for consistency with RFC 822. + However, implementors are warned that the character set name must be + spelled "US-ASCII" in MIME message and body part headers. + + + + + + +Moore Standards Track [Page 3] + +RFC 2047 Message Header Extensions November 1996 + + + This memo specifies a protocol for the representation of non-ASCII + text in message headers. It specifically DOES NOT define any + translation between "8-bit headers" and pure ASCII headers, nor is + any such translation assumed to be possible. + +2. Syntax of encoded-words + + An 'encoded-word' is defined by the following ABNF grammar. The + notation of RFC 822 is used, with the exception that white space + characters MUST NOT appear between components of an 'encoded-word'. + + encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" + + charset = token ; see section 3 + + encoding = token ; see section 4 + + token = 1*<Any CHAR except SPACE, CTLs, and especials> + + especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " + <"> / "/" / "[" / "]" / "?" / "." / "=" + + encoded-text = 1*<Any printable ASCII character other than "?" + or SPACE> + ; (but see "Use of encoded-words in message + ; headers", section 5) + + Both 'encoding' and 'charset' names are case-independent. Thus the + charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the + encoding named "Q" may be spelled either "Q" or "q". + + An 'encoded-word' may not be more than 75 characters long, including + 'charset', 'encoding', 'encoded-text', and delimiters. If it is + desirable to encode more text than will fit in an 'encoded-word' of + 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may + be used. + + While there is no limit to the length of a multiple-line header + field, each line of a header field that contains one or more + 'encoded-word's is limited to 76 characters. + + The length restrictions are included both to ease interoperability + through internetwork mail gateways, and to impose a limit on the + amount of lookahead a header parser must employ (while looking for a + final ?= delimiter) before it can decide whether a token is an + "encoded-word" or something else. + + + + + +Moore Standards Track [Page 4] + +RFC 2047 Message Header Extensions November 1996 + + + IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's + by an RFC 822 parser. As a consequence, unencoded white space + characters (such as SPACE and HTAB) are FORBIDDEN within an + 'encoded-word'. For example, the character sequence + + =?iso-8859-1?q?this is some text?= + + would be parsed as four 'atom's, rather than as a single 'atom' (by + an RFC 822 parser) or 'encoded-word' (by a parser which understands + 'encoded-words'). The correct way to encode the string "this is some + text" is to encode the SPACE characters as well, e.g. + + =?iso-8859-1?q?this=20is=20some=20text?= + + The characters which may appear in 'encoded-text' are further + restricted by the rules in section 5. + +3. Character sets + + The 'charset' portion of an 'encoded-word' specifies the character + set associated with the unencoded text. A 'charset' can be any of + the character set names allowed in an MIME "charset" parameter of a + "text/plain" body part, or any character set name registered with + IANA for use with the MIME text/plain content-type. + + Some character sets use code-switching techniques to switch between + "ASCII mode" and other modes. If unencoded text in an 'encoded-word' + contains a sequence which causes the charset interpreter to switch + out of ASCII mode, it MUST contain additional control codes such that + ASCII mode is again selected at the end of the 'encoded-word'. (This + rule applies separately to each 'encoded-word', including adjacent + 'encoded-word's within a single header field.) + + When there is a possibility of using more than one character set to + represent the text in an 'encoded-word', and in the absence of + private agreements between sender and recipients of a message, it is + recommended that members of the ISO-8859-* series be used in + preference to other character sets. + +4. Encodings + + Initially, the legal values for "encoding" are "Q" and "B". These + encodings are described below. The "Q" encoding is recommended for + use when most of the characters to be encoded are in the ASCII + character set; otherwise, the "B" encoding should be used. + Nevertheless, a mail reader which claims to recognize 'encoded-word's + MUST be able to accept either encoding for any character set which it + supports. + + + +Moore Standards Track [Page 5] + +RFC 2047 Message Header Extensions November 1996 + + + Only a subset of the printable ASCII characters may be used in + 'encoded-text'. Space and tab characters are not allowed, so that + the beginning and end of an 'encoded-word' are obvious. The "?" + character is used within an 'encoded-word' to separate the various + portions of the 'encoded-word' from one another, and thus cannot + appear in the 'encoded-text' portion. Other characters are also + illegal in certain contexts. For example, an 'encoded-word' in a + 'phrase' preceding an address in a From header field may not contain + any of the "specials" defined in RFC 822. Finally, certain other + characters are disallowed in some contexts, to ensure reliability for + messages that pass through internetwork mail gateways. + + The "B" encoding automatically meets these requirements. The "Q" + encoding allows a wide range of printable characters to be used in + non-critical locations in the message header (e.g., Subject), with + fewer characters available for use in other locations. + +4.1. The "B" encoding + + The "B" encoding is identical to the "BASE64" encoding defined by RFC + 2045. + +4.2. The "Q" encoding + + The "Q" encoding is similar to the "Quoted-Printable" content- + transfer-encoding defined in RFC 2045. It is designed to allow text + containing mostly ASCII characters to be decipherable on an ASCII + terminal without decoding. + + (1) Any 8-bit value may be represented by a "=" followed by two + hexadecimal digits. For example, if the character set in use + were ISO-8859-1, the "=" character would thus be encoded as + "=3D", and a SPACE by "=20". (Upper case should be used for + hexadecimal digits "A" through "F".) + + (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be + represented as "_" (underscore, ASCII 95.). (This character may + not pass through some internetwork mail gateways, but its use + will greatly enhance readability of "Q" encoded data with mail + readers that do not support this encoding.) Note that the "_" + always represents hexadecimal 20, even if the SPACE character + occupies a different code position in the character set in use. + + (3) 8-bit values which correspond to printable ASCII characters other + than "=", "?", and "_" (underscore), MAY be represented as those + characters. (But see section 5 for restrictions.) In + particular, SPACE and TAB MUST NOT be represented as themselves + within encoded words. + + + +Moore Standards Track [Page 6] + +RFC 2047 Message Header Extensions November 1996 + + +5. Use of encoded-words in message headers + + An 'encoded-word' may appear in a message header or body part header + according to the following rules: + +(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822) + in any Subject or Comments header field, any extension message + header field, or any MIME body part field for which the field body + is defined as '*text'. An 'encoded-word' may also appear in any + user-defined ("X-") message or body part header field. + + Ordinary ASCII text and 'encoded-word's may appear together in the + same header field. However, an 'encoded-word' that appears in a + header field defined as '*text' MUST be separated from any adjacent + 'encoded-word' or 'text' by 'linear-white-space'. + +(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and + ")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC + 822 ABNF definition for 'comment' is amended as follows: + + comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" + + A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT + contain the characters "(", ")" or " + 'encoded-word' that appears in a 'comment' MUST be separated from + any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'. + + It is important to note that 'comment's are only recognized inside + "structured" field bodies. In fields whose bodies are defined as + '*text', "(" and ")" are treated as ordinary characters rather than + comment delimiters, and rule (1) of this section applies. (See RFC + 822, sections 3.1.2 and 3.1.3) + +(3) As a replacement for a 'word' entity within a 'phrase', for example, + one that precedes an address in a From, To, or Cc header. The ABNF + definition for 'phrase' from RFC 822 thus becomes: + + phrase = 1*( encoded-word / word ) + + In this case the set of characters that may be used in a "Q"-encoded + 'encoded-word' is restricted to: <upper and lower case ASCII + letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_" + (underscore, ASCII 95.)>. An 'encoded-word' that appears within a + 'phrase' MUST be separated from any adjacent 'word', 'text' or + 'special' by 'linear-white-space'. + + + + + + +Moore Standards Track [Page 7] + +RFC 2047 Message Header Extensions November 1996 + + + These are the ONLY locations where an 'encoded-word' may appear. In + particular: + + + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'. + + + An 'encoded-word' MUST NOT appear within a 'quoted-string'. + + + An 'encoded-word' MUST NOT be used in a Received header field. + + + An 'encoded-word' MUST NOT be used in parameter of a MIME + Content-Type or Content-Disposition field, or in any structured + field body except within a 'comment' or 'phrase'. + + The 'encoded-text' in an 'encoded-word' must be self-contained; + 'encoded-text' MUST NOT be continued from one 'encoded-word' to + another. This implies that the 'encoded-text' portion of a "B" + 'encoded-word' will be a multiple of 4 characters long; for a "Q" + 'encoded-word', any "=" character that appears in the 'encoded-text' + portion will be followed by two hexadecimal characters. + + Each 'encoded-word' MUST encode an integral number of octets. The + 'encoded-text' in each 'encoded-word' must be well-formed according + to the encoding specified; the 'encoded-text' may not be continued in + the next 'encoded-word'. (For example, "=?charset?Q?=?= + =?charset?Q?AB?=" would be illegal, because the two hex digits "AB" + must follow the "=" in the same 'encoded-word'.) + + Each 'encoded-word' MUST represent an integral number of characters. + A multi-octet character may not be split across adjacent 'encoded- + word's. + + Only printable and white space character data should be encoded using + this scheme. However, since these encoding schemes allow the + encoding of arbitrary octet values, mail readers that implement this + decoding should also ensure that display of the decoded data on the + recipient's terminal will not cause unwanted side-effects. + + Use of these methods to encode non-textual data (e.g., pictures or + sounds) is not defined by this memo. Use of 'encoded-word's to + represent strings of purely ASCII characters is allowed, but + discouraged. In rare cases it may be necessary to encode ordinary + text that looks like an 'encoded-word'. + + + + + + + + + +Moore Standards Track [Page 8] + +RFC 2047 Message Header Extensions November 1996 + + +6. Support of 'encoded-word's by mail readers + +6.1. Recognition of 'encoded-word's in message headers + + A mail reader must parse the message and body part headers according + to the rules in RFC 822 to correctly recognize 'encoded-word's. + + 'encoded-word's are to be recognized as follows: + + (1) Any message or body part header field defined as '*text', or any + user-defined header field, should be parsed as follows: Beginning + at the start of the field-body and immediately following each + occurrence of 'linear-white-space', each sequence of up to 75 + printable characters (not containing any 'linear-white-space') + should be examined to see if it is an 'encoded-word' according to + the syntax rules in section 2. Any other sequence of printable + characters should be treated as ordinary ASCII text. + + (2) Any header field not defined as '*text' should be parsed + according to the syntax rules for that header field. However, + any 'word' that appears within a 'phrase' should be treated as an + 'encoded-word' if it meets the syntax rules in section 2. + Otherwise it should be treated as an ordinary 'word'. + + (3) Within a 'comment', any sequence of up to 75 printable characters + (not containing 'linear-white-space'), that meets the syntax + rules in section 2, should be treated as an 'encoded-word'. + Otherwise it should be treated as normal comment text. + + (4) A MIME-Version header field is NOT required to be present for + 'encoded-word's to be interpreted according to this + specification. One reason for this is that the mail reader is + not expected to parse the entire message header before displaying + lines that may contain 'encoded-word's. + +6.2. Display of 'encoded-word's + + Any 'encoded-word's so recognized are decoded, and if possible, the + resulting unencoded text is displayed in the original character set. + + NOTE: Decoding and display of encoded-words occurs *after* a + structured field body is parsed into tokens. It is therefore + possible to hide 'special' characters in encoded-words which, when + displayed, will be indistinguishable from 'special' characters in the + surrounding text. For this and other reasons, it is NOT generally + possible to translate a message header containing 'encoded-word's to + an unencoded form which can be parsed by an RFC 822 mail reader. + + + + +Moore Standards Track [Page 9] + +RFC 2047 Message Header Extensions November 1996 + + + When displaying a particular header field that contains multiple + 'encoded-word's, any 'linear-white-space' that separates a pair of + adjacent 'encoded-word's is ignored. (This is to allow the use of + multiple 'encoded-word's to represent long strings of unencoded text, + without having to separate 'encoded-word's where spaces occur in the + unencoded text.) + + In the event other encodings are defined in the future, and the mail + reader does not support the encoding used, it may either (a) display + the 'encoded-word' as ordinary text, or (b) substitute an appropriate + message indicating that the text could not be decoded. + + If the mail reader does not support the character set used, it may + (a) display the 'encoded-word' as ordinary text (i.e., as it appears + in the header), (b) make a "best effort" to display using such + characters as are available, or (c) substitute an appropriate message + indicating that the decoded text could not be displayed. + + If the character set being used employs code-switching techniques, + display of the encoded text implicitly begins in "ASCII mode". In + addition, the mail reader must ensure that the output device is once + again in "ASCII mode" after the 'encoded-word' is displayed. + +6.3. Mail reader handling of incorrectly formed 'encoded-word's + + It is possible that an 'encoded-word' that is legal according to the + syntax defined in section 2, is incorrectly formed according to the + rules for the encoding being used. For example: + + (1) An 'encoded-word' which contains characters which are not legal + for a particular encoding (for example, a "-" in the "B" + encoding, or a SPACE or HTAB in either the "B" or "Q" encoding), + is incorrectly formed. + + (2) Any 'encoded-word' which encodes a non-integral number of + characters or octets is incorrectly formed. + + A mail reader need not attempt to display the text associated with an + 'encoded-word' that is incorrectly formed. However, a mail reader + MUST NOT prevent the display or handling of a message because an + 'encoded-word' is incorrectly formed. + +7. Conformance + + A mail composing program claiming compliance with this specification + MUST ensure that any string of non-white-space printable ASCII + characters within a '*text' or '*ctext' that begins with "=?" and + ends with "?=" be a valid 'encoded-word'. ("begins" means: at the + + + +Moore Standards Track [Page 10] + +RFC 2047 Message Header Extensions November 1996 + + + start of the field-body, immediately following 'linear-white-space', + or immediately following a "(" for an 'encoded-word' within '*ctext'; + "ends" means: at the end of the field-body, immediately preceding + 'linear-white-space', or immediately preceding a ")" for an + 'encoded-word' within '*ctext'.) In addition, any 'word' within a + 'phrase' that begins with "=?" and ends with "?=" must be a valid + 'encoded-word'. + + A mail reading program claiming compliance with this specification + must be able to distinguish 'encoded-word's from 'text', 'ctext', or + 'word's, according to the rules in section 6, anytime they appear in + appropriate places in message headers. It must support both the "B" + and "Q" encodings for any character set which it supports. The + program must be able to display the unencoded text if the character + set is "US-ASCII". For the ISO-8859-* character sets, the mail + reading program must at least be able to display the characters which + are also in the ASCII set. + +8. Examples + + The following are examples of message headers containing 'encoded- + word's: + + From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu> + To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk> + CC: =?ISO-8859-1?Q?Andr=E9?= Pirard <PIRARD@vm1.ulg.ac.be> + Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= + =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= + + Note: In the first 'encoded-word' of the Subject field above, the + last "=" at the end of the 'encoded-text' is necessary because each + 'encoded-word' must be self-contained (the "=" character completes a + group of 4 base64 characters representing 2 octets). An additional + octet could have been encoded in the first 'encoded-word' (so that + the encoded-word would contain an exact multiple of 3 encoded + octets), except that the second 'encoded-word' uses a different + 'charset' than the first one. + + From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <ojarnef@admin.kth.se> + To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se + Subject: Time for ISO 10646? + + To: Dave Crocker <dcrocker@mordor.stanford.edu> + Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se + From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@nada.kth.se> + Subject: Re: RFC-HDR care and feeding + + + + + +Moore Standards Track [Page 11] + +RFC 2047 Message Header Extensions November 1996 + + + From: Nathaniel Borenstein <nsb@thumper.bellcore.com> + (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=) + To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed + <ned@innosoft.com>, Keith Moore <moore@cs.utk.edu> + Subject: Test of new header generator + MIME-Version: 1.0 + Content-type: text/plain; charset=ISO-8859-1 + + The following examples illustrate how text containing 'encoded-word's + which appear in a structured field body. The rules are slightly + different for fields defined as '*text' because "(" and ")" are not + recognized as 'comment' delimiters. [Section 5, paragraph (1)]. + + In each of the following examples, if the same sequence were to occur + in a '*text' field, the "displayed as" form would NOT be treated as + encoded words, but be identical to the "encoded form". This is + because each of the encoded-words in the following examples is + adjacent to a "(" or ")" character. + + encoded form displayed as + --------------------------------------------------------------------- + (=?ISO-8859-1?Q?a?=) (a) + + (=?ISO-8859-1?Q?a?= b) (a b) + + Within a 'comment', white space MUST appear between an + 'encoded-word' and surrounding text. [Section 5, + paragraph (2)]. However, white space is not needed between + the initial "(" that begins the 'comment', and the + 'encoded-word'. + + + (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) + + White space between adjacent 'encoded-word's is not + displayed. + + (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) + + Even multiple SPACEs between 'encoded-word's are ignored + for the purpose of display. + + (=?ISO-8859-1?Q?a?= (ab) + =?ISO-8859-1?Q?b?=) + + Any amount of linear-space-white between 'encoded-word's, + even if it includes a CRLF followed by one or more SPACEs, + is ignored for the purposes of display. + + + +Moore Standards Track [Page 12] + +RFC 2047 Message Header Extensions November 1996 + + + (=?ISO-8859-1?Q?a_b?=) (a b) + + In order to cause a SPACE to be displayed within a portion + of encoded text, the SPACE MUST be encoded as part of the + 'encoded-word'. + + (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b) + + In order to cause a SPACE to be displayed between two strings + of encoded text, the SPACE MAY be encoded as part of one of + the 'encoded-word's. + +9. References + + [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [RFC 2049] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and Examples", + RFC 2049, November 1996. + + [RFC 2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [RFC 2046] Borenstein N., and N. Freed, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: Registration + Procedures", RFC 2048, November 1996. + + + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 13] + +RFC 2047 Message Header Extensions November 1996 + + +10. Security Considerations + + Security issues are not discussed in this memo. + +11. Acknowledgements + + The author wishes to thank Nathaniel Borenstein, Issac Chan, Lutz + Donnerhacke, Paul Eggert, Ned Freed, Andreas M. Kirchwitz, Olle + Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, and Kazuhiko + Yamamoto, for their helpful advice, insightful comments, and + illuminating questions in response to earlier versions of this + specification. + +12. Author's Address + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville TN 37996-1301 + + EMail: moore@cs.utk.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 14] + +RFC 2047 Message Header Extensions November 1996 + + +Appendix - changes since RFC 1522 (in no particular order) + + + explicitly state that the MIME-Version is not requried to use + 'encoded-word's. + + + add explicit note that SPACEs and TABs are not allowed within + 'encoded-word's, explaining that an 'encoded-word' must look like an + 'atom' to an RFC822 parser.values, to be precise). + + + add examples from Olle Jarnefors (thanks!) which illustrate how + encoded-words with adjacent linear-white-space are displayed. + + + explicitly list terms defined in RFC822 and referenced in this memo + + + fix transcription typos that caused one or two lines and a couple of + characters to disappear in the resulting text, due to nroff quirks. + + + clarify that encoded-words are allowed in '*text' fields in both + RFC822 headers and MIME body part headers, but NOT as parameter + values. + + + clarify the requirement to switch back to ASCII within the encoded + portion of an 'encoded-word', for any charset that uses code switching + sequences. + + + add a note about 'encoded-word's being delimited by "(" and ")" + within a comment, but not in a *text (how bizarre!). + + + fix the Andre Pirard example to get rid of the trailing "_" after + the =E9. (no longer needed post-1342). + + + clarification: an 'encoded-word' may appear immediately following + the initial "(" or immediately before the final ")" that delimits a + comment, not just adjacent to "(" and ")" *within* *ctext. + + + add a note to explain that a "B" 'encoded-word' will always have a + multiple of 4 characters in the 'encoded-text' portion. + + + add note about the "=" in the examples + + + note that processing of 'encoded-word's occurs *after* parsing, and + some of the implications thereof. + + + explicitly state that you can't expect to translate between + 1522 and either vanilla 822 or so-called "8-bit headers". + + + explicitly state that 'encoded-word's are not valid within a + 'quoted-string'. + + + +Moore Standards Track [Page 15] + diff --git a/Documentation/en/rfc/rfc2048.txt b/Documentation/en/rfc/rfc2048.txt new file mode 100644 index 00000000..a3b18b31 --- /dev/null +++ b/Documentation/en/rfc/rfc2048.txt @@ -0,0 +1,1180 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2048 Innosoft +BCP: 13 J. Klensin +Obsoletes: 1521, 1522, 1590 MCI +Category: Best Current Practice J. Postel + ISI + November 1996 + + + Multipurpose Internet Mail Extensions + (MIME) Part Four: + Registration Procedures + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Abstract + + STD 11, RFC 822, defines a message representation protocol specifying + considerable detail about US-ASCII message headers, and leaves the + message content, or message body, as flat US-ASCII text. This set of + documents, collectively called the Multipurpose Internet Mail + Extensions, or MIME, redefines the format of messages to allow for + + (1) textual message bodies in character sets other than + US-ASCII, + + (2) an extensible set of different formats for non-textual + message bodies, + + (3) multi-part message bodies, and + + (4) textual header information in character sets other than + US-ASCII. + + These documents are based on earlier work documented in RFC 934, STD + 11, and RFC 1049, but extends and revises them. Because RFC 822 said + so little about message bodies, these documents are largely + orthogonal to (rather than a revision of) RFC 822. + + + + + + + + + +Freed, et. al. Best Current Practice [Page 1] + +RFC 2048 MIME Registration Procedures November 1996 + + + This fourth document, RFC 2048, specifies various IANA registration + procedures for the following MIME facilities: + + (1) media types, + + (2) external body access types, + + (3) content-transfer-encodings. + + Registration of character sets for use in MIME is covered elsewhere + and is no longer addressed by this document. + + These documents are revisions of RFCs 1521 and 1522, which themselves + were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 + describes differences and changes from previous versions. + +Table of Contents + + 1. Introduction ......................................... 3 + 2. Media Type Registration .............................. 4 + 2.1 Registration Trees and Subtype Names ................ 4 + 2.1.1 IETF Tree ......................................... 4 + 2.1.2 Vendor Tree ....................................... 4 + 2.1.3 Personal or Vanity Tree ........................... 5 + 2.1.4 Special `x.' Tree ................................. 5 + 2.1.5 Additional Registration Trees ..................... 6 + 2.2 Registration Requirements ........................... 6 + 2.2.1 Functionality Requirement ......................... 6 + 2.2.2 Naming Requirements ............................... 6 + 2.2.3 Parameter Requirements ............................ 7 + 2.2.4 Canonicalization and Format Requirements .......... 7 + 2.2.5 Interchange Recommendations ....................... 8 + 2.2.6 Security Requirements ............................. 8 + 2.2.7 Usage and Implementation Non-requirements ......... 9 + 2.2.8 Publication Requirements .......................... 10 + 2.2.9 Additional Information ............................ 10 + 2.3 Registration Procedure .............................. 11 + 2.3.1 Present the Media Type to the Community for Review 11 + 2.3.2 IESG Approval ..................................... 12 + 2.3.3 IANA Registration ................................. 12 + 2.4 Comments on Media Type Registrations ................ 12 + 2.5 Location of Registered Media Type List .............. 12 + 2.6 IANA Procedures for Registering Media Types ......... 12 + 2.7 Change Control ...................................... 13 + 2.8 Registration Template ............................... 14 + 3. External Body Access Types ........................... 14 + 3.1 Registration Requirements ........................... 15 + 3.1.1 Naming Requirements ............................... 15 + + + +Freed, et. al. Best Current Practice [Page 2] + +RFC 2048 MIME Registration Procedures November 1996 + + + 3.1.2 Mechanism Specification Requirements .............. 15 + 3.1.3 Publication Requirements .......................... 15 + 3.1.4 Security Requirements ............................. 15 + 3.2 Registration Procedure .............................. 15 + 3.2.1 Present the Access Type to the Community .......... 16 + 3.2.2 Access Type Reviewer .............................. 16 + 3.2.3 IANA Registration ................................. 16 + 3.3 Location of Registered Access Type List ............. 16 + 3.4 IANA Procedures for Registering Access Types ........ 16 + 4. Transfer Encodings ................................... 17 + 4.1 Transfer Encoding Requirements ...................... 17 + 4.1.1 Naming Requirements ............................... 17 + 4.1.2 Algorithm Specification Requirements .............. 18 + 4.1.3 Input Domain Requirements ......................... 18 + 4.1.4 Output Range Requirements ......................... 18 + 4.1.5 Data Integrity and Generality Requirements ........ 18 + 4.1.6 New Functionality Requirements .................... 18 + 4.2 Transfer Encoding Definition Procedure .............. 19 + 4.3 IANA Procedures for Transfer Encoding Registration... 19 + 4.4 Location of Registered Transfer Encodings List ...... 19 + 5. Authors' Addresses ................................... 20 + A. Grandfathered Media Types ............................ 21 + +1. Introduction + + Recent Internet protocols have been carefully designed to be easily + extensible in certain areas. In particular, MIME [RFC 2045] is an + open-ended framework and can accommodate additional object types, + character sets, and access methods without any changes to the basic + protocol. A registration process is needed, however, to ensure that + the set of such values is developed in an orderly, well-specified, + and public manner. + + This document defines registration procedures which use the Internet + Assigned Numbers Authority (IANA) as a central registry for such + values. + + Historical Note: The registration process for media types was + initially defined in the context of the asynchronous Internet mail + environment. In this mail environment there is a need to limit the + number of possible media types to increase the likelihood of + interoperability when the capabilities of the remote mail system are + not known. As media types are used in new environments, where the + proliferation of media types is not a hindrance to interoperability, + the original procedure was excessively restrictive and had to be + generalized. + + + + + +Freed, et. al. Best Current Practice [Page 3] + +RFC 2048 MIME Registration Procedures November 1996 + + +2. Media Type Registration + + Registration of a new media type or types starts with the + construction of a registration proposal. Registration may occur in + several different registration trees, which have different + requirements as discussed below. In general, the new registration + proposal is circulated and reviewed in a fashion appropriate to the + tree involved. The media type is then registered if the proposal is + acceptable. The following sections describe the requirements and + procedures used for each of the different registration trees. + +2.1. Registration Trees and Subtype Names + + In order to increase the efficiency and flexibility of the + registration process, different structures of subtype names may be + registered to accomodate the different natural requirements for, + e.g., a subtype that will be recommended for wide support and + implementation by the Internet Community or a subtype that is used to + move files associated with proprietary software. The following + subsections define registration "trees", distinguished by the use of + faceted names (e.g., names of the form "tree.subtree...type"). Note + that some media types defined prior to this document do not conform + to the naming conventions described below. See Appendix A for a + discussion of them. + +2.1.1. IETF Tree + + The IETF tree is intended for types of general interest to the + Internet Community. Registration in the IETF tree requires approval + by the IESG and publication of the media type registration as some + form of RFC. + + Media types in the IETF tree are normally denoted by names that are + not explicitly faceted, i.e., do not contain period (".", full stop) + characters. + + The "owner" of a media type registration in the IETF tree is assumed + to be the IETF itself. Modification or alteration of the + specification requires the same level of processing (e.g. standards + track) required for the initial registration. + +2.1.2. Vendor Tree + + The vendor tree is used for media types associated with commercially + available products. "Vendor" or "producer" are construed as + equivalent and very broadly in this context. + + + + + +Freed, et. al. Best Current Practice [Page 4] + +RFC 2048 MIME Registration Procedures November 1996 + + + A registration may be placed in the vendor tree by anyone who has + need to interchange files associated with the particular product. + However, the registration formally belongs to the vendor or + organization producing the software or file format. Changes to the + specification will be made at their request, as discussed in + subsequent sections. + + Registrations in the vendor tree will be distinguished by the leading + facet "vnd.". That may be followed, at the discretion of the + registration, by either a media type name from a well-known producer + (e.g., "vnd.mudpie") or by an IANA-approved designation of the + producer's name which is then followed by a media type or product + designation (e.g., vnd.bigcompany.funnypictures). + + While public exposure and review of media types to be registered in + the vendor tree is not required, using the ietf-types list for review + is strongly encouraged to improve the quality of those + specifications. Registrations in the vendor tree may be submitted + directly to the IANA. + +2.1.3. Personal or Vanity Tree + + Registrations for media types created experimentally or as part of + products that are not distributed commercially may be registered in + the personal or vanity tree. The registrations are distinguished by + the leading facet "prs.". + + The owner of "personal" registrations and associated specifications + is the person or entity making the registration, or one to whom + responsibility has been transferred as described below. + + While public exposure and review of media types to be registered in + the personal tree is not required, using the ietf-types list for + review is strongly encouraged to improve the quality of those + specifications. Registrations in the personl tree may be submitted + directly to the IANA. + +2.1.4. Special `x.' Tree + + For convenience and symmetry with this registration scheme, media + type names with "x." as the first facet may be used for the same + purposes for which names starting in "x-" are normally used. These + types are unregistered, experimental, and should be used only with + the active agreement of the parties exchanging them. + + + + + + + +Freed, et. al. Best Current Practice [Page 5] + +RFC 2048 MIME Registration Procedures November 1996 + + + However, with the simplified registration procedures described above + for vendor and personal trees, it should rarely, if ever, be + necessary to use unregistered experimental types, and as such use of + both "x-" and "x." forms is discouraged. + +2.1.5. Additional Registration Trees + + From time to time and as required by the community, the IANA may, + with the advice and consent of the IESG, create new top-level + registration trees. It is explicitly assumed that these trees may be + created for external registration and management by well-known + permanent bodies, such as scientific societies for media types + specific to the sciences they cover. In general, the quality of + review of specifications for one of these additional registration + trees is expected to be equivalent to that which IETF would give to + registrations in its own tree. Establishment of these new trees will + be announced through RFC publication approved by the IESG. + +2.2. Registration Requirements + + Media type registration proposals are all expected to conform to + various requirements laid out in the following sections. Note that + requirement specifics sometimes vary depending on the registration + tree, again as detailed in the following sections. + +2.2.1. Functionality Requirement + + Media types must function as an actual media format: Registration of + things that are better thought of as a transfer encoding, as a + character set, or as a collection of separate entities of another + type, is not allowed. For example, although applications exist to + decode the base64 transfer encoding [RFC 2045], base64 cannot be + registered as a media type. + + This requirement applies regardless of the registration tree + involved. + +2.2.2. Naming Requirements + + All registered media types must be assigned MIME type and subtype + names. The combination of these names then serves to uniquely + identify the media type and the format of the subtype name identifies + the registration tree. + + The choice of top-level type name must take the nature of media type + involved into account. For example, media normally used for + representing still images should be a subtype of the image content + type, whereas media capable of representing audio information belongs + + + +Freed, et. al. Best Current Practice [Page 6] + +RFC 2048 MIME Registration Procedures November 1996 + + + under the audio content type. See RFC 2046 for additional information + on the basic set of top-level types and their characteristics. + + New subtypes of top-level types must conform to the restrictions of + the top-level type, if any. For example, all subtypes of the + multipart content type must use the same encapsulation syntax. + + In some cases a new media type may not "fit" under any currently + defined top-level content type. Such cases are expected to be quite + rare. However, if such a case arises a new top-level type can be + defined to accommodate it. Such a definition must be done via + standards-track RFC; no other mechanism can be used to define + additional top-level content types. + + These requirements apply regardless of the registration tree + involved. + +2.2.3. Parameter Requirements + + Media types may elect to use one or more MIME content type + parameters, or some parameters may be automatically made available to + the media type by virtue of being a subtype of a content type that + defines a set of parameters applicable to any of its subtypes. In + either case, the names, values, and meanings of any parameters must + be fully specified when a media type is registered in the IETF tree, + and should be specified as completely as possible when media types + are registered in the vendor or personal trees. + + New parameters must not be defined as a way to introduce new + functionality in types registered in the IETF tree, although new + parameters may be added to convey additional information that does + not otherwise change existing functionality. An example of this + would be a "revision" parameter to indicate a revision level of an + external specification such as JPEG. Similar behavior is encouraged + for media types registered in the vendor or personal trees but is not + required. + +2.2.4. Canonicalization and Format Requirements + + All registered media types must employ a single, canonical data + format, regardless of registration tree. + + A precise and openly available specification of the format of each + media type is required for all types registered in the IETF tree and + must at a minimum be referenced by, if it isn't actually included in, + the media type registration proposal itself. + + + + + +Freed, et. al. Best Current Practice [Page 7] + +RFC 2048 MIME Registration Procedures November 1996 + + + The specifications of format and processing particulars may or may + not be publically available for media types registered in the vendor + tree, and such registration proposals are explicitly permitted to + include only a specification of which software and version produce or + process such media types. References to or inclusion of format + specifications in registration proposals is encouraged but not + required. + + Format specifications are still required for registration in the + personal tree, but may be either published as RFCs or otherwise + deposited with IANA. The deposited specifications will meet the same + criteria as those required to register a well-known TCP port and, in + particular, need not be made public. + + Some media types involve the use of patented technology. The + registration of media types involving patented technology is + specifically permitted. However, the restrictions set forth in RFC + 1602 on the use of patented technology in standards-track protocols + must be respected when the specification of a media type is part of a + standards-track protocol. + +2.2.5. Interchange Recommendations + + Media types should, whenever possible, interoperate across as many + systems and applications as possible. However, some media types will + inevitably have problems interoperating across different platforms. + Problems with different versions, byte ordering, and specifics of + gateway handling can and will arise. + + Universal interoperability of media types is not required, but known + interoperability issues should be identified whenever possible. + Publication of a media type does not require an exhaustive review of + interoperability, and the interoperability considerations section is + subject to continuing evaluation. + + These recommendations apply regardless of the registration tree + involved. + +2.2.6. Security Requirements + + An analysis of security issues is required for for all types + registered in the IETF Tree. (This is in accordance with the basic + requirements for all IETF protocols.) A similar analysis for media + types registered in the vendor or personal trees is encouraged but + not required. However, regardless of what security analysis has or + has not been done, all descriptions of security issues must be as + accurate as possible regardless of registration tree. In particular, + a statement that there are "no security issues associated with this + + + +Freed, et. al. Best Current Practice [Page 8] + +RFC 2048 MIME Registration Procedures November 1996 + + + type" must not be confused with "the security issues associates with + this type have not been assessed". + + There is absolutely no requirement that media types registered in any + tree be secure or completely free from risks. Nevertheless, all + known security risks must be identified in the registration of a + media type, again regardless of registration tree. + + The security considerations section of all registrations is subject + to continuing evaluation and modification, and in particular may be + extended by use of the "comments on media types" mechanism described + in subsequent sections. + + Some of the issues that should be looked at in a security analysis of + a media type are: + + (1) Complex media types may include provisions for + directives that institute actions on a recipient's + files or other resources. In many cases provision is + made for originators to specify arbitrary actions in an + unrestricted fashion which may then have devastating + effects. See the registration of the + application/postscript media type in RFC 2046 for + an example of such directives and how to handle them. + + (2) Complex media types may include provisions for + directives that institute actions which, while not + directly harmful to the recipient, may result in + disclosure of information that either facilitates a + subsequent attack or else violates a recipient's + privacy in some way. Again, the registration of the + application/postscript media type illustrates how such + directives can be handled. + + (3) A media type might be targeted for applications that + require some sort of security assurance but not provide + the necessary security mechanisms themselves. For + example, a media type could be defined for storage of + confidential medical information which in turn requires + an external confidentiality service. + +2.2.7. Usage and Implementation Non-requirements + + In the asynchronous mail environment, where information on the + capabilities of the remote mail agent is frequently not available to + the sender, maximum interoperability is attained by restricting the + number of media types used to those "common" formats expected to be + widely implemented. This was asserted in the past as a reason to + + + +Freed, et. al. Best Current Practice [Page 9] + +RFC 2048 MIME Registration Procedures November 1996 + + + limit the number of possible media types and resulted in a + registration process with a significant hurdle and delay for those + registering media types. + + However, the need for "common" media types does not require limiting + the registration of new media types. If a limited set of media types + is recommended for a particular application, that should be asserted + by a separate applicability statement specific for the application + and/or environment. + + As such, universal support and implementation of a media type is NOT + a requirement for registration. If, however, a media type is + explicitly intended for limited use, this should be noted in its + registration. + +2.2.8. Publication Requirements + + Proposals for media types registered in the IETF tree must be + published as RFCs. RFC publication of vendor and personal media type + proposals is encouraged but not required. In all cases IANA will + retain copies of all media type proposals and "publish" them as part + of the media types registration tree itself. + + Other than in the IETF tree, the registration of a data type does not + imply endorsement, approval, or recommendation by IANA or IETF or + even certification that the specification is adequate. To become + Internet Standards, protocol, data objects, or whatever must go + through the IETF standards process. This is too difficult and too + lengthy a process for the convenient registration of media types. + + The IETF tree exists for media types that do require require a + substantive review and approval process with the vendor and personal + trees exist for those that do not. It is expected that applicability + statements for particular applications will be published from time to + time that recommend implementation of, and support for, media types + that have proven particularly useful in those contexts. + + As discussed above, registration of a top-level type requires + standards-track processing and, hence, RFC publication. + +2.2.9. Additional Information + + Various sorts of optional information may be included in the + specification of a media type if it is available: + + (1) Magic number(s) (length, octet values). Magic numbers + are byte sequences that are always present and thus can + be used to identify entities as being of a given media + + + +Freed, et. al. Best Current Practice [Page 10] + +RFC 2048 MIME Registration Procedures November 1996 + + + type. + + (2) File extension(s) commonly used on one or more + platforms to indicate that some file containing a given + type of media. + + (3) Macintosh File Type code(s) (4 octets) used to label + files containing a given type of media. + + Such information is often quite useful to implementors and if + available should be provided. + +2.3. Registration Procedure + + The following procedure has been implemented by the IANA for review + and approval of new media types. This is not a formal standards + process, but rather an administrative procedure intended to allow + community comment and sanity checking without excessive time delay. + For registration in the IETF tree, the normal IETF processes should + be followed, treating posting of an internet-draft and announcement + on the ietf-types list (as described in the next subsection) as a + first step. For registrations in the vendor or personal tree, the + initial review step described below may be omitted and the type + registered directly by submitting the template and an explanation + directly to IANA (at iana@iana.org). However, authors of vendor or + personal media type specifications are encouraged to seek community + review and comment whenever that is feasible. + +2.3.1. Present the Media Type to the Community for Review + + Send a proposed media type registration to the "ietf-types@iana.org" + mailing list for a two week review period. This mailing list has + been established for the purpose of reviewing proposed media and + access types. Proposed media types are not formally registered and + must not be used; the "x-" prefix specified in RFC 2045 can be used + until registration is complete. + + The intent of the public posting is to solicit comments and feedback + on the choice of type/subtype name, the unambiguity of the references + with respect to versions and external profiling information, and a + review of any interoperability or security considerations. The + submitter may submit a revised registration, or withdraw the + registration completely, at any time. + + + + + + + + +Freed, et. al. Best Current Practice [Page 11] + +RFC 2048 MIME Registration Procedures November 1996 + + +2.3.2. IESG Approval + + Media types registered in the IETF tree must be submitted to the IESG + for approval. + +2.3.3. IANA Registration + + Provided that the media type meets the requirements for media types + and has obtained approval that is necessary, the author may submit + the registration request to the IANA, which will register the media + type and make the media type registration available to the community. + +2.4. Comments on Media Type Registrations + + Comments on registered media types may be submitted by members of the + community to IANA. These comments will be passed on to the "owner" + of the media type if possible. Submitters of comments may request + that their comment be attached to the media type registration itself, + and if IANA approves of this the comment will be made accessible in + conjunction with the type registration itself. + +2.5. Location of Registered Media Type List + + Media type registrations will be posted in the anonymous FTP + directory "ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/" + and all registered media types will be listed in the periodically + issued "Assigned Numbers" RFC [currently STD 2, RFC 1700]. The media + type description and other supporting material may also be published + as an Informational RFC by sending it to "rfc-editor@isi.edu" (please + follow the instructions to RFC authors [RFC-1543]). + +2.6. IANA Procedures for Registering Media Types + + The IANA will only register media types in the IETF tree in response + to a communication from the IESG stating that a given registration + has been approved. Vendor and personal types will be registered by + the IANA automatically and without any formal review as long as the + following minimal conditions are met: + + (1) Media types must function as an actual media format. + In particular, character sets and transfer encodings + may not be registered as media types. + + (2) All media types must have properly formed type and + subtype names. All type names must be defined by a + standards-track RFC. All subtype names must be unique, + must conform to the MIME grammar for such names, and + must contain the proper tree prefix. + + + +Freed, et. al. Best Current Practice [Page 12] + +RFC 2048 MIME Registration Procedures November 1996 + + + (3) Types registered in the personal tree must either + provide a format specification or a pointer to one. + + (4) Any security considerations given must not be obviously + bogus. (It is neither possible nor necessary for the + IANA to conduct a comprehensive security review of + media type registrations. Nevertheless, IANA has the + authority to identify obviously incompetent material + and exclude it.) + +2.7. Change Control + + Once a media type has been published by IANA, the author may request + a change to its definition. The descriptions of the different + registration trees above designate the "owners" of each type of + registration. The change request follows the same procedure as the + registration request: + + (1) Publish the revised template on the ietf-types list. + + (2) Leave at least two weeks for comments. + + (3) Publish using IANA after formal review if required. + + Changes should be requested only when there are serious omission or + errors in the published specification. When review is required, a + change request may be denied if it renders entities that were valid + under the previous definition invalid under the new definition. + + The owner of a content type may pass responsibility for the content + type to another person or agency by informing IANA and the ietf-types + list; this can be done without discussion or review. + + The IESG may reassign responsibility for a media type. The most + common case of this will be to enable changes to be made to types + where the author of the registration has died, moved out of contact + or is otherwise unable to make changes that are important to the + community. + + Media type registrations may not be deleted; media types which are no + longer believed appropriate for use can be declared OBSOLETE by a + change to their "intended use" field; such media types will be + clearly marked in the lists published by IANA. + + + + + + + + +Freed, et. al. Best Current Practice [Page 13] + +RFC 2048 MIME Registration Procedures November 1996 + + +2.8. Registration Template + + To: ietf-types@iana.org + Subject: Registration of MIME media type XXX/YYY + + MIME media type name: + + MIME subtype name: + + Required parameters: + + Optional parameters: + + Encoding considerations: + + Security considerations: + + Interoperability considerations: + + Published specification: + + Applications which use this media type: + + Additional information: + + Magic number(s): + File extension(s): + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Intended usage: + + (One of COMMON, LIMITED USE or OBSOLETE) + + Author/Change controller: + + (Any other information that the author deems interesting may be + added below this line.) + +3. External Body Access Types + + RFC 2046 defines the message/external-body media type, whereby a MIME + entity can act as pointer to the actual body data in lieu of + including the data directly in the entity body. Each + message/external-body reference specifies an access type, which + determines the mechanism used to retrieve the actual body data. RFC + 2046 defines an initial set of access types, but allows for the + + + +Freed, et. al. Best Current Practice [Page 14] + +RFC 2048 MIME Registration Procedures November 1996 + + + registration of additional access types to accommodate new retrieval + mechanisms. + +3.1. Registration Requirements + + New access type specifications must conform to a number of + requirements as described below. + +3.1.1. Naming Requirements + + Each access type must have a unique name. This name appears in the + access-type parameter in the message/external-body content-type + header field, and must conform to MIME content type parameter syntax. + +3.1.2. Mechanism Specification Requirements + + All of the protocols, transports, and procedures used by a given + access type must be described, either in the specification of the + access type itself or in some other publicly available specification, + in sufficient detail for the access type to be implemented by any + competent implementor. Use of secret and/or proprietary methods in + access types are expressly prohibited. The restrictions imposed by + RFC 1602 on the standardization of patented algorithms must be + respected as well. + +3.1.3. Publication Requirements + + All access types must be described by an RFC. The RFC may be + informational rather than standards-track, although standard-track + review and approval are encouraged for all access types. + +3.1.4. Security Requirements + + Any known security issues that arise from the use of the access type + must be completely and fully described. It is not required that the + access type be secure or that it be free from risks, but that the + known risks be identified. Publication of a new access type does not + require an exhaustive security review, and the security + considerations section is subject to continuing evaluation. + Additional security considerations should be addressed by publishing + revised versions of the access type specification. + +3.2. Registration Procedure + + Registration of a new access type starts with the construction of a + draft of an RFC. + + + + + +Freed, et. al. Best Current Practice [Page 15] + +RFC 2048 MIME Registration Procedures November 1996 + + +3.2.1. Present the Access Type to the Community + + Send a proposed access type specification to the "ietf- + types@iana.org" mailing list for a two week review period. This + mailing list has been established for the purpose of reviewing + proposed access and media types. Proposed access types are not + formally registered and must not be used. + + The intent of the public posting is to solicit comments and feedback + on the access type specification and a review of any security + considerations. + +3.2.2. Access Type Reviewer + + When the two week period has passed, the access type reviewer, who is + appointed by the IETF Applications Area Director, either forwards the + request to iana@isi.edu, or rejects it because of significant + objections raised on the list. + + Decisions made by the reviewer must be posted to the ietf-types + mailing list within 14 days. Decisions made by the reviewer may be + appealed to the IESG. + +3.2.3. IANA Registration + + Provided that the access type has either passed review or has been + successfully appealed to the IESG, the IANA will register the access + type and make the registration available to the community. The + specification of the access type must also be published as an RFC. + Informational RFCs are published by sending them to "rfc- + editor@isi.edu" (please follow the instructions to RFC authors [RFC- + 1543]). + +3.3. Location of Registered Access Type List + + Access type registrations will be posted in the anonymous FTP + directory "ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/" + and all registered access types will be listed in the periodically + issued "Assigned Numbers" RFC [currently RFC-1700]. + +3.4. IANA Procedures for Registering Access Types + + The identity of the access type reviewer is communicated to the IANA + by the IESG. The IANA then only acts in response to access type + definitions that either are approved by the access type reviewer and + forwarded by the reviewer to the IANA for registration, or in + response to a communication from the IESG that an access type + definition appeal has overturned the access type reviewer's ruling. + + + +Freed, et. al. Best Current Practice [Page 16] + +RFC 2048 MIME Registration Procedures November 1996 + + +4. Transfer Encodings + + Transfer encodings are tranformations applied to MIME media types + after conversion to the media type's canonical form. Transfer + encodings are used for several purposes: + + (1) Many transports, especially message transports, can + only handle data consisting of relatively short lines + of text. There can also be severe restrictions on what + characters can be used in these lines of text -- some + transports are restricted to a small subset of US-ASCII + and others cannot handle certain character sequences. + Transfer encodings are used to transform binary data + into textual form that can survive such transports. + Examples of this sort of transfer encoding include the + base64 and quoted-printable transfer encodings defined + in RFC 2045. + + (2) Image, audio, video, and even application entities are + sometimes quite large. Compression algorithms are often + quite effective in reducing the size of large entities. + Transfer encodings can be used to apply general-purpose + non-lossy compression algorithms to MIME entities. + + (3) Transport encodings can be defined as a means of + representing existing encoding formats in a MIME + context. + + IMPORTANT: The standardization of a large numbers of different + transfer encodings is seen as a significant barrier to widespread + interoperability and is expressely discouraged. Nevertheless, the + following procedure has been defined to provide a means of defining + additional transfer encodings, should standardization actually be + justified. + +4.1. Transfer Encoding Requirements + + Transfer encoding specifications must conform to a number of + requirements as described below. + +4.1.1. Naming Requirements + + Each transfer encoding must have a unique name. This name appears in + the Content-Transfer-Encoding header field and must conform to the + syntax of that field. + + + + + + +Freed, et. al. Best Current Practice [Page 17] + +RFC 2048 MIME Registration Procedures November 1996 + + +4.1.2. Algorithm Specification Requirements + + All of the algorithms used in a transfer encoding (e.g. conversion + to printable form, compression) must be described in their entirety + in the transfer encoding specification. Use of secret and/or + proprietary algorithms in standardized transfer encodings are + expressly prohibited. The restrictions imposed by RFC 1602 on the + standardization of patented algorithms must be respected as well. + +4.1.3. Input Domain Requirements + + All transfer encodings must be applicable to an arbitrary sequence of + octets of any length. Dependence on particular input forms is not + allowed. + + It should be noted that the 7bit and 8bit encodings do not conform to + this requirement. Aside from the undesireability of having + specialized encodings, the intent here is to forbid the addition of + additional encodings along the lines of 7bit and 8bit. + +4.1.4. Output Range Requirements + + There is no requirement that a particular tranfer encoding produce a + particular form of encoded output. However, the output format for + each transfer encoding must be fully and completely documented. In + particular, each specification must clearly state whether the output + format always lies within the confines of 7bit data, 8bit data, or is + simply pure binary data. + +4.1.5. Data Integrity and Generality Requirements + + All transfer encodings must be fully invertible on any platform; it + must be possible for anyone to recover the original data by + performing the corresponding decoding operation. Note that this + requirement effectively excludes all forms of lossy compression as + well as all forms of encryption from use as a transfer encoding. + +4.1.6. New Functionality Requirements + + All transfer encodings must provide some sort of new functionality. + Some degree of functionality overlap with previously defined transfer + encodings is acceptable, but any new transfer encoding must also + offer something no other transfer encoding provides. + + + + + + + + +Freed, et. al. Best Current Practice [Page 18] + +RFC 2048 MIME Registration Procedures November 1996 + + +4.2. Transfer Encoding Definition Procedure + + Definition of a new transfer encoding starts with the construction of + a draft of a standards-track RFC. The RFC must define the transfer + encoding precisely and completely, and must also provide substantial + justification for defining and standardizing a new transfer encoding. + This specification must then be presented to the IESG for + consideration. The IESG can + + (1) reject the specification outright as being + inappropriate for standardization, + + (2) approve the formation of an IETF working group to work + on the specification in accordance with IETF + procedures, or, + + (3) accept the specification as-is and put it directly on + the standards track. + + Transfer encoding specifications on the standards track follow normal + IETF rules for standards track documents. A transfer encoding is + considered to be defined and available for use once it is on the + standards track. + +4.3. IANA Procedures for Transfer Encoding Registration + + There is no need for a special procedure for registering Transfer + Encodings with the IANA. All legitimate transfer encoding + registrations must appear as a standards-track RFC, so it is the + IESG's responsibility to notify the IANA when a new transfer encoding + has been approved. + +4.4. Location of Registered Transfer Encodings List + + Transfer encoding registrations will be posted in the anonymous FTP + directory "ftp://ftp.isi.edu/in-notes/iana/assignments/transfer- + encodings/" and all registered transfer encodings will be listed in + the periodically issued "Assigned Numbers" RFC [currently RFC-1700]. + + + + + + + + + + + + + +Freed, et. al. Best Current Practice [Page 19] + +RFC 2048 MIME Registration Procedures November 1996 + + +5. Authors' Addresses + + For more information, the authors of this document are best + contacted via Internet mail: + + Ned Freed + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + John Klensin + MCI + 2100 Reston Parkway + Reston, VA 22091 + + Phone: +1 703 715-7361 + Fax: +1 703 715-7436 + EMail: klensin@mci.net + + + Jon Postel + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292 + USA + + + Phone: +1 310 822 1511 + Fax: +1 310 823 6714 + EMail: Postel@ISI.EDU + + + + + + + + + + + + + + + +Freed, et. al. Best Current Practice [Page 20] + +RFC 2048 MIME Registration Procedures November 1996 + + +Appendix A -- Grandfathered Media Types + + A number of media types, registered prior to 1996, would, if + registered under the guidelines in this document, be placed into + either the vendor or personal trees. Reregistration of those types + to reflect the appropriate trees is encouraged, but not required. + Ownership and change control principles outlined in this document + apply to those types as if they had been registered in the trees + described above. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freed, et. al. Best Current Practice [Page 21] + diff --git a/Documentation/en/rfc/rfc2049.txt b/Documentation/en/rfc/rfc2049.txt new file mode 100644 index 00000000..99f174b9 --- /dev/null +++ b/Documentation/en/rfc/rfc2049.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2049 Innosoft +Obsoletes: 1521, 1522, 1590 N. Borenstein +Category: Standards Track First Virtual + November 1996 + + + Multipurpose Internet Mail Extensions + (MIME) Part Five: + Conformance Criteria and Examples + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + STD 11, RFC 822, defines a message representation protocol specifying + considerable detail about US-ASCII message headers, and leaves the + message content, or message body, as flat US-ASCII text. This set of + documents, collectively called the Multipurpose Internet Mail + Extensions, or MIME, redefines the format of messages to allow for + + (1) textual message bodies in character sets other than + US-ASCII, + + (2) an extensible set of different formats for non-textual + message bodies, + + (3) multi-part message bodies, and + + (4) textual header information in character sets other than + US-ASCII. + + These documents are based on earlier work documented in RFC 934, STD + 11, and RFC 1049, but extends and revises them. Because RFC 822 said + so little about message bodies, these documents are largely + orthogonal to (rather than a revision of) RFC 822. + + The initial document in this set, RFC 2045, specifies the various + headers used to describe the structure of MIME messages. The second + document defines the general structure of the MIME media typing + system and defines an initial set of media types. The third + document, RFC 2047, describes extensions to RFC 822 to allow non-US- + + + +Freed & Borenstein Standards Track [Page 1] + +RFC 2049 MIME Conformance November 1996 + + + ASCII text data in Internet mail header fields. The fourth document, + RFC 2048, specifies various IANA registration procedures for MIME- + related facilities. This fifth and final document describes MIME + conformance criteria as well as providing some illustrative examples + of MIME message formats, acknowledgements, and the bibliography. + + These documents are revisions of RFCs 1521, 1522, and 1590, which + themselves were revisions of RFCs 1341 and 1342. Appendix B of this + document describes differences and changes from previous versions. + +Table of Contents + + 1. Introduction .......................................... 2 + 2. MIME Conformance ...................................... 2 + 3. Guidelines for Sending Email Data ..................... 6 + 4. Canonical Encoding Model .............................. 9 + 5. Summary ............................................... 12 + 6. Security Considerations ............................... 12 + 7. Authors' Addresses .................................... 12 + 8. Acknowledgements ...................................... 13 + A. A Complex Multipart Example ........................... 15 + B. Changes from RFC 1521, 1522, and 1590 ................. 16 + C. References ............................................ 20 + +1. Introduction + + The first and second documents in this set define MIME header fields + and the initial set of MIME media types. The third document + describes extensions to RFC822 formats to allow for character sets + other than US-ASCII. This document describes what portions of MIME + must be supported by a conformant MIME implementation. It also + describes various pitfalls of contemporary messaging systems as well + as the canonical encoding model MIME is based on. + +2. MIME Conformance + + The mechanisms described in these documents are open-ended. It is + definitely not expected that all implementations will support all + available media types, nor that they will all share the same + extensions. In order to promote interoperability, however, it is + useful to define the concept of "MIME-conformance" to define a + certain level of implementation that allows the useful interworking + of messages with content that differs from US-ASCII text. In this + section, we specify the requirements for such conformance. + + + + + + + +Freed & Borenstein Standards Track [Page 2] + +RFC 2049 MIME Conformance November 1996 + + + A mail user agent that is MIME-conformant MUST: + + (1) Always generate a "MIME-Version: 1.0" header field in + any message it creates. + + (2) Recognize the Content-Transfer-Encoding header field + and decode all received data encoded by either quoted- + printable or base64 implementations. The identity + transformations 7bit, 8bit, and binary must also be + recognized. + + Any non-7bit data that is sent without encoding must be + properly labelled with a content-transfer-encoding of + 8bit or binary, as appropriate. If the underlying + transport does not support 8bit or binary (as SMTP + [RFC-821] does not), the sender is required to both + encode and label data using an appropriate Content- + Transfer-Encoding such as quoted-printable or base64. + + (3) Must treat any unrecognized Content-Transfer-Encoding + as if it had a Content-Type of "application/octet- + stream", regardless of whether or not the actual + Content-Type is recognized. + + (4) Recognize and interpret the Content-Type header field, + and avoid showing users raw data with a Content-Type + field other than text. Implementations must be able + to send at least text/plain messages, with the + character set specified with the charset parameter if + it is not US-ASCII. + + (5) Ignore any content type parameters whose names they do + not recognize. + + (6) Explicitly handle the following media type values, to + at least the following extents: + + Text: + + -- Recognize and display "text" mail with the + character set "US-ASCII." + + -- Recognize other character sets at least to the + extent of being able to inform the user about what + character set the message uses. + + + + + + +Freed & Borenstein Standards Track [Page 3] + +RFC 2049 MIME Conformance November 1996 + + + -- Recognize the "ISO-8859-*" character sets to the + extent of being able to display those characters that + are common to ISO-8859-* and US-ASCII, namely all + characters represented by octet values 1-127. + + -- For unrecognized subtypes in a known character + set, show or offer to show the user the "raw" version + of the data after conversion of the content from + canonical form to local form. + + -- Treat material in an unknown character set as if + it were "application/octet-stream". + + Image, audio, and video: + + -- At a minumum provide facilities to treat any + unrecognized subtypes as if they were + "application/octet-stream". + + Application: + + -- Offer the ability to remove either of the quoted- + printable or base64 encodings defined in this + document if they were used and put the resulting + information in a user file. + + Multipart: + + -- Recognize the mixed subtype. Display all relevant + information on the message level and the body part + header level and then display or offer to display + each of the body parts individually. + + -- Recognize the "alternative" subtype, and avoid + showing the user redundant parts of + multipart/alternative mail. + + -- Recognize the "multipart/digest" subtype, + specifically using "message/rfc822" rather than + "text/plain" as the default media type for body parts + inside "multipart/digest" entities. + + -- Treat any unrecognized subtypes as if they were + "mixed". + + + + + + + +Freed & Borenstein Standards Track [Page 4] + +RFC 2049 MIME Conformance November 1996 + + + Message: + + -- Recognize and display at least the RFC822 message + encapsulation (message/rfc822) in such a way as to + preserve any recursive structure, that is, displaying + or offering to display the encapsulated data in + accordance with its media type. + + -- Treat any unrecognized subtypes as if they were + "application/octet-stream". + + (7) Upon encountering any unrecognized Content-Type field, + an implementation must treat it as if it had a media + type of "application/octet-stream" with no parameter + sub-arguments. How such data are handled is up to an + implementation, but likely options for handling such + unrecognized data include offering the user to write it + into a file (decoded from its mail transport format) or + offering the user to name a program to which the + decoded data should be passed as input. + + (8) Conformant user agents are required, if they provide + non-standard support for non-MIME messages employing + character sets other than US-ASCII, to do so on + received messages only. Conforming user agents must not + send non-MIME messages containing anything other than + US-ASCII text. + + In particular, the use of non-US-ASCII text in mail + messages without a MIME-Version field is strongly + discouraged as it impedes interoperability when sending + messages between regions with different localization + conventions. Conforming user agents MUST include proper + MIME labelling when sending anything other than plain + text in the US-ASCII character set. + + In addition, non-MIME user agents should be upgraded if + at all possible to include appropriate MIME header + information in the messages they send even if nothing + else in MIME is supported. This upgrade will have + little, if any, effect on non-MIME recipients and will + aid MIME in correctly displaying such messages. It + also provides a smooth transition path to eventual + adoption of other MIME capabilities. + + (9) Conforming user agents must ensure that any string of + non-white-space printable US-ASCII characters within a + "*text" or "*ctext" that begins with "=?" and ends with + + + +Freed & Borenstein Standards Track [Page 5] + +RFC 2049 MIME Conformance November 1996 + + + "?=" be a valid encoded-word. ("begins" means: At the + start of the field-body or immediately following + linear-white-space; "ends" means: At the end of the + field-body or immediately preceding linear-white- + space.) In addition, any "word" within a "phrase" that + begins with "=?" and ends with "?=" must be a valid + encoded-word. + + (10) Conforming user agents must be able to distinguish + encoded-words from "text", "ctext", or "word"s, + according to the rules in section 4, anytime they + appear in appropriate places in message headers. It + must support both the "B" and "Q" encodings for any + character set which it supports. The program must be + able to display the unencoded text if the character set + is "US-ASCII". For the ISO-8859-* character sets, the + mail reading program must at least be able to display + the characters which are also in the US-ASCII set. + + A user agent that meets the above conditions is said to be MIME- + conformant. The meaning of this phrase is that it is assumed to be + "safe" to send virtually any kind of properly-marked data to users of + such mail systems, because such systems will at least be able to + treat the data as undifferentiated binary, and will not simply splash + it onto the screen of unsuspecting users. + + There is another sense in which it is always "safe" to send data in a + format that is MIME-conformant, which is that such data will not + break or be broken by any known systems that are conformant with RFC + 821 and RFC 822. User agents that are MIME-conformant have the + additional guarantee that the user will not be shown data that were + never intended to be viewed as text. + +3. Guidelines for Sending Email Data + + Internet email is not a perfect, homogeneous system. Mail may become + corrupted at several stages in its travel to a final destination. + Specifically, email sent throughout the Internet may travel across + many networking technologies. Many networking and mail technologies + do not support the full functionality possible in the SMTP transport + environment. Mail traversing these systems is likely to be modified + in order that it can be transported. + + There exist many widely-deployed non-conformant MTAs in the Internet. + These MTAs, speaking the SMTP protocol, alter messages on the fly to + take advantage of the internal data structure of the hosts they are + implemented on, or are just plain broken. + + + + +Freed & Borenstein Standards Track [Page 6] + +RFC 2049 MIME Conformance November 1996 + + + The following guidelines may be useful to anyone devising a data + format (media type) that is supposed to survive the widest range of + networking technologies and known broken MTAs unscathed. Note that + anything encoded in the base64 encoding will satisfy these rules, but + that some well-known mechanisms, notably the UNIX uuencode facility, + will not. Note also that anything encoded in the Quoted-Printable + encoding will survive most gateways intact, but possibly not some + gateways to systems that use the EBCDIC character set. + + (1) Under some circumstances the encoding used for data may + change as part of normal gateway or user agent + operation. In particular, conversion from base64 to + quoted-printable and vice versa may be necessary. This + may result in the confusion of CRLF sequences with line + breaks in text bodies. As such, the persistence of + CRLF as something other than a line break must not be + relied on. + + (2) Many systems may elect to represent and store text data + using local newline conventions. Local newline + conventions may not match the RFC822 CRLF convention -- + systems are known that use plain CR, plain LF, CRLF, or + counted records. The result is that isolated CR and LF + characters are not well tolerated in general; they may + be lost or converted to delimiters on some systems, and + hence must not be relied on. + + (3) The transmission of NULs (US-ASCII value 0) is + problematic in Internet mail. (This is largely the + result of NULs being used as a termination character by + many of the standard runtime library routines in the C + programming language.) The practice of using NULs as + termination characters is so entrenched now that + messages should not rely on them being preserved. + + (4) TAB (HT) characters may be misinterpreted or may be + automatically converted to variable numbers of spaces. + This is unavoidable in some environments, notably those + not based on the US-ASCII character set. Such + conversion is STRONGLY DISCOURAGED, but it may occur, + and mail formats must not rely on the persistence of + TAB (HT) characters. + + (5) Lines longer than 76 characters may be wrapped or + truncated in some environments. Line wrapping or line + truncation imposed by mail transports is STRONGLY + DISCOURAGED, but unavoidable in some cases. + Applications which require long lines must somehow + + + +Freed & Borenstein Standards Track [Page 7] + +RFC 2049 MIME Conformance November 1996 + + + differentiate between soft and hard line breaks. (A + simple way to do this is to use the quoted-printable + encoding.) + + (6) Trailing "white space" characters (SPACE, TAB (HT)) on + a line may be discarded by some transport agents, while + other transport agents may pad lines with these + characters so that all lines in a mail file are of + equal length. The persistence of trailing white space, + therefore, must not be relied on. + + (7) Many mail domains use variations on the US-ASCII + character set, or use character sets such as EBCDIC + which contain most but not all of the US-ASCII + characters. The correct translation of characters not + in the "invariant" set cannot be depended on across + character converting gateways. For example, this + situation is a problem when sending uuencoded + information across BITNET, an EBCDIC system. Similar + problems can occur without crossing a gateway, since + many Internet hosts use character sets other than US- + ASCII internally. The definition of Printable Strings + in X.400 adds further restrictions in certain special + cases. In particular, the only characters that are + known to be consistent across all gateways are the 73 + characters that correspond to the upper and lower case + letters A-Z and a-z, the 10 digits 0-9, and the + following eleven special characters: + + "'" (US-ASCII decimal value 39) + "(" (US-ASCII decimal value 40) + ")" (US-ASCII decimal value 41) + "+" (US-ASCII decimal value 43) + "," (US-ASCII decimal value 44) + "-" (US-ASCII decimal value 45) + "." (US-ASCII decimal value 46) + "/" (US-ASCII decimal value 47) + ":" (US-ASCII decimal value 58) + "=" (US-ASCII decimal value 61) + "?" (US-ASCII decimal value 63) + + A maximally portable mail representation will confine + itself to relatively short lines of text in which the + only meaningful characters are taken from this set of + 73 characters. The base64 encoding follows this rule. + + (8) Some mail transport agents will corrupt data that + includes certain literal strings. In particular, a + + + +Freed & Borenstein Standards Track [Page 8] + +RFC 2049 MIME Conformance November 1996 + + + period (".") alone on a line is known to be corrupted + by some (incorrect) SMTP implementations, and a line + that starts with the five characters "From " (the fifth + character is a SPACE) are commonly corrupted as well. + A careful composition agent can prevent these + corruptions by encoding the data (e.g., in the quoted- + printable encoding using "=46rom " in place of "From " + at the start of a line, and "=2E" in place of "." alone + on a line). + + Please note that the above list is NOT a list of recommended + practices for MTAs. RFC 821 MTAs are prohibited from altering the + character of white space or wrapping long lines. These BAD and + invalid practices are known to occur on established networks, and + implementations should be robust in dealing with the bad effects they + can cause. + +4. Canonical Encoding Model + + There was some confusion, in earlier versions of these documents, + regarding the model for when email data was to be converted to + canonical form and encoded, and in particular how this process would + affect the treatment of CRLFs, given that the representation of + newlines varies greatly from system to system. For this reason, a + canonical model for encoding is presented below. + + The process of composing a MIME entity can be modeled as being done + in a number of steps. Note that these steps are roughly similar to + those steps used in PEM [RFC-1421] and are performed for each + "innermost level" body: + + (1) Creation of local form. + + The body to be transmitted is created in the system's + native format. The native character set is used and, + where appropriate, local end of line conventions are + used as well. The body may be a UNIX-style text file, + or a Sun raster image, or a VMS indexed file, or audio + data in a system-dependent format stored only in + memory, or anything else that corresponds to the local + model for the representation of some form of + information. Fundamentally, the data is created in the + "native" form that corresponds to the type specified by + the media type. + + + + + + + +Freed & Borenstein Standards Track [Page 9] + +RFC 2049 MIME Conformance November 1996 + + + (2) Conversion to canonical form. + + The entire body, including "out-of-band" information + such as record lengths and possibly file attribute + information, is converted to a universal canonical + form. The specific media type of the body as well as + its associated attributes dictate the nature of the + canonical form that is used. Conversion to the proper + canonical form may involve character set conversion, + transformation of audio data, compression, or various + other operations specific to the various media types. + If character set conversion is involved, however, care + must be taken to understand the semantics of the media + type, which may have strong implications for any + character set conversion, e.g. with regard to + syntactically meaningful characters in a text subtype + other than "plain". + + For example, in the case of text/plain data, the text + must be converted to a supported character set and + lines must be delimited with CRLF delimiters in + accordance with RFC 822. Note that the restriction on + line lengths implied by RFC 822 is eliminated if the + next step employs either quoted-printable or base64 + encoding. + + (3) Apply transfer encoding. + + A Content-Transfer-Encoding appropriate for this body + is applied. Note that there is no fixed relationship + between the media type and the transfer encoding. In + particular, it may be appropriate to base the choice of + base64 or quoted-printable on character frequency + counts which are specific to a given instance of a + body. + + (4) Insertion into entity. + + The encoded body is inserted into a MIME entity with + appropriate headers. The entity is then inserted into + the body of a higher-level entity (message or + multipart) as needed. + + Conversion from entity form to local form is accomplished by + reversing these steps. Note that reversal of these steps may produce + differing results since there is no guarantee that the original and + final local forms are the same. + + + + +Freed & Borenstein Standards Track [Page 10] + +RFC 2049 MIME Conformance November 1996 + + + It is vital to note that these steps are only a model; they are + specifically NOT a blueprint for how an actual system would be built. + In particular, the model fails to account for two common designs: + + (1) In many cases the conversion to a canonical form prior + to encoding will be subsumed into the encoder itself, + which understands local formats directly. For example, + the local newline convention for text bodies might be + carried through to the encoder itself along with + knowledge of what that format is. + + (2) The output of the encoders may have to pass through one + or more additional steps prior to being transmitted as + a message. As such, the output of the encoder may not + be conformant with the formats specified by RFC 822. + In particular, once again it may be appropriate for the + converter's output to be expressed using local newline + conventions rather than using the standard RFC 822 CRLF + delimiters. + + Other implementation variations are conceivable as well. The vital + aspect of this discussion is that, in spite of any optimizations, + collapsings of required steps, or insertion of additional processing, + the resulting messages must be consistent with those produced by the + model described here. For example, a message with the following + header fields: + + Content-type: text/foo; charset=bar + Content-Transfer-Encoding: base64 + + must be first represented in the text/foo form, then (if necessary) + represented in the "bar" character set, and finally transformed via + the base64 algorithm into a mail-safe form. + + NOTE: Some confusion has been caused by systems that represent + messages in a format which uses local newline conventions which + differ from the RFC822 CRLF convention. It is important to note that + these formats are not canonical RFC822/MIME. These formats are + instead *encodings* of RFC822, where CRLF sequences in the canonical + representation of the message are encoded as the local newline + convention. Note that formats which encode CRLF sequences as, for + example, LF are not capable of representing MIME messages containing + binary data which contains LF octets not part of CRLF line separation + sequences. + + + + + + + +Freed & Borenstein Standards Track [Page 11] + +RFC 2049 MIME Conformance November 1996 + + +5. Summary + + This document defines what is meant by MIME Conformance. It also + details various problems known to exist in the Internet email system + and how to use MIME to overcome them. Finally, it describes MIME's + canonical encoding model. + +6. Security Considerations + + Security issues are discussed in the second document in this set, RFC + 2046. + +7. Authors' Addresses + + For more information, the authors of this document are best contacted + via Internet mail: + + Ned Freed + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + Nathaniel S. Borenstein + First Virtual Holdings + 25 Washington Avenue + Morristown, NJ 07960 + USA + + Phone: +1 201 540 8967 + Fax: +1 201 993 3032 + EMail: nsb@nsb.fv.com + + MIME is a result of the work of the Internet Engineering Task Force + Working Group on RFC 822 Extensions. The chairman of that group, + Greg Vaudreuil, may be reached at: + + Gregory M. Vaudreuil + Octel Network Services + 17080 Dallas Parkway + Dallas, TX 75248-1905 + USA + + EMail: Greg.Vaudreuil@Octel.Com + + + +Freed & Borenstein Standards Track [Page 12] + +RFC 2049 MIME Conformance November 1996 + + +8. Acknowledgements + + This document is the result of the collective effort of a large + number of people, at several IETF meetings, on the IETF-SMTP and + IETF-822 mailing lists, and elsewhere. Although any enumeration + seems doomed to suffer from egregious omissions, the following are + among the many contributors to this effort: + + Harald Tveit Alvestrand Marc Andreessen + Randall Atkinson Bob Braden + Philippe Brandon Brian Capouch + Kevin Carosso Uhhyung Choi + Peter Clitherow Dave Collier-Brown + Cristian Constantinof John Coonrod + Mark Crispin Dave Crocker + Stephen Crocker Terry Crowley + Walt Daniels Jim Davis + Frank Dawson Axel Deininger + Hitoshi Doi Kevin Donnelly + Steve Dorner Keith Edwards + Chris Eich Dana S. Emery + Johnny Eriksson Craig Everhart + Patrik Faltstrom Erik E. Fair + Roger Fajman Alain Fontaine + Martin Forssen James M. Galvin + Stephen Gildea Philip Gladstone + Thomas Gordon Keld Simonsen + Terry Gray Phill Gross + James Hamilton David Herron + Mark Horton Bruce Howard + Bill Janssen Olle Jarnefors + Risto Kankkunen Phil Karn + Alan Katz Tim Kehres + Neil Katin Steve Kille + Kyuho Kim Anders Klemets + John Klensin Valdis Kletniek + Jim Knowles Stev Knowles + Bob Kummerfeld Pekka Kytolaakso + Stellan Lagerstrom Vincent Lau + Timo Lehtinen Donald Lindsay + Warner Losh Carlyn Lowery + Laurence Lundblade Charles Lynn + John R. MacMillan Larry Masinter + Rick McGowan Michael J. McInerny + Leo Mclaughlin Goli Montaser-Kohsari + Tom Moore John Gardiner Myers + Erik Naggum Mark Needleman + Chris Newman John Noerenberg + + + +Freed & Borenstein Standards Track [Page 13] + +RFC 2049 MIME Conformance November 1996 + + + Mats Ohrman Julian Onions + Michael Patton David J. Pepper + Erik van der Poel Blake C. Ramsdell + Christer Romson Luc Rooijakkers + Marshall T. Rose Jonathan Rosenberg + Guido van Rossum Jan Rynning + Harri Salminen Michael Sanderson + Yutaka Sato Markku Savela + Richard Alan Schafer Masahiro Sekiguchi + Mark Sherman Bob Smart + Peter Speck Henry Spencer + Einar Stefferud Michael Stein + Klaus Steinberger Peter Svanberg + James Thompson Steve Uhler + Stuart Vance Peter Vanderbilt + Greg Vaudreuil Ed Vielmetti + Larry W. Virden Ryan Waldron + Rhys Weatherly Jay Weber + Dave Wecker Wally Wedel + Sven-Ove Westberg Brian Wideen + John Wobus Glenn Wright + Rayan Zachariassen David Zimmerman + + The authors apologize for any omissions from this list, which are + certainly unintentional. + + + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 14] + +RFC 2049 MIME Conformance November 1996 + + +Appendix A -- A Complex Multipart Example + + What follows is the outline of a complex multipart message. This + message contains five parts that are to be displayed serially: two + introductory plain text objects, an embedded multipart message, a + text/enriched object, and a closing encapsulated text message in a + non-ASCII character set. The embedded multipart message itself + contains two objects to be displayed in parallel, a picture and an + audio fragment. + + MIME-Version: 1.0 + From: Nathaniel Borenstein <nsb@nsb.fv.com> + To: Ned Freed <ned@innosoft.com> + Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) + Subject: A multipart example + Content-Type: multipart/mixed; + boundary=unique-boundary-1 + + This is the preamble area of a multipart message. + Mail readers that understand multipart format + should ignore this preamble. + + If you are reading this text, you might want to + consider changing to a mail reader that understands + how to properly display multipart messages. + + --unique-boundary-1 + + ... Some text appears here ... + + [Note that the blank between the boundary and the start + of the text in this part means no header fields were + given and this is text in the US-ASCII character set. + It could have been done with explicit typing as in the + next part.] + + --unique-boundary-1 + Content-type: text/plain; charset=US-ASCII + + This could have been part of the previous part, but + illustrates explicit versus implicit typing of body + parts. + + --unique-boundary-1 + Content-Type: multipart/parallel; boundary=unique-boundary-2 + + --unique-boundary-2 + Content-Type: audio/basic + + + +Freed & Borenstein Standards Track [Page 15] + +RFC 2049 MIME Conformance November 1996 + + + Content-Transfer-Encoding: base64 + + ... base64-encoded 8000 Hz single-channel + mu-law-format audio data goes here ... + + --unique-boundary-2 + Content-Type: image/jpeg + Content-Transfer-Encoding: base64 + + ... base64-encoded image data goes here ... + + --unique-boundary-2-- + + --unique-boundary-1 + Content-type: text/enriched + + This is <bold><italic>enriched.</italic></bold> + <smaller>as defined in RFC 1896</smaller> + + Isn't it + <bigger><bigger>cool?</bigger></bigger> + + --unique-boundary-1 + Content-Type: message/rfc822 + + From: (mailbox in US-ASCII) + To: (address in US-ASCII) + Subject: (subject in US-ASCII) + Content-Type: Text/plain; charset=ISO-8859-1 + Content-Transfer-Encoding: Quoted-printable + + ... Additional text in ISO-8859-1 goes here ... + + --unique-boundary-1-- + +Appendix B -- Changes from RFC 1521, 1522, and 1590 + + These documents are a revision of RFC 1521, 1522, and 1590. For the + convenience of those familiar with the earlier documents, the changes + from those documents are summarized in this appendix. For further + history, note that Appendix H in RFC 1521 specified how that document + differed from its predecessor, RFC 1341. + + (1) This document has been completely reformatted and split + into multiple documents. This was done to improve the + quality of the plain text version of this document, + which is required to be the reference copy. + + + + +Freed & Borenstein Standards Track [Page 16] + +RFC 2049 MIME Conformance November 1996 + + + (2) BNF describing the overall structure of MIME object + headers has been added. This is a documentation change + only -- the underlying syntax has not changed in any + way. + + (3) The specific BNF for the seven media types in MIME has + been removed. This BNF was incorrect, incomplete, amd + inconsistent with the type-indendependent BNF. And + since the type-independent BNF already fully specifies + the syntax of the various MIME headers, the type- + specific BNF was, in the final analysis, completely + unnecessary and caused more problems than it solved. + + (4) The more specific "US-ASCII" character set name has + replaced the use of the informal term ASCII in many + parts of these documents. + + (5) The informal concept of a primary subtype has been + removed. + + (6) The term "object" was being used inconsistently. The + definition of this term has been clarified, along with + the related terms "body", "body part", and "entity", + and usage has been corrected where appropriate. + + (7) The BNF for the multipart media type has been + rearranged to make it clear that the CRLF preceeding + the boundary marker is actually part of the marker + itself rather than the preceeding body part. + + (8) The prose and BNF describing the multipart media type + have been changed to make it clear that the body parts + within a multipart object MUST NOT contain any lines + beginning with the boundary parameter string. + + (9) In the rules on reassembling "message/partial" MIME + entities, "Subject" is added to the list of headers to + take from the inner message, and the example is + modified to clarify this point. + + (10) "Message/partial" fragmenters are restricted to + splitting MIME objects only at line boundaries. + + (11) In the discussion of the application/postscript type, + an additional paragraph has been added warning about + possible interoperability problems caused by embedding + of binary data inside a PostScript MIME entity. + + + + +Freed & Borenstein Standards Track [Page 17] + +RFC 2049 MIME Conformance November 1996 + + + (12) Added a clarifying note to the basic syntax rules for + the Content-Type header field to make it clear that the + following two forms: + + Content-type: text/plain; charset=us-ascii (comment) + + Content-type: text/plain; charset="us-ascii" + + are completely equivalent. + + (13) The following sentence has been removed from the + discussion of the MIME-Version header: "However, + conformant software is encouraged to check the version + number and at least warn the user if an unrecognized + MIME-version is encountered." + + (14) A typo was fixed that said "application/external-body" + instead of "message/external-body". + + (15) The definition of a character set has been reorganized + to make the requirements clearer. + + (16) The definition of the "image/gif" media type has been + moved to a separate document. This change was made + because of potential conflicts with IETF rules + governing the standardization of patented technology. + + (17) The definitions of "7bit" and "8bit" have been + tightened so that use of bare CR, LF can only be used + as end-of-line sequences. The document also no longer + requires that NUL characters be preserved, which brings + MIME into alignment with real-world implementations. + + (18) The definition of canonical text in MIME has been + tightened so that line breaks must be represented by a + CRLF sequence. CR and LF characters are not allowed + outside of this usage. The definition of quoted- + printable encoding has been altered accordingly. + + (19) The definition of the quoted-printable encoding now + includes a number of suggestions for how quoted- + printable encoders might best handle improperly encoded + material. + + (20) Prose was added to clarify the use of the "7bit", + "8bit", and "binary" transfer-encodings on multipart or + message entities encapsulating "8bit" or "binary" data. + + + + +Freed & Borenstein Standards Track [Page 18] + +RFC 2049 MIME Conformance November 1996 + + + (21) In the section on MIME Conformance, "multipart/digest" + support was added to the list of requirements for + minimal MIME conformance. Also, the requirement for + "message/rfc822" support were strengthened to clarify + the importance of recognizing recursive structure. + + (22) The various restrictions on subtypes of "message" are + now specified entirely on a subtype by subtype basis. + + (23) The definition of "message/rfc822" was changed to + indicate that at least one of the "From", "Subject", or + "Date" headers must be present. + + (24) The required handling of unrecognized subtypes as + "application/octet-stream" has been made more explicit + in both the type definitions sections and the + conformance guidelines. + + (25) Examples using text/richtext were changed to + text/enriched. + + (26) The BNF definition of subtype has been changed to make + it clear that either an IANA registered subtype or a + nonstandard "X-" subtype must be used in a Content-Type + header field. + + (27) MIME media types that are simply registered for use and + those that are standardized by the IETF are now + distinguished in the MIME BNF. + + (28) All of the various MIME registration procedures have + been extensively revised. IANA registration procedures + for character sets have been moved to a separate + document that is no included in this set of documents. + + (29) The use of escape and shift mechanisms in the US-ASCII + and ISO-8859-X character sets these documents define + have been clarified: Such mechanisms should never be + used in conjunction with these character sets and their + effect if they are used is undefined. + + (30) The definition of the AFS access-type for + message/external-body has been removed. + + (31) The handling of the combination of + multipart/alternative and message/external-body is now + specifically addressed. + + + + +Freed & Borenstein Standards Track [Page 19] + +RFC 2049 MIME Conformance November 1996 + + + (32) Security issues specific to message/external-body are + now discussed in some detail. + +Appendix C -- References + + [ATK] + Borenstein, Nathaniel S., Multimedia Applications + Development with the Andrew Toolkit, Prentice-Hall, 1990. + + [ISO-2022] + International Standard -- Information Processing -- + Character Code Structure and Extension Techniques, + ISO/IEC 2022:1994, 4th ed. + + [ISO-8859] + International Standard -- Information Processing -- 8-bit + Single-Byte Coded Graphic Character Sets + - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed. + - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed. + - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed. + - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed. + - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st + ed. + - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed. + - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed. + - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed. + - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st + ed. + International Standard -- Information Technology -- 8-bit + Single-Byte Coded Graphic Character Sets + - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, + 1st ed. + + [ISO-646] + International Standard -- Information Technology -- ISO + 7-bit Coded Character Set for Information Interchange, + ISO 646:1991, 3rd ed.. + + [JPEG] + JPEG Draft Standard ISO 10918-1 CD. + + [MPEG] + Video Coding Draft Standard ISO 11172 CD, ISO + IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May, + 1991. + + + + + + +Freed & Borenstein Standards Track [Page 20] + +RFC 2049 MIME Conformance November 1996 + + + [PCM] + CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code + Modulation (PCM) of Voice Frequencies", Geneva, 1972. + + [POSTSCRIPT] + Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, 1985. + + [POSTSCRIPT2] + Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, Second Ed., 1990. + + [RFC-783] + Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, + MIT, June 1981. + + [RFC-821] + Postel, J.B., "Simple Mail Transfer Protocol", STD 10, + RFC 821, USC/Information Sciences Institute, August 1982. + + [RFC-822] + Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822, UDEL, August 1982. + + [RFC-934] + Rose, M. and E. Stefferud, "Proposed Standard for Message + Encapsulation", RFC 934, Delaware and NMA, January 1985. + + [RFC-959] + Postel, J. and J. Reynolds, "File Transfer Protocol", STD + 9, RFC 959, USC/Information Sciences Institute, October + 1985. + + [RFC-1049] + Sirbu, M., "Content-Type Header Field for Internet + Messages", RFC 1049, CMU, March 1988. + + [RFC-1154] + Robinson, D., and R. Ullmann, "Encoding Header Field for + Internet Messages", RFC 1154, Prime Computer, Inc., April + 1990. + + [RFC-1341] + Borenstein, N., and N. Freed, "MIME (Multipurpose + Internet Mail Extensions): Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", RFC + 1341, Bellcore, Innosoft, June 1992. + + + + +Freed & Borenstein Standards Track [Page 21] + +RFC 2049 MIME Conformance November 1996 + + + [RFC-1342] + Moore, K., "Representation of Non-Ascii Text in Internet + Message Headers", RFC 1342, University of Tennessee, June + 1992. + + [RFC-1344] + Borenstein, N., "Implications of MIME for Internet Mail + Gateways", RFC 1344, Bellcore, June 1992. + + [RFC-1345] + Simonsen, K., "Character Mnemonics & Character Sets", RFC + 1345, Rationel Almen Planlaegning, June 1992. + + [RFC-1421] + Linn, J., "Privacy Enhancement for Internet Electronic + Mail: Part I -- Message Encryption and Authentication + Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, + February 1993. + + [RFC-1422] + Kent, S., "Privacy Enhancement for Internet Electronic + Mail: Part II -- Certificate-Based Key Management", RFC + 1422, IAB IRTF PSRG, IETF PEM WG, February 1993. + + [RFC-1423] + Balenson, D., "Privacy Enhancement for Internet + Electronic Mail: Part III -- Algorithms, Modes, and + Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993. + + [RFC-1424] + Kaliski, B., "Privacy Enhancement for Internet Electronic + Mail: Part IV -- Key Certification and Related + Services", IAB IRTF PSRG, IETF PEM WG, February 1993. + + [RFC-1521] + Borenstein, N., and Freed, N., "MIME (Multipurpose + Internet Mail Extensions): Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", RFC + 1521, Bellcore, Innosoft, September, 1993. + + [RFC-1522] + Moore, K., "Representation of Non-ASCII Text in Internet + Message Headers", RFC 1522, University of Tennessee, + September 1993. + + + + + + + +Freed & Borenstein Standards Track [Page 22] + +RFC 2049 MIME Conformance November 1996 + + + [RFC-1524] + Borenstein, N., "A User Agent Configuration Mechanism for + Multimedia Mail Format Information", RFC 1524, Bellcore, + September 1993. + + [RFC-1543] + Postel, J., "Instructions to RFC Authors", RFC 1543, + USC/Information Sciences Institute, October 1993. + + [RFC-1556] + Nussbacher, H., "Handling of Bi-directional Texts in + MIME", RFC 1556, Israeli Inter-University Computer + Center, December 1993. + + [RFC-1590] + Postel, J., "Media Type Registration Procedure", RFC + 1590, USC/Information Sciences Institute, March 1994. + + [RFC-1602] + Internet Architecture Board, Internet Engineering + Steering Group, Huitema, C., Gross, P., "The Internet + Standards Process -- Revision 2", March 1994. + + [RFC-1652] + Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., + Stefferud, E., and Crocker, D., "SMTP Service Extension + for 8bit-MIME transport", RFC 1652, United Nations + University, Innosoft, Dover Beach Consulting, Inc., + Network Management Associates, Inc., The Branch Office, + March 1994. + + [RFC-1700] + Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, + RFC 1700, USC/Information Sciences Institute, October + 1994. + + [RFC-1741] + Faltstrom, P., Crocker, D., and Fair, E., "MIME Content + Type for BinHex Encoded Files", December 1994. + + [RFC-1896] + Resnick, P., and A. Walker, "The text/enriched MIME + Content-type", RFC 1896, February, 1996. + + + + + + + + +Freed & Borenstein Standards Track [Page 23] + +RFC 2049 MIME Conformance November 1996 + + + [RFC-2045] + Freed, N., and and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, Innosoft, First Virtual Holdings, + November 1996. + + [RFC-2046] + Freed, N., and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + Innosoft, First Virtual Holdings, November 1996. + + [RFC-2047] + Moore, K., "Multipurpose Internet Mail Extensions (MIME) + Part Three: Representation of Non-ASCII Text in Internet + Message Headers", RFC 2047, University of + Tennessee, November 1996. + + [RFC-2048] + Freed, N., Klensin, J., and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: MIME + Registration Procedures", RFC 2048, Innosoft, MCI, + ISI, November 1996. + + [RFC-2049] + Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049 (this document), Innosoft, First + Virtual Holdings, November 1996. + + [US-ASCII] + Coded Character Set -- 7-Bit American Standard Code for + Information Interchange, ANSI X3.4-1986. + + [X400] + Schicker, Pietro, "Message Handling Systems, X.400", + Message Handling Systems and Distributed Applications, E. + Stefferud, O-j. Jacobsen, and P. Schicker, eds., North- + Holland, 1989, pp. 3-41. + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 24] + diff --git a/Documentation/en/rfc/rfc2065.txt b/Documentation/en/rfc/rfc2065.txt new file mode 100644 index 00000000..b0351447 --- /dev/null +++ b/Documentation/en/rfc/rfc2065.txt @@ -0,0 +1,2299 @@ + + + + + + +Network Working Group D. Eastlake, 3rd +Request for Comments: 2065 CyberCash +Updates: 1034, 1035 C. Kaufman +Category: Standards Track Iris + January 1997 + + + Domain Name System Security Extensions + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Domain Name System (DNS) has become a critical operational part + of the Internet infrastructure yet it has no strong security + mechanisms to assure data integrity or authentication. Extensions to + the DNS are described that provide these services to security aware + resolvers or applications through the use of cryptographic digital + signatures. These digital signatures are included in secured zones + as resource records. Security can still be provided even through + non-security aware DNS servers in many cases. + + The extensions also provide for the storage of authenticated public + keys in the DNS. This storage of keys can support general public key + distribution service as well as DNS security. The stored keys enable + security aware resolvers to learn the authenticating key of zones in + addition to those for which they are initially configured. Keys + associated with DNS names can be retrieved to support other + protocols. Provision is made for a variety of key types and + algorithms. + + In addition, the security extensions provide for the optional + authentication of DNS protocol transactions. + + + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 1] + +RFC 2065 DNS Security Extensions January 1997 + + +Acknowledgments + + The significant contributions of the following persons (in alphabetic + order) to this document are gratefully acknowledged: + + Harald T. Alvestrand + Madelyn Badger + Scott Bradner + Matt Crawford + James M. Galvin + Olafur Gudmundsson + Edie Gunter + Sandy Murphy + Masataka Ohta + Michael A. Patton + Jeffrey I. Schiller + +Table of Contents + + 1. Overview of Contents....................................3 + 2. Overview of the DNS Extensions.........................4 + 2.1 Services Not Provided..................................4 + 2.2 Key Distribution.......................................5 + 2.3 Data Origin Authentication and Integrity...............5 + 2.3.1 The SIG Resource Record..............................6 + 2.3.2 Authenticating Name and Type Non-existence...........7 + 2.3.3 Special Considerations With Time-to-Live.............7 + 2.3.4 Special Considerations at Delegation Points..........7 + 2.3.5 Special Considerations with CNAME RRs................8 + 2.3.6 Signers Other Than The Zone..........................8 + 2.4 DNS Transaction and Request Authentication.............8 + 3. The KEY Resource Record.................................9 + 3.1 KEY RDATA format......................................10 + 3.2 Object Types, DNS Names, and Keys.....................10 + 3.3 The KEY RR Flag Field.................................11 + 3.4 The Protocol Octet....................................13 + 3.5 The KEY Algorithm Number and the MD5/RSA Algorithm....13 + 3.6 Interaction of Flags, Algorithm, and Protocol Bytes...14 + 3.7 KEY RRs in the Construction of Responses..............15 + 3.8 File Representation of KEY RRs........................16 + 4. The SIG Resource Record................................16 + 4.1 SIG RDATA Format......................................17 + 4.1.1 Signature Data......................................19 + 4.1.2 MD5/RSA Algorithm Signature Calculation.............20 + 4.1.3 Zone Transfer (AXFR) SIG............................21 + 4.1.4 Transaction and Request SIGs........................22 + 4.2 SIG RRs in the Construction of Responses..............23 + 4.3 Processing Responses and SIG RRs......................24 + + + +Eastlake & Kaufman Standards Track [Page 2] + +RFC 2065 DNS Security Extensions January 1997 + + + 4.4 Signature Expiration, TTLs, and Validity..............24 + 4.5 File Representation of SIG RRs........................25 + 5. Non-existent Names and Types...........................26 + 5.1 The NXT Resource Record...............................26 + 5.2 NXT RDATA Format......................................27 + 5.3 Example...............................................28 + 5.4 Interaction of NXT RRs and Wildcard RRs...............28 + 5.5 Blocking NXT Pseudo-Zone Transfers....................29 + 5.6 Special Considerations at Delegation Points...........29 + 6. The AD and CD Bits and How to Resolve Securely.........30 + 6.1 The AD and CD Header Bits.............................30 + 6.2 Boot File Format......................................32 + 6.3 Chaining Through Zones................................32 + 6.4 Secure Time...........................................33 + 7. Operational Considerations.............................33 + 7.1 Key Size Considerations...............................34 + 7.2 Key Storage...........................................34 + 7.3 Key Generation........................................35 + 7.4 Key Lifetimes.........................................35 + 7.5 Signature Lifetime....................................36 + 7.6 Root..................................................36 + 8. Conformance............................................36 + 8.1 Server Conformance....................................36 + 8.2 Resolver Conformance..................................37 + 9. Security Considerations................................37 + References................................................38 + Authors' Addresses........................................39 + Appendix: Base 64 Encoding................................40 + +1. Overview of Contents + + This document describes extensions of the Domain Name System (DNS) + protocol to support DNS security and public key distribution. It + assumes that the reader is familiar with the Domain Name System, + particularly as described in RFCs 1033, 1034, and 1035. + + Section 2 provides an overview of the extensions and the key + distribution, data origin authentication, and transaction and request + security they provide. + + Section 3 discusses the KEY resource record, its structure, use in + DNS responses, and file representation. These resource records + represent the public keys of entities named in the DNS and are used + for key distribution. + + + + + + + +Eastlake & Kaufman Standards Track [Page 3] + +RFC 2065 DNS Security Extensions January 1997 + + + Section 4 discusses the SIG digital signature resource record, its + structure, use in DNS responses, and file representation. These + resource records are used to authenticate other resource records in + the DNS and optionally to authenticate DNS transactions and requests. + + Section 5 discusses the NXT resource record and its use in DNS + responses. The NXT RR permits authenticated denial in the DNS of the + existence of a name or of a particular type for an existing name. + + Section 6 discusses how a resolver can be configured with a starting + key or keys and proceed to securely resolve DNS requests. + Interactions between resolvers and servers are discussed for all + combinations of security aware and security non-aware. Two + additional query header bits are defined for signaling between + resolvers and servers. + + Section 7 reviews a variety of operational considerations including + key generation, lifetime, and storage. + + Section 8 defines levels of conformance for resolvers and servers. + + Section 9 provides a few paragraphs on overall security + considerations. + + An Appendix is provided that gives details of base 64 encoding which + is used in the file representation of some RR's defined in this + document. + +2. Overview of the DNS Extensions + + The Domain Name System (DNS) protocol security extensions provide + three distinct services: key distribution as described in Section 2.2 + below, data origin authentication as described in Section 2.3 below, + and transaction and request authentication, described in Section 2.4 + below. + + Special considerations related to "time to live", CNAMEs, and + delegation points are also discussed in Section 2.3. + +2.1 Services Not Provided + + It is part of the design philosophy of the DNS that the data in it is + public and that the DNS gives the same answers to all inquirers. + + Following this philosophy, no attempt has been made to include any + sort of access control lists or other means to differentiate + inquirers. + + + + +Eastlake & Kaufman Standards Track [Page 4] + +RFC 2065 DNS Security Extensions January 1997 + + + In addition, no effort has been made to provide for any + confidentiality for queries or responses. (This service may be + available via IPSEC [RFC 1825].) + +2.2 Key Distribution + + Resource records (RRs) are defined to associate keys with DNS names. + This permits the DNS to be used as a public key distribution + mechanism in support of the DNS data origin authentication and other + security services. + + The syntax of a KEY resource record (RR) is described in Section 3. + It includes an algorithm identifier, the actual public key + parameters, and a variety of flags including those indicating the + type of entity the key is associated with and/or asserting that there + is no key associated with that entity. + + Under conditions described in Section 3.7, security aware DNS servers + will automatically attempt to return KEY resources as additional + information, along with those resource records actually requested, to + minimize the number of queries needed. + +2.3 Data Origin Authentication and Integrity + + Authentication is provided by associating with resource records in + the DNS cryptographically generated digital signatures. Commonly, + there will be a single private key that signs for an entire zone. If + a security aware resolver reliably learns the public key of the zone, + it can verify, for signed data read from that zone, that it was + properly authorized and is reasonably current. The expected + implementation is for the zone private key to be kept off-line and + used to re-sign all of the records in the zone periodically. + + This data origin authentication key belongs to the zone and not to + the servers that store copies of the data. That means compromise of + a server or even all servers for a zone will not necessarily affect + the degree of assurance that a resolver has that it can determine + whether data is genuine. + + A resolver can learn the public key of a zone either by reading it + from DNS or by having it staticly configured. To reliably learn the + public key by reading it from DNS, the key itself must be signed. + Thus, to provide a reasonable degree of security, the resolver must + be configured with at least the public key of one zone that it can + use to authenticate signatures. From there, it can securely read the + public keys of other zones, if the intervening zones in the DNS tree + are secure and their signed keys accessible. (It is in principle + more secure to have the resolver manually configured with the public + + + +Eastlake & Kaufman Standards Track [Page 5] + +RFC 2065 DNS Security Extensions January 1997 + + + keys of multiple zones, since then the compromise of a single zone + would not permit the faking of information from other zones. It is + also more administratively cumbersome, however, particularly when + public keys change.) + + Adding data origin authentication and integrity requires no change to + the "on-the-wire" DNS protocol beyond the addition of the signature + resource type and, as a practical matter, the key resource type + needed for key distribution. This service can be supported by + existing resolver and server implementations so long as they can + support the additional resource types (see Section 8). The one + exception is that CNAME referrals from a secure zone can not be + authenticated if they are from non-security aware servers (see + Section 2.3.5). + + If signatures are always separately retrieved and verified when + retrieving the information they authenticate, there will be more + trips to the server and performance will suffer. To avoid this, + security aware servers mitigate that degradation by always attempting + to send the signature(s) needed. + +2.3.1 The SIG Resource Record + + The syntax of a SIG resource record (signature) is described in + Section 4. It includes the type of the RR(s) being signed, the name + of the signer, the time at which the signature was created, the time + it expires (when it is no longer to be believed), its original time + to live (which may be longer than its current time to live but cannot + be shorter), the cryptographic algorithm in use, and the actual + signature. + + Every name in a secured zone will have associated with it at least + one SIG resource record for each resource type under that name except + for glue RRs and delgation point NS RRs. A security aware server + supporting the performance enhanced version of the DNS protocol + security extensions will attempt to return, with RRs retrieved, the + corresponding SIGs. If a server does not support the protocol, the + resolver must retrieve all the SIG records for a name and select the + one or ones that sign the resource record(s) that resolver is + interested in. + + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 6] + +RFC 2065 DNS Security Extensions January 1997 + + +2.3.2 Authenticating Name and Type Non-existence + + The above security mechanism provides only a way to sign existing RRs + in a zone. "Data origin" authentication is not obviously provided + for the non-existence of a domain name in a zone or the non-existence + of a type for an existing name. This gap is filled by the NXT RR + which authenticatably asserts a range of non-existent names in a zone + and the non-existence of types for the name just before that range. + + Section 5 below covers the NXT RR. + +2.3.3 Special Considerations With Time-to-Live + + A digital signature will fail to verify if any change has occurred to + the data between the time it was originally signed and the time the + signature is verified. This conflicts with our desire to have the + time-to-live field tick down when resource records are cached. + + This could be avoided by leaving the time-to-live out of the digital + signature, but that would allow unscrupulous servers to set + arbitrarily long time to live values undetected. Instead, we include + the "original" time-to-live in the signature and communicate that + data in addition to the current time-to-live. Unscrupulous servers + under this scheme can manipulate the time to live but a security + aware resolver will bound the TTL value it uses at the original + signed value. Separately, signatures include a time signed and an + expiration time. A resolver that knows the absolute time can + determine securely whether a signature has expired. It is not + possible to rely solely on the signature expiration as a substitute + for the TTL, however, since the TTL is primarily a database + consistency mechanism and, in any case, non-security aware servers + that depend on TTL must still be supported. + +2.3.4 Special Considerations at Delegation Points + + DNS security would like to view each zone as a unit of data + completely under the control of the zone owner and signed by the + zone's key. But the operational DNS views the leaf nodes in a zone, + which are also the apex nodes of a subzone (i.e., delegation points), + as "really" belonging to the subzone. These nodes occur in two + master files and may have RRs signed by both the upper and lower + zone's keys. A retrieval could get a mixture of these RRs and SIGs, + especially since one server could be serving both the zone above and + below a delegation point. + + In general, there must be a zone KEY RR for the subzone in the + superzone and the copy signed in the superzone is controlling. For + all but one other RR type that should appearing in both the superzone + + + +Eastlake & Kaufman Standards Track [Page 7] + +RFC 2065 DNS Security Extensions January 1997 + + + and subzone, the data from the subzone is more authoritative. To + avoid conflicts, only the KEY RR in the superzone should be signed + and the NS and any A (glue) RRs should only be signed in the subzone. + The SOA and any other RRs that have the zone name as owner should + appear only in the subzone and thus are signed there. The NXT RR type + is an exceptional case that will always appear differently and + authoritatively in both the superzone and subzone, if both are + secure, as described in Section 5. + +2.3.5 Special Considerations with CNAME RRs + + There is a significant problem when security related RRs with the + same owner name as a CNAME RR are retrieved from a non-security-aware + server. In particular, an initial retrieval for the CNAME or any + other type will not retrieve any associated signature, key, or NXT + RR. For types other than CNAME, it will retrieve that type at the + target name of the CNAME (or chain of CNAMEs) and will return the + CNAME as additional information. In particular, a specific retrieval + for type SIG will not get the SIG, if any, at the original CNAME + domain name but rather a SIG at the target name. + + In general, security aware servers MUST be used to securely CNAME in + DNS. Security aware servers must (1) allow KEY, SIG, and NXT RRs + along with CNAME RRs, (2) suppress CNAME processing on retrieval of + these types as well as on retrieval of the type CNAME, and (3) + automatically return SIG RRs authenticating the CNAME or CNAMEs + encountered in resolving a query. This is a change from the previous + DNS standard which prohibited any other RR type at a node where a + CNAME RR was present. + +2.3.6 Signers Other Than The Zone + + There are two cases where a SIG resource record is signed by other + than the zone private key. One is for support of dynamic update + where an entity is permitted to authenticate/update its own records. + The public key of the entity must be present in the DNS and be + appropriately signed but the other RR(s) may be signed with the + entity's key. The other is for support of transaction and request + authentication as described in Section 2.4 immediately below. + +2.4 DNS Transaction and Request Authentication + + The data origin authentication service described above protects + retrieved resource records but provides no protection for DNS + requests or for message headers. + + + + + + +Eastlake & Kaufman Standards Track [Page 8] + +RFC 2065 DNS Security Extensions January 1997 + + + If header bits are falsely set by a server, there is little that can + be done. However, it is possible to add transaction authentication. + Such authentication means that a resolver can be sure it is at least + getting messages from the server it thinks it queried, that the + response is from the query it sent, and that these messages have not + been diddled in transit. This is accomplished by optionally adding a + special SIG resource record at the end of the reply which digitally + signs the concatenation of the server's response and the resolver's + query. + + Requests can also be authenticated by including a special SIG RR at + the end of the request. Authenticating requests serves no function + in the current DNS and requests with a non-empty additional + information section are ignored by almost all current DNS servers. + However, this syntax for signing requests is defined in connection + with authenticating future secure dynamic update requests or the + like. + + The private keys used in transaction and request security belongs to + the host composing the request or reply message, not to the zone + involved. The corresponding public key is normally stored in and + retrieved from the DNS. + + Because requests and replies are highly variable, message + authentication SIGs can not be pre-calculated. Thus it will be + necessary to keep the private key on-line, for example in software or + in a directly connected piece of hardware. + +3. The KEY Resource Record + + The KEY resource record (RR) is used to document a key that is + associated with a Domain Name System (DNS) name. It will be a public + key as only public keys are stored in the DNS. This can be the + public key of a zone, a host or other end entity, or a user. A KEY + RR is, like any other RR, authenticated by a SIG RR. Security aware + DNS implementations MUST be designed to handle at least two + simultaneously valid keys of the same type associated with a name. + + The type number for the KEY RR is 25. + + + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 9] + +RFC 2065 DNS Security Extensions January 1997 + + +3.1 KEY RDATA format + + The RDATA for a KEY RR consists of flags, a protocol octet, the + algorithm number, and the public key itself. The format is as + follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags | protocol | algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + The meaning of the KEY RR owner name, flags, and protocol octet are + described in Sections 3.2, 3.3 and 3.4 below respectively. The flags + and algorithm must be examined before any data following the + algorithm octet as they control the format and even whether there is + any following data. The algorithm and public key fields are + described in Section 3.5. The format of the public key is algorithm + dependent. + +3.2 Object Types, DNS Names, and Keys + + The public key in a KEY RR belongs to the object named in the owner + name. + + This DNS name may refer to up to three different categories of + things. For example, dee.cybercash.com could be (1) a zone, (2) a + host or other end entity , and (3) the mapping into a DNS name of the + user or account dee@cybercash.com. Thus, there are flags, as + described below, in the KEY RR to indicate with which of these roles + the owner name and public key are associated. Note that an + appropriate zone KEY RR MUST occur at the apex node of a secure zone + and at every leaf node which is a delegation point (and thus the same + owner name as the apex of a subzone) within a secure zone. + + Although the same name can be used for up to all three of these + categories, such overloading of a name is discouraged. It is also + possible to use the same key for different things with the same name + or even different names, but this is strongly discouraged. In + particular, the use of a zone key as a non-zone key will usually + require that the corresponding private key be kept on line and + thereby become more vulnerable. + + + + + +Eastlake & Kaufman Standards Track [Page 10] + +RFC 2065 DNS Security Extensions January 1997 + + + In addition to the name type bits, there are additional flag bits + including the "type" field, "experimental" bit, "signatory" field, + etc., as described below. + +3.3 The KEY RR Flag Field + + In the "flags" field: + + Bit 0 and 1 are the key "type" field. Bit 0 a one indicates + that use of the key is prohibited for authentication. Bit 1 a one + indicates that use of the key is prohibited for confidentiality. If + this field is zero, then use of the key for authentication and/or + confidentiality is permitted. Note that DNS security makes use of + keys for authentication only. Confidentiality use flagging is + provided for use of keys in other protocols. Implementations not + intended to support key distribution for confidentiality MAY require + that the confidentiality use prohibited bit be on for keys they + serve. If both bits of this field are one, the "no key" value, there + is no key information and the RR stops after the algorithm octet. By + the use of this "no key" value, a signed KEY RR can authenticatably + assert that, for example, a zone is not secured. + + Bit 2 is the "experimental" bit. It is ignored if the type + field indicates "no key" and the following description assumes that + type field to be non-zero. Keys may be associated with zones, + entities, or users for experimental, trial, or optional use, in which + case this bit will be one. If this bit is a zero, it means that the + use or availability of security based on the key is "mandatory". + Thus, if this bit is off for a zone key, the zone should be assumed + secured by SIG RRs and any responses indicating the zone is not + secured should be considered bogus. If this bit is a one for a host + or end entity, it might sometimes operate in a secure mode and at + other times operate without security. The experimental bit, like all + other aspects of the KEY RR, is only effective if the KEY RR is + appropriately signed by a SIG RR. The experimental bit must be zero + for safe secure operation and should only be a one for a minimal + transition period. + + Bits 3-4 are reserved and must be zero. + + Bit 5 on indicates that this is a key associated with a "user" + or "account" at an end entity, usually a host. The coding of the + owner name is that used for the responsible individual mailbox in the + SOA and RP RRs: The owner name is the user name as the name of a node + under the entity name. For example, "j.random_user" on + host.subdomain.domain could have a public key associated through a + KEY RR with name j\.random_user.host.subdomain.domain and the user + bit a one. It could be used in an security protocol where + + + +Eastlake & Kaufman Standards Track [Page 11] + +RFC 2065 DNS Security Extensions January 1997 + + + authentication of a user was desired. This key might be useful in IP + or other security for a user level service such a telnet, ftp, + rlogin, etc. + + Bit 6 on indicates that this is a key associated with the non- + zone "entity" whose name is the RR owner name. This will commonly be + a host but could, in some parts of the DNS tree, be some other type + of entity such as a telephone number [RFC 1530]. This is the public + key used in connection with the optional DNS transaction + authentication service if the owner name is a DNS server host. It + could also be used in an IP-security protocol where authentication of + at the host, rather than user, level was desired, such as routing, + NTP, etc. + + Bit 7 is the "zone" bit and indicates that this is a zone key + for the zone whose name is the KEY RR owner name. This is the public + key used for DNS data origin authentication. + + Bit 8 is reserved to be the IPSEC [RFC 1825] bit and indicates + that this key is valid for use in conjunction with that security + standard. This key could be used in connection with secured + communication on behalf of an end entity or user whose name is the + owner name of the KEY RR if the entity or user bits are on. The + presence of a KEY resource with the IPSEC and entity bits on and + experimental and no-key bits off is an assertion that the host speaks + IPSEC. + + Bit 9 is reserved to be the "email" bit and indicate that this + key is valid for use in conjunction with MIME security multiparts. + This key could be used in connection with secured communication on + behalf of an end entity or user whose name is the owner name of the + KEY RR if the entity or user bits are on. + + Bits 10-11 are reserved and must be zero. + + Bits 12-15 are the "signatory" field. If non-zero, they + indicate that the key can validly sign RRs or updates of the same + name. If the owner name is a wildcard, then RRs or updates with any + name which is in the wildcard's scope can be signed. Fifteen + different non-zero values are possible for this field and any + differences in their meaning are reserved for definition in + connection with DNS dynamic update or other new DNS commands. Zone + keys always have authority to sign any RRs in the zone regardless of + the value of this field. The signatory field, like all other aspects + of the KEY RR, is only effective if the KEY RR is appropriately + signed by a SIG RR. + + + + + +Eastlake & Kaufman Standards Track [Page 12] + +RFC 2065 DNS Security Extensions January 1997 + + +3.4 The Protocol Octet + + It is anticipated that some keys stored in DNS will be used in + conjunction with Internet protocols other than DNS (keys with zone + bit or signatory field non-zero) and IPSEC/email (keys with IPSEC + and/or email bit set). The protocol octet is provided to indicate + that a key is valid for such use and, for end entity keys or the host + part of user keys, that the secure version of that protocol is + implemented on that entity or host. + + Values between 1 and 191 decimal inclusive are available for + assignment by IANA for such protocols. The 63 values between 192 and + 254 inclusive will not be assigned to a specific protocol and are + available for experimental use under bilateral agreement. Value 0 + indicates, for a particular key, that it is not valid for any + particular additional protocol beyond those indicated in the flag + field. And value 255 indicates that the key is valid for all assigned + protocols (those in the 1 to 191 range). + + It is intended that new uses of DNS stored keys would initially be + implemented, and operational experience gained, using the + experimental range of the protocol octet. If demand for widespread + deployment for the indefinite future warrants, a value in the + assigned range would then be designated for the protocol. Finally, + (1) should the protocol become so widespread in conjunction with + other protocols and with which it shares key values that duplicate + RRs are a serious burden and (2) should the protocol provide + substantial facilities not available in any protocol for which a + flags field bit has been allocated, then one of the remaining flag + field bits may be allocated to the protocol. When such a bit has been + allocated, a key can be simultaneously indicated as valid for that + protocol and the entity or host can be simultaneously flagged as + implementing the secure version of that protocol, along with other + protocols for which flag field bits have been assigned. + +3.5 The KEY Algorithm Number and the MD5/RSA Algorithm + + This octet is the key algorithm parallel to the same field for the + SIG resource. The MD5/RSA algorithm described in this document is + number 1. Numbers 2 through 252 are available for assignment should + sufficient reason arise. However, the designation of a new algorithm + could have a major impact on interoperability and requires an IETF + standards action. Number 254 is reserved for private use and will + never be assigned a specific algorithm. For number 254, the public + key area shown in the packet diagram above will actually begin with a + length byte followed by an Object Identifier (OID) of that length. + The OID indicates the private algorithm in use and the remainder of + the area is whatever is required by that algorithm. Number 253 is + + + +Eastlake & Kaufman Standards Track [Page 13] + +RFC 2065 DNS Security Extensions January 1997 + + + reserved as the "expiration date algorithm" for use where the + expiration date or other labeling fields of SIGs are desired without + any actual security. It is anticipated that this algorithm will only + be used in connection with some modes of DNS dynamic update. For + number 253, the public key area is null. Values 0 and 255 are + reserved. + + If the type field does not have the "no key" value and the algorithm + field is 1, indicating the MD5/RSA algorithm, the public key field is + structured as follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | pub exp length| public key exponent / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + +- modulus / + | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ + + To promote interoperability, the exponent and modulus are each + limited to 2552 bits in length. The public key exponent is a + variable length unsigned integer. Its length in octets is + represented as one octet if it is in the range of 1 to 255 and by a + zero octet followed by a two octet unsigned length if it is longer + than 255 bytes. The public key modulus field is a multiprecision + unsigned integer. The length of the modulus can be determined from + the RDLENGTH and the preceding RDATA fields including the exponent. + Leading zero bytes are prohibited in the exponent and modulus. + +3.6 Interaction of Flags, Algorithm, and Protocol Bytes + + Various combinations of the no-key type value, algorithm byte, + protocol byte, and any protocol indicating flags (such as the + reserved IPSEC flag) are possible. (Note that the zone flag bit + being on or the signatory field being non-zero is effectively a DNS + protocol flag on.) The meaning of these combinations is indicated + below: + + + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 14] + +RFC 2065 DNS Security Extensions January 1997 + + + NK = no key type value + AL = algorithm byte + PR = protocols indicated by protocol byte or protocol flags + + x represents any valid non-zero value(s). + + AL PR NK Meaning + 0 0 0 Illegal, claims key but has bad algorithm field. + 0 0 1 Specifies total lack of security for owner. + 0 x 0 Illegal, claims key but has bad algorithm field. + 0 x 1 Specified protocols insecure, others may be secure. + x 0 0 Useless. Gives key but no protocols to use it. + x 0 1 Useless. Denies key but for no protocols. + x x 0 Specifies key for protocols and asserts that + those protocols are implemented with security. + x x 1 Algorithm not understood for protocol. + + (remember, in reference to the above table, that a protocol + byte of 255 means all protocols with protocol byte values + assigned) + +3.7 KEY RRs in the Construction of Responses + + An explicit request for KEY RRs does not cause any special additional + information processing except, of course, for the corresponding SIG + RR from a security aware server. + + Security aware DNS servers MUST include KEY RRs as additional + information in responses where appropriate including the following: + + (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone + served by these name servers MUST be included as additional + information if space is avilable. There will always be at least one + such KEY RR in a secure zone, even if it has the no-key type value to + indicate that the subzone is insecure. If not all additional + information will fit, the KEY RR(s) have higher priority than type A + or AAAA glue RRs. If such a KEY RR does not fit on a retrieval, the + retrieval must be considered truncated. + + (2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) MUST + be included if space is available. On inclusion of A or AAAA RRs as + additional information, their KEY RRs will also be included but with + lower priority than the relevant A or AAAA RRs. + + + + + + + + +Eastlake & Kaufman Standards Track [Page 15] + +RFC 2065 DNS Security Extensions January 1997 + + +3.8 File Representation of KEY RRs + + KEY RRs may appear as lines in a zone data master file. + + The flag field, protocol, and algorithm number octets are then + represented as unsigned integers. Note that if the type field has + the "no key" value or the algorithm specified is 253, nothing appears + after the algorithm octet. + + The remaining public key portion is represented in base 64 (see + Appendix) and may be divided up into any number of white space + separated substrings, down to single base 64 digits, which are + concatenated to obtain the full signature. These substrings can span + lines using the standard parenthesis. + + Note that the public key may have internal sub-fields but these do + not appear in the master file representation. For example, with + algorithm 1 there is a public exponent size, then a public exponent, + and then a modulus. With algorithm 254, there will be an OID size, + an OID, and algorithm dependent information. But in both cases only a + single logical base 64 string will appear in the master file. + +4. The SIG Resource Record + + The SIG or "signature" resource record (RR) is the fundamental way + that data is authenticated in the secure Domain Name System (DNS). As + such it is the heart of the security provided. + + The SIG RR unforgably authenticates other RRs of a particular type, + class, and name and binds them to a time interval and the signer's + domain name. This is done using cryptographic techniques and the + signer's private key. The signer is frequently the owner of the zone + from which the RR originated. + + + + + + + + + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 16] + +RFC 2065 DNS Security Extensions January 1997 + + +4.1 SIG RDATA Format + + The RDATA portion of a SIG RR is as shown below. The integrity of + the RDATA information is protected by the signature field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | type covered | algorithm | labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | signature expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | time signed | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | key footprint | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + +- signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value of the SIG RR type is 24. + + The "type covered" is the type of the other RRs covered by this SIG. + + The algorithm number is an octet specifying the digital signature + algorithm used parallel to the algorithm octet for the KEY RR. The + MD5/RSA algorithm described in this document is number 1. Numbers 2 + through 252 are available for assignment should sufficient reason + arise to allocate them. However, the designation of a new algorithm + could have a major impact on the interoperability of the global DNS + system and requires an IETF standards action. Number 254 is reserved + for private use and will not be assigned a specific algorithm. For + number 254, the "signature" area shown above will actually begin with + a length byte followed by an Object Identifier (OID) of that length. + The OID indicates the private algorithm in use and the remainder of + the area is whatever is required by that algorithm. Number 253, + known as the "expiration date algorithm", is used when the expiration + date or other non-signature fields of the SIG are desired without any + actual security. It is anticipated that this algorithm will only be + used in connection with some modes of DNS dynamic update. For number + 253, the signature field will be null. Values 0 and 255 are + reserved. + + + + +Eastlake & Kaufman Standards Track [Page 17] + +RFC 2065 DNS Security Extensions January 1997 + + + The "labels" octet is an unsigned count of how many labels there are + in the original SIG RR owner name not counting the null label for + root and not counting any initial "*" for a wildcard. If a secured + retrieval is the result of wild card substitution, it is necessary + for the resolver to use the original form of the name in verifying + the digital signature. This field helps optimize the determination + of the original form thus reducing the effort in authenticating + signed data. + + If, on retrieval, the RR appears to have a longer name than indicated + by "labels", the resolver can tell it is the result of wildcard + substitution. If the RR owner name appears to be shorter than the + labels count, the SIG RR must be considered corrupt and ignored. The + maximum number of labels allowed in the current DNS is 127 but the + entire octet is reserved and would be required should DNS names ever + be expanded to 255 labels. The following table gives some examples. + The value of "labels" is at the top, the retrieved owner name on the + left, and the table entry is the name to use in signature + verification except that "bad" means the RR is corrupt. + + labels= | 0 | 1 | 2 | 3 | 4 | + --------+-----+------+--------+----------+----------+ + .| . | bad | bad | bad | bad | + d.| *. | d. | bad | bad | bad | + c.d.| *. | *.d. | c.d. | bad | bad | + b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | + a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | + + The "original TTL" field is included in the RDATA portion to avoid + (1) authentication problems that caching servers would otherwise + cause by decrementing the real TTL field and (2) security problems + that unscrupulous servers could otherwise cause by manipulating the + real TTL field. This original TTL is protected by the signature + while the current TTL field is not. + + NOTE: The "original TTL" must be restored into the covered RRs when + the signature is verified. This implies that all RRs for a + particular type, name, and class must have the same TTL to start + with. + + The SIG is valid until the "signature expiration" time which is an + unsigned number of seconds since the start of 1 January 1970, GMT, + ignoring leap seconds. (See also Section 4.4.) SIG RRs should not + have a date signed significantly in the future. To prevent + misordering of network requests to update a zone dynamically, + monotonically increasing "time signed" dates may be necessary. + + + + + +Eastlake & Kaufman Standards Track [Page 18] + +RFC 2065 DNS Security Extensions January 1997 + + + The "time signed" field is an unsigned number of seconds since the + start of 1 January 1970, GMT, ignoring leap seconds. + + A SIG RR with an expiration date before the time signed must be + considered corrupt and ignored. + + The "key footprint" is a 16 bit quantity that is used to help + efficiently select between multiple keys which may be applicable and + as a quick check that a public key about to be used for the + computationally expensive effort to check the signature is possibly + valid. Its exact meaning is algorithm dependent. For the MD5/RSA + algorithm, it is the next to the bottom two octets of the public key + modulus needed to decode the signature field. That is to say, the + most significant 16 of the lest significant 24 bits of the modulus in + network order. + + The "signer's name" field is the domain name of the signer generating + the SIG RR. This is the owner of the public KEY RR that can be used + to verify the signature. It is frequently the zone which contained + the RR(s) being authenticated. The signer's name may be compressed + with standard DNS name compression when being transmitted over the + network. + + The structure of the "signature" field is described below. + +4.1.1 Signature Data + + Except for algorithm number 253 where it is null, the actual + signature portion of the SIG RR binds the other RDATA fields to all + of the "type covered" RRs with that owner name and class. These + covered RRs are thereby authenticated. To accomplish this, a data + sequence is constructed as follows: + + data = RDATA | RR(s)... + + where "|" is concatenation, RDATA is all the RDATA fields in the SIG + RR itself before and not including the signature, and RR(s) are all + the RR(s) of the type covered with the same owner name and class as + the SIG RR in canonical form and order. How this data sequence is + processed into the signature is algorithm dependent. + + For purposes of DNS security, the canonical form for an RR is the RR + with domain names (1) fully expanded (no name compression via + pointers), (2) all domain name letters set to lower case, and (3) the + original TTL substituted for the current TTL. + + + + + + +Eastlake & Kaufman Standards Track [Page 19] + +RFC 2065 DNS Security Extensions January 1997 + + + For purposes of DNS security, the canonical order for RRs is to sort + them in ascending order by name, considering labels as a left + justified unsigned octet sequence in network (transmission) order + where a missing octet sorts before a zero octet. (See also ordering + discussion in Section 5.1.) Within any particular name they are + similarly sorted by type and then RDATA as a left justified unsigned + octet sequence. EXCEPT that the type SIG RR(s) covering any + particular type appear immediately after the other RRs of that type. + (This special consideration for SIG RR(s) in ordering really only + applies to calculating the AXFR SIG RR as explained in section 4.1.3 + below.) Thus if at name a.b there are two A RRs and one KEY RR, + their order with SIGs for concatenating the "data" to be signed would + be as follows: + + a.b. A .... + a.b. A .... + a.b. SIG A ... + a.b. KEY ... + a.b. SIG KEY ... + + SIGs covering type ANY should not be included in a zone. + +4.1.2 MD5/RSA Algorithm Signature Calculation + + For the MD5/RSA algorithm, the signature is as follows + + hash = MD5 ( data ) + + signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) + + where MD5 is the message digest algorithm documented in RFC 1321, "|" + is concatenation, "e" is the private key exponent of the signer, and + "n" is the modulus of the signer's public key. 01, FF, and 00 are + fixed octets of the corresponding hexadecimal value. "prefix" is the + ASN.1 BER MD5 algorithm designator prefix specified in PKCS1, that + is, + hex 3020300c06082a864886f70d020505000410 [NETSEC]. + This prefix is included to make it easier to use RSAREF or similar + packages. The FF octet is repeated the maximum number of times such + that the value of the quantity being exponentiated is one octet + shorter than the value of n. + + (The above specifications are identical to the corresponding part of + Public Key Cryptographic Standard #1 [PKCS1].) + + + + + + + +Eastlake & Kaufman Standards Track [Page 20] + +RFC 2065 DNS Security Extensions January 1997 + + + The size of n, including most and least significant bits (which will + be 1) SHALL be not less than 512 bits and not more than 2552 bits. n + and e SHOULD be chosen such that the public exponent is small. + + Leading zeros bytes are not permitted in the MD5/RSA algorithm + signature. + + A public exponent of 3 minimizes the effort needed to decode a + signature. Use of 3 as the public exponent may be weak for + confidentiality uses since, if the same data can be collected + encrypted under three different keys with an exponent of 3 then, + using the Chinese Remainder Theorem, the original plain text can be + easily recovered. This weakness is not significant for DNS because + we seek only authentication, not confidentiality. + +4.1.3 Zone Transfer (AXFR) SIG + + The above SIG mechanisms assure the authentication of all zone signed + RRs of a particular name, class and type. However, to efficiently + assure the completeness and security of zone transfers, a SIG RR + owned by the zone name must be created with a type covered of AXFR + that covers all zone signed RRs in the zone and their zone SIGs but + not the SIG AXFR itself. The RRs are ordered and concatenated for + hashing as described in Section 4.1.1. (See also ordering discussion + in Section 5.1.) + + The AXFR SIG must be calculated last of all zone key signed SIGs in + the zone. In effect, when signing the zone, you order, as described + above, all RRs to be signed by the zone, and all associated glue RRs + and delegation point NS RRs. You can then make one pass inserting + all the zone SIGs. As you proceed you hash RRs to be signed into + both an RRset hash and the zone hash. When the name or type changes + you calculate and insert the RRset zone SIG, clear the RRset hash, + and hash that SIG into the zone hash (note that glue RRs and + delegation point NSs are not zone signed but zone apex NSs are). + When you have finished processing all the starting RRs as described + above, you can then use the cumulative zone hash RR to calculate and + insert an AXFR SIG covering the zone. Of course any computational + technique producing the same results as above is permitted. + + The AXFR SIG really belongs to the zone as a whole, not to the zone + name. Although it should be correct for the zone name, the labels + field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only + retrieved as part of a zone transfer. After validation of the AXFR + SIG, the zone MAY be considered valid without verification of the + internal zone signed SIGs in the zone; however, any RRs authenticated + by SIGs signed by entity keys or the like MUST still be validated. + The AXFR SIG SHOULD be transmitted first in a zone transfer so the + + + +Eastlake & Kaufman Standards Track [Page 21] + +RFC 2065 DNS Security Extensions January 1997 + + + receiver can tell immediately that they may be able to avoid + verifying other zone signed SIGs. + + RRs which are authenticated by a dynamic update key and not by the + zone key (see Section 3.2) are not included in the AXFR SIG. They may + originate in the network and might not, in general, be migrated to + the recommended off line zone signing procedure (see Section 7.2). + Thus, such RRs are not directly signed by the zone, are not included + in the AXFR SIG, and are protected against omission from zone + transfers only to the extent that the server and communication can be + trusted. + +4.1.4 Transaction and Request SIGs + + A response message from a security aware server may optionally + contain a special SIG as the last item in the additional information + section to authenticate the transaction. + + This SIG has a "type covered" field of zero, which is not a valid RR + type. It is calculated by using a "data" (see Section 4.1.2) of the + entire preceding DNS reply message, including DNS header but not the + IP header, concatenated with the entire DNS query message that + produced this response, including the query's DNS header but not its + IP header. That is + + data = full response (less final transaction SIG) | full query + + Verification of the transaction SIG (which is signed by the server + host key, not the zone key) by the requesting resolver shows that the + query and response were not tampered with in transit, that the + response corresponds to the intended query, and that the response + comes from the queried server. + + A DNS request may be optionally signed by including one or more SIGs + at the end of the query. Such SIGs are identified by having a "type + covered" field of zero. They sign the preceding DNS request message + including DNS header but not including the IP header or at the + begining or any preceding request SIGs at the end. Such request SIGs + are included in the "data" used to form any optional response + transaction SIG. + + WARNING: Request SIGs are unnecessary for currently defined queries + and will cause almost all existing DNS servers to completely ignore a + query. However, such SIGs may be needed to authenticate future DNS + secure dynamic update or other requests. + + + + + + +Eastlake & Kaufman Standards Track [Page 22] + +RFC 2065 DNS Security Extensions January 1997 + + +4.2 SIG RRs in the Construction of Responses + + Security aware DNS servers MUST, for every authoritative RR the query + will return, attempt to send the available SIG RRs which authenticate + the requested RR. The following rules apply to the inclusion of SIG + RRs in responses: + + 1. when an RR set is placed in a response, its SIG RR has a higher + priority for inclusion than other additional RRs that may need to + be included. If space does not permit its inclusion, the response + MUST be considered truncated except as provided in 2 below. + + 2. when a SIG RR is present in the zone for an additional information + section RR, the response MUST NOT be considered truncated merely + because space does not permit the inclusion of its SIG RR. + + 3. SIGs to authenticate non-authoritative data (glue records and NS + RRs for subzones) are unnecessary and MUST NOT be sent. (Note + that KEYs for subzones are controlling in a superzone so the + superzone's signature on the KEY MUST be included (unless the KEY + was additional information and the SIG did not fit).) + + 4. If a SIG covers any RR that would be in the answer section of the + response, its automatic inclusion MUST be the answer section. If + it covers an RR that would appear in the authority section, its + automatic inclusion MUST be in the authority section. If it + covers an RR that would appear in the additional information + section it MUST appear in the additional information section. + This is a change in the existing standard which contemplates only + NS and SOA RRs in the authority section. + + 5. Optionally, DNS transactions may be authenticated by a SIG RR at + the end of the response in the additional information section + (Section 4.1.4). Such SIG RRs are signed by the DNS server + originating the response. Although the signer field MUST be the + name of the originating server host, the owner name, class, TTL, + and original TTL, are meaningless. The class and TTL fields + SHOULD be zero. To conserve space, the owner name SHOULD be root + (a single zero octet). If transaction authentication is desired, + that SIG RR must be considered higher priority for inclusion than + any other RR in the response. + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 23] + +RFC 2065 DNS Security Extensions January 1997 + + +4.3 Processing Responses and SIG RRs + + The following rules apply to the processing of SIG RRs included in a + response: + + 1. a security aware resolver that receives a response from what it + believes to be a security aware server via a secure communication + with the AD bit (see Section 6.1) set, MAY choose to accept the + RRs as received without verifying the zone SIG RRs. + + 2. in other cases, a security aware resolver SHOULD verify the SIG + RRs for the RRs of interest. This may involve initiating + additional queries for SIG or KEY RRs, especially in the case of + getting a response from an insecure server. (As explained in 4.2 + above, it will not be possible to secure CNAMEs being served up by + non-secure resolvers.) + + NOTE: Implementers might expect the above SHOULD to be a MUST. + However, local policy or the calling application may not require + the security services. + + 3. If SIG RRs are received in response to a user query explicitly + specifying the SIG type, no special processing is required. + + If the message does not pass reasonable checks or the SIG does not + check against the signed RRs, the SIG RR is invalid and should be + ignored. If all of the SIG RR(s) purporting to authenticate a set of + RRs are invalid, then the set of RR(s) is not authenticated. + + If the SIG RR is the last RR in a response in the additional + information section and has a type covered of zero, it is a + transaction signature of the response and the query that produced the + response. It MAY be optionally checked and the message rejected if + the checks fail. But even if the checks succeed, such a transaction + authentication SIG does NOT authenticate any RRs in the message. + Only a proper SIG RR signed by the zone or a key tracing its + authority to the zone or to static resolver configuration can + authenticate RRs. If a resolver does not implement transaction + and/or request SIGs, it MUST ignore them without error. + + If all reasonable checks indicate that the SIG RR is valid then RRs + verified by it should be considered authenticated. + +4.4 Signature Expiration, TTLs, and Validity + + Security aware servers must not consider SIG RRs to authenticate + anything after their expiration time and not consider any RR to be + authenticated after its signatures have expired. Within that + + + +Eastlake & Kaufman Standards Track [Page 24] + +RFC 2065 DNS Security Extensions January 1997 + + + constraint, servers should continue to follow DNS TTL aging. Thus + authoritative servers should continue to follow the zone refresh and + expire parameters and a non-authoritative server should count down + the TTL and discard RRs when the TTL is zero. In addition, when RRs + are transmitted in a query response, the TTL should be trimmed so + that current time plus the TTL does not extend beyond the signature + expiration time. Thus, in general, the TTL on an transmitted RR + would be + + min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) + +4.5 File Representation of SIG RRs + + A SIG RR can be represented as a single logical line in a zone data + file [RFC1033] but there are some special considerations as described + below. (It does not make sense to include a transaction or request + authenticating SIG RR in a file as they are a transient + authentication that covers data including an ephemeral transaction + number and so must be calculated in real time.) + + There is no particular problem with the signer, covered type, and + times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY + is the year, the first MM is the month number (01-12), DD is the day + of the month (01-31), HH is the hour in 24 hours notation (00-23), + the second MM is the minute (00-59), and SS is the second (00-59). + + The original TTL and algorithm fields appear as unsigned integers. + + If the original TTL, which applies to the type signed, is the same as + the TTL of the SIG RR itself, it may be omitted. The date field + which follows it is larger than the maximum possible TTL so there is + no ambiguity. + + The "labels" field does not appear in the file representation as it + can be calculated from the owner name. + + The key footprint appears as an unsigned decimal number. + + However, the signature itself can be very long. It is the last data + field and is represented in base 64 (see Appendix) and may be divided + up into any number of white space separated substrings, down to + single base 64 digits, which are concatenated to obtain the full + signature. These substrings can be split between lines using the + standard parenthesis. + + + + + + + +Eastlake & Kaufman Standards Track [Page 25] + +RFC 2065 DNS Security Extensions January 1997 + + +5. Non-existent Names and Types + + The SIG RR mechanism described in Section 4 above provides strong + authentication of RRs that exist in a zone. But is it not clear + above how to authenticatably deny the existence of a name in a zone + or a type for an existent name. + + The nonexistence of a name in a zone is indicated by the NXT ("next") + RR for a name interval containing the nonexistent name. A NXT RR and + its SIG are returned in the authority section, along with the error, + if the server is security aware. The same is true for a non-existent + type under an existing name. This is a change in the existing + standard which contemplates only NS and SOA RRs in the authority + section. NXT RRs will also be returned if an explicit query is made + for the NXT type. + + The existence of a complete set of NXT records in a zone means that + any query for any name and any type to a security aware server + serving the zone will always result in an reply containing at least + one signed RR. + + NXT RRs do not appear in zone master files since they can be derived + from the rest of the zone. + +5.1 The NXT Resource Record + + The NXT resource record is used to securely indicate that RRs with an + owner name in a certain name interval do not exist in a zone and to + indicate what zone signed RR types are present for an existing name. + + The owner name of the NXT RR is an existing name in the zone. It's + RDATA is a "next" name and a type bit map. The presence of the NXT RR + means that generally no name between its owner name and the name in + its RDATA area exists and that no other zone signed types exist under + its owner name. This implies a canonical ordering of all domain + names in a zone. + + The ordering is to sort labels as unsigned left justified octet + strings where the absence of a octet sorts before a zero value octet + and upper case letters are treated as lower case letters. Names are + then sorted by sorting on the highest level label and then, within + those names with the same highest level label by the next lower + label, etc. down to leaf node labels. Since we are talking about a + zone, the zone name itself always exists and all other names are the + zone name with some prefix of lower level labels. Thus the zone name + itself always sorts first. + + + + + +Eastlake & Kaufman Standards Track [Page 26] + +RFC 2065 DNS Security Extensions January 1997 + + + There is a potential problem with the last NXT in a zone as it wants + to have an owner name which is the last existing name in canonical + order, which is easy, but it is not obvious what name to put in its + RDATA to indicate the entire remainder of the name space. This is + handled by treating the name space as circular and putting the zone + name in the RDATA of the last NXT in a zone. + + There are special considerations due to interaction with wildcards as + explained below. + + The NXT RRs for a zone SHOULD be automatically calculated and added + to the zone by the same recommended off-line process that signs the + zone (see Section 7.2). The NXT RR's TTL SHOULD not exceed the zone + minimum TTL. + +5.2 NXT RDATA Format + + The RDATA for an NXT RR consists simply of a domain name followed by + a bit map. + + The type number for the NXT RR is 30. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | next domain name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | type bit map / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The NXT RR type bit map is one bit per RR type present for the owner + name similar to the WKS socket bit map. The first bit represents RR + type zero (an illegal type which should not be present.) A one bit + indicates that at least one RR of that type is present for the owner + name. A zero indicates that no such RR is present. All bits not + specified because they are beyond the end of the bit map are assumed + to be zero. Note that bit 30, for NXT, will always be on so the + minimum bit map length is actually four octets. The NXT bit map + should be printed as a list of RR type mnemonics or decimal numbers + similar to the WKS RR. + + The domain name may be compressed with standard DNS name compression + when being transmitted over the network. The size of the bit map can + be inferred from the RDLENGTH and the length of the next domain name. + + + + + + + +Eastlake & Kaufman Standards Track [Page 27] + +RFC 2065 DNS Security Extensions January 1997 + + +5.3 Example + + Assume zone foo.tld has entries for + + big.foo.tld, + medium.foo.tld. + small.foo.tld. + tiny.foo.tld. + + Then a query to a security aware server for huge.foo.tld would + produce an error reply with the authority section data including + something like the following: + + big.foo.tld. NXT medium.foo.tld. A MX SIG NXT + big.foo.tld. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 + 19960102030405 ;signature expiration + 19951211100908 ;time signed + 21435 ;key footprint + foo.tld. ;signer + MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU + 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) + ) + + Note that this response implies that big.foo.tld is an existing name + in the zone and thus has other RR types associated with it than NXT. + However, only the NXT (and its SIG) RR appear in the response to this + query for huge.foo.tld, which is a non-existent name. + +5.4 Interaction of NXT RRs and Wildcard RRs + + Since, in some sense, a wildcard RR causes all possible names in an + interval to exist, there should not be an NXT RR that would cover any + part of this interval. Thus if *.X.ZONE exists you would expect an + NXT RR that ends at X.ZONE and one that starts with the last name + covered by *.X.ZONE. However, this "last name covered" is something + very ugly and long like \255\255\255....X.zone. So the NXT for the + interval following is simply given the owner name *.X.ZONE and an + RDATA of the next name after the wildcard. This "*" type owner name + is not expanded when the NXT is returned as authority information in + connection with a query for a non-existent name. + + If there could be any wildcard RRs in a zone and thus wildcard NXTs, + care must be taken in interpreting the results of explicit NXT + retrievals as the owner name may be a wildcard expansion. + + The existence of one or more wildcard RRs covering a name interval + makes it possible for a malicious server to hide any more + specifically named RRs in the internal. The server can just falsely + + + +Eastlake & Kaufman Standards Track [Page 28] + +RFC 2065 DNS Security Extensions January 1997 + + + return the wildcard match NXT instead of the more specifically named + RRs. If there is a zone wide wildcard, there will be an NXT RR whose + owner name is the wild card and whose RDATA is the zone name. In this + case a server could conceal the existence of any more specific RRs in + the zone. It would be possible to design a more strict NXT feature + which would eliminate this possibility. But it would be more complex + and might be so constraining as to make any dynamic update feature + very difficult. + +5.5 Blocking NXT Pseudo-Zone Transfers + + In a secure zone, a resolver can query for the initial NXT associated + with the zone name. Using the next domain name RDATA field from that + RR, it can query for the next NXT RR. By repeating this, it can walk + through all the NXTs in the zone. If there are no wildcards, it can + use this technique to find all names in a zone. If it does type ANY + queries, it can incrementally get all information in the zone and + thus defeat attempts to administratively block zone transfers. + + If there are any wildcards, this NXT walking technique will not find + any more specific RR names in the part of the name space the wildcard + covers. By doing explicit retrievals for wildcard names, a resolver + could determine what intervals are covered by wildcards but still + could not, with these techniques, find any names inside such + intervals except by trying every name. + + If it is desired to block NXT walking, the recommended method is to + add a zone wide wildcard of the KEY type with the no-key type value + and with no type (zone, entity, or user) bit on. This will cause + there to be one zone covering NXT RR and leak no information about + what real names exist in the zone. This protection from pseudo-zone + transfers is bought at the expense of eliminating the data origin + authentication of the non-existence of names that NXT RRs can + provide. If an entire zone is covered by a wildcard, a malicious + server can return an RR produced by matching the resulting wildcard + NXT and can thus hide all the real data and delegations in the zone + that have more specific names. + +5.6 Special Considerations at Delegation Points + + A name (other than root) which is the head of a zone also appears as + the leaf in a superzone. If both are secure, there will always be + two different NXT RRs with the same name. They can be distinguished + by their signers and next domain name fields. Security aware servers + should return the correct NXT automatically when required to + authenticate the non-existence of a name and both NXTs, if available, + on explicit query for type NXT. + + + + +Eastlake & Kaufman Standards Track [Page 29] + +RFC 2065 DNS Security Extensions January 1997 + + + Insecure servers will never automatically return an NXT and some + implementations may only return the NXT from the subzone on explicit + queries. + +6. The AD and CD Bits and How to Resolve Securely + + Retrieving or resolving authentic data from the Domain Name System + (DNS) involves starting with one or more trusted public keys for one + or more zones. With trusted keys, a resolver willing to perform + cryptography can progress securely through the secure DNS zone + structure to the zone of interest as described in Section 6.3. Such + trusted public keys would normally be configured in a manner similar + to that described in Section 6.2. However, as a practical matter, a + security aware resolver would still gain some confidence in the + results it returns even if it was not configured with any keys but + trusted what it got from a local well known server as a starting + point. + + Data stored at a security aware server needs to be internally + categorized as Authenticated, Pending, or Insecure. There is also a + fourth transient state of Bad which indicates that all SIG checks + have explicitly failed on the data. Such Bad data is not retained at + a security aware server. Authenticated means that the data has a + valid SIG under a KEY traceable via a chain of zero or more SIG and + KEY RRs to a KEY configured at the resolver via its boot file. + Pending data has no authenticated SIGs and at least one additional + SIG the resolver is still trying to authenticate. Insecure data is + data which it is known can never be either Authenticated or found Bad + because it is in or has been reached via a non-secured zone. Behavior + in terms of control of and flagging based on such data labels is + described in Section 6.1. + + The proper validation of signatures requires a reasonably secure + shared opinion of the absolute time between resolvers and servers as + described in Section 6.4. + +6.1 The AD and CD Header Bits + + Two previously unused bits are allocated out of the DNS + query/response format header. The AD (authentic data) bit indicates + in a response that the data included has been verified by the server + providing it. The CD (checking disabled) bit indicates in a query + that non-verified data is acceptable to the resolver sending the + query. + + + + + + + +Eastlake & Kaufman Standards Track [Page 30] + +RFC 2065 DNS Security Extensions January 1997 + + + These bits are allocated from the must-be-zero Z field as follows: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + These bits are zero in old servers and resolvers. Thus the responses + of old servers are not flagged as authenticated to security aware + resolvers and queries from non-security aware resolvers do not assert + the checking disabled bit and thus will be answered by security aware + servers only with authenticated data. Aware resolvers MUST not trust + the AD bit unless they trust the server they are talking to and + either have a secure path to it or use DNS transaction security. + + Any security aware resolver willing to do cryptography SHOULD assert + the CD bit on all queries to reduce DNS latency time by allowing + security aware servers to answer before they have resolved the + validity of data. + + Security aware servers NEVER return Bad data. For non-security aware + resolvers or security aware resolvers requesting service by having + the CD bit clear, security aware servers MUST return only + Authenticated or Insecure data with the AD bit set in the response. + Security aware resolvers will know that if data is Insecure versus + Authentic by the absence of SIG RRs. Security aware servers MAY + return Pending data to security aware resolvers requesting the + service by clearing the AD bit in the response. The AD bit MUST NOT + be set on a response unless all of the RRs in the response are either + Authenticated or Insecure. + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 31] + +RFC 2065 DNS Security Extensions January 1997 + + +6.2 Boot File Format + + Two boot file directives are added as described in this section. + + The format for a boot file directive to configure a starting zone key + is as follows: + + pubkey name flags protocol algorithm key-data + + for a public key. "name" is the owner name (if the line is + translated into a KEY RR). Flags indicates the type of key and is + the same as the flag octet in the KEY RR. Protocol and algorithm + also have the same meaning as they do in the KEY RR. The material + after the algorithm is algorithm dependent and, for private + algorithms (algorithm 254), starts with the algorithm's identifying + OID and its length. If the "no key" type value is set in flags or + the algorithm is specified as 253, then the key-data after algorithm + is null. When present the key-data is treated as an octet stream and + encoded in base 64 (see Appendix). + + A file of keys for cross certification or other purposes can be + configured though the keyfile directive as follows: + + keyfile filename + + The file looks like a master file except that it can only contain KEY + and SIG RRs with the SIGs signed under a key configured with the + pubkey directive. + + While it might seem logical for everyone to start with the key for + the root zone, this has problems. The logistics of updating every + DNS resolver in the world when the root key changes would be + excessive. It may be some time before there even is a root key. + Furthermore, many organizations will explicitly wish their "interior" + DNS implementations to completely trust only their own zone. Such + interior resolvers can then go through the organization's zone + servers to access data outsize the organization's domain and should + only be configured with the key forthe organization's DNS apex. + +6.3 Chaining Through Zones + + Starting with one or more trusted keys for a zone, it should be + possible to retrieve signed keys for its subzones which have a key + and, if the zone is not root, for its superzone. Every authoritative + secure zone server MUST also include the KEY RR for a super-zone + signed by the secure zone via a keyfile directive. This makes it + possible to climb the tree of zones if one starts below root. A + secure sub-zone is indicated by a KEY RR with non-null key + + + +Eastlake & Kaufman Standards Track [Page 32] + +RFC 2065 DNS Security Extensions January 1997 + + + information appearing with the NS RRs for the sub-zone. These make + it possible to descend within the tree of zones. + + A resolver should keep track of the number of successive secure zones + traversed from a starting point to any secure zone it can reach. In + general, the lower such a distance number is, the greater the + confidence in the data. Data configured via a boot file directive + should be given a distance number of zero. If a query encounters + different data for the same query with different distance values, + that with a larger value should be ignored. + + A security conscious resolver should completely refuse to step from a + secure zone into a non-secure zone unless the non-secure zone is + certified to be non-secure, or only experimentally secure, by the + presence of an authenticated KEY RR for the non-secure zone with the + no-key type value or the presence of a KEY RR with the experimental + bit set. Otherwise the resolver is getting bogus or spoofed data. + + If legitimate non-secure zones are encountered in traversing the DNS + tree, then no zone can be trusted as secure that can be reached only + via information from such non-secure zones. Since the non-secure zone + data could have been spoofed, the "secure" zone reach via it could be + counterfeit. The "distance" to data in such zones or zones reached + via such zones could be set to 512 or more as this exceeds the + largest possible distance through secure zones in the DNS. + Nevertheless, continuing to apply secure checks within "secure" zones + reached via non-secure zones is a good practice and will, as a + practical matter, provide some small increase in security. + +6.4 Secure Time + + Coordinated interpretation of the time fields in SIG RRs requires + that reasonably consistent time be available to the hosts + implementing the DNS security extensions. + + A variety of time synchronization protocols exist including the + Network Time Protocol (NTP, RFC1305). If such protocols are used, + they MUST be used securely so that time can not be spoofed. + Otherwise, for example, a host could get its clock turned back and + might then believe old SIG and KEY RRs which were valid but no longer + are. + +7. Operational Considerations + + This section discusses a variety of considerations in secure + operation of the Domain Name System (DNS) using these protocol + extensions. + + + + +Eastlake & Kaufman Standards Track [Page 33] + +RFC 2065 DNS Security Extensions January 1997 + + +7.1 Key Size Considerations + + There are a number of factors that effect public key size choice for + use in the DNS security extension. Unfortunately, these factors + usually do not all point in the same direction. Choice of zone key + size should generally be made by the zone administrator depending on + their local conditions. + + For most schemes, larger keys are more secure but slower. Given a + small public exponent, verification (the most common operation) for + the MD5/RSA algorithm will vary roughly with the square of the + modulus length, signing will vary with the cube of the modulus + length, and key generation (the least common operation) will vary + with the fourth power of the modulus length. The current best + algorithms for factoring a modulus and breaking RSA security vary + roughly with the 1.6 power of the modulus itself. Thus going from a + 640 bit modulus to a 1280 bit modulus only increases the verification + time by a factor of 4 but increases the work factor of breaking the + key by over 2^900. An upper bound of 2552 bits has been established + for the MD5/RSA DNS security algorithm for interoperability purposes. + + However, larger keys increase the size of the KEY and SIG RRs. This + increases the chance of DNS UDP packet overflow and the possible + necessity for using higher overhead TCP in responses. + + The recommended minimum RSA algorithm modulus size, 640 bits, is + believed by the authors to be secure at this time but high level + zones in the DNS tree may wish to set a higher minimum, perhaps 1000 + bits, for security reasons. (Since the United States National + Security Agency generally permits export of encryption systems using + an RSA modulus of up to 512 bits, use of that small a modulus, i.e. + n, must be considered weak.) + + For a key used only to secure data and not to secure other keys, 640 + bits should be adequate at this time. + +7.2 Key Storage + + It is recommended that zone private keys and the zone file master + copy be kept and used in off-line non-network connected physically + secure machines only. Periodically an application can be run to add + authentication to a zone by adding SIG and NXT RRs and adding no-key + type KEY RRs for subzones where a real KEY RR is not provided. Then + the augmented file can be transferred, perhaps by sneaker-net, to the + networked zone primary server machine. + + The idea is to have a one way information flow to the network to + avoid the possibility of tampering from the network. Keeping the + + + +Eastlake & Kaufman Standards Track [Page 34] + +RFC 2065 DNS Security Extensions January 1997 + + + zone master file on-line on the network and simply cycling it through + an off-line signer does not do this. The on-line version could still + be tampered with if the host it resides on is compromised. For + maximum security, the master copy of the zone file should be off net + and should not be updated based on an unsecured network mediated + communication. + + Note, however, that secure resolvers must be configured with some + trusted on-line public key information (or a secure path to such a + resolver) or they will be unable to authenticate. + + Non-zone private keys, such as host or user keys, generally have to + be kept on line to be used for real-time purposes such as DNS + transaction security, IPSEC session set-up, or secure mail. + +7.3 Key Generation + + Careful key generation is a sometimes overlooked but absolutely + essential element in any cryptographically secure system. The + strongest algorithms used with the longest keys are still of no use + if an adversary can guess enough to lower the size of the likely key + space so that it can be exhaustively searched. Suggestions will be + found in RFC 1750. + + It is strongly recommended that key generation also occur off-line, + perhaps on the machine used to sign zones (see Section 7.2). + +7.4 Key Lifetimes + + No key should be used forever. The longer a key is in use, the + greater the probability that it will have been compromised through + carelessness, accident, espionage, or cryptanalysis. Furthermore, if + key rollover is a rare event, there is an increased risk that, when + the time does come up change the key, no one at the site will + remember how to do it or other problems will have developed in the + procedures. + + While key lifetime is a matter of local policy, these considerations + suggest that no zone key should have a lifetime significantly over + four years. A reasonable maximum lifetime for zone keys that are + kept off-line and carefully guarded is 13 months with the intent that + they be replaced every year. A reasonable maximum lifetime for end + entity and useer keys that are used for IP-security or the like and + are kept on line is 36 days with the intent that they be replaced + monthly or more often. In some cases, an entity key lifetime of + somewhat over a day may be reasonable. + + + + + +Eastlake & Kaufman Standards Track [Page 35] + +RFC 2065 DNS Security Extensions January 1997 + + +7.5 Signature Lifetime + + Signature expiration times must be set far enough in the future that + it is quite certain that new signatures can be generated before the + old ones expire. However, setting expiration too far into the future + could, if bad data or signatures were ever generated, mean a long + time to flush such badness. + + It is recommended that signature lifetime be a small multiple of the + TTL but not less than a reasonable re-signing interval. + +7.6 Root + + It should be noted that in DNS the root is a zone unto itself. Thus + the root zone key should only be seen signing itself or signing RRs + with names one level below root, such as .aq, .edu, or .arpa. + Implementations MAY reject as bogus any purported root signature of + records with a name more than one level below root. The root zone + contains the root KEY RR signed by a SIG RR under the root key + itself. + +8. Conformance + + Levels of server and resolver conformance are defined. + +8.1 Server Conformance + + Two levels of server conformance are defined as follows: + + Minimal server compliance is the ability to store and retrieve + (including zone transfer) SIG, KEY, and NXT RRs. Any secondary, + caching, or other server for a secure zone MUST be at least + minimally compliant and even then some things, such as secure + CNAMEs, will not work without full compliance. + + Full server compliance adds the following to basic compliance: + + (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) + ability, given a zone file and private key, to add appropriate SIG + and NXT RRs, possibly via a separate application, (3) proper + automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) + suppression of CNAME following on retrieval of the security type + RRs, (5) recognize the CD query header bit and set the AD query + header bit, as appropriate, and (6) proper handling of the two NXT + RRs at delegation points. Primary servers for secure zones MUST + be fully compliant and for completely successful secure operation, + all secondary, caching, and other servers handling the zone SHOULD + be fully compliant as well. + + + +Eastlake & Kaufman Standards Track [Page 36] + +RFC 2065 DNS Security Extensions January 1997 + + +8.2 Resolver Conformance + + Two levels of resolver compliance are defined: + + A basic compliance resolver can handle SIG, KEY, and NXT RRs when + they are explicitly requested. + + A fully compliant resolver (1) understands KEY, SIG, and NXT RRs, + (2) maintains appropriate information in its local caches and + database to indicate which RRs have been authenticated and to what + extent they have been authenticated, (3) performs additional + queries as necessary to attempt to obtain KEY, SIG, or NXT RRs + from non-security aware servers, (4) normally sets the CD query + header bit on its queries. + +9. Security Considerations + + This document describes technical details of extensions to the Domain + Name System (DNS) protocol to provide data integrity and origin + authentication, public key distribution, and optional transaction and + request security. + + It should be noted that, at most, these extensions guarantee the + validity of resource records, including KEY resource records, + retrieved from the DNS. They do not magically solve other security + problems. For example, using secure DNS you can have high confidence + in the IP address you retrieve for a host name; however, this does + not stop someone for substituting an unauthorized host at that + address or capturing packets sent to that address and falsely + responding with packets apparently from that address. Any reasonably + complete security system will require the protection of many + additional facets of the Internet. + + + + + + + + + + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 37] + +RFC 2065 DNS Security Extensions January 1997 + + +References + + [NETSEC] - Network Security: PRIVATE Communications in a PUBLIC + World, Charlie Kaufman, Radia Perlman, & Mike Speciner, + Prentice Hall Series in Computer Networking and + Distributed Communications 1995. + + [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, + Inc., 3 June 1991, Version 1.4. + + [RFC1032] - Stahl, M., "Domain Administrators Guide", RFC 1032, + November 1987. + + [RFC1033] - Lottor, M., "Domain Administrators Operations Guide", + RRFC 1033, November 1987. + + [RFC1034] - Mockapetris, P., "Domain Names - Concepts and + Facilities", STD 13, RFC 1034, November 1987. + + [RFC1035] - Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC1305] - Mills, D., "Network Time Protocol (v3)", RFC 1305, March + 1992. + + [RFC1321] - Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC1530] - Malamud, C., and M. Rose, "Principles of Operation for + the TPC.INT Subdomain: General Principles and Policy", + RFC 1530, October 1993. + + [RFC1750] - Eastlake, D., Crocker, S., and J, Schiller, "Randomness + Requirements for Security", RFC 1750, December 1994. + + [RFC1825] - Atkinson, R., "Security Architecture for the Internet + Protocol", RFC 1825, August 1995. + + [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. + + + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 38] + +RFC 2065 DNS Security Extensions January 1997 + + +Authors' Addresses + + Donald E. Eastlake 3rd + CyberCash, Inc. + 318 Acton Street + Carlisle, MA 01741 USA + + Telephone: +1 508-287-4877 + +1 508-371-7148(fax) + +1 703-620-4200(main office, Reston, Virginia, USA) + EMail: dee@cybercash.com + + + Charles W. Kaufman + Iris Associates + 1 Technology Park Drive + Westford, MA 01886 USA + + Telephone: +1 508-392-5276 + EMail: charlie_kaufman@iris.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 39] + +RFC 2065 DNS Security Extensions January 1997 + + +Appendix: Base 64 Encoding + + The following encoding technique is taken from RFC 1521 by N. + Borenstein and N. Freed. It is reproduced here in an edited form for + convenience. + + A 65-character subset of US-ASCII is used, enabling 6 bits to be + represented per printable character. (The extra 65th character, "=", + is used to signify a special processing function.) + + The encoding process represents 24-bit groups of input bits as output + strings of 4 encoded characters. Proceeding from left to right, a + 24-bit input group is formed by concatenating 3 8-bit input groups. + These 24 bits are then treated as 4 concatenated 6-bit groups, each + of which is translated into a single digit in the base 64 alphabet. + + Each 6-bit group is used as an index into an array of 64 printable + characters. The character referenced by the index is placed in the + output string. + + Table 1: The Base 64 Alphabet + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y + + Special processing is performed if fewer than 24 bits are available + at the end of the data being encoded. A full encoding quantum is + always completed at the end of a quantity. When fewer than 24 input + bits are available in an input group, zero bits are added (on the + right) to form an integral number of 6-bit groups. Padding at the + end of the data is performed using the '=' character. Since all base + 64 input is an integral number of octets, only the following cases + + + +Eastlake & Kaufman Standards Track [Page 40] + +RFC 2065 DNS Security Extensions January 1997 + + + can arise: (1) the final quantum of encoding input is an integral + multiple of 24 bits; here, the final unit of encoded output will be + an integral multiple of 4 characters with no "=" padding, (2) the + final quantum of encoding input is exactly 8 bits; here, the final + unit of encoded output will be two characters followed by two "=" + padding characters, or (3) the final quantum of encoding input is + exactly 16 bits; here, the final unit of encoded output will be three + characters followed by one "=" padding character. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake & Kaufman Standards Track [Page 41] + diff --git a/Documentation/en/rfc/rfc2136.txt b/Documentation/en/rfc/rfc2136.txt new file mode 100644 index 00000000..c0ed36b0 --- /dev/null +++ b/Documentation/en/rfc/rfc2136.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group P. Vixie, Editor +Request for Comments: 2136 ISC +Updates: 1035 S. Thomson +Category: Standards Track Bellcore + Y. Rekhter + Cisco + J. Bound + DEC + April 1997 + + Dynamic Updates in the Domain Name System (DNS UPDATE) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Domain Name System was originally designed to support queries of + a statically configured database. While the data was expected to + change, the frequency of those changes was expected to be fairly low, + and all updates were made as external edits to a zone's Master File. + + Using this specification of the UPDATE opcode, it is possible to add + or delete RRs or RRsets from a specified zone. Prerequisites are + specified separately from update operations, and can specify a + dependency upon either the previous existence or nonexistence of an + RRset, or the existence of a single RR. + + UPDATE is atomic, i.e., all prerequisites must be satisfied or else + no update operations will take place. There are no data dependent + error conditions defined after the prerequisites have been met. + +1 - Definitions + + This document intentionally gives more definition to the roles of + "Master," "Slave," and "Primary Master" servers, and their + enumeration in NS RRs, and the SOA MNAME field. In that sense, the + following server type definitions can be considered an addendum to + [RFC1035], and are intended to be consistent with [RFC1996]: + + Slave an authoritative server that uses AXFR or IXFR to + retrieve the zone and is named in the zone's NS + RRset. + + + +Vixie, et. al. Standards Track [Page 1] + +RFC 2136 DNS Update April 1997 + + + Master an authoritative server configured to be the + source of AXFR or IXFR data for one or more slave + servers. + + Primary Master master server at the root of the AXFR/IXFR + dependency graph. The primary master is named in + the zone's SOA MNAME field and optionally by an NS + RR. There is by definition only one primary master + server per zone. + + A domain name identifies a node within the domain name space tree + structure. Each node has a set (possibly empty) of Resource Records + (RRs). All RRs having the same NAME, CLASS and TYPE are called a + Resource Record Set (RRset). + + The pseudocode used in this document is for example purposes only. + If it is found to disagree with the text, the text shall be + considered authoritative. If the text is found to be ambiguous, the + pseudocode can be used to help resolve the ambiguity. + + 1.1 - Comparison Rules + + 1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, + RDLENGTH and RDATA fields are equal. Note that the time-to-live + (TTL) field is explicitly excluded from the comparison. + + 1.1.2. The rules for comparison of character strings in names are + specified in [RFC1035 2.3.3]. + + 1.1.3. Wildcarding is disabled. That is, a wildcard ("*") in an + update only matches a wildcard ("*") in the zone, and vice versa. + + 1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in + the update, and will not otherwise be followed. All UPDATE + operations are done on the basis of canonical names. + + 1.1.5. The following RR types cannot be appended to an RRset. If the + following comparison rules are met, then an attempt to add the new RR + will result in the replacement of the previous RR: + + SOA compare only NAME, CLASS and TYPE -- it is not possible to + have more than one SOA per zone, even if any of the data + fields differ. + + WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL + -- only one WKS RR is possible for this tuple, even if the + services masks differ. + + + + +Vixie, et. al. Standards Track [Page 2] + +RFC 2136 DNS Update April 1997 + + + CNAME compare only NAME, CLASS, and TYPE -- it is not possible + to have more than one CNAME RR, even if their data fields + differ. + + 1.2 - Glue RRs + + For the purpose of determining whether a domain name used in the + UPDATE protocol is contained within a specified zone, a domain name + is "in" a zone if it is owned by that zone's domain name. See + section 7.18 for details. + + 1.3 - New Assigned Numbers + + CLASS = NONE (254) + RCODE = YXDOMAIN (6) + RCODE = YXRRSET (7) + RCODE = NXRRSET (8) + RCODE = NOTAUTH (9) + RCODE = NOTZONE (10) + Opcode = UPDATE (5) + +2 - Update Message Format + + The DNS Message Format is defined by [RFC1035 4.1]. Some extensions + are necessary (for example, more error codes are possible under + UPDATE than under QUERY) and some fields must be overloaded (see + description of CLASS fields below). + + The overall format of an UPDATE message is, following [ibid]: + + +---------------------+ + | Header | + +---------------------+ + | Zone | specifies the zone to be updated + +---------------------+ + | Prerequisite | RRs or RRsets which must (not) preexist + +---------------------+ + | Update | RRs or RRsets to be added or deleted + +---------------------+ + | Additional Data | additional data + +---------------------+ + + + + + + + + + + +Vixie, et. al. Standards Track [Page 3] + +RFC 2136 DNS Update April 1997 + + + The Header Section specifies that this message is an UPDATE, and + describes the size of the other sections. The Zone Section names the + zone that is to be updated by this message. The Prerequisite Section + specifies the starting invariants (in terms of zone content) required + for this update. The Update Section contains the edits to be made, + and the Additional Data Section contains data which may be necessary + to complete, but is not part of, this update. + + 2.1 - Transport Issues + + An update transaction may be carried in a UDP datagram, if the + request fits, or in a TCP connection (at the discretion of the + requestor). When TCP is used, the message is in the format described + in [RFC1035 4.2.2]. + + 2.2 - Message Header + + The header of the DNS Message Format is defined by [RFC 1035 4.1]. + Not all opcodes define the same set of flag bits, though as a + practical matter most of the bits defined for QUERY (in [ibid]) are + identically defined by the other opcodes. UPDATE uses only one flag + bit (QR). + + The DNS Message Format specifies record counts for its four sections + (Question, Answer, Authority, and Additional). UPDATE uses the same + fields, and the same section formats, but the naming and use of these + sections differs as shown in the following modified header, after + [RFC1035 4.1.1]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode | Z | RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ZOCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | PRCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | UPCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ADCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + + + + + + +Vixie, et. al. Standards Track [Page 4] + +RFC 2136 DNS Update April 1997 + + + These fields are used as follows: + + ID A 16-bit identifier assigned by the entity that generates any + kind of request. This identifier is copied in the + corresponding reply and can be used by the requestor to match + replies to outstanding requests, or by the server to detect + duplicated requests from some requestor. + + QR A one bit field that specifies whether this message is a + request (0), or a response (1). + + Opcode A four bit field that specifies the kind of request in this + message. This value is set by the originator of a request + and copied into the response. The Opcode value that + identifies an UPDATE message is five (5). + + Z Reserved for future use. Should be zero (0) in all requests + and responses. A non-zero Z field should be ignored by + implementations of this specification. + + RCODE Response code - this four bit field is undefined in requests + and set in responses. The values and meanings of this field + within responses are as follows: + + Mneumonic Value Description + ------------------------------------------------------------ + NOERROR 0 No error condition. + FORMERR 1 The name server was unable to interpret + the request due to a format error. + SERVFAIL 2 The name server encountered an internal + failure while processing this request, + for example an operating system error + or a forwarding timeout. + NXDOMAIN 3 Some name that ought to exist, + does not exist. + NOTIMP 4 The name server does not support + the specified Opcode. + REFUSED 5 The name server refuses to perform the + specified operation for policy or + security reasons. + YXDOMAIN 6 Some name that ought not to exist, + does exist. + YXRRSET 7 Some RRset that ought not to exist, + does exist. + NXRRSET 8 Some RRset that ought to exist, + does not exist. + + + + + +Vixie, et. al. Standards Track [Page 5] + +RFC 2136 DNS Update April 1997 + + + NOTAUTH 9 The server is not authoritative for + the zone named in the Zone Section. + NOTZONE 10 A name used in the Prerequisite or + Update Section is not within the + zone denoted by the Zone Section. + + ZOCOUNT The number of RRs in the Zone Section. + + PRCOUNT The number of RRs in the Prerequisite Section. + + UPCOUNT The number of RRs in the Update Section. + + ADCOUNT The number of RRs in the Additional Data Section. + + 2.3 - Zone Section + + The Zone Section has the same format as that specified in [RFC1035 + 4.1.2], with the fields redefined as follows: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / ZNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ZTYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ZCLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + UPDATE uses this section to denote the zone of the records being + updated. All records to be updated must be in the same zone, and + therefore the Zone Section is allowed to contain exactly one record. + The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is + the zone's class. + + 2.4 - Prerequisite Section + + This section contains a set of RRset prerequisites which must be + satisfied at the time the UPDATE packet is received by the primary + master server. The format of this section is as specified by + [RFC1035 4.1.3]. There are five possible sets of semantics that can + be expressed here, summarized as follows and then explained below. + + (1) RRset exists (value independent). At least one RR with a + specified NAME and TYPE (in the zone and class specified by + the Zone Section) must exist. + + + +Vixie, et. al. Standards Track [Page 6] + +RFC 2136 DNS Update April 1997 + + + (2) RRset exists (value dependent). A set of RRs with a + specified NAME and TYPE exists and has the same members + with the same RDATAs as the RRset specified here in this + Section. + + (3) RRset does not exist. No RRs with a specified NAME and TYPE + (in the zone and class denoted by the Zone Section) can exist. + + (4) Name is in use. At least one RR with a specified NAME (in + the zone and class specified by the Zone Section) must exist. + Note that this prerequisite is NOT satisfied by empty + nonterminals. + + (5) Name is not in use. No RR of any type is owned by a + specified NAME. Note that this prerequisite IS satisfied by + empty nonterminals. + + The syntax of these is as follows: + + 2.4.1 - RRset Exists (Value Independent) + + At least one RR with a specified NAME and TYPE (in the zone and class + specified in the Zone Section) must exist. + + For this prerequisite, a requestor adds to the section a single RR + whose NAME and TYPE are equal to that of the zone RRset whose + existence is required. RDLENGTH is zero and RDATA is therefore + empty. CLASS must be specified as ANY to differentiate this + condition from that of an actual RR whose RDLENGTH is naturally zero + (0) (e.g., NULL). TTL is specified as zero (0). + + 2.4.2 - RRset Exists (Value Dependent) + + A set of RRs with a specified NAME and TYPE exists and has the same + members with the same RDATAs as the RRset specified here in this + section. While RRset ordering is undefined and therefore not + significant to this comparison, the sets be identical in their + extent. + + For this prerequisite, a requestor adds to the section an entire + RRset whose preexistence is required. NAME and TYPE are that of the + RRset being denoted. CLASS is that of the zone. TTL must be + specified as zero (0) and is ignored when comparing RRsets for + identity. + + + + + + + +Vixie, et. al. Standards Track [Page 7] + +RFC 2136 DNS Update April 1997 + + + 2.4.3 - RRset Does Not Exist + + No RRs with a specified NAME and TYPE (in the zone and class denoted + by the Zone Section) can exist. + + For this prerequisite, a requestor adds to the section a single RR + whose NAME and TYPE are equal to that of the RRset whose nonexistence + is required. The RDLENGTH of this record is zero (0), and RDATA + field is therefore empty. CLASS must be specified as NONE in order + to distinguish this condition from a valid RR whose RDLENGTH is + naturally zero (0) (for example, the NULL RR). TTL must be specified + as zero (0). + + 2.4.4 - Name Is In Use + + Name is in use. At least one RR with a specified NAME (in the zone + and class specified by the Zone Section) must exist. Note that this + prerequisite is NOT satisfied by empty nonterminals. + + For this prerequisite, a requestor adds to the section a single RR + whose NAME is equal to that of the name whose ownership of an RR is + required. RDLENGTH is zero and RDATA is therefore empty. CLASS must + be specified as ANY to differentiate this condition from that of an + actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE + must be specified as ANY to differentiate this case from that of an + RRset existence test. TTL is specified as zero (0). + + 2.4.5 - Name Is Not In Use + + Name is not in use. No RR of any type is owned by a specified NAME. + Note that this prerequisite IS satisfied by empty nonterminals. + + For this prerequisite, a requestor adds to the section a single RR + whose NAME is equal to that of the name whose nonownership of any RRs + is required. RDLENGTH is zero and RDATA is therefore empty. CLASS + must be specified as NONE. TYPE must be specified as ANY. TTL must + be specified as zero (0). + + 2.5 - Update Section + + This section contains RRs to be added to or deleted from the zone. + The format of this section is as specified by [RFC1035 4.1.3]. There + are four possible sets of semantics, summarized below and with + details to follow. + + + + + + + +Vixie, et. al. Standards Track [Page 8] + +RFC 2136 DNS Update April 1997 + + + (1) Add RRs to an RRset. + (2) Delete an RRset. + (3) Delete all RRsets from a name. + (4) Delete an RR from an RRset. + + The syntax of these is as follows: + + 2.5.1 - Add To An RRset + + RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH + and RDATA are those being added, and CLASS is the same as the zone + class. Any duplicate RRs will be silently ignored by the primary + master. + + 2.5.2 - Delete An RRset + + One RR is added to the Update Section whose NAME and TYPE are those + of the RRset to be deleted. TTL must be specified as zero (0) and is + otherwise not used by the primary master. CLASS must be specified as + ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. + If no such RRset exists, then this Update RR will be silently ignored + by the primary master. + + 2.5.3 - Delete All RRsets From A Name + + One RR is added to the Update Section whose NAME is that of the name + to be cleansed of RRsets. TYPE must be specified as ANY. TTL must + be specified as zero (0) and is otherwise not used by the primary + master. CLASS must be specified as ANY. RDLENGTH must be zero (0) + and RDATA must therefore be empty. If no such RRsets exist, then + this Update RR will be silently ignored by the primary master. + + 2.5.4 - Delete An RR From An RRset + + RRs to be deleted are added to the Update Section. The NAME, TYPE, + RDLENGTH and RDATA must match the RR being deleted. TTL must be + specified as zero (0) and will otherwise be ignored by the primary + master. CLASS must be specified as NONE to distinguish this from an + RR addition. If no such RRs exist, then this Update RR will be + silently ignored by the primary master. + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 9] + +RFC 2136 DNS Update April 1997 + + + 2.6 - Additional Data Section + + This section contains RRs which are related to the update itself, or + to new RRs being added by the update. For example, out of zone glue + (A RRs referred to by new NS RRs) should be presented here. The + server can use or ignore out of zone glue, at the discretion of the + server implementor. The format of this section is as specified by + [RFC1035 4.1.3]. + +3 - Server Behavior + + A server, upon receiving an UPDATE request, will signal NOTIMP to the + requestor if the UPDATE opcode is not recognized or if it is + recognized but has not been implemented. Otherwise, processing + continues as follows. + + 3.1 - Process Zone Section + + 3.1.1. The Zone Section is checked to see that there is exactly one + RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the + requestor. Next, the ZNAME and ZCLASS are checked to see if the zone + so named is one of this server's authority zones, else signal NOTAUTH + to the requestor. If the server is a zone slave, the request will be + forwarded toward the primary master. + + 3.1.2 - Pseudocode For Zone Section Processing + + if (zcount != 1 || ztype != SOA) + return (FORMERR) + if (zone_type(zname, zclass) == SLAVE) + return forward() + if (zone_type(zname, zclass) == MASTER) + return update() + return (NOTAUTH) + + Sections 3.2 through 3.8 describe the primary master's behaviour, + whereas Section 6 describes a forwarder's behaviour. + + 3.2 - Process Prerequisite Section + + Next, the Prerequisite Section is checked to see that all + prerequisites are satisfied by the current state of the zone. Using + the definitions expressed in Section 1.2, if any RR's NAME is not + within the zone specified in the Zone Section, signal NOTZONE to the + requestor. + + + + + + +Vixie, et. al. Standards Track [Page 10] + +RFC 2136 DNS Update April 1997 + + + 3.2.1. For RRs in this section whose CLASS is ANY, test to see that + TTL and RDLENGTH are both zero (0), else signal FORMERR to the + requestor. If TYPE is ANY, test to see that there is at least one RR + in the zone whose NAME is the same as that of the Prerequisite RR, + else signal NXDOMAIN to the requestor. If TYPE is not ANY, test to + see that there is at least one RR in the zone whose NAME and TYPE are + the same as that of the Prerequisite RR, else signal NXRRSET to the + requestor. + + 3.2.2. For RRs in this section whose CLASS is NONE, test to see that + the TTL and RDLENGTH are both zero (0), else signal FORMERR to the + requestor. If the TYPE is ANY, test to see that there are no RRs in + the zone whose NAME is the same as that of the Prerequisite RR, else + signal YXDOMAIN to the requestor. If the TYPE is not ANY, test to + see that there are no RRs in the zone whose NAME and TYPE are the + same as that of the Prerequisite RR, else signal YXRRSET to the + requestor. + + 3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS, + test to see that the TTL is zero (0), else signal FORMERR to the + requestor. Then, build an RRset for each unique <NAME,TYPE> and + compare each resulting RRset for set equality (same members, no more, + no less) with RRsets in the zone. If any Prerequisite RRset is not + entirely and exactly matched by a zone RRset, signal NXRRSET to the + requestor. If any RR in this section has a CLASS other than ZCLASS + or NONE or ANY, signal FORMERR to the requestor. + + 3.2.4 - Table Of Metavalues Used In Prerequisite Section + + CLASS TYPE RDATA Meaning + ------------------------------------------------------------ + ANY ANY empty Name is in use + ANY rrset empty RRset exists (value independent) + NONE ANY empty Name is not in use + NONE rrset empty RRset does not exist + zone rrset rr RRset exists (value dependent) + + + + + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 11] + +RFC 2136 DNS Update April 1997 + + + 3.2.5 - Pseudocode for Prerequisite Section Processing + + for rr in prerequisites + if (rr.ttl != 0) + return (FORMERR) + if (zone_of(rr.name) != ZNAME) + return (NOTZONE); + if (rr.class == ANY) + if (rr.rdlength != 0) + return (FORMERR) + if (rr.type == ANY) + if (!zone_name<rr.name>) + return (NXDOMAIN) + else + if (!zone_rrset<rr.name, rr.type>) + return (NXRRSET) + if (rr.class == NONE) + if (rr.rdlength != 0) + return (FORMERR) + if (rr.type == ANY) + if (zone_name<rr.name>) + return (YXDOMAIN) + else + if (zone_rrset<rr.name, rr.type>) + return (YXRRSET) + if (rr.class == zclass) + temp<rr.name, rr.type> += rr + else + return (FORMERR) + + for rrset in temp + if (zone_rrset<rrset.name, rrset.type> != rrset) + return (NXRRSET) + + 3.3 - Check Requestor's Permissions + + 3.3.1. Next, the requestor's permission to update the RRs named in + the Update Section may be tested in an implementation dependent + fashion or using mechanisms specified in a subsequent Secure DNS + Update protocol. If the requestor does not have permission to + perform these updates, the server may write a warning message in its + operations log, and may either signal REFUSED to the requestor, or + ignore the permission problem and proceed with the update. + + + + + + + + +Vixie, et. al. Standards Track [Page 12] + +RFC 2136 DNS Update April 1997 + + + 3.3.2. While the exact processing is implementation defined, if these + verification activities are to be performed, this is the point in the + server's processing where such performance should take place, since + if a REFUSED condition is encountered after an update has been + partially applied, it will be necessary to undo the partial update + and restore the zone to its original state before answering the + requestor. + + 3.3.3 - Pseudocode for Permission Checking + + if (security policy exists) + if (this update is not permitted) + if (local option) + log a message about permission problem + if (local option) + return (REFUSED) + + 3.4 - Process Update Section + + Next, the Update Section is processed as follows. + + 3.4.1 - Prescan + + The Update Section is parsed into RRs and each RR's CLASS is checked + to see if it is ANY, NONE, or the same as the Zone Class, else signal + a FORMERR to the requestor. Using the definitions in Section 1.2, + each RR's NAME must be in the zone specified by the Zone Section, + else signal NOTZONE to the requestor. + + 3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is + ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any + unrecognized type, then signal FORMERR to the requestor. For RRs + whose CLASS is ANY or NONE, check the TTL to see that it is zero (0), + else signal a FORMERR to the requestor. For any RR whose CLASS is + ANY, check the RDLENGTH to make sure that it is zero (0) (that is, + the RDATA field is empty), and that the TYPE is not AXFR, MAILA, + MAILB, or any other QUERY metatype besides ANY, or any unrecognized + type, else signal FORMERR to the requestor. + + + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 13] + +RFC 2136 DNS Update April 1997 + + + 3.4.1.3 - Pseudocode For Update Section Prescan + + [rr] for rr in updates + if (zone_of(rr.name) != ZNAME) + return (NOTZONE); + if (rr.class == zclass) + if (rr.type & ANY|AXFR|MAILA|MAILB) + return (FORMERR) + elsif (rr.class == ANY) + if (rr.ttl != 0 || rr.rdlength != 0 + || rr.type & AXFR|MAILA|MAILB) + return (FORMERR) + elsif (rr.class == NONE) + if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB) + return (FORMERR) + else + return (FORMERR) + + 3.4.2 - Update + + The Update Section is parsed into RRs and these RRs are processed in + order. + + 3.4.2.1. If any system failure (such as an out of memory condition, + or a hardware error in persistent storage) occurs during the + processing of this section, signal SERVFAIL to the requestor and undo + all updates applied to the zone during this transaction. + + 3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to + the zone. In case of duplicate RDATAs (which for SOA RRs is always + the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL + fields both match), the Zone RR is replaced by Update RR. If the + TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is + lower (according to [RFC1982]) than or equal to the current Zone SOA + RR's SOA.SERIAL, the Update RR is ignored. In the case of a CNAME + Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME + Update RR, otherwise replace the CNAME Zone RR with the CNAME Update + RR. + + 3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, + all Zone RRs with the same NAME are deleted, unless the NAME is the + same as ZNAME in which case only those RRs whose TYPE is other than + SOA or NS are deleted. For any Update RR whose CLASS is ANY and + whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are + deleted, unless the NAME is the same as ZNAME in which case neither + SOA or NS RRs will be deleted. + + + + + +Vixie, et. al. Standards Track [Page 14] + +RFC 2136 DNS Update April 1997 + + + 3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose + NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, + unless the NAME is the same as ZNAME and either the TYPE is SOA or + the TYPE is NS and the matching Zone RR is the only NS remaining in + the RRset, in which case this Update RR is ignored. + + 3.4.2.5. Signal NOERROR to the requestor. + + 3.4.2.6 - Table Of Metavalues Used In Update Section + + CLASS TYPE RDATA Meaning + --------------------------------------------------------- + ANY ANY empty Delete all RRsets from a name + ANY rrset empty Delete an RRset + NONE rrset rr Delete an RR from an RRset + zone rrset rr Add to an RRset + + 3.4.2.7 - Pseudocode For Update Section Processing + + [rr] for rr in updates + if (rr.class == zclass) + if (rr.type == CNAME) + if (zone_rrset<rr.name, ~CNAME>) + next [rr] + elsif (zone_rrset<rr.name, CNAME>) + next [rr] + if (rr.type == SOA) + if (!zone_rrset<rr.name, SOA> || + zone_rr<rr.name, SOA>.serial > rr.soa.serial) + next [rr] + for zrr in zone_rrset<rr.name, rr.type> + if (rr.type == CNAME || rr.type == SOA || + (rr.type == WKS && rr.proto == zrr.proto && + rr.address == zrr.address) || + rr.rdata == zrr.rdata) + zrr = rr + next [rr] + zone_rrset<rr.name, rr.type> += rr + elsif (rr.class == ANY) + if (rr.type == ANY) + if (rr.name == zname) + zone_rrset<rr.name, ~(SOA|NS)> = Nil + else + zone_rrset<rr.name, *> = Nil + elsif (rr.name == zname && + (rr.type == SOA || rr.type == NS)) + next [rr] + else + + + +Vixie, et. al. Standards Track [Page 15] + +RFC 2136 DNS Update April 1997 + + + zone_rrset<rr.name, rr.type> = Nil + elsif (rr.class == NONE) + if (rr.type == SOA) + next [rr] + if (rr.type == NS && zone_rrset<rr.name, NS> == rr) + next [rr] + zone_rr<rr.name, rr.type, rr.data> = Nil + return (NOERROR) + + 3.5 - Stability + + When a zone is modified by an UPDATE operation, the server must + commit the change to nonvolatile storage before sending a response to + the requestor or answering any queries or transfers for the modified + zone. It is reasonable for a server to store only the update records + as long as a system reboot or power failure will cause these update + records to be incorporated into the zone the next time the server is + started. It is also reasonable for the server to copy the entire + modified zone to nonvolatile storage after each update operation, + though this would have suboptimal performance for large zones. + + 3.6 - Zone Identity + + If the zone's SOA SERIAL is changed by an update operation, that + change must be in a positive direction (using modulo 2**32 arithmetic + as specified by [RFC1982]). Attempts to replace an SOA with one + whose SERIAL is less than the current one will be silently ignored by + the primary master server. + + If the zone's SOA's SERIAL is not changed as a result of an update + operation, then the server shall increment it automatically before + the SOA or any changed name or RR or RRset is included in any + response or transfer. The primary master server's implementor might + choose to autoincrement the SOA SERIAL if any of the following events + occurs: + + (1) Each update operation. + + (2) A name, RR or RRset in the zone has changed and has subsequently + been visible to a DNS client since the unincremented SOA was + visible to a DNS client, and the SOA is about to become visible + to a DNS client. + + (3) A configurable period of time has elapsed since the last update + operation. This period shall be less than or equal to one third + of the zone refresh time, and the default shall be the lesser of + that maximum and 300 seconds. + + + + +Vixie, et. al. Standards Track [Page 16] + +RFC 2136 DNS Update April 1997 + + + (4) A configurable number of updates has been applied since the last + SOA change. The default value for this configuration parameter + shall be one hundred (100). + + It is imperative that the zone's contents and the SOA's SERIAL be + tightly synchronized. If the zone appears to change, the SOA must + appear to change as well. + + 3.7 - Atomicity + + During the processing of an UPDATE transaction, the server must + ensure atomicity with respect to other (concurrent) UPDATE or QUERY + transactions. No two transactions can be processed concurrently if + either depends on the final results of the other; in particular, a + QUERY should not be able to retrieve RRsets which have been partially + modified by a concurrent UPDATE, and an UPDATE should not be able to + start from prerequisites that might not still hold at the completion + of some other concurrent UPDATE. Finally, if two UPDATE transactions + would modify the same names, RRs or RRsets, then such UPDATE + transactions must be serialized. + + 3.8 - Response + + At the end of UPDATE processing, a response code will be known. A + response message is generated by copying the ID and Opcode fields + from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT, + and ADCOUNT fields and associated sections, or placing zeros (0) in + the these "count" fields and not including any part of the original + update. The QR bit is set to one (1), and the response is sent back + to the requestor. If the requestor used UDP, then the response will + be sent to the requestor's source UDP port. If the requestor used + TCP, then the response will be sent back on the requestor's open TCP + connection. + +4 - Requestor Behaviour + + 4.1. From a requestor's point of view, any authoritative server for + the zone can appear to be able to process update requests, even + though only the primary master server is actually able to modify the + zone's master file. Requestors are expected to know the name of the + zone they intend to update and to know or be able to determine the + name servers for that zone. + + + + + + + + + +Vixie, et. al. Standards Track [Page 17] + +RFC 2136 DNS Update April 1997 + + + 4.2. If update ordering is desired, the requestor will need to know + the value of the existing SOA RR. Requestors who update the SOA RR + must update the SOA SERIAL field in a positive direction (as defined + by [RFC1982]) and also preserve the other SOA fields unless the + requestor's explicit intent is to change them. The SOA SERIAL field + must never be set to zero (0). + + 4.3. If the requestor has reasonable cause to believe that all of a + zone's servers will be equally reachable, then it should arrange to + try the primary master server (as given by the SOA MNAME field if + matched by some NS NSDNAME) first to avoid unnecessary forwarding + inside the slave servers. (Note that the primary master will in some + cases not be reachable by all requestors, due to firewalls or network + partitioning.) + + 4.4. Once the zone's name servers been found and possibly sorted so + that the ones more likely to be reachable and/or support the UPDATE + opcode are listed first, the requestor composes an UPDATE message of + the following form and sends it to the first name server on its list: + + ID: (new) + Opcode: UPDATE + Zone zcount: 1 + Zone zname: (zone name) + Zone zclass: (zone class) + Zone ztype: T_SOA + Prerequisite Section: (see previous text) + Update Section: (see previous text) + Additional Data Section: (empty) + + 4.5. If the requestor receives a response, and the response has an + RCODE other than SERVFAIL or NOTIMP, then the requestor returns an + appropriate response to its caller. + + 4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or + if no response is received within an implementation dependent timeout + period, or if an ICMP error is received indicating that the server's + port is unreachable, then the requestor will delete the unusable + server from its internal name server list and try the next one, + repeating until the name server list is empty. If the requestor runs + out of servers to try, an appropriate error will be returned to the + requestor's caller. + + + + + + + + + +Vixie, et. al. Standards Track [Page 18] + +RFC 2136 DNS Update April 1997 + + +5 - Duplicate Detection, Ordering and Mutual Exclusion + + 5.1. For correct operation, mechanisms may be needed to ensure + idempotence, order UPDATE requests and provide mutual exclusion. An + UPDATE message or response might be delivered zero times, one time, + or multiple times. Datagram duplication is of particular interest + since it covers the case of the so-called "replay attack" where a + correct request is duplicated maliciously by an intruder. + + 5.2. Multiple UPDATE requests or responses in transit might be + delivered in any order, due to network topology changes or load + balancing, or to multipath forwarding graphs wherein several slave + servers all forward to the primary master. In some cases, it might + be required that the earlier update not be applied after the later + update, where "earlier" and "later" are defined by an external time + base visible to some set of requestors, rather than by the order of + request receipt at the primary master. + + 5.3. A requestor can ensure transaction idempotence by explicitly + deleting some "marker RR" (rather than deleting the RRset of which it + is a part) and then adding a new "marker RR" with a different RDATA + field. The Prerequisite Section should specify that the original + "marker RR" must be present in order for this UPDATE message to be + accepted by the server. + + 5.4. If the request is duplicated by a network error, all duplicate + requests will fail since only the first will find the original + "marker RR" present and having its known previous value. The + decisions of whether to use such a "marker RR" and what RR to use are + left up to the application programmer, though one obvious choice is + the zone's SOA RR as described below. + + 5.5. Requestors can ensure update ordering by externally + synchronizing their use of successive values of the "marker RR." + Mutual exclusion can be addressed as a degenerate case, in that a + single succession of the "marker RR" is all that is needed. + + 5.6. A special case where update ordering and datagram duplication + intersect is when an RR validly changes to some new value and then + back to its previous value. Without a "marker RR" as described + above, this sequence of updates can leave the zone in an undefined + state if datagrams are duplicated. + + 5.7. To achieve an atomic multitransaction "read-modify-write" cycle, + a requestor could first retrieve the SOA RR, and build an UPDATE + message one of whose prerequisites was the old SOA RR. It would then + specify updates that would delete this SOA RR and add a new one with + an incremented SOA SERIAL, along with whatever actual prerequisites + + + +Vixie, et. al. Standards Track [Page 19] + +RFC 2136 DNS Update April 1997 + + + and updates were the object of the transaction. If the transaction + succeeds, the requestor knows that the RRs being changed were not + otherwise altered by any other requestor. + +6 - Forwarding + + When a zone slave forwards an UPDATE message upward toward the zone's + primary master server, it must allocate a new ID and prepare to enter + the role of "forwarding server," which is a requestor with respect to + the forward server. + + 6.1. The set of forward servers will be same as the set of servers + this zone slave would use as the source of AXFR or IXFR data. So, + while the original requestor might have used the zone's NS RRset to + locate its update server, a forwarder always forwards toward its + designated zone master servers. + + 6.2. If the original requestor used TCP, then the TCP connection from + the requestor is still open and the forwarder must use TCP to forward + the message. If the original requestor used UDP, the forwarder may + use either UDP or TCP to forward the message, at the whim of the + implementor. + + 6.3. It is reasonable for forward servers to be forwarders + themselves, if the AXFR dependency graph being followed is a deep one + involving firewalls and multiple connectivity realms. In most cases + the AXFR dependency graph will be shallow and the forward server will + be the primary master server. + + 6.4. The forwarder will not respond to its requestor until it + receives a response from its forward server. UPDATE transactions + involving forwarders are therefore time synchronized with respect to + the original requestor and the primary master server. + + 6.5. When there are multiple possible sources of AXFR data and + therefore multiple possible forward servers, a forwarder will use the + same fallback strategy with respect to connectivity or timeout errors + that it would use when performing an AXFR. This is implementation + dependent. + + 6.6. When a forwarder receives a response from a forward server, it + copies this response into a new response message, assigns its + requestor's ID to that message, and sends the response back to the + requestor. + + + + + + + +Vixie, et. al. Standards Track [Page 20] + +RFC 2136 DNS Update April 1997 + + +7 - Design, Implementation, Operation, and Protocol Notes + + Some of the principles which guided the design of this UPDATE + specification are as follows. Note that these are not part of the + formal specification and any disagreement between this section and + any other section of this document should be resolved in favour of + the other section. + + 7.1. Using metavalues for CLASS is possible only because all RRs in + the packet are assumed to be in the same zone, and CLASS is an + attribute of a zone rather than of an RRset. (It is for this reason + that the Zone Section is not optional.) + + 7.2. Since there are no data-present or data-absent errors possible + from processing the Update Section, any necessary data-present and + data- absent dependencies should be specified in the Prerequisite + Section. + + 7.3. The Additional Data Section can be used to supply a server with + out of zone glue that will be needed in referrals. For example, if + adding a new NS RR to HOME.VIX.COM specifying a nameserver called + NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional + Data Section. Servers can use this information or ignore it, at the + discretion of the implementor. We discourage caching this + information for use in subsequent DNS responses. + + 7.4. The Additional Data Section might be used if some of the RRs + later needed for Secure DNS Update are not actually zone updates, but + rather ancillary keys or signatures not intended to be stored in the + zone (as an update would be), yet necessary for validating the update + operation. + + 7.5. It is expected that in the absence of Secure DNS Update, a + server will only accept updates if they come from a source address + that has been statically configured in the server's description of a + primary master zone. DHCP servers would be likely candidates for + inclusion in this statically configured list. + + 7.6. It is not possible to create a zone using this protocol, since + there is no provision for a slave server to be told who its master + servers are. It is expected that this protocol will be extended in + the future to cover this case. Therefore, at this time, the addition + of SOA RRs is unsupported. For similar reasons, deletion of SOA RRs + is also unsupported. + + + + + + + +Vixie, et. al. Standards Track [Page 21] + +RFC 2136 DNS Update April 1997 + + + 7.7. The prerequisite for specifying that a name own at least one RR + differs semantically from QUERY, in that QUERY would return + <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at + this name, while UPDATE's prerequisite condition [Section 2.4.4] + would NOT be satisfied. + + 7.8. It is possible for a UDP response to be lost in transit and for + a request to be retried due to a timeout condition. In this case an + UPDATE that was successful the first time it was received by the + primary master might ultimately appear to have failed when the + response to a duplicate request is finally received by the requestor. + (This is because the original prerequisites may no longer be + satisfied after the update has been applied.) For this reason, + requestors who require an accurate response code must use TCP. + + 7.9. Because a requestor who requires an accurate response code will + initiate their UPDATE transaction using TCP, a forwarder who receives + a request via TCP must forward it using TCP. + + 7.10. Deferral of SOA SERIAL autoincrements is made possible so that + serial numbers can be conserved and wraparound at 2**32 can be made + an infrequent occurance. Visible (to DNS clients) SOA SERIALs need + to differ if the zone differs. Note that the Authority Section SOA + in a QUERY response is a form of visibility, for the purposes of this + prerequisite. + + 7.11. A zone's SOA SERIAL should never be set to zero (0) due to + interoperability problems with some older but widely installed + implementations of DNS. When incrementing an SOA SERIAL, if the + result of the increment is zero (0) (as will be true when wrapping + around 2**32), it is necessary to increment it again or set it to one + (1). See [RFC1982] for more detail on this subject. + + 7.12. Due to the TTL minimalization necessary when caching an RRset, + it is recommended that all TTLs in an RRset be set to the same value. + While the DNS Message Format permits variant TTLs to exist in the + same RRset, and this variance can exist inside a zone, such variance + will have counterintuitive results and its use is discouraged. + + 7.13. Zone cut management presents some obscure corner cases to the + add and delete operations in the Update Section. It is possible to + delete an NS RR as long as it is not the last NS RR at the root of a + zone. If deleting all RRs from a name, SOA and NS RRs at the root of + a zone are unaffected. If deleting RRsets, it is not possible to + delete either SOA or NS RRsets at the top of a zone. An attempt to + add an SOA will be treated as a replace operation if an SOA already + exists, or as a no-op if the SOA would be new. + + + + +Vixie, et. al. Standards Track [Page 22] + +RFC 2136 DNS Update April 1997 + + + 7.14. No semantic checking is required in the primary master server + when adding new RRs. Therefore a requestor can cause CNAME or NS or + any other kind of RR to be added even if their target name does not + exist or does not have the proper RRsets to make the original RR + useful. Primary master servers that DO implement this kind of + checking should take great care to avoid out-of-zone dependencies + (whose veracity cannot be authoritatively checked) and should + implement all such checking during the prescan phase. + + 7.15. Nonterminal or wildcard CNAMEs are not well specified by + [RFC1035] and their use will probably lead to unpredictable results. + Their use is discouraged. + + 7.16. Empty nonterminals (nodes with children but no RRs of their + own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response + to a query of any type for that name. There is no provision for + empty terminal nodes -- so if all RRs of a terminal node are deleted, + the name is no longer in use, and queries of any type for that name + will result in an NXDOMAIN response. + + 7.17. In a deep AXFR dependency graph, it has not historically been + an error for slaves to depend mutually upon each other. This + configuration has been used to enable a zone to flow from the primary + master to all slaves even though not all slaves have continuous + connectivity to the primary master. UPDATE's use of the AXFR + dependency graph for forwarding prohibits this kind of dependency + loop, since UPDATE forwarding has no loop detection analagous to the + SOA SERIAL pretest used by AXFR. + + 7.18. Previously existing names which are occluded by a new zone cut + are still considered part of the parent zone, for the purposes of + zone transfers, even though queries for such names will be referred + to the new subzone's servers. If a zone cut is removed, all parent + zone names that were occluded by it will again become visible to + queries. (This is a clarification of [RFC1034].) + + 7.19. If a server is authoritative for both a zone and its child, + then queries for names at the zone cut between them will be answered + authoritatively using only data from the child zone. (This is a + clarification of [RFC1034].) + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 23] + +RFC 2136 DNS Update April 1997 + + + 7.20. Update ordering using the SOA RR is problematic since there is + no way to know which of a zone's NS RRs represents the primary + master, and the zone slaves can be out of date if their SOA.REFRESH + timers have not elapsed since the last time the zone was changed on + the primary master. We recommend that a zone needing ordered updates + use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see + [RFC1995]), and that a client receiving a prerequisite error while + attempting an ordered update simply retry after a random delay period + to allow the zone to settle. + +8 - Security Considerations + + 8.1. In the absence of [RFC2137] or equivilent technology, the + protocol described by this document makes it possible for anyone who + can reach an authoritative name server to alter the contents of any + zones on that server. This is a serious increase in vulnerability + from the current technology. Therefore it is very strongly + recommended that the protocols described in this document not be used + without [RFC2137] or other equivalently strong security measures, + e.g. IPsec. + + 8.2. A denial of service attack can be launched by flooding an update + forwarder with TCP sessions containing updates that the primary + master server will ultimately refuse due to permission problems. + This arises due to the requirement that an update forwarder receiving + a request via TCP use a synchronous TCP session for its forwarding + operation. The connection management mechanisms of [RFC1035 4.2.2] + are sufficient to prevent large scale damage from such an attack, but + not to prevent some queries from going unanswered during the attack. + +Acknowledgements + + We would like to thank the IETF DNSIND working group for their input + and assistance, in particular, Rob Austein, Randy Bush, Donald + Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz. Special + thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this + document. + + + + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 24] + +RFC 2136 DNS Update April 1997 + + +References + + [RFC1035] + Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + [RFC1982] + Elz, R., "Serial Number Arithmetic", RFC 1982, University of + Melbourne, August 1996. + + [RFC1995] + Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute + of Technology, August 1996. + + [RFC1996] + Vixie, P., "A Mechanism for Prompt Notification of Zone Changes", + RFC 1996, Internet Software Consortium, August 1996. + + [RFC2065] + Eastlake, D., and C. Kaufman, "Domain Name System Protocol + Security Extensions", RFC 2065, January 1997. + + [RFC2137] + Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. + +Authors' Addresses + + Yakov Rekhter + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134-1706 + + Phone: +1 914 528 0090 + EMail: yakov@cisco.com + + + Susan Thomson + Bellcore + 445 South Street + Morristown, NJ 07960 + + Phone: +1 201 829 4514 + EMail: set@thumper.bellcore.com + + + + + + +Vixie, et. al. Standards Track [Page 25] + +RFC 2136 DNS Update April 1997 + + + Jim Bound + Digital Equipment Corp. + 110 Spitbrook Rd ZK3-3/U14 + Nashua, NH 03062-2698 + + Phone: +1 603 881 0400 + EMail: bound@zk3.dec.com + + + Paul Vixie + Internet Software Consortium + Star Route Box 159A + Woodside, CA 94062 + + Phone: +1 415 747 0204 + EMail: paul@vix.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 26] + diff --git a/Documentation/en/rfc/rfc2137.txt b/Documentation/en/rfc/rfc2137.txt new file mode 100644 index 00000000..ceb3613d --- /dev/null +++ b/Documentation/en/rfc/rfc2137.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 2137 CyberCash, Inc. +Updates: 1035 April 1997 +Category: Standards Track + + + Secure Domain Name System Dynamic Update + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + Domain Name System (DNS) protocol extensions have been defined to + authenticate the data in DNS and provide key distribution services + [RFC2065]. DNS Dynamic Update operations have also been defined + [RFC2136], but without a detailed description of security for the + update operation. This memo describes how to use DNSSEC digital + signatures covering requests and data to secure updates and restrict + updates to those authorized to perform them as indicated by the + updater's possession of cryptographic keys. + +Acknowledgements + + The contributions of the following persons (who are listed in + alphabetic order) to this memo are gratefully acknowledged: + + Olafur Gudmundsson (ogud@tis.com> + Charlie Kaufman <Charlie_Kaufman@iris.com> + Stuart Kwan <skwan@microsoft.com> + Edward Lewis <lewis@tis.com> + +Table of Contents + + 1. Introduction............................................2 + 1.1 Overview of DNS Dynamic Update.........................2 + 1.2 Overview of DNS Security...............................2 + 2. Two Basic Modes.........................................3 + 3. Keys....................................................5 + 3.1 Update Keys............................................6 + 3.1.1 Update Key Name Scope................................6 + 3.1.2 Update Key Class Scope...............................6 + 3.1.3 Update Key Signatory Field...........................6 + + + +Eastlake Standards Track [Page 1] + +RFC 2137 SDNSDU April 1997 + + + 3.2 Zone Keys and Update Modes.............................8 + 3.3 Wildcard Key Punch Through.............................9 + 4. Update Signatures.......................................9 + 4.1 Update Request Signatures..............................9 + 4.2 Update Data Signatures................................10 + 5. Security Considerations................................10 + References................................................10 + Author's Address..........................................11 + +1. Introduction + + Dynamic update operations have been defined for the Domain Name + System (DNS) in RFC 2136, but without a detailed description of + security for those updates. Means of securing the DNS and using it + for key distribution have been defined in RFC 2065. + + This memo proposes techniques based on the defined DNS security + mechanisms to authenticate DNS updates. + + Familiarity with the DNS system [RFC 1034, 1035] is assumed. + Familiarity with the DNS security and dynamic update proposals will + be helpful. + +1.1 Overview of DNS Dynamic Update + + DNS dynamic update defines a new DNS opcode, new DNS request and + response structure if that opcode is used, and new error codes. An + update can specify complex combinations of deletion and insertion + (with or without pre-existence testing) of resource records (RRs) + with one or more owner names; however, all testing and changes for + any particular DNS update request are restricted to a single zone. + Updates occur at the primary server for a zone. + + The primary server for a secure dynamic zone must increment the zone + SOA serial number when an update occurs or the next time the SOA is + retrieved if one or more updates have occurred since the previous SOA + retrieval and the updates themselves did not update the SOA. + +1.2 Overview of DNS Security + + DNS security authenticates data in the DNS by also storing digital + signatures in the DNS as SIG resource records (RRs). A SIG RR + provides a digital signature on the set of all RRs with the same + owner name and class as the SIG and whose type is the type covered by + the SIG. The SIG RR cryptographically binds the covered RR set to + the signer, time signed, signature expiration date, etc. There are + one or more keys associated with every secure zone and all data in + the secure zone is signed either by a zone key or by a dynamic update + + + +Eastlake Standards Track [Page 2] + +RFC 2137 SDNSDU April 1997 + + + key tracing its authority to a zone key. + + DNS security also defines transaction SIGs and request SIGs. + Transaction SIGs appear at the end of a response. Transaction SIGs + authenticate the response and bind it to the corresponding request + with the key of the host where the responding DNS server is. Request + SIGs appear at the end of a request and authenticate the request with + the key of the submitting entity. + + Request SIGs are the primary means of authenticating update requests. + + DNS security also permits the storage of public keys in the DNS via + KEY RRs. These KEY RRs are also, of course, authenticated by SIG + RRs. KEY RRs for zones are stored in their superzone and subzone + servers, if any, so that the secure DNS tree of zones can be + traversed by a security aware resolver. + +2. Two Basic Modes + + A dynamic secure zone is any secure DNS zone containing one or more + KEY RRs that can authorize dynamic updates, i.e., entity or user KEY + RRs with the signatory field non-zero, and whose zone KEY RR + signatory field indicates that updates are implemented. There are two + basic modes of dynamic secure zone which relate to the update + strategy, mode A and mode B. A summary comparison table is given + below and then each mode is described. + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 3] + +RFC 2137 SDNSDU April 1997 + + + SUMMARY OF DYNAMIC SECURE ZONE MODES + + CRITERIA: | MODE A | MODE B + =========================+====================+=================== + Definition: | Zone Key Off line | Zone Key On line + =========================+====================+=================== + Server Workload | Low | High + -------------------------+--------------------+------------------- + Static Data Security | Very High | Medium-High + -------------------------+--------------------+------------------- + Dynamic Data Security | Medium | Medium-High + -------------------------+--------------------+------------------- + Key Restrictions | Fine grain | Coarse grain + -------------------------+--------------------+------------------- + Dynamic Data Temporality | Transient | Permanent + -------------------------+--------------------+------------------- + Dynamic Key Rollover | No | Yes + -------------------------+--------------------+------------------- + + For mode A, the zone owner key and static zone master file are always + kept off-line for maximum security of the static zone contents. + + As a consequence, any dynamicly added or changed RRs are signed in + the secure zone by their authorizing dynamic update key and they are + backed up, along with this SIG RR, in a separate online dynamic + master file. In this type of zone, server computation is minimized + since the server need only check signatures on the update data and + request, which have already been signed by the updater, generally a + much faster operation than signing data. However, the AXFR SIG and + NXT RRs which covers the zone under the zone key will not cover + dynamically added data. Thus, for type A dynamic secure zones, zone + transfer security is not automatically provided for dynamically added + RRs, where they could be omitted, and authentication is not provided + for the server denial of the existence of a dynamically added type. + Because the dynamicly added RRs retain their update KEY signed SIG, + finer grained control of updates can be implemented via bits in the + KEY RR signatory field. Because dynamic data is only stored in the + online dynamic master file and only authenticated by dynamic keys + which expire, updates are transient in nature. Key rollover for an + entity that can authorize dynamic updates is more cumbersome since + the authority of their key must be traceable to a zone key and so, in + general, they must securely communicate a new key to the zone + authority for manual transfer to the off line static master file. + NOTE: for this mode the zone SOA must be signed by a dynamic update + key and that private key must be kept on line so that the SOA can be + changed for updates. + + + + + +Eastlake Standards Track [Page 4] + +RFC 2137 SDNSDU April 1997 + + + For mode B, the zone owner key and master file are kept on-line at + the zone primary server. When authenticated updates succeed, SIGs + under the zone key for the resulting data (including the possible NXT + type bit map changes) are calculated and these SIG (and possible NXT) + changes are entered into the zone and the unified on-line master + file. (The zone transfer AXFR SIG may be recalculated for each + update or on demand when a zone transfer is requested and it is out + of date.) + + As a consequence, this mode requires considerably more computational + effort on the part of the server as the public/private keys are + generally arranged so that signing (calculating a SIG) is more effort + than verifying a signature. The security of static data in the zone + is decreased because the ultimate state of the static data being + served and the ultimate zone authority private key are all on-line on + the net. This means that if the primary server is subverted, false + data could be authenticated to secondaries and other + servers/resolvers. On the other hand, this mode of operation means + that data added dynamically is more secure than in mode A. Dynamic + data will be covered by the AXFR SIG and thus always protected during + zone transfers and will be included in NXT RRs so that it can be + falsely denied by a server only to the same extent that static data + can (i.e., if it is within a wild card scope). Because the zone key + is used to sign all the zone data, the information as to who + originated the current state of dynamic RR sets is lost, making + unavailable the effects of some of the update control bits in the KEY + RR signatory field. In addition, the incorporation of the updates + into the primary master file and their authentication by the zone key + makes then permanent in nature. Maintaining the zone key on-line + also means that dynamic update keys which are signed by the zone key + can be dynamically updated since the zone key is available to + dynamically sign new values. + + NOTE: The Mode A / Mode B distinction only effects the validation + and performance of update requests. It has no effect on retrievals. + One reasonable operational scheme may be to keep a mostly static main + zone operating in Mode A and have one or more dynamic subzones + operating in Mode B. + +3. Keys + + Dynamic update requests depend on update keys as described in section + 3.1 below. In addition, the zone secure dynamic update mode and + availability of some options is indicated in the zone key. Finally, + a special rule is used in searching for KEYs to validate updates as + described in section 3.3. + + + + + +Eastlake Standards Track [Page 5] + +RFC 2137 SDNSDU April 1997 + + +3.1 Update Keys + + All update requests to a secure zone must include signatures by one + or more key(s) that together can authorize that update. In order for + the Domain Name System (DNS) server receiving the request to confirm + this, the key or keys must be available to and authenticated by that + server as a specially flagged KEY Resource Record. + + The scope of authority of such keys is indicated by their KEY RR + owner name, class, and signatory field flags as described below. In + addition, such KEY RRs must be entity or user keys and not have the + authentication use prohibited bit on. All parts of the actual update + must be within the scope of at least one of the keys used for a + request SIG on the update request as described in section 4. + +3.1.1 Update Key Name Scope + + The owner name of any update authorizing KEY RR must (1) be the same + as the owner name of any RRs being added or deleted or (2) a wildcard + name including within its extended scope (see section 3.3) the name + of any RRs being added or deleted and those RRs must be in the same + zone. + +3.1.2 Update Key Class Scope + + The class of any update authorizing KEY RR must be the same as the + class of any RR's being added or deleted. + +3.1.3 Update Key Signatory Field + + The four bit "signatory field" (see RFC 2065) of any update + authorizing KEY RR must be non-zero. The bits have the meanings + described below for non-zone keys (see section 3.2 for zone type + keys). + + UPDATE KEY RR SIGNATORY FIELD BITS + + 0 1 2 3 + +-----------+-----------+-----------+-----------+ + | zone | strong | unique | general | + +-----------+-----------+-----------+-----------+ + + Bit 0, zone control - If nonzero, this key is authorized to attach, + detach, and move zones by creating and deleting NS, glue A, and + zone KEY RR(s). If zero, the key can not authorize any update + that would effect such RRs. This bit is meaningful for both + type A and type B dynamic secure zones. + + + + +Eastlake Standards Track [Page 6] + +RFC 2137 SDNSDU April 1997 + + + NOTE: do not confuse the "zone" signatory field bit with the + "zone" key type bit. + + Bit 1, strong update - If nonzero, this key is authorized to add and + delete RRs even if there are other RRs with the same owner name + and class that are authenticated by a SIG signed with a + different dynamic update KEY. If zero, the key can only + authorize updates where any existing RRs of the same owner and + class are authenticated by a SIG using the same key. This bit + is meaningful only for type A dynamic zones and is ignored in + type B dynamic zones. + + Keeping this bit zero on multiple KEY RRs with the same or + nested wild card owner names permits multiple entities to exist + that can create and delete names but can not effect RRs with + different owner names from any they created. In effect, this + creates two levels of dynamic update key, strong and weak, where + weak keys are limited in interfering with each other but a + strong key can interfere with any weak keys or other strong + keys. + + Bit 2, unique name update - If nonzero, this key is authorized to add + and update RRs for only a single owner name. If there already + exist RRs with one or more names signed by this key, they may be + updated but no new name created until the number of existing + names is reduced to zero. This bit is meaningful only for mode + A dynamic zones and is ignored in mode B dynamic zones. This bit + is meaningful only if the owner name is a wildcard. (Any + dynamic update KEY with a non-wildcard name is, in effect, a + unique name update key.) + + This bit can be used to restrict a KEY from flooding a zone with + new names. In conjunction with a local administratively imposed + limit on the number of dynamic RRs with a particular name, it + can completely restrict a KEY from flooding a zone with RRs. + + Bit 3, general update - The general update signatory field bit has no + special meaning. If the other three bits are all zero, it must + be one so that the field is non-zero to designate that the key + is an update key. The meaning of all values of the signatory + field with the general bit and one or more other signatory field + bits on is reserved. + + All the signatory bit update authorizations described above only + apply if the update is within the name and class scope as per + sections 3.1.1 and 3.1.2. + + + + + +Eastlake Standards Track [Page 7] + +RFC 2137 SDNSDU April 1997 + + +3.2 Zone Keys and Update Modes + + Zone type keys are automatically authorized to sign anything in their + zone, of course, regardless of the value of their signatory field. + For zone keys, the signatory field bits have different means than + they they do for update keys, as shown below. The signatory field + MUST be zero if dynamic update is not supported for a zone and MUST + be non-zero if it is. + + ZONE KEY RR SIGNATORY FIELD BITS + + 0 1 2 3 + +-----------+-----------+-----------+-----------+ + | mode | strong | unique | general | + +-----------+-----------+-----------+-----------+ + + Bit 0, mode - This bit indicates the update mode for this zone. Zero + indicates mode A while a one indicates mode B. + + Bit 1, strong update - If nonzero, this indicates that the "strong" + key feature described in section 3.1.3 above is implemented and + enabled for this secure zone. If zero, the feature is not + available. Has no effect if the zone is a mode B secure update + zone. + + Bit 2, unique name update - If nonzero, this indicates that the + "unique name" feature described in section 3.1.3 above is + implemented and enabled for this secure zone. If zero, this + feature is not available. Has no effect if the zone is a mode B + secure update zone. + + Bit 3, general - This bit has no special meeting. If dynamic update + for a zone is supported and the other bits in the zone key + signatory field are zero, it must be a one. The meaning of zone + keys where the signatory field has the general bit and one or + more other bits on is reserved. + + If there are multiple dynamic update KEY RRs for a zone and zone + policy is in transition, they might have different non-zero signatory + fields. In that case, strong and unique name restrictions must be + enforced as long as there is a non-expired zone key being advertised + that indicates mode A with the strong or unique name bit on + respectively. Mode B updates MUST be supported as long as there is a + non-expired zone key that indicates mode B. Mode A updates may be + treated as mode B updates at server option if non-expired zone keys + indicate that both are supported. + + + + + +Eastlake Standards Track [Page 8] + +RFC 2137 SDNSDU April 1997 + + + A server that will be executing update operations on a zone, that is, + the primary master server, MUST not advertize a zone key that will + attract requests for a mode or features that it can not support. + +3.3 Wildcard Key Punch Through + + Just as a zone key is valid throughout the entire zone, update keys + with wildcard names are valid throughout their extended scope, within + the zone. That is, they remain valid for any name that would match + them, even existing specific names within their apparent scope. + + If this were not so, then whenever a name within a wildcard scope was + created by dynamic update, it would be necessary to first create a + copy of the KEY RR with this name, because otherwise the existence of + the more specific name would hide the authorizing KEY RR and would + make later updates impossible. An updater could create such a KEY RR + but could not zone sign it with their authorizing signer. They would + have to sign it with the same key using the wildcard name as signer. + Thus in creating, for example, one hundred type A RRs authorized by a + *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100 + KEYs, and 200 SIGs would have to be created as opposed to merely 100 + As and 100 SIGs with key punch through. + +4. Update Signatures + + Two kinds of signatures can appear in updates. Request signatures, + which are always required, cover the entire request and authenticate + the DNS header, including opcode, counts, etc., as well as the data. + Data signatures, on the other hand, appear only among the RRs to be + added and are only required for mode A operation. These two types of + signatures are described further below. + +4.1 Update Request Signatures + + An update can effect multiple owner names in a zone. It may be that + these different names are covered by different dynamic update keys. + For every owner name effected, the updater must know a private key + valid for that name (and the zone's class) and must prove this by + appending request SIG RRs under each such key. + + As specified in RFC 2065, a request signature is a SIG RR occurring + at the end of a request with a type covered field of zero. For an + update, request signatures occur in the Additional information + section. Each request SIG signs the entire request, including DNS + header, but excluding any other request SIG(s) and with the ARCOUNT + in the DNS header set to what it wold be without the request SIGs. + + + + + +Eastlake Standards Track [Page 9] + +RFC 2137 SDNSDU April 1997 + + +4.2 Update Data Signatures + + Mode A dynamic secure zones require that the update requester provide + SIG RRs that will authenticate the after update state of all RR sets + that are changed by the update and are non-empty after the update. + These SIG RRs appear in the request as RRs to be added and the + request must delete any previous data SIG RRs that are invalidated by + the request. + + In Mode B dynamic secure zones, all zone data is authenticated by + zone key SIG RRs. In this case, data signatures need not be included + with the update. A resolver can determine which mode an updatable + secure zone is using by examining the signatory field bits of the + zone KEY RR (see section 3.2). + +5. Security Considerations + + Any zone permitting dynamic updates is inherently less secure than a + static secure zone maintained off line as recommended in RFC 2065. If + nothing else, secure dynamic update requires on line change to and + re-signing of the zone SOA resource record (RR) to increase the SOA + serial number. This means that compromise of the primary server host + could lead to arbitrary serial number changes. + + Isolation of dynamic RRs to separate zones from those holding most + static RRs can limit the damage that could occur from breach of a + dynamic zone's security. + +References + + [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, CyberCash, Iris, January 1997. + + [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + + + + + + + + +Eastlake Standards Track [Page 10] + +RFC 2137 SDNSDU April 1997 + + +Author's Address + + Donald E. Eastlake, 3rd + CyberCash, Inc. + 318 Acton Street + Carlisle, MA 01741 USA + + Phone: +1 508-287-4877 + +1 508-371-7148 (fax) + +1 703-620-4200 (main office, Reston, Virginia, USA) + EMail: dee@cybercash.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 11] + diff --git a/Documentation/en/rfc/rfc2181.txt b/Documentation/en/rfc/rfc2181.txt new file mode 100644 index 00000000..7899e1cb --- /dev/null +++ b/Documentation/en/rfc/rfc2181.txt @@ -0,0 +1,842 @@ + + + + + + +Network Working Group R. Elz +Request for Comments: 2181 University of Melbourne +Updates: 1034, 1035, 1123 R. Bush +Category: Standards Track RGnet, Inc. + July 1997 + + + Clarifications to the DNS Specification + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This document considers some areas that have been identified as + problems with the specification of the Domain Name System, and + proposes remedies for the defects identified. Eight separate issues + are considered: + + + IP packet header address usage from multi-homed servers, + + TTLs in sets of records with the same name, class, and type, + + correct handling of zone cuts, + + three minor issues concerning SOA records and their use, + + the precise definition of the Time to Live (TTL) + + Use of the TC (truncated) header bit + + the issue of what is an authoritative, or canonical, name, + + and the issue of what makes a valid DNS label. + + The first six of these are areas where the correct behaviour has been + somewhat unclear, we seek to rectify that. The other two are already + adequately specified, however the specifications seem to be sometimes + ignored. We seek to reinforce the existing specifications. + + + + + + + + + + + + + + +Elz & Bush Standards Track [Page 1] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + + +Contents + + 1 Abstract ................................................... 1 + 2 Introduction ............................................... 2 + 3 Terminology ................................................ 3 + 4 Server Reply Source Address Selection ...................... 3 + 5 Resource Record Sets ....................................... 4 + 6 Zone Cuts .................................................. 8 + 7 SOA RRs .................................................... 10 + 8 Time to Live (TTL) ......................................... 10 + 9 The TC (truncated) header bit .............................. 11 + 10 Naming issues .............................................. 11 + 11 Name syntax ................................................ 13 + 12 Security Considerations .................................... 14 + 13 References ................................................. 14 + 14 Acknowledgements ........................................... 15 + 15 Authors' Addresses ......................................... 15 + + + + +2. Introduction + + Several problem areas in the Domain Name System specification + [RFC1034, RFC1035] have been noted through the years [RFC1123]. This + document addresses several additional problem areas. The issues here + are independent. Those issues are the question of which source + address a multi-homed DNS server should use when replying to a query, + the issue of differing TTLs for DNS records with the same label, + class and type, and the issue of canonical names, what they are, how + CNAME records relate, what names are legal in what parts of the DNS, + and what is the valid syntax of a DNS name. + + Clarifications to the DNS specification to avoid these problems are + made in this memo. A minor ambiguity in RFC1034 concerned with SOA + records is also corrected, as is one in the definition of the TTL + (Time To Live) and some possible confusion in use of the TC bit. + + + + + + + + + + + + +Elz & Bush Standards Track [Page 2] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + +3. Terminology + + This memo does not use the oft used expressions MUST, SHOULD, MAY, or + their negative forms. In some sections it may seem that a + specification is worded mildly, and hence some may infer that the + specification is optional. That is not correct. Anywhere that this + memo suggests that some action should be carried out, or must be + carried out, or that some behaviour is acceptable, or not, that is to + be considered as a fundamental aspect of this specification, + regardless of the specific words used. If some behaviour or action + is truly optional, that will be clearly specified by the text. + +4. Server Reply Source Address Selection + + Most, if not all, DNS clients, expect the address from which a reply + is received to be the same address as that to which the query + eliciting the reply was sent. This is true for servers acting as + clients for the purposes of recursive query resolution, as well as + simple resolver clients. The address, along with the identifier (ID) + in the reply is used for disambiguating replies, and filtering + spurious responses. This may, or may not, have been intended when + the DNS was designed, but is now a fact of life. + + Some multi-homed hosts running DNS servers generate a reply using a + source address that is not the same as the destination address from + the client's request packet. Such replies will be discarded by the + client because the source address of the reply does not match that of + a host to which the client sent the original request. That is, it + appears to be an unsolicited response. + +4.1. UDP Source Address Selection + + To avoid these problems, servers when responding to queries using UDP + must cause the reply to be sent with the source address field in the + IP header set to the address that was in the destination address + field of the IP header of the packet containing the query causing the + response. If this would cause the response to be sent from an IP + address that is not permitted for this purpose, then the response may + be sent from any legal IP address allocated to the server. That + address should be chosen to maximise the possibility that the client + will be able to use it for further queries. Servers configured in + such a way that not all their addresses are equally reachable from + all potential clients need take particular care when responding to + queries sent to anycast, multicast, or similar, addresses. + + + + + + + +Elz & Bush Standards Track [Page 3] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + +4.2. Port Number Selection + + Replies to all queries must be directed to the port from which they + were sent. When queries are received via TCP this is an inherent + part of the transport protocol. For queries received by UDP the + server must take note of the source port and use that as the + destination port in the response. Replies should always be sent from + the port to which they were directed. Except in extraordinary + circumstances, this will be the well known port assigned for DNS + queries [RFC1700]. + +5. Resource Record Sets + + Each DNS Resource Record (RR) has a label, class, type, and data. It + is meaningless for two records to ever have label, class, type and + data all equal - servers should suppress such duplicates if + encountered. It is however possible for most record types to exist + with the same label, class and type, but with different data. Such a + group of records is hereby defined to be a Resource Record Set + (RRSet). + +5.1. Sending RRs from an RRSet + + A query for a specific (or non-specific) label, class, and type, will + always return all records in the associated RRSet - whether that be + one or more RRs. The response must be marked as "truncated" if the + entire RRSet will not fit in the response. + +5.2. TTLs of RRs in an RRSet + + Resource Records also have a time to live (TTL). It is possible for + the RRs in an RRSet to have different TTLs. No uses for this have + been found that cannot be better accomplished in other ways. This + can, however, cause partial replies (not marked "truncated") from a + caching server, where the TTLs for some but not all the RRs in the + RRSet have expired. + + Consequently the use of differing TTLs in an RRSet is hereby + deprecated, the TTLs of all RRs in an RRSet must be the same. + + Should a client receive a response containing RRs from an RRSet with + differing TTLs, it should treat this as an error. If the RRSet + concerned is from a non-authoritative source for this data, the + client should simply ignore the RRSet, and if the values were + required, seek to acquire them from an authoritative source. Clients + that are configured to send all queries to one, or more, particular + servers should treat those servers as authoritative for this purpose. + Should an authoritative source send such a malformed RRSet, the + + + +Elz & Bush Standards Track [Page 4] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + client should treat the RRs for all purposes as if all TTLs in the + RRSet had been set to the value of the lowest TTL in the RRSet. In + no case may a server send an RRSet with TTLs not all equal. + +5.3. DNSSEC Special Cases + + Two of the record types added by DNS Security (DNSSEC) [RFC2065] + require special attention when considering the formation of Resource + Record Sets. Those are the SIG and NXT records. It should be noted + that DNS Security is still very new, and there is, as yet, little + experience with it. Readers should be prepared for the information + related to DNSSEC contained in this document to become outdated as + the DNS Security specification matures. + +5.3.1. SIG records and RRSets + + A SIG record provides signature (validation) data for another RRSet + in the DNS. Where a zone has been signed, every RRSet in the zone + will have had a SIG record associated with it. The data type of the + RRSet is included in the data of the SIG RR, to indicate with which + particular RRSet this SIG record is associated. Were the rules above + applied, whenever a SIG record was included with a response to + validate that response, the SIG records for all other RRSets + associated with the appropriate node would also need to be included. + In some cases, this could be a very large number of records, not + helped by their being rather large RRs. + + Thus, it is specifically permitted for the authority section to + contain only those SIG RRs with the "type covered" field equal to the + type field of an answer being returned. However, where SIG records + are being returned in the answer section, in response to a query for + SIG records, or a query for all records associated with a name + (type=ANY) the entire SIG RRSet must be included, as for any other RR + type. + + Servers that receive responses containing SIG records in the + authority section, or (probably incorrectly) as additional data, must + understand that the entire RRSet has almost certainly not been + included. Thus, they must not cache that SIG record in a way that + would permit it to be returned should a query for SIG records be + received at that server. RFC2065 actually requires that SIG queries + be directed only to authoritative servers to avoid the problems that + could be caused here, and while servers exist that do not understand + the special properties of SIG records, this will remain necessary. + However, careful design of SIG record processing in new + implementations should permit this restriction to be relaxed in the + future, so resolvers do not need to treat SIG record queries + specially. + + + +Elz & Bush Standards Track [Page 5] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + It has been occasionally stated that a received request for a SIG + record should be forwarded to an authoritative server, rather than + being answered from data in the cache. This is not necessary - a + server that has the knowledge of SIG as a special case for processing + this way would be better to correctly cache SIG records, taking into + account their characteristics. Then the server can determine when it + is safe to reply from the cache, and when the answer is not available + and the query must be forwarded. + +5.3.2. NXT RRs + + Next Resource Records (NXT) are even more peculiar. There will only + ever be one NXT record in a zone for a particular label, so + superficially, the RRSet problem is trivial. However, at a zone cut, + both the parent zone, and the child zone (superzone and subzone in + RFC2065 terminology) will have NXT records for the same name. Those + two NXT records do not form an RRSet, even where both zones are + housed at the same server. NXT RRSets always contain just a single + RR. Where both NXT records are visible, two RRSets exist. However, + servers are not required to treat this as a special case when + receiving NXT records in a response. They may elect to notice the + existence of two different NXT RRSets, and treat that as they would + two different RRSets of any other type. That is, cache one, and + ignore the other. Security aware servers will need to correctly + process the NXT record in the received response though. + +5.4. Receiving RRSets + + Servers must never merge RRs from a response with RRs in their cache + to form an RRSet. If a response contains data that would form an + RRSet with data in a server's cache the server must either ignore the + RRs in the response, or discard the entire RRSet currently in the + cache, as appropriate. Consequently the issue of TTLs varying + between the cache and a response does not cause concern, one will be + ignored. That is, one of the data sets is always incorrect if the + data from an answer differs from the data in the cache. The + challenge for the server is to determine which of the data sets is + correct, if one is, and retain that, while ignoring the other. Note + that if a server receives an answer containing an RRSet that is + identical to that in its cache, with the possible exception of the + TTL value, it may, optionally, update the TTL in its cache with the + TTL of the received answer. It should do this if the received answer + would be considered more authoritative (as discussed in the next + section) than the previously cached answer. + + + + + + + +Elz & Bush Standards Track [Page 6] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + +5.4.1. Ranking data + + When considering whether to accept an RRSet in a reply, or retain an + RRSet already in its cache instead, a server should consider the + relative likely trustworthiness of the various data. An + authoritative answer from a reply should replace cached data that had + been obtained from additional information in an earlier reply. + However additional information from a reply will be ignored if the + cache contains data from an authoritative answer or a zone file. + + The accuracy of data available is assumed from its source. + Trustworthiness shall be, in order from most to least: + + + Data from a primary zone file, other than glue data, + + Data from a zone transfer, other than glue, + + The authoritative data included in the answer section of an + authoritative reply. + + Data from the authority section of an authoritative answer, + + Glue from a primary zone, or glue from a zone transfer, + + Data from the answer section of a non-authoritative answer, and + non-authoritative data from the answer section of authoritative + answers, + + Additional information from an authoritative answer, + Data from the authority section of a non-authoritative answer, + Additional information from non-authoritative answers. + + Note that the answer section of an authoritative answer normally + contains only authoritative data. However when the name sought is an + alias (see section 10.1.1) only the record describing that alias is + necessarily authoritative. Clients should assume that other records + may have come from the server's cache. Where authoritative answers + are required, the client should query again, using the canonical name + associated with the alias. + + Unauthenticated RRs received and cached from the least trustworthy of + those groupings, that is data from the additional data section, and + data from the authority section of a non-authoritative answer, should + not be cached in such a way that they would ever be returned as + answers to a received query. They may be returned as additional + information where appropriate. Ignoring this would allow the + trustworthiness of relatively untrustworthy data to be increased + without cause or excuse. + + When DNS security [RFC2065] is in use, and an authenticated reply has + been received and verified, the data thus authenticated shall be + considered more trustworthy than unauthenticated data of the same + type. Note that throughout this document, "authoritative" means a + reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY + + + +Elz & Bush Standards Track [Page 7] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + records to determine the authenticity of data, the AA bit is almost + irrelevant. However DNSSEC aware servers must still correctly set + the AA bit in responses to enable correct operation with servers that + are not security aware (almost all currently). + + Note that, glue excluded, it is impossible for data from two + correctly configured primary zone files, two correctly configured + secondary zones (data from zone transfers) or data from correctly + configured primary and secondary zones to ever conflict. Where glue + for the same name exists in multiple zones, and differs in value, the + nameserver should select data from a primary zone file in preference + to secondary, but otherwise may choose any single set of such data. + Choosing that which appears to come from a source nearer the + authoritative data source may make sense where that can be + determined. Choosing primary data over secondary allows the source + of incorrect glue data to be discovered more readily, when a problem + with such data exists. Where a server can detect from two zone files + that one or more are incorrectly configured, so as to create + conflicts, it should refuse to load the zones determined to be + erroneous, and issue suitable diagnostics. + + "Glue" above includes any record in a zone file that is not properly + part of that zone, including nameserver records of delegated sub- + zones (NS records), address records that accompany those NS records + (A, AAAA, etc), and any other stray data that might appear. + +5.5. Sending RRSets (reprise) + + A Resource Record Set should only be included once in any DNS reply. + It may occur in any of the Answer, Authority, or Additional + Information sections, as required. However it should not be repeated + in the same, or any other, section, except where explicitly required + by a specification. For example, an AXFR response requires the SOA + record (always an RRSet containing a single RR) be both the first and + last record of the reply. Where duplicates are required this way, + the TTL transmitted in each case must be the same. + +6. Zone Cuts + + The DNS tree is divided into "zones", which are collections of + domains that are treated as a unit for certain management purposes. + Zones are delimited by "zone cuts". Each zone cut separates a + "child" zone (below the cut) from a "parent" zone (above the cut). + The domain name that appears at the top of a zone (just below the cut + that separates the zone from its parent) is called the zone's + "origin". The name of the zone is the same as the name of the domain + at the zone's origin. Each zone comprises that subset of the DNS + tree that is at or below the zone's origin, and that is above the + + + +Elz & Bush Standards Track [Page 8] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + cuts that separate the zone from its children (if any). The + existence of a zone cut is indicated in the parent zone by the + existence of NS records specifying the origin of the child zone. A + child zone does not contain any explicit reference to its parent. + +6.1. Zone authority + + The authoritative servers for a zone are enumerated in the NS records + for the origin of the zone, which, along with a Start of Authority + (SOA) record are the mandatory records in every zone. Such a server + is authoritative for all resource records in a zone that are not in + another zone. The NS records that indicate a zone cut are the + property of the child zone created, as are any other records for the + origin of that child zone, or any sub-domains of it. A server for a + zone should not return authoritative answers for queries related to + names in another zone, which includes the NS, and perhaps A, records + at a zone cut, unless it also happens to be a server for the other + zone. + + Other than the DNSSEC cases mentioned immediately below, servers + should ignore data other than NS records, and necessary A records to + locate the servers listed in the NS records, that may happen to be + configured in a zone at a zone cut. + +6.2. DNSSEC issues + + The DNS security mechanisms [RFC2065] complicate this somewhat, as + some of the new resource record types added are very unusual when + compared with other DNS RRs. In particular the NXT ("next") RR type + contains information about which names exist in a zone, and hence + which do not, and thus must necessarily relate to the zone in which + it exists. The same domain name may have different NXT records in + the parent zone and the child zone, and both are valid, and are not + an RRSet. See also section 5.3.2. + + Since NXT records are intended to be automatically generated, rather + than configured by DNS operators, servers may, but are not required + to, retain all differing NXT records they receive regardless of the + rules in section 5.4. + + For a secure parent zone to securely indicate that a subzone is + insecure, DNSSEC requires that a KEY RR indicating that the subzone + is insecure, and the parent zone's authenticating SIG RR(s) be + present in the parent zone, as they by definition cannot be in the + subzone. Where a subzone is secure, the KEY and SIG records will be + present, and authoritative, in that zone, but should also always be + present in the parent zone (if secure). + + + + +Elz & Bush Standards Track [Page 9] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + Note that in none of these cases should a server for the parent zone, + not also being a server for the subzone, set the AA bit in any + response for a label at a zone cut. + +7. SOA RRs + + Three minor issues concerning the Start of Zone of Authority (SOA) + Resource Record need some clarification. + +7.1. Placement of SOA RRs in authoritative answers + + RFC1034, in section 3.7, indicates that the authority section of an + authoritative answer may contain the SOA record for the zone from + which the answer was obtained. When discussing negative caching, + RFC1034 section 4.3.4 refers to this technique but mentions the + additional section of the response. The former is correct, as is + implied by the example shown in section 6.2.5 of RFC1034. SOA + records, if added, are to be placed in the authority section. + +7.2. TTLs on SOA RRs + + It may be observed that in section 3.2.1 of RFC1035, which defines + the format of a Resource Record, that the definition of the TTL field + contains a throw away line which states that the TTL of an SOA record + should always be sent as zero to prevent caching. This is mentioned + nowhere else, and has not generally been implemented. + Implementations should not assume that SOA records will have a TTL of + zero, nor are they required to send SOA records with a TTL of zero. + +7.3. The SOA.MNAME field + + It is quite clear in the specifications, yet seems to have been + widely ignored, that the MNAME field of the SOA record should contain + the name of the primary (master) server for the zone identified by + the SOA. It should not contain the name of the zone itself. That + information would be useless, as to discover it, one needs to start + with the domain name of the SOA record - that is the name of the + zone. + +8. Time to Live (TTL) + + The definition of values appropriate to the TTL field in STD 13 is + not as clear as it could be, with respect to how many significant + bits exist, and whether the value is signed or unsigned. It is + hereby specified that a TTL value is an unsigned number, with a + minimum value of 0, and a maximum value of 2147483647. That is, a + maximum of 2^31 - 1. When transmitted, this value shall be encoded + in the less significant 31 bits of the 32 bit TTL field, with the + + + +Elz & Bush Standards Track [Page 10] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + most significant, or sign, bit set to zero. + + Implementations should treat TTL values received with the most + significant bit set as if the entire value received was zero. + + Implementations are always free to place an upper bound on any TTL + received, and treat any larger values as if they were that upper + bound. The TTL specifies a maximum time to live, not a mandatory + time to live. + +9. The TC (truncated) header bit + + The TC bit should be set in responses only when an RRSet is required + as a part of the response, but could not be included in its entirety. + The TC bit should not be set merely because some extra information + could have been included, but there was insufficient room. This + includes the results of additional section processing. In such cases + the entire RRSet that will not fit in the response should be omitted, + and the reply sent as is, with the TC bit clear. If the recipient of + the reply needs the omitted data, it can construct a query for that + data and send that separately. + + Where TC is set, the partial RRSet that would not completely fit may + be left in the response. When a DNS client receives a reply with TC + set, it should ignore that response, and query again, using a + mechanism, such as a TCP connection, that will permit larger replies. + +10. Naming issues + + It has sometimes been inferred from some sections of the DNS + specification [RFC1034, RFC1035] that a host, or perhaps an interface + of a host, is permitted exactly one authoritative, or official, name, + called the canonical name. There is no such requirement in the DNS. + +10.1. CNAME resource records + + The DNS CNAME ("canonical name") record exists to provide the + canonical name associated with an alias name. There may be only one + such canonical name for any one alias. That name should generally be + a name that exists elsewhere in the DNS, though there are some rare + applications for aliases with the accompanying canonical name + undefined in the DNS. An alias name (label of a CNAME record) may, + if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no + other data. That is, for any label in the DNS (any domain name) + exactly one of the following is true: + + + + + + +Elz & Bush Standards Track [Page 11] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + + one CNAME record exists, optionally accompanied by SIG, NXT, and + KEY RRs, + + one or more records exist, none being CNAME records, + + the name exists, but has no associated RRs of any type, + + the name does not exist at all. + +10.1.1. CNAME terminology + + It has been traditional to refer to the label of a CNAME record as "a + CNAME". This is unfortunate, as "CNAME" is an abbreviation of + "canonical name", and the label of a CNAME record is most certainly + not a canonical name. It is, however, an entrenched usage. Care + must therefore be taken to be very clear whether the label, or the + value (the canonical name) of a CNAME resource record is intended. + In this document, the label of a CNAME resource record will always be + referred to as an alias. + +10.2. PTR records + + Confusion about canonical names has lead to a belief that a PTR + record should have exactly one RR in its RRSet. This is incorrect, + the relevant section of RFC1034 (section 3.6.2) indicates that the + value of a PTR record should be a canonical name. That is, it should + not be an alias. There is no implication in that section that only + one PTR record is permitted for a name. No such restriction should + be inferred. + + Note that while the value of a PTR record must not be an alias, there + is no requirement that the process of resolving a PTR record not + encounter any aliases. The label that is being looked up for a PTR + value might have a CNAME record. That is, it might be an alias. The + value of that CNAME RR, if not another alias, which it should not be, + will give the location where the PTR record is found. That record + gives the result of the PTR type lookup. This final result, the + value of the PTR RR, is the label which must not be an alias. + +10.3. MX and NS records + + The domain name used as the value of a NS resource record, or part of + the value of a MX resource record must not be an alias. Not only is + the specification clear on this point, but using an alias in either + of these positions neither works as well as might be hoped, nor well + fulfills the ambition that may have led to this approach. This + domain name must have as its value one or more address records. + Currently those will be A records, however in the future other record + types giving addressing information may be acceptable. It can also + have other RRs, but never a CNAME RR. + + + + +Elz & Bush Standards Track [Page 12] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + Searching for either NS or MX records causes "additional section + processing" in which address records associated with the value of the + record sought are appended to the answer. This helps avoid needless + extra queries that are easily anticipated when the first was made. + + Additional section processing does not include CNAME records, let + alone the address records that may be associated with the canonical + name derived from the alias. Thus, if an alias is used as the value + of an NS or MX record, no address will be returned with the NS or MX + value. This can cause extra queries, and extra network burden, on + every query. It is trivial for the DNS administrator to avoid this + by resolving the alias and placing the canonical name directly in the + affected record just once when it is updated or installed. In some + particular hard cases the lack of the additional section address + records in the results of a NS lookup can cause the request to fail. + +11. Name syntax + + Occasionally it is assumed that the Domain Name System serves only + the purpose of mapping Internet host names to data, and mapping + Internet addresses to host names. This is not correct, the DNS is a + general (if somewhat limited) hierarchical database, and can store + almost any kind of data, for almost any purpose. + + The DNS itself places only one restriction on the particular labels + that can be used to identify resource records. That one restriction + relates to the length of the label and the full name. The length of + any one label is limited to between 1 and 63 octets. A full domain + name is limited to 255 octets (including the separators). The zero + length full name is defined as representing the root of the DNS tree, + and is typically written and displayed as ".". Those restrictions + aside, any binary string whatever can be used as the label of any + resource record. Similarly, any binary string can serve as the value + of any record that includes a domain name as some or all of its value + (SOA, NS, MX, PTR, CNAME, and any others that may be added). + Implementations of the DNS protocols must not place any restrictions + on the labels that can be used. In particular, DNS servers must not + refuse to serve a zone because it contains labels that might not be + acceptable to some DNS client programs. A DNS server may be + configurable to issue warnings when loading, or even to refuse to + load, a primary zone containing labels that might be considered + questionable, however this should not happen by default. + + Note however, that the various applications that make use of DNS data + can have restrictions imposed on what particular values are + acceptable in their environment. For example, that any binary label + can have an MX record does not imply that any binary name can be used + as the host part of an e-mail address. Clients of the DNS can impose + + + +Elz & Bush Standards Track [Page 13] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + whatever restrictions are appropriate to their circumstances on the + values they use as keys for DNS lookup requests, and on the values + returned by the DNS. If the client has such restrictions, it is + solely responsible for validating the data from the DNS to ensure + that it conforms before it makes any use of that data. + + See also [RFC1123] section 6.1.3.5. + +12. Security Considerations + + This document does not consider security. + + In particular, nothing in section 4 is any way related to, or useful + for, any security related purposes. + + Section 5.4.1 is also not related to security. Security of DNS data + will be obtained by the Secure DNS [RFC2065], which is mostly + orthogonal to this memo. + + It is not believed that anything in this document adds to any + security issues that may exist with the DNS, nor does it do anything + to that will necessarily lessen them. Correct implementation of the + clarifications in this document might play some small part in + limiting the spread of non-malicious bad data in the DNS, but only + DNSSEC can help with deliberate attempts to subvert DNS data. + +13. References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - application + and support", STD 3, RFC 1123, January 1989. + + [RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", + STD 2, RFC 1700, October 1994. + + [RFC2065] Eastlake, D., Kaufman, C., "Domain Name System Security + Extensions", RFC 2065, January 1997. + + + + + + + + + +Elz & Bush Standards Track [Page 14] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + +14. Acknowledgements + + This memo arose from discussions in the DNSIND working group of the + IETF in 1995 and 1996, the members of that working group are largely + responsible for the ideas captured herein. Particular thanks to + Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the + DNSSEC issues in this document, and to John Gilmore for pointing out + where the clarifications were not necessarily clarifying. Bob Halley + suggested clarifying the placement of SOA records in authoritative + answers, and provided the references. Michael Patton, as usual, and + Mark Andrews, Alan Barrett and Stan Barber provided much assistance + with many details. Josh Littlefield helped make sure that the + clarifications didn't cause problems in some irritating corner cases. + +15. Authors' Addresses + + Robert Elz + Computer Science + University of Melbourne + Parkville, Victoria, 3052 + Australia. + + EMail: kre@munnari.OZ.AU + + + Randy Bush + RGnet, Inc. + 5147 Crystal Springs Drive NE + Bainbridge Island, Washington, 98110 + United States. + + EMail: randy@psg.com + + + + + + + + + + + + + + + + + + + +Elz & Bush Standards Track [Page 15] diff --git a/Documentation/en/rfc/rfc2183.txt b/Documentation/en/rfc/rfc2183.txt new file mode 100644 index 00000000..f16f127e --- /dev/null +++ b/Documentation/en/rfc/rfc2183.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group R. Troost +Request for Comments: 2183 New Century Systems +Updates: 1806 S. Dorner +Category: Standards Track QUALCOMM Incorporated + K. Moore, Editor + University of Tennessee + August 1997 + + + Communicating Presentation Information in + Internet Messages: + The Content-Disposition Header Field + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo provides a mechanism whereby messages conforming to the + MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC + 2049] can convey presentational information. It specifies the + "Content-Disposition" header field, which is optional and valid for + any MIME entity ("message" or "body part"). Two values for this + header field are described in this memo; one for the ordinary linear + presentation of the body part, and another to facilitate the use of + mail to transfer files. It is expected that more values will be + defined in the future, and procedures are defined for extending this + set of values. + + This document is intended as an extension to MIME. As such, the + reader is assumed to be familiar with the MIME specifications, and + [RFC 822]. The information presented herein supplements but does not + replace that found in those documents. + + This document is a revision to the Experimental protocol defined in + RFC 1806. As compared to RFC 1806, this document contains minor + editorial updates, adds new parameters needed to support the File + Transfer Body Part, and references a separate specification for the + handling of non-ASCII and/or very long parameter values. + + + + + + + +Troost, et. al. Standards Track [Page 1] + +RFC 2183 Content-Disposition August 1997 + + +1. Introduction + + MIME specifies a standard format for encapsulating multiple pieces of + data into a single Internet message. That document does not address + the issue of presentation styles; it provides a framework for the + interchange of message content, but leaves presentation issues solely + in the hands of mail user agent (MUA) implementors. + + Two common ways of presenting multipart electronic messages are as a + main document with a list of separate attachments, and as a single + document with the various parts expanded (displayed) inline. The + display of an attachment is generally construed to require positive + action on the part of the recipient, while inline message components + are displayed automatically when the message is viewed. A mechanism + is needed to allow the sender to transmit this sort of presentational + information to the recipient; the Content-Disposition header provides + this mechanism, allowing each component of a message to be tagged + with an indication of its desired presentation semantics. + + Tagging messages in this manner will often be sufficient for basic + message formatting. However, in many cases a more powerful and + flexible approach will be necessary. The definition of such + approaches is beyond the scope of this memo; however, such approaches + can benefit from additional Content-Disposition values and + parameters, to be defined at a later date. + + In addition to allowing the sender to specify the presentational + disposition of a message component, it is desirable to allow her to + indicate a default archival disposition; a filename. The optional + "filename" parameter provides for this. Further, the creation-date, + modification-date, and read-date parameters allow preservation of + those file attributes when the file is transmitted over MIME email. + + NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in [RFC 2119]. + +2. The Content-Disposition Header Field + + Content-Disposition is an optional header field. In its absence, the + MUA may use whatever presentation method it deems suitable. + + It is desirable to keep the set of possible disposition types small + and well defined, to avoid needless complexity. Even so, evolving + usage will likely require the definition of additional disposition + types or parameters, so the set of disposition values is extensible; + see below. + + + + +Troost, et. al. Standards Track [Page 2] + +RFC 2183 Content-Disposition August 1997 + + + In the extended BNF notation of [RFC 822], the Content-Disposition + header field is defined as follows: + + disposition := "Content-Disposition" ":" + disposition-type + *(";" disposition-parm) + + disposition-type := "inline" + / "attachment" + / extension-token + ; values are not case-sensitive + + disposition-parm := filename-parm + / creation-date-parm + / modification-date-parm + / read-date-parm + / size-parm + / parameter + + filename-parm := "filename" "=" value + + creation-date-parm := "creation-date" "=" quoted-date-time + + modification-date-parm := "modification-date" "=" quoted-date-time + + read-date-parm := "read-date" "=" quoted-date-time + + size-parm := "size" "=" 1*DIGIT + + quoted-date-time := quoted-string + ; contents MUST be an RFC 822 `date-time' + ; numeric timezones (+HHMM or -HHMM) MUST be used + + + + NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters) + parameter value containing only non-`tspecials' characters SHOULD be + represented as a single `token'. A short parameter value containing + only ASCII characters, but including `tspecials' characters, SHOULD + be represented as `quoted-string'. Parameter values longer than 78 + characters, or which contain non-ASCII characters, MUST be encoded as + specified in [RFC 2184]. + + `Extension-token', `parameter', `tspecials' and `value' are defined + according to [RFC 2045] (which references [RFC 822] in the definition + of some of these tokens). `quoted-string' and `DIGIT' are defined in + [RFC 822]. + + + + +Troost, et. al. Standards Track [Page 3] + +RFC 2183 Content-Disposition August 1997 + + +2.1 The Inline Disposition Type + + A bodypart should be marked `inline' if it is intended to be + displayed automatically upon display of the message. Inline + bodyparts should be presented in the order in which they occur, + subject to the normal semantics of multipart messages. + +2.2 The Attachment Disposition Type + + Bodyparts can be designated `attachment' to indicate that they are + separate from the main body of the mail message, and that their + display should not be automatic, but contingent upon some further + action of the user. The MUA might instead present the user of a + bitmap terminal with an iconic representation of the attachments, or, + on character terminals, with a list of attachments from which the + user could select for viewing or storage. + +2.3 The Filename Parameter + + The sender may want to suggest a filename to be used if the entity is + detached and stored in a separate file. If the receiving MUA writes + the entity to a file, the suggested filename should be used as a + basis for the actual filename, where possible. + + It is important that the receiving MUA not blindly use the suggested + filename. The suggested filename SHOULD be checked (and possibly + changed) to see that it conforms to local filesystem conventions, + does not overwrite an existing file, and does not present a security + problem (see Security Considerations below). + + The receiving MUA SHOULD NOT respect any directory path information + that may seem to be present in the filename parameter. The filename + should be treated as a terminal component only. Portable + specification of directory paths might possibly be done in the future + via a separate Content-Disposition parameter, but no provision is + made for it in this draft. + + Current [RFC 2045] grammar restricts parameter values (and hence + Content-Disposition filenames) to US-ASCII. We recognize the great + desirability of allowing arbitrary character sets in filenames, but + it is beyond the scope of this document to define the necessary + mechanisms. We expect that the basic [RFC 1521] `value' + specification will someday be amended to allow use of non-US-ASCII + characters, at which time the same mechanism should be used in the + Content-Disposition filename parameter. + + + + + + +Troost, et. al. Standards Track [Page 4] + +RFC 2183 Content-Disposition August 1997 + + + Beyond the limitation to US-ASCII, the sending MUA may wish to bear + in mind the limitations of common filesystems. Many have severe + length and character set restrictions. Short alphanumeric filenames + are least likely to require modification by the receiving system. + + The presence of the filename parameter does not force an + implementation to write the entity to a separate file. It is + perfectly acceptable for implementations to leave the entity as part + of the normal mail stream unless the user requests otherwise. As a + consequence, the parameter may be used on any MIME entity, even + `inline' ones. These will not normally be written to files, but the + parameter could be used to provide a filename if the receiving user + should choose to write the part to a file. + +2.4 The Creation-Date parameter + + The creation-date parameter MAY be used to indicate the date at which + the file was created. If this parameter is included, the paramter + value MUST be a quoted-string which contains a representation of the + creation date of the file in [RFC 822] `date-time' format. + + UNIX and POSIX implementors are cautioned that the `st_ctime' file + attribute of the `stat' structure is not the creation time of the + file; it is thus not appropriate as a source for the creation-date + parameter value. + +2.5 The Modification-Date parameter + + The modification-date parameter MAY be used to indicate the date at + which the file was last modified. If the modification-date parameter + is included, the paramter value MUST be a quoted-string which + contains a representation of the last modification date of the file + in [RFC 822] `date-time' format. + +2.6 The Read-Date parameter + + The read-date parameter MAY be used to indicate the date at which the + file was last read. If the read-date parameter is included, the + parameter value MUST be a quoted-string which contains a + representation of the last-read date of the file in [RFC 822] `date- + time' format. + +2.7 The Size parameter + + The size parameter indicates an approximate size of the file in + octets. It can be used, for example, to pre-allocate space before + attempting to store the file, or to determine whether enough space + exists. + + + +Troost, et. al. Standards Track [Page 5] + +RFC 2183 Content-Disposition August 1997 + + +2.8 Future Extensions and Unrecognized Disposition Types + + In the likely event that new parameters or disposition types are + needed, they should be registered with the Internet Assigned Numbers + Authority (IANA), in the manner specified in Section 9 of this memo. + + Once new disposition types and parameters are defined, there is of + course the likelihood that implementations will see disposition types + and parameters they do not understand. Furthermore, since x-tokens + are allowed, implementations may also see entirely unregistered + disposition types and parameters. + + Unrecognized parameters should be ignored. Unrecognized disposition + types should be treated as `attachment'. The choice of `attachment' + for unrecognized types is made because a sender who goes to the + trouble of producing a Content-Disposition header with a new + disposition type is more likely aiming for something more elaborate + than inline presentation. + + Unless noted otherwise in the definition of a parameter, Content- + Disposition parameters are valid for all dispositions. (In contrast + to MIME content-type parameters, which are defined on a per-content- + type basis.) Thus, for example, the `filename' parameter still means + the name of the file to which the part should be written, even if the + disposition itself is unrecognized. + +2.9 Content-Disposition and Multipart + + If a Content-Disposition header is used on a multipart body part, it + applies to the multipart as a whole, not the individual subparts. + The disposition types of the subparts do not need to be consulted + until the multipart itself is presented. When the multipart is + displayed, then the dispositions of the subparts should be respected. + + If the `inline' disposition is used, the multipart should be + displayed as normal; however, an `attachment' subpart should require + action from the user to display. + + If the `attachment' disposition is used, presentation of the + multipart should not proceed without explicit user action. Once the + user has chosen to display the multipart, the individual subpart + dispositions should be consulted to determine how to present the + subparts. + + + + + + + + +Troost, et. al. Standards Track [Page 6] + +RFC 2183 Content-Disposition August 1997 + + +2.10 Content-Disposition and the Main Message + + It is permissible to use Content-Disposition on the main body of an + [RFC 822] message. + +3. Examples + + Here is a an example of a body part containing a JPEG image that is + intended to be viewed by the user immediately: + + Content-Type: image/jpeg + Content-Disposition: inline + Content-Description: just a small picture of me + + <jpeg data> + + The following body part contains a JPEG image that should be + displayed to the user only if the user requests it. If the JPEG is + written to a file, the file should be named "genome.jpg". The + recipient's user might also choose to set the last-modified date of + the stored file to date in the modification-date parameter: + + Content-Type: image/jpeg + Content-Disposition: attachment; filename=genome.jpeg; + modification-date="Wed, 12 Feb 1997 16:29:51 -0500"; + Content-Description: a complete map of the human genome + + <jpeg data> + + The following is an example of the use of the `attachment' + disposition with a multipart body part. The user should see text- + part-1 immediately, then take some action to view multipart-2. After + taking action to view multipart-2, the user will see text-part-2 + right away, and be required to take action to view jpeg-1. Subparts + are indented for clarity; they would not be so indented in a real + message. + + + + + + + + + + + + + + + +Troost, et. al. Standards Track [Page 7] + +RFC 2183 Content-Disposition August 1997 + + + Content-Type: multipart/mixed; boundary=outer + Content-Description: multipart-1 + + --outer + Content-Type: text/plain + Content-Disposition: inline + Content-Description: text-part-1 + + Some text goes here + + --outer + Content-Type: multipart/mixed; boundary=inner + Content-Disposition: attachment + Content-Description: multipart-2 + + --inner + Content-Type: text/plain + Content-Disposition: inline + Content-Description: text-part-2 + + Some more text here. + + --inner + Content-Type: image/jpeg + Content-Disposition: attachment + Content-Description: jpeg-1 + + <jpeg data> + --inner-- + --outer-- + +4. Summary + + Content-Disposition takes one of two values, `inline' and + `attachment'. `Inline' indicates that the entity should be + immediately displayed to the user, whereas `attachment' means that + the user should take additional action to view the entity. + + The `filename' parameter can be used to suggest a filename for + storing the bodypart, if the user wishes to store it in an external + file. + + + + + + + + + + +Troost, et. al. Standards Track [Page 8] + +RFC 2183 Content-Disposition August 1997 + + +5. Security Considerations + + There are security issues involved any time users exchange data. + While these are not to be minimized, neither does this memo change + the status quo in that regard, except in one instance. + + Since this memo provides a way for the sender to suggest a filename, + a receiving MUA must take care that the sender's suggested filename + does not represent a hazard. Using UNIX as an example, some hazards + would be: + + + Creating startup files (e.g., ".login"). + + + Creating or overwriting system files (e.g., "/etc/passwd"). + + + Overwriting any existing file. + + + Placing executable files into any command search path + (e.g., "~/bin/more"). + + + Sending the file to a pipe (e.g., "| sh"). + + In general, the receiving MUA should not name or place the file such + that it will get interpreted or executed without the user explicitly + initiating the action. + + It is very important to note that this is not an exhaustive list; it + is intended as a small set of examples only. Implementors must be + alert to the potential hazards on their target systems. + +6. References + + [RFC 2119] + Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + [RFC 2184] + Freed, N. and K. Moore, "MIME Parameter value and Encoded Words: + Character Sets, Lanaguage, and Continuations", RFC 2184, August + 1997. + + [RFC 2045] + Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail + Extensions) Part One: Format of Internet Message Bodies", RFC + 2045, December 1996. + + + + + + +Troost, et. al. Standards Track [Page 9] + +RFC 2183 Content-Disposition August 1997 + + + [RFC 2046] + Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail + Extensions) Part Two: Media Types", RFC 2046, December 1996. + + [RFC 2047] + Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part + Three: Message Header Extensions for non-ASCII Text", RFC 2047, + December 1996. + + [RFC 2048] + Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose + Internet Mail Extensions) Part Four: Registration Procedures", + RFC 2048, December 1996. + + [RFC 2049] + Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail + Extensions) Part Five: Conformance Criteria and Examples", RFC + 2049, December 1996. + + [RFC 822] + Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + +7. Acknowledgements + + We gratefully acknowledge the help these people provided during the + preparation of this draft: + + Nathaniel Borenstein + Ned Freed + Keith Moore + Dave Crocker + Dan Pritchett + + + + + + + + + + + + + + + + + + +Troost, et. al. Standards Track [Page 10] + +RFC 2183 Content-Disposition August 1997 + + +8. Authors' Addresses + + You should blame the editor of this version of the document for any + changes since RFC 1806: + + Keith Moore + Department of Computer Science + University of Tennessee, Knoxville + 107 Ayres Hall + Knoxville TN 37996-1301 + USA + + Phone: +1 (423) 974-5067 + Fax: +1 (423) 974-8296 + Email: moore@cs.utk.edu + + + The authors of RFC 1806 are: + + Rens Troost + New Century Systems + 324 East 41st Street #804 + New York, NY, 10017 USA + + Phone: +1 (212) 557-2050 + Fax: +1 (212) 557-2049 + EMail: rens@century.com + + + Steve Dorner + QUALCOMM Incorporated + 6455 Lusk Boulevard + San Diego, CA 92121 + USA + + EMail: sdorner@qualcomm.com + + +9. Registration of New Content-Disposition Values and Parameters + + New Content-Disposition values (besides "inline" and "attachment") + may be defined only by Internet standards-track documents, or in + Experimental documents approved by the Internet Engineering Steering + Group. + + + + + + + +Troost, et. al. Standards Track [Page 11] + +RFC 2183 Content-Disposition August 1997 + + + New content-disposition parameters may be registered by supplying the + information in the following template and sending it via electronic + mail to IANA@IANA.ORG: + + To: IANA@IANA.ORG + Subject: Registration of new Content-Disposition parameter + + Content-Disposition parameter name: + + Allowable values for this parameter: + (If the parameter can only assume a small number of values, + list each of those values. Otherwise, describe the values + that the parameter can assume.) + Description: + (What is the purpose of this parameter and how is it used?) + +10. Changes since RFC 1806 + + The following changes have been made since the earlier version of + this document, published in RFC 1806 as an Experimental protocol: + + + Updated references to MIME documents. In some cases this + involved substituting a reference to one of the current MIME + RFCs for a reference to RFC 1521; in other cases, a reference to + RFC 1521 was simply replaced with the word "MIME". + + + Added a section on registration procedures, since none of the + procedures in RFC 2048 seemed to be appropriate. + + + Added new parameter types: creation-date, modification-date, + read-date, and size. + + + + Incorporated a reference to draft-freed-pvcsc-* for encoding + long or non-ASCII parameter values. + + + Added reference to RFC 2119 to define MUST, SHOULD, etc. + keywords. + + + + + + + + + + + + + +Troost, et. al. Standards Track [Page 12] + diff --git a/Documentation/en/rfc/rfc2184.txt b/Documentation/en/rfc/rfc2184.txt new file mode 100644 index 00000000..254321a1 --- /dev/null +++ b/Documentation/en/rfc/rfc2184.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2184 Innosoft +Updates: 2045, 2047, 2183 K. Moore +Category: Standards Track University of Tennessee + August 1997 + + + MIME Parameter Value and Encoded Word Extensions: + Character Sets, Languages, and Continuations + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines extensions to the RFC 2045 media type and RFC 2183 + disposition parameter value mechanisms to provide + + (1) a means to specify parameter values in character sets + other than US-ASCII, + + (2) to specify the language to be used should the value be + displayed, and + + (3) a continuation mechanism for long parameter values to + avoid problems with header line wrapping. + + This memo also defines an extension to the encoded words defined in + RFC 2047 to allow the specification of the language to be used for + display as well as the character set. + +2. Introduction + + The Multipurpose Internet Mail Extensions, or MIME [RFC-2045, RFC- + 2046, RFC-2047, RFC-2048, RFC-2049], define a message format that + allows for + + (1) textual message bodies in character sets other than + US-ASCII, + + (2) non-textual message bodies, + + (3) multi-part message bodies, and + + + +Freed & Moore Standards Track [Page 1] + +RFC 2184 MIME Parameter Value and Encoded Word Extensions August 1997 + + + (4) textual header information in character sets other than + US-ASCII. + + MIME is now widely deployed and is used by a variety of Internet + protocols, including, of course, Internet email. However, MIME's + success has resulted in the need for additional mechanisms that were + not provided in the original protocol specification. + + In particular, existing MIME mechanisms provide for named media type + (content-type field) parameters as well as named disposition + (content-disposition field). A MIME media type may specify any + number of parameters associated with all of its subtypes, and any + specific subtype may specify additional parameters for its own use. A + MIME disposition value may specify any number of associated + parameters, the most important of which is probably the attachment + disposition's filename parameter. + + These parameter names and values end up appearing in the content-type + and content-disposition header fields in Internet email. This + inherently imposes three crucial limitations: + + (1) Lines in Internet email header fields are folded according to + RFC 822 folding rules. This makes long parameter values + problematic. + + (2) MIME headers, like the RFC 822 headers they often appear in, + are limited to 7bit US-ASCII, and the encoded-word mechanisms + of RFC 2047 are not available to parameter values. This makes + it impossible to have parameter values in character sets other + than US-ASCII without specifying some sort of private per- + parameter encoding. + + (3) It has recently become clear that character set information + is not sufficient to properly display some sorts of + information -- language information is also needed [RFC-2130]. + For example, support for handicapped users may require reading + text string aloud. The language the text is written in is + needed for this to be done correctly. Some parameter values + may need to be displayed, hence there is a need to allow for + the inclusion of language information. + + The last problem on this list is also an issue for the encoded words + defined by RFC 2047, as encoded words are intended primarily for + display purposes. + + + + + + + +Freed & Moore Standards Track [Page 2] + +RFC 2184 MIME Parameter Value and Encoded Word Extensions August 1997 + + + This document defines extensions that address all of these + limitations. All of these extensions are implemented in a fashion + that is completely compatible at a syntactic level with existing MIME + implementations. In addition, the extensions are designed to have as + little impact as possible on existing uses of MIME. + + IMPORTANT NOTE: These mechanisms end up being somewhat gibbous when + they actually are used. As such, use of these mechanisms should not + be used lightly; they should be reserved for situations where a real + need for them exists. + +2.1. Requirements notation + + This document occasionally uses terms that appear in capital letters. + When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" + appear capitalized, they are being used to indicate particular + requirements of this specification. A discussion of the meanings of + these terms appears in [RFC-2119]. + + +3. Parameter Value Continuations + + Long MIME media type or disposition parameter values do not interact + well with header line wrapping conventions. In particular, proper + header line wrapping depends on there being places where linear + whitespace (LWSP) is allowed, which may or may not be present in a + parameter value, and even if present may not be recognizable as such + since specific knowledge of parameter value syntax may not be + available to the agent doing the line wrapping. The result is that + long parameter values may end up getting truncated or otherwise + damaged by incorrect line wrapping implementations. + + A mechanism is therefore needed to break up parameter values into + smaller units that are amenable to line wrapping. Any such mechanism + MUST be compatible with existing MIME processors. This means that + + (1) the mechanism MUST NOT change the syntax of MIME media + type and disposition lines, and + + (2) the mechanism MUST NOT depend on parameter ordering + since MIME states that parameters are not order sensitive. + Note that while MIME does prohibit modification of MIME + headers during transport, it is still possible that parameters + will be reordered when user agent level processing is done. + + + + + + + +Freed & Moore Standards Track [Page 3] + +RFC 2184 MIME Parameter Value and Encoded Word Extensions August 1997 + + + The obvious solution, then, is to use multiple parameters to contain + a single parameter value and to use some kind of distinguished name + to indicate when this is being done. And this obvious solution is + exactly what is specified here: The asterisk character ("*") followed + by a decimal count is employed to indicate that multiple parameters + are being used to encapsulate a single parameter value. The count + starts at 0 and increments by 1 for each subsequent section of the + parameter value. Decimal values are used and neither leading zeroes + nor gaps in the sequence are allowed. + + The original parameter value is recovered by concatenating the + various sections of the parameter, in order. For example, the + content-type field + + Content-Type: message/external-body; access-type=URL; + URL*0="ftp://"; + URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar" + + is semantically identical to + + Content-Type: message/external-body; access-type=URL; + URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar" + + Note that quotes around parameter values are part of the value + syntax; they are NOT part of the value itself. Furthermore, it is + explicitly permitted to have a mixture of quoted and unquoted + continuation fields. + +4. Parameter Value Character Set and Language Information + + Some parameter values may need to be qualified with character set or + language information. It is clear that a distinguished parameter + name is needed to identify when this information is present along + with a specific syntax for the information in the value itself. In + addition, a lightweight encoding mechanism is needed to accomodate 8 + bit information in parameter values. + + Asterisks ("*") are reused to provide the indicator that language and + character set information is present and encoding is being used. A + single quote ("'") is used to delimit the character set and language + information at the beginning of the parameter value. Percent signs + ("%") are used as the encoding flag, which agrees with RFC 2047. + + + + + + + + + +Freed & Moore Standards Track [Page 4] + +RFC 2184 MIME Parameter Value and Encoded Word Extensions August 1997 + + + Specifically, an asterisk at the end of a parameter name acts as an + indicator that character set and language information may appear at + the beginning of the parameter value. A single quote is used to + separate the character set, language, and actual value information in + the parameter value string, and an percent sign is used to flag + octets encoded in hexadecimal. For example: + + Content-Type: application/x-stuff; + title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A + + Note that it is perfectly permissible to leave either the character + set or language field blank. Note also that the single quote + delimiters MUST be present even when one of the field values is + omitted. This is done when either character set, language, or both + are not relevant to the parameter value at hand. This MUST NOT be + done in order to indicate a default character set or language -- + parameter field definitions MUST NOT assign a default character set + or lanugage. + +4.1. Combining Character Set, Language, and Parameter Continuations + + Character set and language information may be combined with the + parameter continuation mechanism. For example: + + Content-Type: application/x-stuff + title*1*=us-ascii'en'This%20is%20even%20more%20 + title*2*=%2A%2A%2Afun%2A%2A%2A%20 + title*3="isn't it!" + + Note that: + + (1) Language and character set information only appear at + the beginning of a given parameter value. + + (2) Continuations do not provide a facility for using more + than one character set or language in the same parameter + value. + + (3) A value presented using multiple continuations may + contain a mixture of encoded and unencoded segments. + + (4) The first segment of a continuation MUST be encoded if + language and character set information are given. + + (5) If the first segment of a continued parameter value is + encoded the language and character set field delimiters MUST + be present even when the fields are left blank. + + + + +Freed & Moore Standards Track [Page 5] + +RFC 2184 MIME Parameter Value and Encoded Word Extensions August 1997 + + +5. Language specification in Encoded Words + + RFC 2047 provides support for non-US-ASCII character sets in RFC 822 + message header comments, phrases, and any unstructured text field. + This is done by defining an encoded word construct which can appear + in any of these places. Given that these are fields intended for + display, it is sometimes necessary to associate language information + with encoded words as well as just the character set. This + specification extends the definition of an encoded word to allow the + inclusion of such information. This is simply done by suffixing the + character set specification with an asterisk followed by the language + tag. For example: + + From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu> + +6. IMAP4 Handling of Parameter Values + + IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations + when generating the BODY and BODYSTRUCTURE fetch attributes. + +7. Modifications to MIME ABNF + + The ABNF for MIME parameter values given in RFC 2045 is: + + parameter := attribute "=" value + + attribute := token + ; Matching of attributes + ; is ALWAYS case-insensitive. + + This specification changes this ABNF to: + + parameter := regular-parameter / extended-parameter + + regular-parameter := regular-parameter-name "=" value + + regular-parameter-name := attribute [section] + + attribute := 1*attribute-char + + attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs, + "*", "'", "%", or tspecials> + + section := initial-section / other-sections + + initial-section := "*1" + + + + + +Freed & Moore Standards Track [Page 6] + +RFC 2184 MIME Parameter Value and Encoded Word Extensions August 1997 + + + other-sections := "*" (("2" / "3" / "4" / "5" / + "6" / "7" / "8" / "9") *DIGIT) / + ("1" 1*DIGIT)) + + extended-parameter := (extended-initial-name "=" + extended-value) / + (extended-other-names "=" + extended-other-values) + + extended-initial-name := attribute [initial-section] "*" + + extended-other-names := attribute other-sections "*" + + extended-initial-value := [charset] "'" [language] "'" + extended-other-values + + extended-other-values := *(ext-octet / attribute-char) + + ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + + charset := <registered character set name> + + language := <registered language tag [RFC-1766]> + + The ABNF given in RFC 2047 for encoded-words is: + + encoded-word := "=?" charset "?" encoding "?" encoded-text "?=" + + This specification changes this ABNF to: + + encoded-word := "=?" charset ["*" language] "?" encoded-text "?=" + + +8. Character sets which allow specification of language + + In the future it is likely that some character sets will provide + facilities for inline language labelling. Such facilities are + inherently more flexible than those defined here as they allow for + language switching in the middle of a string. + + If and when such facilities are developed they SHOULD be used in + preference to the language labelling facilities specified here. Note + that all the mechanisms defined here allow for the omission of + language labels so as to be able to accomodate this possible future + usage. + + + + + + +Freed & Moore Standards Track [Page 7] + +RFC 2184 MIME Parameter Value and Encoded Word Extensions August 1997 + + +9. Security Considerations + + This RFC does not discuss security issues and is not believed to + raise any security issues not already endemic in electronic mail and + present in fully conforming implementations of MIME. + +10. References + + [RFC-822] + Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, August 1982. + + [RFC-1766] + Alvestrand, H., "Tags for the Identification of Languages", RFC + 1766, March 1995. + + [RFC-2045] + Freed, N. and Borenstein, N., "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, Innosoft, First Virtual Holdings, December 1996. + + [RFC-2046] + Freed, N. and Borenstein, N., "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, + First Virtual Holdings, December 1996. + + [RFC-2047] + Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part + Three: Representation of Non-ASCII Text in Internet Message + Headers", RFC 2047, University of Tennessee, December 1996. + + [RFC-2048] + Freed, N., Klensin, J., Postel, J., "Multipurpose Internet Mail + Extensions (MIME) Part Four: MIME Registration Procedures", RFC + 2048, Innosoft, MCI, ISI, December 1996. + + [RFC-2049] + Freed, N. and Borenstein, N., "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and Examples", + RFC 2049, Innosoft, FIrst Virtual Holdings, December 1996. + + [RFC-2060] + Crispin, M., "Internet Message Access Protocol - Version 4rev1", + RFC 2060, December 1996. + + [RFC-2119] + Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + + +Freed & Moore Standards Track [Page 8] + +RFC 2184 MIME Parameter Value and Encoded Word Extensions August 1997 + + + [RFC-2130] + Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, + R., Crispin, M., Svanberg, P., "Report from the IAB Character Set + Workshop", RFC 2130, April 1997. + + [RFC-2183] + Troost, R., Dorner, S., and Moore, K., "Communicating Presentation + Information in Internet Messages: The Content-Disposition + Header", RFC 2183, August 1997. + +11. Authors' Addresses + + Ned Freed + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + tel: +1 818 919 3600 fax: +1 818 919 3614 + email: ned@innosoft.com + + Keith Moore + Computer Science Dept. + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + email: moore@cs.utk.edu + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Moore Standards Track [Page 9] + diff --git a/Documentation/en/rfc/rfc2231.txt b/Documentation/en/rfc/rfc2231.txt new file mode 100644 index 00000000..120f98f8 --- /dev/null +++ b/Documentation/en/rfc/rfc2231.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2231 Innosoft +Updates: 2045, 2047, 2183 K. Moore +Obsoletes: 2184 University of Tennessee +Category: Standards Track November 1997 + + + MIME Parameter Value and Encoded Word Extensions: + Character Sets, Languages, and Continuations + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1997). All Rights Reserved. + +1. Abstract + + This memo defines extensions to the RFC 2045 media type and RFC 2183 + disposition parameter value mechanisms to provide + + (1) a means to specify parameter values in character sets + other than US-ASCII, + + (2) to specify the language to be used should the value be + displayed, and + + (3) a continuation mechanism for long parameter values to + avoid problems with header line wrapping. + + This memo also defines an extension to the encoded words defined in + RFC 2047 to allow the specification of the language to be used for + display as well as the character set. + +2. Introduction + + The Multipurpose Internet Mail Extensions, or MIME [RFC-2045, RFC- + 2046, RFC-2047, RFC-2048, RFC-2049], define a message format that + allows for: + + + + + +Freed & Moore Standards Track [Page 1] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + (1) textual message bodies in character sets other than + US-ASCII, + + (2) non-textual message bodies, + + (3) multi-part message bodies, and + + (4) textual header information in character sets other than + US-ASCII. + + MIME is now widely deployed and is used by a variety of Internet + protocols, including, of course, Internet email. However, MIME's + success has resulted in the need for additional mechanisms that were + not provided in the original protocol specification. + + In particular, existing MIME mechanisms provide for named media type + (content-type field) parameters as well as named disposition + (content-disposition field). A MIME media type may specify any + number of parameters associated with all of its subtypes, and any + specific subtype may specify additional parameters for its own use. A + MIME disposition value may specify any number of associated + parameters, the most important of which is probably the attachment + disposition's filename parameter. + + These parameter names and values end up appearing in the content-type + and content-disposition header fields in Internet email. This + inherently imposes three crucial limitations: + + (1) Lines in Internet email header fields are folded + according to RFC 822 folding rules. This makes long + parameter values problematic. + + (2) MIME headers, like the RFC 822 headers they often + appear in, are limited to 7bit US-ASCII, and the + encoded-word mechanisms of RFC 2047 are not available + to parameter values. This makes it impossible to have + parameter values in character sets other than US-ASCII + without specifying some sort of private per-parameter + encoding. + + (3) It has recently become clear that character set + information is not sufficient to properly display some + sorts of information -- language information is also + needed [RFC-2130]. For example, support for + handicapped users may require reading text string + + + + + + +Freed & Moore Standards Track [Page 2] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + aloud. The language the text is written in is needed + for this to be done correctly. Some parameter values + may need to be displayed, hence there is a need to + allow for the inclusion of language information. + + The last problem on this list is also an issue for the encoded words + defined by RFC 2047, as encoded words are intended primarily for + display purposes. + + This document defines extensions that address all of these + limitations. All of these extensions are implemented in a fashion + that is completely compatible at a syntactic level with existing MIME + implementations. In addition, the extensions are designed to have as + little impact as possible on existing uses of MIME. + + IMPORTANT NOTE: These mechanisms end up being somewhat gibbous when + they actually are used. As such, these mechanisms should not be used + lightly; they should be reserved for situations where a real need for + them exists. + +2.1. Requirements notation + + This document occasionally uses terms that appear in capital letters. + When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" + appear capitalized, they are being used to indicate particular + requirements of this specification. A discussion of the meanings of + these terms appears in [RFC- 2119]. + +3. Parameter Value Continuations + + Long MIME media type or disposition parameter values do not interact + well with header line wrapping conventions. In particular, proper + header line wrapping depends on there being places where linear + whitespace (LWSP) is allowed, which may or may not be present in a + parameter value, and even if present may not be recognizable as such + since specific knowledge of parameter value syntax may not be + available to the agent doing the line wrapping. The result is that + long parameter values may end up getting truncated or otherwise + damaged by incorrect line wrapping implementations. + + A mechanism is therefore needed to break up parameter values into + smaller units that are amenable to line wrapping. Any such mechanism + MUST be compatible with existing MIME processors. This means that + + (1) the mechanism MUST NOT change the syntax of MIME media + type and disposition lines, and + + + + + +Freed & Moore Standards Track [Page 3] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + (2) the mechanism MUST NOT depend on parameter ordering + since MIME states that parameters are not order + sensitive. Note that while MIME does prohibit + modification of MIME headers during transport, it is + still possible that parameters will be reordered when + user agent level processing is done. + + The obvious solution, then, is to use multiple parameters to contain + a single parameter value and to use some kind of distinguished name + to indicate when this is being done. And this obvious solution is + exactly what is specified here: The asterisk character ("*") followed + by a decimal count is employed to indicate that multiple parameters + are being used to encapsulate a single parameter value. The count + starts at 0 and increments by 1 for each subsequent section of the + parameter value. Decimal values are used and neither leading zeroes + nor gaps in the sequence are allowed. + + The original parameter value is recovered by concatenating the + various sections of the parameter, in order. For example, the + content-type field + + Content-Type: message/external-body; access-type=URL; + URL*0="ftp://"; + URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar" + + is semantically identical to + + Content-Type: message/external-body; access-type=URL; + URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar" + + Note that quotes around parameter values are part of the value + syntax; they are NOT part of the value itself. Furthermore, it is + explicitly permitted to have a mixture of quoted and unquoted + continuation fields. + +4. Parameter Value Character Set and Language Information + + Some parameter values may need to be qualified with character set or + language information. It is clear that a distinguished parameter + name is needed to identify when this information is present along + with a specific syntax for the information in the value itself. In + addition, a lightweight encoding mechanism is needed to accommodate 8 + bit information in parameter values. + + + + + + + + +Freed & Moore Standards Track [Page 4] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + Asterisks ("*") are reused to provide the indicator that language and + character set information is present and encoding is being used. A + single quote ("'") is used to delimit the character set and language + information at the beginning of the parameter value. Percent signs + ("%") are used as the encoding flag, which agrees with RFC 2047. + + Specifically, an asterisk at the end of a parameter name acts as an + indicator that character set and language information may appear at + the beginning of the parameter value. A single quote is used to + separate the character set, language, and actual value information in + the parameter value string, and an percent sign is used to flag + octets encoded in hexadecimal. For example: + + Content-Type: application/x-stuff; + title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A + + Note that it is perfectly permissible to leave either the character + set or language field blank. Note also that the single quote + delimiters MUST be present even when one of the field values is + omitted. This is done when either character set, language, or both + are not relevant to the parameter value at hand. This MUST NOT be + done in order to indicate a default character set or language -- + parameter field definitions MUST NOT assign a default character set + or language. + +4.1. Combining Character Set, Language, and Parameter Continuations + + Character set and language information may be combined with the + parameter continuation mechanism. For example: + + Content-Type: application/x-stuff + title*0*=us-ascii'en'This%20is%20even%20more%20 + title*1*=%2A%2A%2Afun%2A%2A%2A%20 + title*2="isn't it!" + + Note that: + + (1) Language and character set information only appear at + the beginning of a given parameter value. + + (2) Continuations do not provide a facility for using more + than one character set or language in the same + parameter value. + + (3) A value presented using multiple continuations may + contain a mixture of encoded and unencoded segments. + + + + + +Freed & Moore Standards Track [Page 5] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + (4) The first segment of a continuation MUST be encoded if + language and character set information are given. + + (5) If the first segment of a continued parameter value is + encoded the language and character set field delimiters + MUST be present even when the fields are left blank. + +5. Language specification in Encoded Words + + RFC 2047 provides support for non-US-ASCII character sets in RFC 822 + message header comments, phrases, and any unstructured text field. + This is done by defining an encoded word construct which can appear + in any of these places. Given that these are fields intended for + display, it is sometimes necessary to associate language information + with encoded words as well as just the character set. This + specification extends the definition of an encoded word to allow the + inclusion of such information. This is simply done by suffixing the + character set specification with an asterisk followed by the language + tag. For example: + + From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu> + +6. IMAP4 Handling of Parameter Values + + IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations + when generating the BODY and BODYSTRUCTURE fetch attributes. + +7. Modifications to MIME ABNF + + The ABNF for MIME parameter values given in RFC 2045 is: + + parameter := attribute "=" value + + attribute := token + ; Matching of attributes + ; is ALWAYS case-insensitive. + + This specification changes this ABNF to: + + parameter := regular-parameter / extended-parameter + + regular-parameter := regular-parameter-name "=" value + + regular-parameter-name := attribute [section] + + attribute := 1*attribute-char + + + + + +Freed & Moore Standards Track [Page 6] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs, + "*", "'", "%", or tspecials> + + section := initial-section / other-sections + + initial-section := "*0" + + other-sections := "*" ("1" / "2" / "3" / "4" / "5" / + "6" / "7" / "8" / "9") *DIGIT) + + extended-parameter := (extended-initial-name "=" + extended-value) / + (extended-other-names "=" + extended-other-values) + + extended-initial-name := attribute [initial-section] "*" + + extended-other-names := attribute other-sections "*" + + extended-initial-value := [charset] "'" [language] "'" + extended-other-values + + extended-other-values := *(ext-octet / attribute-char) + + ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + + charset := <registered character set name> + + language := <registered language tag [RFC-1766]> + + The ABNF given in RFC 2047 for encoded-words is: + + encoded-word := "=?" charset "?" encoding "?" encoded-text "?=" + + This specification changes this ABNF to: + + encoded-word := "=?" charset ["*" language] "?" encoded-text "?=" + +8. Character sets which allow specification of language + + In the future it is likely that some character sets will provide + facilities for inline language labeling. Such facilities are + inherently more flexible than those defined here as they allow for + language switching in the middle of a string. + + + + + + + +Freed & Moore Standards Track [Page 7] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + If and when such facilities are developed they SHOULD be used in + preference to the language labeling facilities specified here. Note + that all the mechanisms defined here allow for the omission of + language labels so as to be able to accommodate this possible future + usage. + +9. Security Considerations + + This RFC does not discuss security issues and is not believed to + raise any security issues not already endemic in electronic mail and + present in fully conforming implementations of MIME. + +10. References + + [RFC-822] + Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822 August 1982. + + [RFC-1766] + Alvestrand, H., "Tags for the Identification of + Languages", RFC 1766, March 1995. + + [RFC-2045] + Freed, N., and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, December 1996. + + [RFC-2046] + Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + December 1996. + + [RFC-2047] + Moore, K., "Multipurpose Internet Mail Extensions (MIME) + Part Three: Representation of Non-ASCII Text in Internet + Message Headers", RFC 2047, December 1996. + + [RFC-2048] + Freed, N., Klensin, J. and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: MIME + Registration Procedures", RFC 2048, December 1996. + + [RFC-2049] + Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049, December 1996. + + + + + +Freed & Moore Standards Track [Page 8] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + [RFC-2060] + Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [RFC-2119] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC-2130] + Weider, C., Preston, C., Simonsen, K., Alvestrand, H., + Atkinson, R., Crispin, M., and P. Svanberg, "Report from the + IAB Character Set Workshop", RFC 2130, April 1997. + + [RFC-2183] + Troost, R., Dorner, S. and K. Moore, "Communicating + Presentation Information in Internet Messages: The + Content-Disposition Header", RFC 2183, August 1997. + +11. Authors' Addresses + + Ned Freed + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 + USA + + Phone: +1 626 919 3600 + Fax: +1 626 919 3614 + EMail: ned.freed@innosoft.com + + + Keith Moore + Computer Science Dept. + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + + EMail: moore@cs.utk.edu + + + + + + + + + + + + +Freed & Moore Standards Track [Page 9] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (1997). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Moore Standards Track [Page 10] + diff --git a/Documentation/en/rfc/rfc2308.txt b/Documentation/en/rfc/rfc2308.txt new file mode 100644 index 00000000..9123a952 --- /dev/null +++ b/Documentation/en/rfc/rfc2308.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group M. Andrews +Request for Comments: 2308 CSIRO +Updates: 1034, 1035 March 1998 +Category: Standards Track + + + Negative Caching of DNS Queries (DNS NCACHE) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + [RFC1034] provided a description of how to cache negative responses. + It however had a fundamental flaw in that it did not allow a name + server to hand out those cached responses to other resolvers, thereby + greatly reducing the effect of the caching. This document addresses + issues raise in the light of experience and replaces [RFC1034 Section + 4.3.4]. + + Negative caching was an optional part of the DNS specification and + deals with the caching of the non-existence of an RRset [RFC2181] or + domain name. + + Negative caching is useful as it reduces the response time for + negative answers. It also reduces the number of messages that have + to be sent between resolvers and name servers hence overall network + traffic. A large proportion of DNS traffic on the Internet could be + eliminated if all resolvers implemented negative caching. With this + in mind negative caching should no longer be seen as an optional part + of a DNS resolver. + + + + + + + + + + + +Andrews Standards Track [Page 1] + +RFC 2308 DNS NCACHE March 1998 + + +1 - Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + "Negative caching" - the storage of knowledge that something does not + exist. We can store the knowledge that a record has a particular + value. We can also do the reverse, that is, to store the knowledge + that a record does not exist. It is the storage of knowledge that + something does not exist, cannot or does not give an answer that we + call negative caching. + + "QNAME" - the name in the query section of an answer, or where this + resolves to a CNAME, or CNAME chain, the data field of the last + CNAME. The last CNAME in this sense is that which contains a value + which does not resolve to another CNAME. Implementations should note + that including CNAME records in responses in order, so that the first + has the label from the query section, and then each in sequence has + the label from the data section of the previous (where more than one + CNAME is needed) allows the sequence to be processed in one pass, and + considerably eases the task of the receiver. Other relevant records + (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs. + + "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as + described in [RFC1035 Section 4.1.1] and the two terms are used + interchangeably in this document. + + "NODATA" - a pseudo RCODE which indicates that the name is valid, for + the given class, but are no records of the given type. A NODATA + response has to be inferred from the answer. + + "FORWARDER" - a nameserver used to resolve queries instead of + directly using the authoritative nameserver chain. The forwarder + typically either has better access to the internet, or maintains a + bigger cache which may be shared amongst many resolvers. How a + server is identified as a FORWARDER, or knows it is a FORWARDER is + outside the scope of this document. However if you are being used as + a forwarder the query will have the recursion desired flag set. + + An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected + when reading this document. + + + + + + + + + +Andrews Standards Track [Page 2] + +RFC 2308 DNS NCACHE March 1998 + + +2 - Negative Responses + + The most common negative responses indicate that a particular RRset + does not exist in the DNS. The first sections of this document deal + with this case. Other negative responses can indicate failures of a + nameserver, those are dealt with in section 7 (Other Negative + Responses). + + A negative response is indicated by one of the following conditions: + +2.1 - Name Error + + Name errors (NXDOMAIN) are indicated by the presence of "Name Error" + in the RCODE field. In this case the domain referred to by the QNAME + does not exist. Note: the answer section may have SIG and CNAME RRs + and the authority section may have SOA, NXT [RFC2065] and SIG RRsets. + + It is possible to distinguish between a referral and a NXDOMAIN + response by the presense of NXDOMAIN in the RCODE regardless of the + presence of NS or SOA records in the authority section. + + NXDOMAIN responses can be categorised into four types by the contents + of the authority section. These are shown below along with a + referral for comparison. Fields not mentioned are not important in + terms of the examples. + + NXDOMAIN RESPONSE: TYPE 1. + + Header: + RDCODE=NXDOMAIN + Query: + AN.EXAMPLE. A + Answer: + AN.EXAMPLE. CNAME TRIPPLE.XX. + Authority: + XX. SOA NS1.XX. HOSTMASTER.NS1.XX. .... + XX. NS NS1.XX. + XX. NS NS2.XX. + Additional: + NS1.XX. A 127.0.0.2 + NS2.XX. A 127.0.0.3 + + NXDOMAIN RESPONSE: TYPE 2. + + Header: + RDCODE=NXDOMAIN + Query: + AN.EXAMPLE. A + + + +Andrews Standards Track [Page 3] + +RFC 2308 DNS NCACHE March 1998 + + + Answer: + AN.EXAMPLE. CNAME TRIPPLE.XX. + Authority: + XX. SOA NS1.XX. HOSTMASTER.NS1.XX. .... + Additional: + <empty> + + NXDOMAIN RESPONSE: TYPE 3. + + Header: + RDCODE=NXDOMAIN + Query: + AN.EXAMPLE. A + Answer: + AN.EXAMPLE. CNAME TRIPPLE.XX. + Authority: + <empty> + Additional: + <empty> + + NXDOMAIN RESPONSE: TYPE 4 + + Header: + RDCODE=NXDOMAIN + Query: + AN.EXAMPLE. A + Answer: + AN.EXAMPLE. CNAME TRIPPLE.XX. + Authority: + XX. NS NS1.XX. + XX. NS NS2.XX. + Additional: + NS1.XX. A 127.0.0.2 + NS2.XX. A 127.0.0.3 + + REFERRAL RESPONSE. + + Header: + RDCODE=NOERROR + Query: + AN.EXAMPLE. A + Answer: + AN.EXAMPLE. CNAME TRIPPLE.XX. + Authority: + XX. NS NS1.XX. + XX. NS NS2.XX. + Additional: + NS1.XX. A 127.0.0.2 + + + +Andrews Standards Track [Page 4] + +RFC 2308 DNS NCACHE March 1998 + + + NS2.XX. A 127.0.0.3 + + Note, in the four examples of NXDOMAIN responses, it is known that + the name "AN.EXAMPLE." exists, and has as its value a CNAME record. + The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to + exist. On the other hand, in the referral example, it is shown that + "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is + known one way or the other about the existence of "TRIPPLE.XX", other + than that "NS1.XX" or "NS2.XX" can be consulted as the next step in + obtaining information about it. + + Where no CNAME records appear, the NXDOMAIN response refers to the + name in the label of the RR in the question section. + +2.1.1 Special Handling of Name Error + + This section deals with errors encountered when implementing negative + caching of NXDOMAIN responses. + + There are a large number of resolvers currently in existence that + fail to correctly detect and process all forms of NXDOMAIN response. + Some resolvers treat a TYPE 1 NXDOMAIN response as a referral. To + alleviate this problem it is recommended that servers that are + authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN + responses, that is the authority section contains a SOA record and no + NS records. If a non- authoritative server sends a type 1 NXDOMAIN + response to one of these old resolvers, the result will be an + unnecessary query to an authoritative server. This is undesirable, + but not fatal except when the server is being used a FORWARDER. If + however the resolver is using the server as a FORWARDER to such a + resolver it will be necessary to disable the sending of TYPE 1 + NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead. + + Some resolvers incorrectly continue processing if the authoritative + answer flag is not set, looping until the query retry threshold is + exceeded and then returning SERVFAIL. This is a problem when your + nameserver is listed as a FORWARDER for such resolvers. If the + nameserver is used as a FORWARDER by such resolver, the authority + flag will have to be forced on for NXDOMAIN responses to these + resolvers. In practice this causes no problems even if turned on + always, and has been the default behaviour in BIND from 4.9.3 + onwards. + +2.2 - No Data + + NODATA is indicated by an answer with the RCODE set to NOERROR and no + relevant answers in the answer section. The authority section will + contain an SOA record, or there will be no NS records there. + + + +Andrews Standards Track [Page 5] + +RFC 2308 DNS NCACHE March 1998 + + + NODATA responses have to be algorithmically determined from the + response's contents as there is no RCODE value to indicate NODATA. + In some cases to determine with certainty that NODATA is the correct + response it can be necessary to send another query. + + The authority section may contain NXT and SIG RRsets in addition to + NS and SOA records. CNAME and SIG records may exist in the answer + section. + + It is possible to distinguish between a NODATA and a referral + response by the presence of a SOA record in the authority section or + the absence of NS records in the authority section. + + NODATA responses can be categorised into three types by the contents + of the authority section. These are shown below along with a + referral for comparison. Fields not mentioned are not important in + terms of the examples. + + NODATA RESPONSE: TYPE 1. + + Header: + RDCODE=NOERROR + Query: + ANOTHER.EXAMPLE. A + Answer: + <empty> + Authority: + EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. .... + EXAMPLE. NS NS1.XX. + EXAMPLE. NS NS2.XX. + Additional: + NS1.XX. A 127.0.0.2 + NS2.XX. A 127.0.0.3 + + NO DATA RESPONSE: TYPE 2. + + Header: + RDCODE=NOERROR + Query: + ANOTHER.EXAMPLE. A + Answer: + <empty> + Authority: + EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. .... + Additional: + <empty> + + + + + +Andrews Standards Track [Page 6] + +RFC 2308 DNS NCACHE March 1998 + + + NO DATA RESPONSE: TYPE 3. + + Header: + RDCODE=NOERROR + Query: + ANOTHER.EXAMPLE. A + Answer: + <empty> + Authority: + <empty> + Additional: + <empty> + + REFERRAL RESPONSE. + + Header: + RDCODE=NOERROR + Query: + ANOTHER.EXAMPLE. A + Answer: + <empty> + Authority: + EXAMPLE. NS NS1.XX. + EXAMPLE. NS NS2.XX. + Additional: + NS1.XX. A 127.0.0.2 + NS2.XX. A 127.0.0.3 + + + These examples, unlike the NXDOMAIN examples above, have no CNAME + records, however they could, in just the same way that the NXDOMAIN + examples did, in which case it would be the value of the last CNAME + (the QNAME) for which NODATA would be concluded. + +2.2.1 - Special Handling of No Data + + There are a large number of resolvers currently in existence that + fail to correctly detect and process all forms of NODATA response. + Some resolvers treat a TYPE 1 NODATA response as a referral. To + alleviate this problem it is recommended that servers that are + authoritative for the NODATA response only send TYPE 2 NODATA + responses, that is the authority section contains a SOA record and no + NS records. Sending a TYPE 1 NODATA response from a non- + authoritative server to one of these resolvers will only result in an + unnecessary query. If a server is listed as a FORWARDER for another + resolver it may also be necessary to disable the sending of TYPE 1 + NODATA response for non-authoritative NODATA responses. + + + + +Andrews Standards Track [Page 7] + +RFC 2308 DNS NCACHE March 1998 + + + Some name servers fail to set the RCODE to NXDOMAIN in the presence + of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA + answer is required in this case the resolver must query again using + the QNAME as the query label. + +3 - Negative Answers from Authoritative Servers + + Name servers authoritative for a zone MUST include the SOA record of + the zone in the authority section of the response when reporting an + NXDOMAIN or indicating that no data of the requested type exists. + This is required so that the response may be cached. The TTL of this + record is set from the minimum of the MINIMUM field of the SOA record + and the TTL of the SOA itself, and indicates how long a resolver may + cache the negative answer. The TTL SIG record associated with the + SOA record should also be trimmed in line with the SOA's TTL. + + If the containing zone is signed [RFC2065] the SOA and appropriate + NXT and SIG records MUST be added. + +4 - SOA Minimum Field + + The SOA minimum field has been overloaded in the past to have three + different meanings, the minimum TTL value of all RRs in a zone, the + default TTL of RRs which did not contain a TTL value and the TTL of + negative responses. + + Despite being the original defined meaning, the first of these, the + minimum TTL value of all RRs in a zone, has never in practice been + used and is hereby deprecated. + + The second, the default TTL of RRs which contain no explicit TTL in + the master zone file, is relevant only at the primary server. After + a zone transfer all RRs have explicit TTLs and it is impossible to + determine whether the TTL for a record was explicitly set or derived + from the default after a zone transfer. Where a server does not + require RRs to include the TTL value explicitly, it should provide a + mechanism, not being the value of the MINIMUM field of the SOA + record, from which the missing TTL values are obtained. How this is + done is implementation dependent. + + The Master File format [RFC 1035 Section 5] is extended to include + the following directive: + + $TTL <TTL> [comment] + + + + + + + +Andrews Standards Track [Page 8] + +RFC 2308 DNS NCACHE March 1998 + + + All resource records appearing after the directive, and which do not + explicitly include a TTL value, have their TTL set to the TTL given + in the $TTL directive. SIG records without a explicit TTL get their + TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5]. + + The remaining of the current meanings, of being the TTL to be used + for negative responses, is the new defined meaning of the SOA minimum + field. + +5 - Caching Negative Answers + + Like normal answers negative answers have a time to live (TTL). As + there is no record in the answer section to which this TTL can be + applied, the TTL must be carried by another method. This is done by + including the SOA record from the zone in the authority section of + the reply. When the authoritative server creates this record its TTL + is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. + This TTL decrements in a similar manner to a normal cached answer and + upon reaching zero (0) indicates the cached negative answer MUST NOT + be used again. + + A negative answer that resulted from a name error (NXDOMAIN) should + be cached such that it can be retrieved and returned in response to + another query for the same <QNAME, QCLASS> that resulted in the + cached negative response. + + A negative answer that resulted from a no data error (NODATA) should + be cached such that it can be retrieved and returned in response to + another query for the same <QNAME, QTYPE, QCLASS> that resulted in + the cached negative response. + + The NXT record, if it exists in the authority section of a negative + answer received, MUST be stored such that it can be be located and + returned with SOA record in the authority section, as should any SIG + records in the authority section. For NXDOMAIN answers there is no + "necessary" obvious relationship between the NXT records and the + QNAME. The NXT record MUST have the same owner name as the query + name for NODATA responses. + + Negative responses without SOA records SHOULD NOT be cached as there + is no way to prevent the negative responses looping forever between a + pair of servers even with a short TTL. + + Despite the DNS forming a tree of servers, with various mis- + configurations it is possible to form a loop in the query graph, e.g. + two servers listing each other as forwarders, various lame server + configurations. Without a TTL count down a cache negative response + + + + +Andrews Standards Track [Page 9] + +RFC 2308 DNS NCACHE March 1998 + + + when received by the next server would have its TTL reset. This + negative indication could then live forever circulating between the + servers involved. + + As with caching positive responses it is sensible for a resolver to + limit for how long it will cache a negative response as the protocol + supports caching for up to 68 years. Such a limit should not be + greater than that applied to positive answers and preferably be + tunable. Values of one to three hours have been found to work well + and would make sensible a default. Values exceeding one day have + been found to be problematic. + +6 - Negative answers from the cache + + When a server, in answering a query, encounters a cached negative + response it MUST add the cached SOA record to the authority section + of the response with the TTL decremented by the amount of time it was + stored in the cache. This allows the NXDOMAIN / NODATA response to + time out correctly. + + If a NXT record was cached along with SOA record it MUST be added to + the authority section. If a SIG record was cached along with a NXT + record it SHOULD be added to the authority section. + + As with all answers coming from the cache, negative answers SHOULD + have an implicit referral built into the answer. This enables the + resolver to locate an authoritative source. An implicit referral is + characterised by NS records in the authority section referring the + resolver towards a authoritative source. NXDOMAIN types 1 and 4 + responses contain implicit referrals as does NODATA type 1 response. + +7 - Other Negative Responses + + Caching of other negative responses is not covered by any existing + RFC. There is no way to indicate a desired TTL in these responses. + Care needs to be taken to ensure that there are not forwarding loops. + +7.1 Server Failure (OPTIONAL) + + Server failures fall into two major classes. The first is where a + server can determine that it has been misconfigured for a zone. This + may be where it has been listed as a server, but not configured to be + a server for the zone, or where it has been configured to be a server + for the zone, but cannot obtain the zone data for some reason. This + can occur either because the zone file does not exist or contains + errors, or because another server from which the zone should have + been available either did not respond or was unable or unwilling to + supply the zone. + + + +Andrews Standards Track [Page 10] + +RFC 2308 DNS NCACHE March 1998 + + + The second class is where the server needs to obtain an answer from + elsewhere, but is unable to do so, due to network failures, other + servers that don't reply, or return server failure errors, or + similar. + + In either case a resolver MAY cache a server failure response. If it + does so it MUST NOT cache it for longer than five (5) minutes, and it + MUST be cached against the specific query tuple <query name, type, + class, server IP address>. + +7.2 Dead / Unreachable Server (OPTIONAL) + + Dead / Unreachable servers are servers that fail to respond in any + way to a query or where the transport layer has provided an + indication that the server does not exist or is unreachable. A + server may be deemed to be dead or unreachable if it has not + responded to an outstanding query within 120 seconds. + + Examples of transport layer indications are: + + ICMP error messages indicating host, net or port unreachable. + TCP resets + IP stack error messages providing similar indications to those above. + + A server MAY cache a dead server indication. If it does so it MUST + NOT be deemed dead for longer than five (5) minutes. The indication + MUST be stored against query tuple <query name, type, class, server + IP address> unless there was a transport layer indication that the + server does not exist, in which case it applies to all queries to + that specific IP address. + +8 - Changes from RFC 1034 + + Negative caching in resolvers is no-longer optional, if a resolver + caches anything it must also cache negative answers. + + Non-authoritative negative answers MAY be cached. + + The SOA record from the authority section MUST be cached. Name error + indications must be cached against the tuple <query name, QCLASS>. + No data indications must be cached against <query name, QTYPE, + QCLASS> tuple. + + A cached SOA record must be added to the response. This was + explicitly not allowed because previously the distinction between a + normal cached SOA record, and the SOA cached as a result of a + negative response was not made, and simply extracting a normal cached + SOA and adding that to a cached negative response causes problems. + + + +Andrews Standards Track [Page 11] + +RFC 2308 DNS NCACHE March 1998 + + + The $TTL TTL directive was added to the master file format. + +9 - History of Negative Caching + + This section presents a potted history of negative caching in the DNS + and forms no part of the technical specification of negative caching. + + It is interesting to note that the same concepts were re-invented in + both the CHIVES and BIND servers. + + The history of the early CHIVES work (Section 9.1) was supplied by + Rob Austein <sra@epilogue.com> and is reproduced here in the form in + which he supplied it [MPA]. + + Sometime around the spring of 1985, I mentioned to Paul Mockapetris + that our experience with his JEEVES DNS resolver had pointed out the + need for some kind of negative caching scheme. Paul suggested that + we simply cache authoritative errors, using the SOA MINIMUM value for + the zone that would have contained the target RRs. I'm pretty sure + that this conversation took place before RFC-973 was written, but it + was never clear to me whether this idea was something that Paul came + up with on the spot in response to my question or something he'd + already been planning to put into the document that became RFC-973. + In any case, neither of us was entirely sure that the SOA MINIMUM + value was really the right metric to use, but it was available and + was under the control of the administrator of the target zone, both + of which seemed to us at the time to be important feature. + + Late in 1987, I released the initial beta-test version of CHIVES, the + DNS resolver I'd written to replace Paul's JEEVES resolver. CHIVES + included a search path mechanism that was used pretty heavily at + several sites (including my own), so CHIVES also included a negative + caching mechanism based on SOA MINIMUM values. The basic strategy + was to cache authoritative error codes keyed by the exact query + parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the + SOA MINIMUM value. CHIVES did not attempt to track down SOA RRs if + they weren't supplied in the authoritative response, so it never + managed to completely eliminate the gratuitous DNS error message + traffic, but it did help considerably. Keep in mind that this was + happening at about the same time as the near-collapse of the ARPANET + due to congestion caused by exponential growth and the the "old" + (pre-VJ) TCP retransmission algorithm, so negative caching resulted + in drasticly better DNS response time for our users, mailer daemons, + etcetera. + + + + + + + +Andrews Standards Track [Page 12] + +RFC 2308 DNS NCACHE March 1998 + + + As far as I know, CHIVES was the first resolver to implement negative + caching. CHIVES was developed during the twilight years of TOPS-20, + so it never ran on very many machines, but the few machines that it + did run on were the ones that were too critical to shut down quickly + no matter how much it cost to keep them running. So what few users + we did have tended to drive CHIVES pretty hard. Several interesting + bits of DNS technology resulted from that, but the one that's + relevant here is the MAXTTL configuration parameter. + + Experience with JEEVES had already shown that RRs often showed up + with ridiculously long TTLs (99999999 was particularly popular for + many years, due to bugs in the code and documentation of several + early versions of BIND), and that robust software that blindly + believed such TTLs could create so many strange failures that it was + often necessary to reboot the resolver frequently just to clear this + garbage out of the cache. So CHIVES had a configuration parameter + "MAXTTL", which specified the maximum "reasonable" TTL in a received + RR. RRs with TTLs greater than MAXTTL would either have their TTLs + reduced to MAXTTL or would be discarded entirely, depending on the + setting of another configuration parameter. + + When we started getting field experience with CHIVES's negative + caching code, it became clear that the SOA MINIMUM value was often + large enough to cause the same kinds of problems for negative caching + as the huge TTLs in RRs had for normal caching (again, this was in + part due to a bug in several early versions of BIND, where a + secondary server would authoritatively deny all knowledge of its + zones if it couldn't contact the primaries on reboot). So we started + running the negative cache TTLs through the MAXTTL check too, and + continued to experiment. + + The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL + (last of the major Internet TOPS-20 machines to be shut down, thus + the last major user of CHIVES, thus the place where we had the + longest experimental baseline) was to set MAXTTL to about three days. + Most of the traffic initiated by SIMTEL20 in its last years was + mail-related, and the mail queue timeout was set to one week, so this + gave a "stuck" message several tries at complete DNS resolution, + without bogging down the system with a lot of useless queries. Since + (for reasons that now escape me) we only had the single MAXTTL + parameter rather than separate ones for positive and negative + caching, it's not clear how much effect this setting of MAXTTL had on + the negative caching code. + + CHIVES also included a second, somewhat controversial mechanism which + took the place of negative caching in some cases. The CHIVES + resolver daemon could be configured to load DNS master files, giving + it the ability to act as what today would be called a "stealth + + + +Andrews Standards Track [Page 13] + +RFC 2308 DNS NCACHE March 1998 + + + secondary". That is, when configured in this way, the resolver had + direct access to authoritative information for heavily-used zones. + The search path mechanisms in CHIVES reflected this: there were + actually two separate search paths, one of which only searched local + authoritative zone data, and one which could generate normal + iterative queries. This cut down on the need for negative caching in + cases where usage was predictably heavy (e.g., the resolver on + XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and + AI.MIT.EDU and put both of these suffixes into the "local" search + path, since between them the hosts in these two zones accounted for + the bulk of the DNS traffic). Not all sites running CHIVES chose to + use this feature; C.CS.CMU.EDU, for example, chose to use the + "remote" search path for everything because there were too many + different sub-zones at CMU for zone shadowing to be practical for + them, so they relied pretty heavily on negative caching even for + local traffic. + + Overall, I still think the basic design we used for negative caching + was pretty reasonable: the zone administrator specified how long to + cache negative answers, and the resolver configuration chose the + actual cache time from the range between zero and the period + specified by the zone administrator. There are a lot of details I'd + do differently now (like using a new SOA field instead of overloading + the MINIMUM field), but after more than a decade, I'd be more worried + if we couldn't think of at least a few improvements. + +9.2 BIND + + While not the first attempt to get negative caching into BIND, in + July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that + implemented, validation and negative caching (NCACHE). This code had + a 10 minute TTL for negative caching and only cached the indication + that there was a negative response, NXDOMAIN or NOERROR_NODATA. This + is the origin of the NODATA pseudo response code mentioned above. + + Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA + record such that it could be retrieved by a similar query. UUnet + complained that they were getting old answers after loading a new + zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994. + In reality this indicated that the named needed to purge the space + the zone would occupy. Functionality to do this was added in BIND + 4.9.3 BETA11 patch2, December 1994. + + RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996. + + + + + + + +Andrews Standards Track [Page 14] + +RFC 2308 DNS NCACHE March 1998 + + +10 Example + + The following example is based on a signed zone that is empty apart + from the nameservers. We will query for WWW.XX.EXAMPLE showing + initial response and again 10 minutes later. Note 1: during the + intervening 10 minutes the NS records for XX.EXAMPLE have expired. + Note 2: the TTL of the SIG records are not explicitly set in the zone + file and are hence the TTL of the RRset they are the signature for. + + Zone File: + + $TTL 86400 + $ORIGIN XX.EXAMPLE. + @ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. ( + 1997102000 ; serial + 1800 ; refresh (30 mins) + 900 ; retry (15 mins) + 604800 ; expire (7 days) + 1200 ) ; minimum (20 mins) + IN SIG SOA ... + 1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY + IN SIG NXT ... XX.EXAMPLE. ... + 300 IN NS NS1.XX.EXAMPLE. + 300 IN NS NS2.XX.EXAMPLE. + IN SIG NS ... XX.EXAMPLE. ... + IN KEY 0x4100 1 1 ... + IN SIG KEY ... XX.EXAMPLE. ... + IN SIG KEY ... EXAMPLE. ... + NS1 IN A 10.0.0.1 + IN SIG A ... XX.EXAMPLE. ... + 1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG + IN SIG NXT ... + NS2 IN A 10.0.0.2 + IN SIG A ... XX.EXAMPLE. ... + 1200 IN NXT XX.EXAMPLE. A NXT SIG + IN SIG NXT ... XX.EXAMPLE. ... + + Initial Response: + + Header: + RDCODE=NXDOMAIN, AA=1, QR=1, TC=0 + Query: + WWW.XX.EXAMPLE. IN A + Answer: + <empty> + Authority: + XX.EXAMPLE. 1200 IN SOA NS1.XX.EXAMPLE. ... + XX.EXAMPLE. 1200 IN SIG SOA ... XX.EXAMPLE. ... + + + +Andrews Standards Track [Page 15] + +RFC 2308 DNS NCACHE March 1998 + + + NS2.XX.EXAMPLE. 1200 IN NXT XX.EXAMPLE. NXT A NXT SIG + NS2.XX.EXAMPLE. 1200 IN SIG NXT ... XX.EXAMPLE. ... + XX.EXAMPLE. 86400 IN NS NS1.XX.EXAMPLE. + XX.EXAMPLE. 86400 IN NS NS2.XX.EXAMPLE. + XX.EXAMPLE. 86400 IN SIG NS ... XX.EXAMPLE. ... + Additional + XX.EXAMPLE. 86400 IN KEY 0x4100 1 1 ... + XX.EXAMPLE. 86400 IN SIG KEY ... EXAMPLE. ... + NS1.XX.EXAMPLE. 86400 IN A 10.0.0.1 + NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ... + NS2.XX.EXAMPLE. 86400 IN A 10.0.0.2 + NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ... + + After 10 Minutes: + + Header: + RDCODE=NXDOMAIN, AA=0, QR=1, TC=0 + Query: + WWW.XX.EXAMPLE. IN A + Answer: + <empty> + Authority: + XX.EXAMPLE. 600 IN SOA NS1.XX.EXAMPLE. ... + XX.EXAMPLE. 600 IN SIG SOA ... XX.EXAMPLE. ... + NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG + NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ... + EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE. + EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE. + EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ... + Additional + XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ... + XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ... + NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1 + NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... + NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2 + NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... + EXAMPLE. 65799 IN KEY 0x4100 1 1 ... + EXAMPLE. 65799 IN SIG KEY ... . ... + + +11 Security Considerations + + It is believed that this document does not introduce any significant + additional security threats other that those that already exist when + using data from the DNS. + + + + + + +Andrews Standards Track [Page 16] + +RFC 2308 DNS NCACHE March 1998 + + + With negative caching it might be possible to propagate a denial of + service attack by spreading a NXDOMAIN message with a very high TTL. + Without negative caching that would be much harder. A similar effect + could be achieved previously by spreading a bad A record, so that the + server could not be reached - which is almost the same. It has the + same effect as far as what the end user is able to do, but with a + different psychological effect. With the bad A, I feel "damn the + network is broken again" and try again tomorrow. With the "NXDOMAIN" + I feel "Oh, they've turned off the server and it doesn't exist any + more" and probably never bother trying this server again. + + A practical example of this is a SMTP server where this behaviour is + encoded. With a NXDOMAIN attack the mail message would bounce + immediately, where as with a bad A attack the mail would be queued + and could potentially get through after the attack was suspended. + + For such an attack to be successful, the NXDOMAIN indiction must be + injected into a parent server (or a busy caching resolver). One way + this might be done by the use of a CNAME which results in the parent + server querying an attackers server. Resolvers that wish to prevent + such attacks can query again the final QNAME ignoring any NS data in + the query responses it has received for this query. + + Implementing TTL sanity checking will reduce the effectiveness of + such an attack, because a successful attack would require re- + injection of the bogus data at more frequent intervals. + + DNS Security [RFC2065] provides a mechanism to verify whether a + negative response is valid or not, through the use of NXT and SIG + records. This document supports the use of that mechanism by + promoting the transmission of the relevant security records even in a + non security aware server. + +Acknowledgments + + I would like to thank Rob Austein for his history of the CHIVES + nameserver. The DNSIND working group, in particular Robert Elz for + his valuable technical and editorial contributions to this document. + + + + + + + + + + + + + +Andrews Standards Track [Page 17] + +RFC 2308 DNS NCACHE March 1998 + + +References + + [RFC1034] + Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES," + STD 13, RFC 1034, November 1987. + + [RFC1035] + Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND + SPECIFICATION," STD 13, RFC 1035, November 1987. + + [RFC2065] + Eastlake, D., and C. Kaufman, "Domain Name System Security + Extensions," RFC 2065, January 1997. + + [RFC2119] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels," BCP 14, RFC 2119, March 1997. + + [RFC2181] + Elz, R., and R. Bush, "Clarifications to the DNS + Specification," RFC 2181, July 1997. + +Author's Address + + Mark Andrews + CSIRO - Mathematical and Information Sciences + Locked Bag 17 + North Ryde NSW 2113 + AUSTRALIA + + Phone: +61 2 9325 3148 + EMail: Mark.Andrews@cmis.csiro.au + + + + + + + + + + + + + + + + + + + +Andrews Standards Track [Page 18] + +RFC 2308 DNS NCACHE March 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Andrews Standards Track [Page 19] + diff --git a/Documentation/en/rfc/rfc2376.txt b/Documentation/en/rfc/rfc2376.txt new file mode 100644 index 00000000..73bc3cf3 --- /dev/null +++ b/Documentation/en/rfc/rfc2376.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group E. Whitehead +Request for Comments: 2376 UC Irvine +Category: Informational M. Murata + Fuji Xerox Info. Systems + July 1998 + + + XML Media Types + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This document proposes two new media subtypes, text/xml and + application/xml, for use in exchanging network entities which are + conforming Extensible Markup Language (XML). XML entities are + currently exchanged via the HyperText Transfer Protocol on the World + Wide Web, are an integral part of the WebDAV protocol for remote web + authoring, and are expected to have utility in many domains. + +Table of Contents + + 1 INTRODUCTION ....................................................2 + 2 NOTATIONAL CONVENTIONS ..........................................3 + 3 XML MEDIA TYPES .................................................3 + 3.1 Text/xml Registration ........................................3 + 3.2 Application/xml Registration .................................6 + 4 SECURITY CONSIDERATIONS .........................................8 + 5 THE BYTE ORDER MARK (BOM) AND CONVERSIONS TO/FROM UTF-16 ........9 + 6 EXAMPLES ........................................................9 + 6.1 text/xml with UTF-8 Charset .................................10 + 6.2 text/xml with UTF-16 Charset ................................10 + 6.3 text/xml with ISO-2022-KR Charset ...........................10 + 6.4 text/xml with Omitted Charset ...............................11 + 6.5 application/xml with UTF-16 Charset .........................11 + 6.6 application/xml with ISO-2022-KR Charset ....................11 + 6.7 application/xml with Omitted Charset and UTF-16 XML Entity ..12 + 6.8 application/xml with Omitted Charset and UTF-8 Entity .......12 + 6.9 application/xml with Omitted Charset and Internal Encoding + Declaration.......................................................12 + + + +Whitehead & Murata Informational [Page 1] + +RFC 2376 XML Media Types July 1998 + + + 7 REFERENCES .....................................................13 + 8 ACKNOWLEDGEMENTS ...............................................14 + 9 ADDRESSES OF AUTHORS ...........................................14 + 10 FULL COPYRIGHT STATEMENT ......................................15 + +1 Introduction + + The World Wide Web Consortium (W3C) has issued a Recommendation + [REC-XML] which defines the Extensible Markup Language (XML), version + 1. To enable the exchange of XML network entities, this document + proposes two new media types, text/xml and application/xml. + + XML entities are currently exchanged on the World Wide Web, and XML + is also used for property values and parameter marshalling by the + WebDAV protocol for remote web authoring. Thus, there is a need for a + media type to properly label the exchange of XML network entities. + (Note that, as sometimes happens between two communities, both MIME + and XML have defined the term entity, with different meanings.) + + Although XML is a subset of the Standard Generalized Markup Language + (SGML) [ISO-8897], and currently is assigned the media types + text/sgml and application/sgml, there are several reasons why use of + text/sgml or application/sgml to label XML is inappropriate. First, + there exist many applications which can process XML, but which cannot + process SGML, due to SGML's larger feature set. Second, SGML + applications cannot always process XML entities, because XML uses + features of recent technical corrigenda to SGML. Third, the + definition of text/sgml and application/sgml [RFC-1874] includes + parameters for SGML bit combination transformation format (SGML- + bctf), and SGML boot attribute (SGML-boot). Since XML does not use + these parameters, it would be ambiguous if such parameters were given + for an XML entity. For these reasons, the best approach for labeling + XML network entities is to provide new media types for XML. + + Since XML is an integral part of the WebDAV Distributed Authoring + Protocol, and since World Wide Web Consortium Recommendations have + conventionally been assigned IETF tree media types, and since similar + media types (HTML, SGML) have been assigned IETF tree media types, + the XML media types also belong in the IETF media types tree. + + + + + + + + + + + + +Whitehead & Murata Informational [Page 2] + +RFC 2376 XML Media Types July 1998 + + +2 Notational Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + +3 XML Media Types + + This document introduces two new media types for XML entities, + text/xml and application/xml. Registration information for these + media types are described in the sections below. + + Every XML entity is suitable for use with the application/xml media + type without modification. But this does not exploit the fact that + XML can be treated as plain text in many cases. MIME user agents + (and web user agents) that do not have explicit support for + application/xml will treat it as application/octet-stream, for + example, by offering to save it to a file. + + To indicate that an XML entity should be treated as plain text by + default, use the text/xml media type. This restricts the encoding + used in the XML entity to those that are compatible with the + requirements for text media types as described in [RFC-2045] and + [RFC-2046], e.g., UTF-8, but not UTF-16 (except for HTTP). + + XML provides a general framework for defining sequences of structured + data. In some cases, it may be desirable to define new media types + which use XML but define a specific application of XML, perhaps due + to domain-specific security considerations or runtime information. + This document does not prohibit future media types dedicated to such + XML applications. However, developers of such media types are + recommended to use this document as a basis. In particular, the + charset parameter should be used in the same manner. + + Within the XML specification, XML entities can be classified into + four types. In the XML terminology, they are called "document + entities", "external DTD subsets", "external parsed entities", and + "external parameter entities". The media types text/xml and + application/xml can be used for any of these four types. + +3.1 Text/xml Registration + + MIME media type name: text + + MIME subtype name: xml + + Mandatory parameters: none + + + + +Whitehead & Murata Informational [Page 3] + +RFC 2376 XML Media Types July 1998 + + + Optional parameters: charset + + Although listed as an optional parameter, the use of the charset + parameter is STRONGLY RECOMMENDED, since this information can be + used by XML processors to determine authoritatively the character + encoding of the XML entity. The charset parameter can also be used + to provide protocol-specific operations, such as charset-based + content negotiation in HTTP. "UTF-8" [RFC-2279] is the + recommended value, representing the UTF-8 charset. UTF-8 is + supported by all conforming XML processors [REC-XML]. + + If the XML entity is transmitted via HTTP, which uses a MIME-like + mechanism that is exempt from the restrictions on the text top- + level type (see section 19.4.1 of HTTP 1.1 [RFC-2068]), "UTF-16" + (Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646]) is also + recommended. UTF-16 is supported by all conforming XML processors + [REC-XML]. Since the handling of CR, LF and NUL for text types in + most MIME applications would cause undesired transformations of + individual octets in UTF-16 multi-octet characters, gateways from + HTTP to these MIME applications MUST transform the XML entity from + a text/xml; charset="utf-16" to application/xml; charset="utf-16". + + Conformant with [RFC-2046], if a text/xml entity is received with + the charset parameter omitted, MIME processors and XML processors + MUST use the default charset value of "us-ascii". In cases where + the XML entity is transmitted via HTTP, the default charset value + is still "us-ascii". + + Since the charset parameter is authoritative, the charset is not + always declared within an XML encoding declaration. Thus, special + care is needed when the recipient strips the MIME header and + provides persistent storage of the received XML entity (e.g., in a + file system). Unless the charset is UTF-8 or UTF-16, the recipient + SHOULD also persistently store information about the charset, + perhaps by embedding a correct XML encoding declaration within the + XML entity. + + Encoding considerations: + + This media type MAY be encoded as appropriate for the charset and + the capabilities of the underlying MIME transport. For 7-bit + transports, data in both UTF-8 and UTF-16 is encoded in quoted- + printable or base64. For 8-bit clean transport (e.g., ESMTP, + 8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64 + encoded. For binary clean transports (e.g., HTTP), no content- + transfer-encoding is necessary. + + + + + +Whitehead & Murata Informational [Page 4] + +RFC 2376 XML Media Types July 1998 + + + Security considerations: + + See section 4 below. + + Interoperability considerations: + + XML has proven to be interoperable across WebDAV clients and + servers, and for import and export from multiple XML authoring + tools. + + Published specification: see [REC-XML] + + Applications which use this media type: + + XML is device-, platform-, and vendor-neutral and is supported by + a wide range of Web user agents, WebDAV clients and servers, as + well as XML authoring tools. + + Additional information: + + Magic number(s): none + + Although no byte sequences can be counted on to always be present, + XML entities in ASCII-compatible charsets (including UTF-8) often + begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"). For more + information, see Appendix F of [REC-XML]. + + File extension(s): .xml, .dtd + Macintosh File Type Code(s): "TEXT" + + Person & email address for further information: + + Dan Connolly <connolly@w3.org> + Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp> + + Intended usage: COMMON + + Author/Change controller: + + The XML specification is a work product of the World Wide Web + Consortium's XML Working Group, and was edited by: + + Tim Bray <tbray@textuality.com> + Jean Paoli <jeanpa@microsoft.com> + C. M. Sperberg-McQueen <cmsmcq@uic.edu> + + The W3C, and the W3C XML working group, has change control over + the XML specification. + + + +Whitehead & Murata Informational [Page 5] + +RFC 2376 XML Media Types July 1998 + + +3.2 Application/xml Registration + + MIME media type name: application + + MIME subtype name: xml + + Mandatory parameters: none + + Optional parameters: charset + + Although listed as an optional parameter, the use of the charset + parameter is STRONGLY RECOMMENDED, since this information can be + used by XML processors to determine authoritatively the charset of + the XML entity. The charset parameter can also be used to provide + protocol-specific operations, such as charset-based content + negotiation in HTTP. + + "UTF-8" [RFC-2279] and "UTF-16" (Appendix C.3 of [UNICODE] and + Amendment 1 of [ISO-10646]) are the recommended values, + representing the UTF-8 and UTF-16 charsets, respectively. These + charsets are preferred since they are supported by all conforming + XML processors [REC-XML]. + + If an application/xml entity is received where the charset + parameter is omitted, no information is being provided about the + charset by the MIME Content-Type header. Conforming XML processors + MUST follow the requirements in section 4.3.3 of [REC-XML] which + directly address this contingency. However, MIME processors which + are not XML processors should not assume a default charset if the + charset parameter is omitted from an application/xml entity. + + Since the charset parameter is authoritative, the charset is not + always declared within an XML encoding declaration. Thus, special + care is needed when the recipient strips the MIME header and + provides persistent storage of the received XML entity (e.g., in a + file system). Unless the charset is UTF-8 or UTF-16, the + recipient SHOULD also persistently store information about the + charset, perhaps by embedding a correct XML encoding declaration + within the XML entity. + + + + + + + + + + + + +Whitehead & Murata Informational [Page 6] + +RFC 2376 XML Media Types July 1998 + + + Encoding considerations: + + This media type MAY be encoded as appropriate for the charset and + the capabilities of the underlying MIME transport. For 7-bit + transports, data in both UTF-8 and UTF-16 is encoded in quoted- + printable or base64. For 8-bit clean transport (e.g., ESMTP, + 8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64 + encoded. For binary clean transport (e.g., HTTP), no content- + transfer-encoding is necessary. + + Security considerations: + + See section 4 below. + + Interoperability considerations: + + XML has proven to be interoperable for import and export from + multiple XML authoring tools. + + Published specification: see [REC-XML] + + Applications which use this media type: + + XML is device-, platform-, and vendor-neutral and is supported by + a wide range of Web user agents and XML authoring tools. + + Additional information: + + Magic number(s): none + + Although no byte sequences can be counted on to always be present, + XML entities in ASCII-compatible charsets (including UTF-8) often + begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in + UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D + or FF FE 3C 00 3F 00 78 00 6D 00 (the Byte Order Mark (BOM) + followed by "<?xml"). For more information, see Annex F of [REC- + XML]. + + File extension(s): .xml, .dtd + Macintosh File Type Code(s): "TEXT" + + Person & email address for further information: + + Dan Connolly <connolly@w3.org> + Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp> + + Intended usage: COMMON + + + + +Whitehead & Murata Informational [Page 7] + +RFC 2376 XML Media Types July 1998 + + + Author/Change controller: + + The XML specification is a work product of the World Wide Web + Consortium's XML Working Group, and was edited by: + + Tim Bray <tbray@textuality.com> + Jean Paoli <jeanpa@microsoft.com> + C. M. Sperberg-McQueen <cmsmcq@uic.edu> + + The W3C, and the W3C XML working group, has change control over + the XML specification. + +4 Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in [RFC-1874]. + + To paraphrase section 3 of [RFC-1874], XML entities contain + information to be parsed and processed by the recipient's XML system. + These entities may contain and such systems may permit explicit + system level commands to be executed while processing the data. To + the extent that an XML system will execute arbitrary command strings, + recipients of XML entities may be at risk. In general, it may be + possible to specify commands that perform unauthorized file + operations or make changes to the display processor's environment + that affect subsequent operations. + + Use of XML is expected to be varied, and widespread. XML is under + scrutiny by a wide range of communities for use as a common syntax + for community-specific metadata. For example, the Dublin Core group + is using XML for document metadata, and a new effort has begun which + is considering use of XML for medical information. Other groups view + XML as a mechanism for marshalling parameters for remote procedure + calls. More uses of XML will undoubtedly arise. + + Security considerations will vary by domain of use. For example, XML + medical records will have much more stringent privacy and security + considerations than XML library metadata. Similarly, use of XML as a + parameter marshalling syntax necessitates a case by case security + review. + + XML may also have some of the same security concerns as plain text. + Like plain text, XML can contain escape sequences which, when + displayed, have the potential to change the display processor + environment in ways that adversely affect subsequent operations. + Possible effects include, but are not limited to, locking the + keyboard, changing display parameters so subsequent displayed text is + unreadable, or even changing display parameters to deliberately + + + +Whitehead & Murata Informational [Page 8] + +RFC 2376 XML Media Types July 1998 + + + obscure or distort subsequent displayed material so that its meaning + is lost or altered. Display processors should either filter such + material from displayed text or else make sure to reset all important + settings after a given display operation is complete. + + Some terminal devices have keys whose output, when pressed, can be + changed by sending the display processor a character sequence. If + this is possible the display of a text object containing such + character sequences could reprogram keys to perform some illicit or + dangerous action when the key is subsequently pressed by the user. + In some cases not only can keys be programmed, they can be triggered + remotely, making it possible for a text display operation to directly + perform some unwanted action. As such, the ability to program keys + should be blocked either by filtering or by disabling the ability to + program keys entirely. + + Note that it is also possible to construct XML documents which make + use of what XML terms "entity references" (using the XML meaning of + the term "entity", which differs from the MIME definition of this + term), to construct repeated expansions of text. Recursive expansions + are prohibited [REC-XML] and XML processors are required to detect + them. However, even non-recursive expansions may cause problems with + the finite computing resources of computers, if they are performed + many times. + +5 The Byte Order Mark (BOM) and Conversions to/from UTF-16 + + The XML Recommendation, in section 4.3.3, specifies that UTF-16 XML + entities must begin with a byte order mark (BOM), which is the ZERO + WIDTH NO-BREAK SPACE character, hexadecimal sequence 0xFEFF (or + 0xFFFE, depending on endian). The XML Recommendation further states + that the BOM is an encoding signature, and is not part of either the + markup or the character data of the XML document. + + Due to the BOM, applications which convert XML from the UTF-16 + encoding to another encoding SHOULD strip the BOM before conversion. + Similarly, when converting from another encoding into UTF-16, the BOM + SHOULD be added after conversion is complete. + +6 Examples + + The examples below give the value of the Content-type MIME header and + the XML declaration (which includes the encoding declaration) inside + the XML entity. For UTF-16 examples, the Byte Order Mark character + is denoted as "{BOM}", and the XML declaration is assumed to come at + the beginning of the XML entity, immediately following the BOM. Note + that other MIME headers may be present, and the XML entity may + + + + +Whitehead & Murata Informational [Page 9] + +RFC 2376 XML Media Types July 1998 + + + contain other data in addition to the XML declaration; the examples + focus on the Content-type header and the encoding declaration for + clarity. + +6.1 text/xml with UTF-8 Charset + + Content-type: text/xml; charset="utf-8" + + <?xml version="1.0" encoding="utf-8"?> + + This is the recommended charset value for use with text/xml. Since + the charset parameter is provided, MIME and XML processors must treat + the enclosed entity as UTF-8 encoded. + + If sent using a 7-bit transport (e.g. SMTP), the XML entity must use + a content-transfer-encoding of either quoted-printable or base64. + For an 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), or a + binary clean transport (e.g., HTTP) no content-transfer-encoding is + necessary. + +6.2 text/xml with UTF-16 Charset + + Content-type: text/xml; charset="utf-16" + + {BOM}<?xml version='1.0' encoding='utf-16'?> + + This is possible only when the XML entity is transmitted via HTTP, + which uses a MIME-like mechanism and is a binary-clean protocol, + hence does not perform CR and LF transformations and allows NUL + octets. This differs from typical text MIME type processing (see + section 19.4.1 of HTTP 1.1 [RFC-2068] for details). + + Since HTTP is binary clean, no content-transfer-encoding is + necessary. + +6.3 text/xml with ISO-2022-KR Charset + + Content-type: text/xml; charset="iso-2022-kr" + + <?xml version="1.0" encoding='iso-2022-kr'?> + + This example shows text/xml with a Korean charset (e.g., Hangul) + encoded following the specification in [RFC-1557]. Since the charset + parameter is provided, MIME and XML processors must treat the + enclosed entity as encoded per [RFC-1557]. + + Since ISO-2022-KR has been defined to use only 7 bits of data, no + content-transfer-encoding is necessary with any transport. + + + +Whitehead & Murata Informational [Page 10] + +RFC 2376 XML Media Types July 1998 + + +6.4 text/xml with Omitted Charset + + Content-type: text/xml + + {BOM}<?xml version="1.0" encoding="utf-16"?> + + This example shows text/xml with the charset parameter omitted. In + this case, MIME and XML processors must assume the charset is "us- + ascii", the default charset value for text media types specified in + [RFC-2046]. The default of "us-ascii" holds even if the text/xml + entity is transported using HTTP. + + Omitting the charset parameter is NOT RECOMMENDED for text/xml. For + example, even if the contents of the XML entity are UTF-16 or UTF-8, + or the XML entity has an explicit encoding declaration, XML and MIME + processors must assume the charset is "us-ascii". + +6.5 application/xml with UTF-16 Charset + + Content-type: application/xml; charset="utf-16" + + {BOM}<?xml version="1.0"?> + + This is a recommended charset value for use with application/xml. + Since the charset parameter is provided, MIME and XML processors must + treat the enclosed entity as UTF-16 encoded. + + If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean + transport (e.g., ESMTP, 8BITMIME, or NNTP), the XML entity must be + encoded in quoted-printable or base64. For a binary clean transport + (e.g., HTTP), no content-transfer-encoding is necessary. + +6.6 application/xml with ISO-2022-KR Charset + + Content-type: application/xml; charset="iso-2022-kr" + + <?xml version="1.0" encoding="iso-2022-kr"?> + + This example shows application/xml with a Korean charset (e.g., + Hangul) encoded following the specification in [RFC-1557]. Since the + charset parameter is provided, MIME and XML processors must treat the + enclosed entity as encoded per [RFC-1557], independent of whether the + XML entity has an internal encoding declaration (this example does + show such a declaration, which agrees with the charset parameter). + + Since ISO-2022-KR has been defined to use only 7 bits of data, no + content-transfer-encoding is necessary with any transport. + + + + +Whitehead & Murata Informational [Page 11] + +RFC 2376 XML Media Types July 1998 + + +6.7 application/xml with Omitted Charset and UTF-16 XML Entity + + Content-type: application/xml + + {BOM}<?xml version='1.0'?> + + For this example, the XML entity begins with a BOM. Since the + charset has been omitted, a conforming XML processor follows the + requirements of [REC-XML], section 4.3.3. Specifically, the XML + processor reads the BOM, and thus knows deterministically that the + charset encoding is UTF-16. + + An XML-unaware MIME processor should make no assumptions about the + charset of the XML entity. + +6.8 application/xml with Omitted Charset and UTF-8 Entity + + Content-type: application/xml + + <?xml version='1.0'?> + + In this example, the charset parameter has been omitted, and there is + no BOM. Since there is no BOM, the XML processor follows the + requirements in section 4.3.3, and optionally applies the mechanism + described in appendix F (which is non-normative) of [REC-XML] to + determine the charset encoding of UTF-8. The XML entity does not + contain an encoding declaration, but since the encoding is UTF-8, + this is still a conforming XML entity. + + An XML-unaware MIME processor should make no assumptions about the + charset of the XML entity. + +6.9 application/xml with Omitted Charset and Internal Encoding + Declaration + + Content-type: application/xml + + <?xml version='1.0' encoding="ISO-10646-UCS-4"?> + + In this example, the charset parameter has been omitted, and there is + no BOM. However, the XML entity does have an encoding declaration + inside the XML entity which specifies the entity's charset. Following + the requirements in section 4.3.3, and optionally applying the + mechanism described in appendix F (non-normative) of [REC-XML], the + XML processor determines the charset encoding of the XML entity (in + this example, UCS-4). + + + + + +Whitehead & Murata Informational [Page 12] + +RFC 2376 XML Media Types July 1998 + + + An XML-unaware MIME processor should make no assumptions about the + charset of the XML entity. + +7 References + + [ISO-10646] ISO/IEC, Information Technology - Universal Multiple- + Octet Coded Character Set (UCS) - Part 1: Architecture + and Basic Multilingual Plane, May 1993. + + [ISO-8897] ISO (International Organization for Standardization) ISO + 8879:1986(E) Information Processing -- Text and Office + Systems -- Standard Generalized Markup Language (SGML). + First edition -- 1986- 10-15. + + [REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210. + + [RFC-1557] Choi, U., Chon, K., and H. Park. "Korean Character + Encoding for Internet Messages", RFC 1557. December, + 1993. + + [RFC-1874] Levinson, E., "SGML Media Types", RFC 1874. December + 1995. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC-2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC-2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. + Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", + RFC 2068, January 1997. + + [RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [UNICODE] The Unicode Consortium, "The Unicode Standard -- Version + 2.0", Addison-Wesley, 1996. + + + + + +Whitehead & Murata Informational [Page 13] + +RFC 2376 XML Media Types July 1998 + + +8 Acknowledgements + + Chris Newman and Yaron Y. Goland both contributed content to the + security considerations section of this document. In particular, + some text in the security considerations section is copied verbatim + from work in progress, draft-newman-mime-textpara-00, by permission + of the author. Chris Newman additionally contributed content to the + encoding considerations sections. Dan Connolly contributed content + discussing when to use text/xml. Discussions with Ned Freed and Dan + Connolly helped refine the author's understanding of the text media + type; feedback from Larry Masinter was also very helpful in + understanding media type registration issues. + + Members of the W3C XML Working Group and XML Special Interest group + have made significant contributions to this document, and the authors + would like to specially recognize James Clark, Martin Duerst, Rick + Jelliffe, Gavin Nicol for their many thoughtful comments. + +9 Addresses of Authors + + E. James Whitehead, Jr. + Dept. of Information and Computer Science + University of California, Irvine + Irvine, CA 92697-3425 + + EMail: ejw@ics.uci.edu + + + Murata Makoto (Family Given) + Fuji Xerox Information Systems, + KSP 9A7, 2-1, Sakado 3-chome, Takatsu-ku, + Kawasaki-shi, Kanagawa-ken, + 213 Japan + + EMail: murata@fxis.fujixerox.co.jp + + + + + + + + + + + + + + + + +Whitehead & Murata Informational [Page 14] + +RFC 2376 XML Media Types July 1998 + + +10 Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Whitehead & Murata Informational [Page 15] + diff --git a/Documentation/en/rfc/rfc2535.txt b/Documentation/en/rfc/rfc2535.txt new file mode 100644 index 00000000..fe0b3d07 --- /dev/null +++ b/Documentation/en/rfc/rfc2535.txt @@ -0,0 +1,2635 @@ + + + + + + +Network Working Group D. Eastlake +Request for Comments: 2535 IBM +Obsoletes: 2065 March 1999 +Updates: 2181, 1035, 1034 +Category: Standards Track + + Domain Name System Security Extensions + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + Extensions to the Domain Name System (DNS) are described that provide + data integrity and authentication to security aware resolvers and + applications through the use of cryptographic digital signatures. + These digital signatures are included in secured zones as resource + records. Security can also be provided through non-security aware + DNS servers in some cases. + + The extensions provide for the storage of authenticated public keys + in the DNS. This storage of keys can support general public key + distribution services as well as DNS security. The stored keys + enable security aware resolvers to learn the authenticating key of + zones in addition to those for which they are initially configured. + Keys associated with DNS names can be retrieved to support other + protocols. Provision is made for a variety of key types and + algorithms. + + In addition, the security extensions provide for the optional + authentication of DNS protocol transactions and requests. + + This document incorporates feedback on RFC 2065 from early + implementers and potential users. + + + + + + + + +Eastlake Standards Track [Page 1] + +RFC 2535 DNS Security Extensions March 1999 + + +Acknowledgments + + The significant contributions and suggestions of the following + persons (in alphabetic order) to DNS security are gratefully + acknowledged: + + James M. Galvin + John Gilmore + Olafur Gudmundsson + Charlie Kaufman + Edward Lewis + Thomas Narten + Radia J. Perlman + Jeffrey I. Schiller + Steven (Xunhua) Wang + Brian Wellington + +Table of Contents + + Abstract...................................................1 + Acknowledgments............................................2 + 1. Overview of Contents....................................4 + 2. Overview of the DNS Extensions..........................5 + 2.1 Services Not Provided..................................5 + 2.2 Key Distribution.......................................5 + 2.3 Data Origin Authentication and Integrity...............6 + 2.3.1 The SIG Resource Record..............................7 + 2.3.2 Authenticating Name and Type Non-existence...........7 + 2.3.3 Special Considerations With Time-to-Live.............7 + 2.3.4 Special Considerations at Delegation Points..........8 + 2.3.5 Special Considerations with CNAME....................8 + 2.3.6 Signers Other Than The Zone..........................9 + 2.4 DNS Transaction and Request Authentication.............9 + 3. The KEY Resource Record................................10 + 3.1 KEY RDATA format......................................10 + 3.1.1 Object Types, DNS Names, and Keys...................11 + 3.1.2 The KEY RR Flag Field...............................11 + 3.1.3 The Protocol Octet..................................13 + 3.2 The KEY Algorithm Number Specification................14 + 3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15 + 3.4 Determination of Zone Secure/Unsecured Status.........15 + 3.5 KEY RRs in the Construction of Responses..............17 + 4. The SIG Resource Record................................17 + 4.1 SIG RDATA Format......................................17 + 4.1.1 Type Covered Field..................................18 + 4.1.2 Algorithm Number Field..............................18 + 4.1.3 Labels Field........................................18 + 4.1.4 Original TTL Field..................................19 + + + +Eastlake Standards Track [Page 2] + +RFC 2535 DNS Security Extensions March 1999 + + + 4.1.5 Signature Expiration and Inception Fields...........19 + 4.1.6 Key Tag Field.......................................20 + 4.1.7 Signer's Name Field.................................20 + 4.1.8 Signature Field.....................................20 + 4.1.8.1 Calculating Transaction and Request SIGs..........21 + 4.2 SIG RRs in the Construction of Responses..............21 + 4.3 Processing Responses and SIG RRs......................22 + 4.4 Signature Lifetime, Expiration, TTLs, and Validity....23 + 5. Non-existent Names and Types...........................24 + 5.1 The NXT Resource Record...............................24 + 5.2 NXT RDATA Format......................................25 + 5.3 Additional Complexity Due to Wildcards................26 + 5.4 Example...............................................26 + 5.5 Special Considerations at Delegation Points...........27 + 5.6 Zone Transfers........................................27 + 5.6.1 Full Zone Transfers.................................28 + 5.6.2 Incremental Zone Transfers..........................28 + 6. How to Resolve Securely and the AD and CD Bits.........29 + 6.1 The AD and CD Header Bits.............................29 + 6.2 Staticly Configured Keys..............................31 + 6.3 Chaining Through The DNS..............................31 + 6.3.1 Chaining Through KEYs...............................31 + 6.3.2 Conflicting Data....................................33 + 6.4 Secure Time...........................................33 + 7. ASCII Representation of Security RRs...................34 + 7.1 Presentation of KEY RRs...............................34 + 7.2 Presentation of SIG RRs...............................35 + 7.3 Presentation of NXT RRs...............................36 + 8. Canonical Form and Order of Resource Records...........36 + 8.1 Canonical RR Form.....................................36 + 8.2 Canonical DNS Name Order..............................37 + 8.3 Canonical RR Ordering Within An RRset.................37 + 8.4 Canonical Ordering of RR Types........................37 + 9. Conformance............................................37 + 9.1 Server Conformance....................................37 + 9.2 Resolver Conformance..................................38 + 10. Security Considerations...............................38 + 11. IANA Considerations...................................39 + References................................................39 + Author's Address..........................................41 + Appendix A: Base 64 Encoding..............................42 + Appendix B: Changes from RFC 2065.........................44 + Appendix C: Key Tag Calculation...........................46 + Full Copyright Statement..................................47 + + + + + + + +Eastlake Standards Track [Page 3] + +RFC 2535 DNS Security Extensions March 1999 + + +1. Overview of Contents + + This document standardizes extensions of the Domain Name System (DNS) + protocol to support DNS security and public key distribution. It + assumes that the reader is familiar with the Domain Name System, + particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An + earlier version of these extensions appears in RFC 2065. This + replacement for that RFC incorporates early implementation experience + and requests from potential users. + + Section 2 provides an overview of the extensions and the key + distribution, data origin authentication, and transaction and request + security they provide. + + Section 3 discusses the KEY resource record, its structure, and use + in DNS responses. These resource records represent the public keys + of entities named in the DNS and are used for key distribution. + + Section 4 discusses the SIG digital signature resource record, its + structure, and use in DNS responses. These resource records are used + to authenticate other resource records in the DNS and optionally to + authenticate DNS transactions and requests. + + Section 5 discusses the NXT resource record (RR) and its use in DNS + responses including full and incremental zone transfers. The NXT RR + permits authenticated denial of the existence of a name or of an RR + type for an existing name. + + Section 6 discusses how a resolver can be configured with a starting + key or keys and proceed to securely resolve DNS requests. + Interactions between resolvers and servers are discussed for various + combinations of security aware and security non-aware. Two + additional DNS header bits are defined for signaling between + resolvers and servers. + + Section 7 describes the ASCII representation of the security resource + records for use in master files and elsewhere. + + Section 8 defines the canonical form and order of RRs for DNS + security purposes. + + Section 9 defines levels of conformance for resolvers and servers. + + Section 10 provides a few paragraphs on overall security + considerations. + + Section 11 specified IANA considerations for allocation of additional + values of paramters defined in this document. + + + +Eastlake Standards Track [Page 4] + +RFC 2535 DNS Security Extensions March 1999 + + + Appendix A gives details of base 64 encoding which is used in the + file representation of some RRs defined in this document. + + Appendix B summarizes changes between this memo and RFC 2065. + + Appendix C specified how to calculate the simple checksum used as a + key tag in most SIG RRs. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Overview of the DNS Extensions + + The Domain Name System (DNS) protocol security extensions provide + three distinct services: key distribution as described in Section 2.2 + below, data origin authentication as described in Section 2.3 below, + and transaction and request authentication, described in Section 2.4 + below. + + Special considerations related to "time to live", CNAMEs, and + delegation points are also discussed in Section 2.3. + +2.1 Services Not Provided + + It is part of the design philosophy of the DNS that the data in it is + public and that the DNS gives the same answers to all inquirers. + Following this philosophy, no attempt has been made to include any + sort of access control lists or other means to differentiate + inquirers. + + No effort has been made to provide for any confidentiality for + queries or responses. (This service may be available via IPSEC [RFC + 2401], TLS, or other security protocols.) + + Protection is not provided against denial of service. + +2.2 Key Distribution + + A resource record format is defined to associate keys with DNS names. + This permits the DNS to be used as a public key distribution + mechanism in support of DNS security itself and other protocols. + + The syntax of a KEY resource record (RR) is described in Section 3. + It includes an algorithm identifier, the actual public key + parameter(s), and a variety of flags including those indicating the + type of entity the key is associated with and/or asserting that there + is no key associated with that entity. + + + +Eastlake Standards Track [Page 5] + +RFC 2535 DNS Security Extensions March 1999 + + + Under conditions described in Section 3.5, security aware DNS servers + will automatically attempt to return KEY resources as additional + information, along with those resource records actually requested, to + minimize the number of queries needed. + +2.3 Data Origin Authentication and Integrity + + Authentication is provided by associating with resource record sets + (RRsets [RFC 2181]) in the DNS cryptographically generated digital + signatures. Commonly, there will be a single private key that + authenticates an entire zone but there might be multiple keys for + different algorithms, signers, etc. If a security aware resolver + reliably learns a public key of the zone, it can authenticate, for + signed data read from that zone, that it is properly authorized. The + most secure implementation is for the zone private key(s) to be kept + off-line and used to re-sign all of the records in the zone + periodically. However, there are cases, for example dynamic update + [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC + 2541]. + + The data origin authentication key(s) are associated with the zone + and not with the servers that store copies of the data. That means + compromise of a secondary server or, if the key(s) are kept off line, + even the primary server for a zone, will not necessarily affect the + degree of assurance that a resolver has that it can determine whether + data is genuine. + + A resolver could learn a public key of a zone either by reading it + from the DNS or by having it staticly configured. To reliably learn + a public key by reading it from the DNS, the key itself must be + signed with a key the resolver trusts. The resolver must be + configured with at least a public key which authenticates one zone as + a starting point. From there, it can securely read public keys of + other zones, if the intervening zones in the DNS tree are secure and + their signed keys accessible. + + Adding data origin authentication and integrity requires no change to + the "on-the-wire" DNS protocol beyond the addition of the signature + resource type and the key resource type needed for key distribution. + (Data non-existence authentication also requires the NXT RR as + described in 2.3.2.) This service can be supported by existing + resolver and caching server implementations so long as they can + support the additional resource types (see Section 9). The one + exception is that CNAME referrals in a secure zone can not be + authenticated if they are from non-security aware servers (see + Section 2.3.5). + + + + + +Eastlake Standards Track [Page 6] + +RFC 2535 DNS Security Extensions March 1999 + + + If signatures are separately retrieved and verified when retrieving + the information they authenticate, there will be more trips to the + server and performance will suffer. Security aware servers mitigate + that degradation by attempting to send the signature(s) needed (see + Section 4.2). + +2.3.1 The SIG Resource Record + + The syntax of a SIG resource record (signature) is described in + Section 4. It cryptographicly binds the RRset being signed to the + signer and a validity interval. + + Every name in a secured zone will have associated with it at least + one SIG resource record for each resource type under that name except + for glue address RRs and delegation point NS RRs. A security aware + server will attempt to return, with RRs retrieved, the corresponding + SIGs. If a server is not security aware, the resolver must retrieve + all the SIG records for a name and select the one or ones that sign + the resource record set(s) that resolver is interested in. + +2.3.2 Authenticating Name and Type Non-existence + + The above security mechanism only provides a way to sign existing + RRsets in a zone. "Data origin" authentication is not obviously + provided for the non-existence of a domain name in a zone or the + non-existence of a type for an existing name. This gap is filled by + the NXT RR which authenticatably asserts a range of non-existent + names in a zone and the non-existence of types for the existing name + just before that range. + + Section 5 below covers the NXT RR. + +2.3.3 Special Considerations With Time-to-Live + + A digital signature will fail to verify if any change has occurred to + the data between the time it was originally signed and the time the + signature is verified. This conflicts with our desire to have the + time-to-live (TTL) field of resource records tick down while they are + cached. + + This could be avoided by leaving the time-to-live out of the digital + signature, but that would allow unscrupulous servers to set + arbitrarily long TTL values undetected. Instead, we include the + "original" TTL in the signature and communicate that data along with + the current TTL. Unscrupulous servers under this scheme can + manipulate the TTL but a security aware resolver will bound the TTL + value it uses at the original signed value. Separately, signatures + include a signature inception time and a signature expiration time. A + + + +Eastlake Standards Track [Page 7] + +RFC 2535 DNS Security Extensions March 1999 + + + resolver that knows the absolute time can determine securely whether + a signature is in effect. It is not possible to rely solely on the + signature expiration as a substitute for the TTL, however, since the + TTL is primarily a database consistency mechanism and non-security + aware servers that depend on TTL must still be supported. + +2.3.4 Special Considerations at Delegation Points + + DNS security would like to view each zone as a unit of data + completely under the control of the zone owner with each entry + (RRset) signed by a special private key held by the zone manager. + But the DNS protocol views the leaf nodes in a zone, which are also + the apex nodes of a subzone (i.e., delegation points), as "really" + belonging to the subzone. These nodes occur in two master files and + might have RRs signed by both the upper and lower zone's keys. A + retrieval could get a mixture of these RRs and SIGs, especially since + one server could be serving both the zone above and below a + delegation point. [RFC 2181] + + There MUST be a zone KEY RR, signed by its superzone, for every + subzone if the superzone is secure. This will normally appear in the + subzone and may also be included in the superzone. But, in the case + of an unsecured subzone which can not or will not be modified to add + any security RRs, a KEY declaring the subzone to be unsecured MUST + appear with the superzone signature in the superzone, if the + superzone is secure. For all but one other RR type the data from the + subzone is more authoritative so only the subzone KEY RR should be + signed in the superzone if it appears there. The NS and any glue + address RRs SHOULD only be signed in the subzone. The SOA and any + other RRs that have the zone name as owner should appear only in the + subzone and thus are signed only there. The NXT RR type is the + exceptional case that will always appear differently and + authoritatively in both the superzone and subzone, if both are + secure, as described in Section 5. + +2.3.5 Special Considerations with CNAME + + There is a problem when security related RRs with the same owner name + as a CNAME RR are retrieved from a non-security-aware server. In + particular, an initial retrieval for the CNAME or any other type may + not retrieve any associated SIG, KEY, or NXT RR. For retrieved types + other than CNAME, it will retrieve that type at the target name of + the CNAME (or chain of CNAMEs) and will also return the CNAME. In + particular, a specific retrieval for type SIG will not get the SIG, + if any, at the original CNAME domain name but rather a SIG at the + target name. + + + + + +Eastlake Standards Track [Page 8] + +RFC 2535 DNS Security Extensions March 1999 + + + Security aware servers must be used to securely CNAME in DNS. + Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along + with CNAME RRs, (2) suppress CNAME processing on retrieval of these + types as well as on retrieval of the type CNAME, and (3) + automatically return SIG RRs authenticating the CNAME or CNAMEs + encountered in resolving a query. This is a change from the previous + DNS standard [RFCs 1034/1035] which prohibited any other RR type at a + node where a CNAME RR was present. + +2.3.6 Signers Other Than The Zone + + There are cases where the signer in a SIG resource record is other + than one of the private key(s) used to authenticate a zone. + + One is for support of dynamic update [RFC 2136] (or future requests + which require secure authentication) where an entity is permitted to + authenticate/update its records [RFC 2137] and the zone is operating + in a mode where the zone key is not on line. The public key of the + entity must be present in the DNS and be signed by a zone level key + but the other RR(s) may be signed with the entity's key. + + A second case is support of transaction and request authentication as + described in Section 2.4. + + In additions, signatures can be included on resource records within + the DNS for use by applications other than DNS. DNS related + signatures authenticate that data originated with the authority of a + zone owner or that a request or transaction originated with the + relevant entity. Other signatures can provide other types of + assurances. + +2.4 DNS Transaction and Request Authentication + + The data origin authentication service described above protects + retrieved resource records and the non-existence of resource records + but provides no protection for DNS requests or for message headers. + + If header bits are falsely set by a bad server, there is little that + can be done. However, it is possible to add transaction + authentication. Such authentication means that a resolver can be + sure it is at least getting messages from the server it thinks it + queried and that the response is from the query it sent (i.e., that + these messages have not been diddled in transit). This is + accomplished by optionally adding a special SIG resource record at + the end of the reply which digitally signs the concatenation of the + server's response and the resolver's query. + + + + + +Eastlake Standards Track [Page 9] + +RFC 2535 DNS Security Extensions March 1999 + + + Requests can also be authenticated by including a special SIG RR at + the end of the request. Authenticating requests serves no function + in older DNS servers and requests with a non-empty additional + information section produce error returns or may even be ignored by + many of them. However, this syntax for signing requests is defined as + a way of authenticating secure dynamic update requests [RFC 2137] or + future requests requiring authentication. + + The private keys used in transaction security belong to the entity + composing the reply, not to the zone involved. Request + authentication may also involve the private key of the host or other + entity composing the request or other private keys depending on the + request authority it is sought to establish. The corresponding public + key(s) are normally stored in and retrieved from the DNS for + verification. + + Because requests and replies are highly variable, message + authentication SIGs can not be pre-calculated. Thus it will be + necessary to keep the private key on-line, for example in software or + in a directly connected piece of hardware. + +3. The KEY Resource Record + + The KEY resource record (RR) is used to store a public key that is + associated with a Domain Name System (DNS) name. This can be the + public key of a zone, a user, or a host or other end entity. Security + aware DNS implementations MUST be designed to handle at least two + simultaneously valid keys of the same type associated with the same + name. + + The type number for the KEY RR is 25. + + A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs + must be signed by a zone level key. + +3.1 KEY RDATA format + + The RDATA for a KEY RR consists of flags, a protocol octet, the + algorithm number octet, and the public key itself. The format is as + follows: + + + + + + + + + + + +Eastlake Standards Track [Page 10] + +RFC 2535 DNS Security Extensions March 1999 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags | protocol | algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + The KEY RR is not intended for storage of certificates and a separate + certificate RR has been developed for that purpose, defined in [RFC + 2538]. + + The meaning of the KEY RR owner name, flags, and protocol octet are + described in Sections 3.1.1 through 3.1.5 below. The flags and + algorithm must be examined before any data following the algorithm + octet as they control the existence and format of any following data. + The algorithm and public key fields are described in Section 3.2. + The format of the public key is algorithm dependent. + + KEY RRs do not specify their validity period but their authenticating + SIG RR(s) do as described in Section 4 below. + +3.1.1 Object Types, DNS Names, and Keys + + The public key in a KEY RR is for the object named in the owner name. + + A DNS name may refer to three different categories of things. For + example, foo.host.example could be (1) a zone, (2) a host or other + end entity , or (3) the mapping into a DNS name of the user or + account foo@host.example. Thus, there are flag bits, as described + below, in the KEY RR to indicate with which of these roles the owner + name and public key are associated. Note that an appropriate zone + KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs + occur only at delegation points. + +3.1.2 The KEY RR Flag Field + + In the "flags" field: + + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + Bit 0 and 1 are the key "type" bits whose values have the following + meanings: + + + +Eastlake Standards Track [Page 11] + +RFC 2535 DNS Security Extensions March 1999 + + + 10: Use of the key is prohibited for authentication. + 01: Use of the key is prohibited for confidentiality. + 00: Use of the key for authentication and/or confidentiality + is permitted. Note that DNS security makes use of keys + for authentication only. Confidentiality use flagging is + provided for use of keys in other protocols. + Implementations not intended to support key distribution + for confidentiality MAY require that the confidentiality + use prohibited bit be on for keys they serve. + 11: If both bits are one, the "no key" value, there is no key + information and the RR stops after the algorithm octet. + By the use of this "no key" value, a signed KEY RR can + authenticatably assert that, for example, a zone is not + secured. See section 3.4 below. + + Bits 2 is reserved and must be zero. + + Bits 3 is reserved as a flag extension bit. If it is a one, a second + 16 bit flag field is added after the algorithm octet and + before the key data. This bit MUST NOT be set unless one or + more such additional bits have been defined and are non-zero. + + Bits 4-5 are reserved and must be zero. + + Bits 6 and 7 form a field that encodes the name type. Field values + have the following meanings: + + 00: indicates that this is a key associated with a "user" or + "account" at an end entity, usually a host. The coding + of the owner name is that used for the responsible + individual mailbox in the SOA and RP RRs: The owner name + is the user name as the name of a node under the entity + name. For example, "j_random_user" on + host.subdomain.example could have a public key associated + through a KEY RR with name + j_random_user.host.subdomain.example. It could be used + in a security protocol where authentication of a user was + desired. This key might be useful in IP or other + security for a user level service such a telnet, ftp, + rlogin, etc. + 01: indicates that this is a zone key for the zone whose name + is the KEY RR owner name. This is the public key used + for the primary DNS security feature of data origin + authentication. Zone KEY RRs occur only at delegation + points. + 10: indicates that this is a key associated with the non-zone + "entity" whose name is the RR owner name. This will + commonly be a host but could, in some parts of the DNS + + + +Eastlake Standards Track [Page 12] + +RFC 2535 DNS Security Extensions March 1999 + + + tree, be some other type of entity such as a telephone + number [RFC 1530] or numeric IP address. This is the + public key used in connection with DNS request and + transaction authentication services. It could also be + used in an IP-security protocol where authentication at + the host, rather than user, level was desired, such as + routing, NTP, etc. + 11: reserved. + + Bits 8-11 are reserved and must be zero. + + Bits 12-15 are the "signatory" field. If non-zero, they indicate + that the key can validly sign things as specified in DNS + dynamic update [RFC 2137]. Note that zone keys (see bits + 6 and 7 above) always have authority to sign any RRs in + the zone regardless of the value of the signatory field. + +3.1.3 The Protocol Octet + + It is anticipated that keys stored in DNS will be used in conjunction + with a variety of Internet protocols. It is intended that the + protocol octet and possibly some of the currently unused (must be + zero) bits in the KEY RR flags as specified in the future will be + used to indicate a key's validity for different protocols. + + The following values of the Protocol Octet are reserved as indicated: + + VALUE Protocol + + 0 -reserved + 1 TLS + 2 email + 3 dnssec + 4 IPSEC + 5-254 - available for assignment by IANA + 255 All + + In more detail: + 1 is reserved for use in connection with TLS. + 2 is reserved for use in connection with email. + 3 is used for DNS security. The protocol field SHOULD be set to + this value for zone keys and other keys used in DNS security. + Implementations that can determine that a key is a DNS + security key by the fact that flags label it a zone key or the + signatory flag field is non-zero are NOT REQUIRED to check the + protocol field. + 4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol + and indicates that this key is valid for use in conjunction + + + +Eastlake Standards Track [Page 13] + +RFC 2535 DNS Security Extensions March 1999 + + + with that security standard. This key could be used in + connection with secured communication on behalf of an end + entity or user whose name is the owner name of the KEY RR if + the entity or user flag bits are set. The presence of a KEY + resource with this protocol value is an assertion that the + host speaks Oakley/IPSEC. + 255 indicates that the key can be used in connection with any + protocol for which KEY RR protocol octet values have been + defined. The use of this value is discouraged and the use of + different keys for different protocols is encouraged. + +3.2 The KEY Algorithm Number Specification + + This octet is the key algorithm parallel to the same field for the + SIG resource as described in Section 4.1. The following values are + assigned: + + VALUE Algorithm + + 0 - reserved, see Section 11 + 1 RSA/MD5 [RFC 2537] - recommended + 2 Diffie-Hellman [RFC 2539] - optional, key only + 3 DSA [RFC 2536] - MANDATORY + 4 reserved for elliptic curve crypto + 5-251 - available, see Section 11 + 252 reserved for indirect keys + 253 private - domain name (see below) + 254 private - OID (see below) + 255 - reserved, see Section 11 + + Algorithm specific formats and procedures are given in separate + documents. The mandatory to implement for interoperability algorithm + is number 3, DSA. It is recommended that the RSA/MD5 algorithm, + number 1, also be implemented. Algorithm 2 is used to indicate + Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve. + + Algorithm number 252 indicates an indirect key format where the + actual key material is elsewhere. This format is to be defined in a + separate document. + + Algorithm numbers 253 and 254 are reserved for private use and will + never be assigned a specific algorithm. For number 253, the public + key area and the signature begin with a wire encoded domain name. + Only local domain name compression is permitted. The domain name + indicates the private algorithm to use and the remainder of the + public key area is whatever is required by that algorithm. For + number 254, the public key area for the KEY RR and the signature + begin with an unsigned length byte followed by a BER encoded Object + + + +Eastlake Standards Track [Page 14] + +RFC 2535 DNS Security Extensions March 1999 + + + Identifier (ISO OID) of that length. The OID indicates the private + algorithm in use and the remainder of the area is whatever is + required by that algorithm. Entities should only use domain names + and OIDs they control to designate their private algorithms. + + Values 0 and 255 are reserved but the value 0 is used in the + algorithm field when that field is not used. An example is in a KEY + RR with the top two flag bits on, the "no-key" value, where no key is + present. + +3.3 Interaction of Flags, Algorithm, and Protocol Bytes + + Various combinations of the no-key type flags, algorithm byte, + protocol byte, and any future assigned protocol indicating flags are + possible. The meaning of these combinations is indicated below: + + NK = no key type (flags bits 0 and 1 on) + AL = algorithm byte + PR = protocols indicated by protocol byte or future assigned flags + + x represents any valid non-zero value(s). + + AL PR NK Meaning + 0 0 0 Illegal, claims key but has bad algorithm field. + 0 0 1 Specifies total lack of security for owner zone. + 0 x 0 Illegal, claims key but has bad algorithm field. + 0 x 1 Specified protocols unsecured, others may be secure. + x 0 0 Gives key but no protocols to use it. + x 0 1 Denies key for specific algorithm. + x x 0 Specifies key for protocols. + x x 1 Algorithm not understood for protocol. + +3.4 Determination of Zone Secure/Unsecured Status + + A zone KEY RR with the "no-key" type field value (both key type flag + bits 0 and 1 on) indicates that the zone named is unsecured while a + zone KEY RR with a key present indicates that the zone named is + secure. The secured versus unsecured status of a zone may vary with + different cryptographic algorithms. Even for the same algorithm, + conflicting zone KEY RRs may be present. + + Zone KEY RRs, like all RRs, are only trusted if they are + authenticated by a SIG RR whose signer field is a signer for which + the resolver has a public key they trust and where resolver policy + permits that signer to sign for the KEY owner name. Untrusted zone + KEY RRs MUST be ignored in determining the security status of the + zone. However, there can be multiple sets of trusted zone KEY RRs + for a zone with different algorithms, signers, etc. + + + +Eastlake Standards Track [Page 15] + +RFC 2535 DNS Security Extensions March 1999 + + + For any particular algorithm, zones can be (1) secure, indicating + that any retrieved RR must be authenticated by a SIG RR or it will be + discarded as bogus, (2) unsecured, indicating that SIG RRs are not + expected or required for RRs retrieved from the zone, or (3) + experimentally secure, which indicates that SIG RRs might or might + not be present but must be checked if found. The status of a zone is + determined as follows: + + 1. If, for a zone and algorithm, every trusted zone KEY RR for the + zone says there is no key for that zone, it is unsecured for that + algorithm. + + 2. If, there is at least one trusted no-key zone KEY RR and one + trusted key specifying zone KEY RR, then that zone is only + experimentally secure for the algorithm. Both authenticated and + non-authenticated RRs for it should be accepted by the resolver. + + 3. If every trusted zone KEY RR that the zone and algorithm has is + key specifying, then it is secure for that algorithm and only + authenticated RRs from it will be accepted. + + Examples: + + (1) A resolver initially trusts only signatures by the superzone of + zone Z within the DNS hierarchy. Thus it will look only at the KEY + RRs that are signed by the superzone. If it finds only no-key KEY + RRs, it will assume the zone is not secure. If it finds only key + specifying KEY RRs, it will assume the zone is secure and reject any + unsigned responses. If it finds both, it will assume the zone is + experimentally secure + + (2) A resolver trusts the superzone of zone Z (to which it got + securely from its local zone) and a third party, cert-auth.example. + When considering data from zone Z, it may be signed by the superzone + of Z, by cert-auth.example, by both, or by neither. The following + table indicates whether zone Z will be considered secure, + experimentally secure, or unsecured, depending on the signed zone KEY + RRs for Z; + + c e r t - a u t h . e x a m p l e + + KEY RRs| None | NoKeys | Mixed | Keys | + S --+-----------+-----------+----------+----------+ + u None | illegal | unsecured | experim. | secure | + p --+-----------+-----------+----------+----------+ + e NoKeys | unsecured | unsecured | experim. | secure | + r --+-----------+-----------+----------+----------+ + Z Mixed | experim. | experim. | experim. | secure | + + + +Eastlake Standards Track [Page 16] + +RFC 2535 DNS Security Extensions March 1999 + + + o --+-----------+-----------+----------+----------+ + n Keys | secure | secure | secure | secure | + e +-----------+-----------+----------+----------+ + +3.5 KEY RRs in the Construction of Responses + + An explicit request for KEY RRs does not cause any special additional + information processing except, of course, for the corresponding SIG + RR from a security aware server (see Section 4.2). + + Security aware DNS servers include KEY RRs as additional information + in responses, where a KEY is available, in the following cases: + + (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same + name (perhaps just a zone key) SHOULD be included as additional + information if space is available. If not all additional information + will fit, type A and AAAA glue RRs have higher priority than KEY + RR(s). + + (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same + name (usually just a host RR and NOT the zone key (which usually + would have a different name)) SHOULD be included if space is + available. On inclusion of A or AAAA RRs as additional information, + the KEY RRset with the same name should also be included but with + lower priority than the A or AAAA RRs. + +4. The SIG Resource Record + + The SIG or "signature" resource record (RR) is the fundamental way + that data is authenticated in the secure Domain Name System (DNS). As + such it is the heart of the security provided. + + The SIG RR unforgably authenticates an RRset [RFC 2181] of a + particular type, class, and name and binds it to a time interval and + the signer's domain name. This is done using cryptographic + techniques and the signer's private key. The signer is frequently + the owner of the zone from which the RR originated. + + The type number for the SIG RR type is 24. + +4.1 SIG RDATA Format + + The RDATA portion of a SIG RR is as shown below. The integrity of + the RDATA information is protected by the signature field. + + + + + + + +Eastlake Standards Track [Page 17] + +RFC 2535 DNS Security Extensions March 1999 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | type covered | algorithm | labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | signature expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | signature inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | key tag | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + + | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ + / / + / signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.1.1 Type Covered Field + + The "type covered" is the type of the other RRs covered by this SIG. + +4.1.2 Algorithm Number Field + + This octet is as described in section 3.2. + +4.1.3 Labels Field + + The "labels" octet is an unsigned count of how many labels there are + in the original SIG RR owner name not counting the null label for + root and not counting any initial "*" for a wildcard. If a secured + retrieval is the result of wild card substitution, it is necessary + for the resolver to use the original form of the name in verifying + the digital signature. This field makes it easy to determine the + original form. + + If, on retrieval, the RR appears to have a longer name than indicated + by "labels", the resolver can tell it is the result of wildcard + substitution. If the RR owner name appears to be shorter than the + labels count, the SIG RR must be considered corrupt and ignored. The + maximum number of labels allowed in the current DNS is 127 but the + entire octet is reserved and would be required should DNS names ever + be expanded to 255 labels. The following table gives some examples. + The value of "labels" is at the top, the retrieved owner name on the + left, and the table entry is the name to use in signature + verification except that "bad" means the RR is corrupt. + + + +Eastlake Standards Track [Page 18] + +RFC 2535 DNS Security Extensions March 1999 + + + labels= | 0 | 1 | 2 | 3 | 4 | + --------+-----+------+--------+----------+----------+ + .| . | bad | bad | bad | bad | + d.| *. | d. | bad | bad | bad | + c.d.| *. | *.d. | c.d. | bad | bad | + b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | + a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | + +4.1.4 Original TTL Field + + The "original TTL" field is included in the RDATA portion to avoid + (1) authentication problems that caching servers would otherwise + cause by decrementing the real TTL field and (2) security problems + that unscrupulous servers could otherwise cause by manipulating the + real TTL field. This original TTL is protected by the signature + while the current TTL field is not. + + NOTE: The "original TTL" must be restored into the covered RRs when + the signature is verified (see Section 8). This generaly implies + that all RRs for a particular type, name, and class, that is, all the + RRs in any particular RRset, must have the same TTL to start with. + +4.1.5 Signature Expiration and Inception Fields + + The SIG is valid from the "signature inception" time until the + "signature expiration" time. Both are unsigned numbers of seconds + since the start of 1 January 1970, GMT, ignoring leap seconds. (See + also Section 4.4.) Ring arithmetic is used as for DNS SOA serial + numbers [RFC 1982] which means that these times can never be more + than about 68 years in the past or the future. This means that these + times are ambiguous modulo ~136.09 years. However there is no + security flaw because keys are required to be changed to new random + keys by [RFC 2541] at least every five years. This means that the + probability that the same key is in use N*136.09 years later should + be the same as the probability that a random guess will work. + + A SIG RR may have an expiration time numerically less than the + inception time if the expiration time is near the 32 bit wrap around + point and/or the signature is long lived. + + (To prevent misordering of network requests to update a zone + dynamically, monotonically increasing "signature inception" times may + be necessary.) + + A secure zone must be considered changed for SOA serial number + purposes not only when its data is updated but also when new SIG RRs + are inserted (ie, the zone or any part of it is re-signed). + + + + +Eastlake Standards Track [Page 19] + +RFC 2535 DNS Security Extensions March 1999 + + +4.1.6 Key Tag Field + + The "key Tag" is a two octet quantity that is used to efficiently + select between multiple keys which may be applicable and thus check + that a public key about to be used for the computationally expensive + effort to check the signature is possibly valid. For algorithm 1 + (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two + octets of the public key modulus needed to decode the signature + field. That is to say, the most significant 16 of the least + significant 24 bits of the modulus in network (big endian) order. For + all other algorithms, including private algorithms, it is calculated + as a simple checksum of the KEY RR as described in Appendix C. + +4.1.7 Signer's Name Field + + The "signer's name" field is the domain name of the signer generating + the SIG RR. This is the owner name of the public KEY RR that can be + used to verify the signature. It is frequently the zone which + contained the RRset being authenticated. Which signers should be + authorized to sign what is a significant resolver policy question as + discussed in Section 6. The signer's name may be compressed with + standard DNS name compression when being transmitted over the + network. + +4.1.8 Signature Field + + The actual signature portion of the SIG RR binds the other RDATA + fields to the RRset of the "type covered" RRs with that owner name + and class. This covered RRset is thereby authenticated. To + accomplish this, a data sequence is constructed as follows: + + data = RDATA | RR(s)... + + where "|" is concatenation, + + RDATA is the wire format of all the RDATA fields in the SIG RR itself + (including the canonical form of the signer's name) before but not + including the signature, and + + RR(s) is the RRset of the RR(s) of the type covered with the same + owner name and class as the SIG RR in canonical form and order as + defined in Section 8. + + How this data sequence is processed into the signature is algorithm + dependent. These algorithm dependent formats and procedures are + described in separate documents (Section 3.2). + + + + + +Eastlake Standards Track [Page 20] + +RFC 2535 DNS Security Extensions March 1999 + + + SIGs SHOULD NOT be included in a zone for any "meta-type" such as + ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR). + +4.1.8.1 Calculating Transaction and Request SIGs + + A response message from a security aware server may optionally + contain a special SIG at the end of the additional information + section to authenticate the transaction. + + This SIG has a "type covered" field of zero, which is not a valid RR + type. It is calculated by using a "data" (see Section 4.1.8) of the + entire preceding DNS reply message, including DNS header but not the + IP header and before the reply RR counts have been adjusted for the + inclusion of any transaction SIG, concatenated with the entire DNS + query message that produced this response, including the query's DNS + header and any request SIGs but not its IP header. That is + + data = full response (less transaction SIG) | full query + + Verification of the transaction SIG (which is signed by the server + host key, not the zone key) by the requesting resolver shows that the + query and response were not tampered with in transit, that the + response corresponds to the intended query, and that the response + comes from the queried server. + + A DNS request may be optionally signed by including one or more SIGs + at the end of the query. Such SIGs are identified by having a "type + covered" field of zero. They sign the preceding DNS request message + including DNS header but not including the IP header or any request + SIGs at the end and before the request RR counts have been adjusted + for the inclusions of any request SIG(s). + + WARNING: Request SIGs are unnecessary for any currently defined + request other than update [RFC 2136, 2137] and will cause some old + DNS servers to give an error return or ignore a query. However, such + SIGs may in the future be needed for other requests. + + Except where needed to authenticate an update or similar privileged + request, servers are not required to check request SIGs. + +4.2 SIG RRs in the Construction of Responses + + Security aware DNS servers SHOULD, for every authenticated RRset the + query will return, attempt to send the available SIG RRs which + authenticate the requested RRset. The following rules apply to the + inclusion of SIG RRs in responses: + + + + + +Eastlake Standards Track [Page 21] + +RFC 2535 DNS Security Extensions March 1999 + + + 1. when an RRset is placed in a response, its SIG RR has a higher + priority for inclusion than additional RRs that may need to be + included. If space does not permit its inclusion, the response + MUST be considered truncated except as provided in 2 below. + + 2. When a SIG RR is present in the zone for an additional + information section RR, the response MUST NOT be considered + truncated merely because space does not permit the inclusion of + the SIG RR with the additional information. + + 3. SIGs to authenticate glue records and NS RRs for subzones at a + delegation point are unnecessary and MUST NOT be sent. + + 4. If a SIG covers any RR that would be in the answer section of + the response, its automatic inclusion MUST be in the answer + section. If it covers an RR that would appear in the authority + section, its automatic inclusion MUST be in the authority + section. If it covers an RR that would appear in the additional + information section it MUST appear in the additional information + section. This is a change in the existing standard [RFCs 1034, + 1035] which contemplates only NS and SOA RRs in the authority + section. + + 5. Optionally, DNS transactions may be authenticated by a SIG RR at + the end of the response in the additional information section + (Section 4.1.8.1). Such SIG RRs are signed by the DNS server + originating the response. Although the signer field MUST be a + name of the originating server host, the owner name, class, TTL, + and original TTL, are meaningless. The class and TTL fields + SHOULD be zero. To conserve space, the owner name SHOULD be + root (a single zero octet). If transaction authentication is + desired, that SIG RR must be considered the highest priority for + inclusion. + +4.3 Processing Responses and SIG RRs + + The following rules apply to the processing of SIG RRs included in a + response: + + 1. A security aware resolver that receives a response from a + security aware server via a secure communication with the AD bit + (see Section 6.1) set, MAY choose to accept the RRs as received + without verifying the zone SIG RRs. + + 2. In other cases, a security aware resolver SHOULD verify the SIG + RRs for the RRs of interest. This may involve initiating + additional queries for SIG or KEY RRs, especially in the case of + + + + +Eastlake Standards Track [Page 22] + +RFC 2535 DNS Security Extensions March 1999 + + + getting a response from a server that does not implement + security. (As explained in 2.3.5 above, it will not be possible + to secure CNAMEs being served up by non-secure resolvers.) + + NOTE: Implementers might expect the above SHOULD to be a MUST. + However, local policy or the calling application may not require + the security services. + + 3. If SIG RRs are received in response to a user query explicitly + specifying the SIG type, no special processing is required. + + If the message does not pass integrity checks or the SIG does not + check against the signed RRs, the SIG RR is invalid and should be + ignored. If all of the SIG RR(s) purporting to authenticate an RRset + are invalid, then the RRset is not authenticated. + + If the SIG RR is the last RR in a response in the additional + information section and has a type covered of zero, it is a + transaction signature of the response and the query that produced the + response. It MAY be optionally checked and the message rejected if + the checks fail. But even if the checks succeed, such a transaction + authentication SIG does NOT directly authenticate any RRs in the + message. Only a proper SIG RR signed by the zone or a key tracing + its authority to the zone or to static resolver configuration can + directly authenticate RRs, depending on resolver policy (see Section + 6). If a resolver does not implement transaction and/or request + SIGs, it MUST ignore them without error. + + If all checks indicate that the SIG RR is valid then RRs verified by + it should be considered authenticated. + +4.4 Signature Lifetime, Expiration, TTLs, and Validity + + Security aware servers MUST NOT consider SIG RRs to authenticate + anything before their signature inception or after its expiration + time (see also Section 6). Security aware servers MUST NOT consider + any RR to be authenticated after all its signatures have expired. + When a secure server caches authenticated data, if the TTL would + expire at a time further in the future than the authentication + expiration time, the server SHOULD trim the TTL in the cache entry + not to extent beyond the authentication expiration time. Within + these constraints, servers should continue to follow DNS TTL aging. + Thus authoritative servers should continue to follow the zone refresh + and expire parameters and a non-authoritative server should count + down the TTL and discard RRs when the TTL is zero (even for a SIG + that has not yet reached its authentication expiration time). In + addition, when RRs are transmitted in a query response, the TTL + + + + +Eastlake Standards Track [Page 23] + +RFC 2535 DNS Security Extensions March 1999 + + + should be trimmed so that current time plus the TTL does not extend + beyond the authentication expiration time. Thus, in general, the TTL + on a transmitted RR would be + + min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) + + When signatures are generated, signature expiration times should be + set far enough in the future that it is quite certain that new + signatures can be generated before the old ones expire. However, + setting expiration too far into the future could mean a long time to + flush any bad data or signatures that may have been generated. + + It is recommended that signature lifetime be a small multiple of the + TTL (ie, 4 to 16 times the TTL) but not less than a reasonable + maximum re-signing interval and not less than the zone expiry time. + +5. Non-existent Names and Types + + The SIG RR mechanism described in Section 4 above provides strong + authentication of RRs that exist in a zone. But it is not clear + above how to verifiably deny the existence of a name in a zone or a + type for an existent name. + + The nonexistence of a name in a zone is indicated by the NXT ("next") + RR for a name interval containing the nonexistent name. An NXT RR or + RRs and its or their SIG(s) are returned in the authority section, + along with the error, if the server is security aware. The same is + true for a non-existent type under an existing name except that there + is no error indication other than an empty answer section + accompanying the NXT(s). This is a change in the existing standard + [RFCs 1034/1035] which contemplates only NS and SOA RRs in the + authority section. NXT RRs will also be returned if an explicit query + is made for the NXT type. + + The existence of a complete set of NXT records in a zone means that + any query for any name and any type to a security aware server + serving the zone will result in an reply containing at least one + signed RR unless it is a query for delegation point NS or glue A or + AAAA RRs. + +5.1 The NXT Resource Record + + The NXT resource record is used to securely indicate that RRs with an + owner name in a certain name interval do not exist in a zone and to + indicate what RR types are present for an existing name. + + + + + + +Eastlake Standards Track [Page 24] + +RFC 2535 DNS Security Extensions March 1999 + + + The owner name of the NXT RR is an existing name in the zone. It's + RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone + create a chain of all of the literal owner names in that zone, + including unexpanded wildcards but omitting the owner name of glue + address records unless they would otherwise be included. This implies + a canonical ordering of all domain names in a zone as described in + Section 8. The presence of the NXT RR means that no name between its + owner name and the name in its RDATA area exists and that no other + types exist under its owner name. + + There is a potential problem with the last NXT in a zone as it wants + to have an owner name which is the last existing name in canonical + order, which is easy, but it is not obvious what name to put in its + RDATA to indicate the entire remainder of the name space. This is + handled by treating the name space as circular and putting the zone + name in the RDATA of the last NXT in a zone. + + The NXT RRs for a zone SHOULD be automatically calculated and added + to the zone when SIGs are added. The NXT RR's TTL SHOULD NOT exceed + the zone minimum TTL. + + The type number for the NXT RR is 30. + + NXT RRs are only signed by zone level keys. + +5.2 NXT RDATA Format + + The RDATA for an NXT RR consists simply of a domain name followed by + a bit map, as shown below. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | next domain name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | type bit map / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The NXT RR type bit map format currently defined is one bit per RR + type present for the owner name. A one bit indicates that at least + one RR of that type is present for the owner name. A zero indicates + that no such RR is present. All bits not specified because they are + beyond the end of the bit map are assumed to be zero. Note that bit + 30, for NXT, will always be on so the minimum bit map length is + actually four octets. Trailing zero octets are prohibited in this + format. The first bit represents RR type zero (an illegal type which + can not be present) and so will be zero in this format. This format + is not used if there exists an RR with a type number greater than + + + +Eastlake Standards Track [Page 25] + +RFC 2535 DNS Security Extensions March 1999 + + + 127. If the zero bit of the type bit map is a one, it indicates that + a different format is being used which will always be the case if a + type number greater than 127 is present. + + The domain name may be compressed with standard DNS name compression + when being transmitted over the network. The size of the bit map can + be inferred from the RDLENGTH and the length of the next domain name. + +5.3 Additional Complexity Due to Wildcards + + Proving that a non-existent name response is correct or that a + wildcard expansion response is correct makes things a little more + complex. + + In particular, when a non-existent name response is returned, an NXT + must be returned showing that the exact name queried did not exist + and, in general, one or more additional NXT's need to be returned to + also prove that there wasn't a wildcard whose expansion should have + been returned. (There is no need to return multiple copies of the + same NXT.) These NXTs, if any, are returned in the authority section + of the response. + + Furthermore, if a wildcard expansion is returned in a response, in + general one or more NXTs needs to also be returned in the authority + section to prove that no more specific name (including possibly more + specific wildcards in the zone) existed on which the response should + have been based. + +5.4 Example + + Assume zone foo.nil has entries for + + big.foo.nil, + medium.foo.nil. + small.foo.nil. + tiny.foo.nil. + + Then a query to a security aware server for huge.foo.nil would + produce an error reply with an RCODE of NXDOMAIN and the authority + section data including something like the following: + + + + + + + + + + + +Eastlake Standards Track [Page 26] + +RFC 2535 DNS Security Extensions March 1999 + + + foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil + foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 + 19970102030405 ;signature expiration + 19961211100908 ;signature inception + 2143 ;key identifier + foo.nil. ;signer + AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm + fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits) + ) + big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil + big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 + 19970102030405 ;signature expiration + 19961211100908 ;signature inception + 2143 ;key identifier + foo.nil. ;signer + MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU + 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) + ) + Note that this response implies that big.foo.nil is an existing name + in the zone and thus has other RR types associated with it than NXT. + However, only the NXT (and its SIG) RR appear in the response to this + query for huge.foo.nil, which is a non-existent name. + +5.5 Special Considerations at Delegation Points + + A name (other than root) which is the head of a zone also appears as + the leaf in a superzone. If both are secure, there will always be + two different NXT RRs with the same name. They can be easily + distinguished by their signers, the next domain name fields, the + presence of the SOA type bit, etc. Security aware servers should + return the correct NXT automatically when required to authenticate + the non-existence of a name and both NXTs, if available, on explicit + query for type NXT. + + Non-security aware servers will never automatically return an NXT and + some old implementations may only return the NXT from the subzone on + explicit queries. + +5.6 Zone Transfers + + The subsections below describe how full and incremental zone + transfers are secured. + + SIG RRs secure all authoritative RRs transferred for both full and + incremental [RFC 1995] zone transfers. NXT RRs are an essential + element in secure zone transfers and assure that every authoritative + name and type will be present; however, if there are multiple SIGs + with the same name and type covered, a subset of the SIGs could be + + + +Eastlake Standards Track [Page 27] + +RFC 2535 DNS Security Extensions March 1999 + + + sent as long as at least one is present and, in the case of unsigned + delegation point NS or glue A or AAAA RRs a subset of these RRs or + simply a modified set could be sent as long as at least one of each + type is included. + + When an incremental or full zone transfer request is received with + the same or newer version number than that of the server's copy of + the zone, it is replied to with just the SOA RR of the server's + current version and the SIG RRset verifying that SOA RR. + + The complete NXT chains specified in this document enable a resolver + to obtain, by successive queries chaining through NXTs, all of the + names in a zone even if zone transfers are prohibited. Different + format NXTs may be specified in the future to avoid this. + +5.6.1 Full Zone Transfers + + To provide server authentication that a complete transfer has + occurred, transaction authentication SHOULD be used on full zone + transfers. This provides strong server based protection for the + entire zone in transit. + +5.6.2 Incremental Zone Transfers + + Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be + verified in the same way as for a full zone transfer and the + integrity of the NXT name chain and correctness of the NXT type bits + for the zone after the incremental RR deletes and adds can check each + disjoint area of the zone updated. But the completeness of an + incremental transfer can not be confirmed because usually neither the + deleted RR section nor the added RR section has a compete zone NXT + chain. As a result, a server which securely supports IXFR must + handle IXFR SIG RRs for each incremental transfer set that it + maintains. + + The IXFR SIG is calculated over the incremental zone update + collection of RRs in the order in which it is transmitted: old SOA, + then deleted RRs, then new SOA and added RRs. Within each section, + RRs must be ordered as specified in Section 8. If condensation of + adjacent incremental update sets is done by the zone owner, the + original IXFR SIG for each set included in the condensation must be + discarded and a new on IXFR SIG calculated to cover the resulting + condensed set. + + The IXFR SIG really belongs to the zone as a whole, not to the zone + name. Although it SHOULD be correct for the zone name, the labels + field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only + sent as part of an incremental zone transfer. After validation of + + + +Eastlake Standards Track [Page 28] + +RFC 2535 DNS Security Extensions March 1999 + + + the IXFR SIG, the transferred RRs MAY be considered valid without + verification of the internal SIGs if such trust in the server + conforms to local policy. + +6. How to Resolve Securely and the AD and CD Bits + + Retrieving or resolving secure data from the Domain Name System (DNS) + involves starting with one or more trusted public keys that have been + staticly configured at the resolver. With starting trusted keys, a + resolver willing to perform cryptography can progress securely + through the secure DNS structure to the zone of interest as described + in Section 6.3. Such trusted public keys would normally be configured + in a manner similar to that described in Section 6.2. However, as a + practical matter, a security aware resolver would still gain some + confidence in the results it returns even if it was not configured + with any keys but trusted what it got from a local well known server + as if it were staticly configured. + + Data stored at a security aware server needs to be internally + categorized as Authenticated, Pending, or Insecure. There is also a + fourth transient state of Bad which indicates that all SIG checks + have explicitly failed on the data. Such Bad data is not retained at + a security aware server. Authenticated means that the data has a + valid SIG under a KEY traceable via a chain of zero or more SIG and + KEY RRs allowed by the resolvers policies to a KEY staticly + configured at the resolver. Pending data has no authenticated SIGs + and at least one additional SIG the resolver is still trying to + authenticate. Insecure data is data which it is known can never be + either Authenticated or found Bad in the zone where it was found + because it is in or has been reached via a unsecured zone or because + it is unsigned glue address or delegation point NS data. Behavior in + terms of control of and flagging based on such data labels is + described in Section 6.1. + + The proper validation of signatures requires a reasonably secure + shared opinion of the absolute time between resolvers and servers as + described in Section 6.4. + +6.1 The AD and CD Header Bits + + Two previously unused bits are allocated out of the DNS + query/response format header. The AD (authentic data) bit indicates + in a response that all the data included in the answer and authority + portion of the response has been authenticated by the server + according to the policies of that server. The CD (checking disabled) + bit indicates in a query that Pending (non-authenticated) data is + acceptable to the resolver sending the query. + + + + +Eastlake Standards Track [Page 29] + +RFC 2535 DNS Security Extensions March 1999 + + + These bits are allocated from the previously must-be-zero Z field as + follows: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + These bits are zero in old servers and resolvers. Thus the responses + of old servers are not flagged as authenticated to security aware + resolvers and queries from non-security aware resolvers do not assert + the checking disabled bit and thus will be answered by security aware + servers only with Authenticated or Insecure data. Security aware + resolvers MUST NOT trust the AD bit unless they trust the server they + are talking to and either have a secure path to it or use DNS + transaction security. + + Any security aware resolver willing to do cryptography SHOULD assert + the CD bit on all queries to permit it to impose its own policies and + to reduce DNS latency time by allowing security aware servers to + answer with Pending data. + + Security aware servers MUST NOT return Bad data. For non-security + aware resolvers or security aware resolvers requesting service by + having the CD bit clear, security aware servers MUST return only + Authenticated or Insecure data in the answer and authority sections + with the AD bit set in the response. Security aware servers SHOULD + return Pending data, with the AD bit clear in the response, to + security aware resolvers requesting this service by asserting the CD + bit in their request. The AD bit MUST NOT be set on a response + unless all of the RRs in the answer and authority sections of the + response are either Authenticated or Insecure. The AD bit does not + cover the additional information section. + + + + + + + +Eastlake Standards Track [Page 30] + +RFC 2535 DNS Security Extensions March 1999 + + +6.2 Staticly Configured Keys + + The public key to authenticate a zone SHOULD be defined in local + configuration files before that zone is loaded at the primary server + so the zone can be authenticated. + + While it might seem logical for everyone to start with a public key + associated with the root zone and staticly configure this in every + resolver, this has problems. The logistics of updating every DNS + resolver in the world should this key ever change would be severe. + Furthermore, many organizations will explicitly wish their "interior" + DNS implementations to completely trust only their own DNS servers. + Interior resolvers of such organizations can then go through the + organization's zone servers to access data outside the organization's + domain and need not be configured with keys above the organization's + DNS apex. + + Host resolvers that are not part of a larger organization may be + configured with a key for the domain of their local ISP whose + recursive secure DNS caching server they use. + +6.3 Chaining Through The DNS + + Starting with one or more trusted keys for any zone, it should be + possible to retrieve signed keys for that zone's subzones which have + a key. A secure sub-zone is indicated by a KEY RR with non-null key + information appearing with the NS RRs in the sub-zone and which may + also be present in the parent. These make it possible to descend + within the tree of zones. + +6.3.1 Chaining Through KEYs + + In general, some RRset that you wish to validate in the secure DNS + will be signed by one or more SIG RRs. Each of these SIG RRs has a + signer under whose name is stored the public KEY to use in + authenticating the SIG. Each of those KEYs will, generally, also be + signed with a SIG. And those SIGs will have signer names also + referring to KEYs. And so on. As a result, authentication leads to + chains of alternating SIG and KEY RRs with the first SIG signing the + original data whose authenticity is to be shown and the final KEY + being some trusted key staticly configured at the resolver performing + the authentication. + + In testing such a chain, the validity periods of the SIGs encountered + must be intersected to determine the validity period of the + authentication of the data, a purely algorithmic process. In + addition, the validation of each SIG over the data with reference to + a KEY must meet the objective cryptographic test implied by the + + + +Eastlake Standards Track [Page 31] + +RFC 2535 DNS Security Extensions March 1999 + + + cryptographic algorithm used (although even here the resolver may + have policies as to trusted algorithms and key lengths). Finally, + the judgement that a SIG with a particular signer name can + authenticate data (possibly a KEY RRset) with a particular owner + name, is primarily a policy question. Ultimately, this is a policy + local to the resolver and any clients that depend on that resolver's + decisions. It is, however, recommended, that the policy below be + adopted: + + Let A < B mean that A is a shorter domain name than B formed by + dropping one or more whole labels from the left end of B, i.e., + A is a direct or indirect superdomain of B. Let A = B mean that + A and B are the same domain name (i.e., are identical after + letter case canonicalization). Let A > B mean that A is a + longer domain name than B formed by adding one or more whole + labels on the left end of B, i.e., A is a direct or indirect + subdomain of B + + Let Static be the owner names of the set of staticly configured + trusted keys at a resolver. + + Then Signer is a valid signer name for a SIG authenticating an + RRset (possibly a KEY RRset) with owner name Owner at the + resolver if any of the following three rules apply: + + (1) Owner > or = Signer (except that if Signer is root, Owner + must be root or a top level domain name). That is, Owner is the + same as or a subdomain of Signer. + + (2) ( Owner < Signer ) and ( Signer > or = some Static ). That + is, Owner is a superdomain of Signer and Signer is staticly + configured or a subdomain of a staticly configured key. + + (3) Signer = some Static. That is, the signer is exactly some + staticly configured key. + + Rule 1 is the rule for descending the DNS tree and includes a special + prohibition on the root zone key due to the restriction that the root + zone be only one label deep. This is the most fundamental rule. + + Rule 2 is the rule for ascending the DNS tree from one or more + staticly configured keys. Rule 2 has no effect if only root zone + keys are staticly configured. + + Rule 3 is a rule permitting direct cross certification. Rule 3 has + no effect if only root zone keys are staticly configured. + + + + + +Eastlake Standards Track [Page 32] + +RFC 2535 DNS Security Extensions March 1999 + + + Great care should be taken that the consequences have been fully + considered before making any local policy adjustments to these rules + (other than dispensing with rules 2 and 3 if only root zone keys are + staticly configured). + +6.3.2 Conflicting Data + + It is possible that there will be multiple SIG-KEY chains that appear + to authenticate conflicting RRset answers to the same query. A + resolver should choose only the most reliable answer to return and + discard other data. This choice of most reliable is a matter of + local policy which could take into account differing trust in + algorithms, key sizes, staticly configured keys, zones traversed, + etc. The technique given below is recommended for taking into + account SIG-KEY chain length. + + A resolver should keep track of the number of successive secure zones + traversed from a staticly configured key starting point to any secure + zone it can reach. In general, the lower such a distance number is, + the greater the confidence in the data. Staticly configured data + should be given a distance number of zero. If a query encounters + different Authenticated data for the same query with different + distance values, that with a larger value should be ignored unless + some other local policy covers the case. + + A security conscious resolver should completely refuse to step from a + secure zone into a unsecured zone unless the unsecured zone is + certified to be non-secure by the presence of an authenticated KEY RR + for the unsecured zone with the no-key type value. Otherwise the + resolver is getting bogus or spoofed data. + + If legitimate unsecured zones are encountered in traversing the DNS + tree, then no zone can be trusted as secure that can be reached only + via information from such non-secure zones. Since the unsecured zone + data could have been spoofed, the "secure" zone reached via it could + be counterfeit. The "distance" to data in such zones or zones + reached via such zones could be set to 256 or more as this exceeds + the largest possible distance through secure zones in the DNS. + +6.4 Secure Time + + Coordinated interpretation of the time fields in SIG RRs requires + that reasonably consistent time be available to the hosts + implementing the DNS security extensions. + + A variety of time synchronization protocols exist including the + Network Time Protocol (NTP [RFC 1305, 2030]). If such protocols are + used, they MUST be used securely so that time can not be spoofed. + + + +Eastlake Standards Track [Page 33] + +RFC 2535 DNS Security Extensions March 1999 + + + Otherwise, for example, a host could get its clock turned back and + might then believe old SIG RRs, and the data they authenticate, which + were valid but are no longer. + +7. ASCII Representation of Security RRs + + This section discusses the format for master file and other ASCII + presentation of the three DNS security resource records. + + The algorithm field in KEY and SIG RRs can be represented as either + an unsigned integer or symbolicly. The following initial symbols are + defined as indicated: + + Value Symbol + + 001 RSAMD5 + 002 DH + 003 DSA + 004 ECC + 252 INDIRECT + 253 PRIVATEDNS + 254 PRIVATEOID + +7.1 Presentation of KEY RRs + + KEY RRs may appear as single logical lines in a zone data master file + [RFC 1033]. + + The flag field is represented as an unsigned integer or a sequence of + mnemonics as follows separated by instances of the verticle bar ("|") + character: + + BIT Mnemonic Explanation + 0-1 key type + NOCONF =1 confidentiality use prohibited + NOAUTH =2 authentication use prohibited + NOKEY =3 no key present + 2 FLAG2 - reserved + 3 EXTEND flags extension + 4 FLAG4 - reserved + 5 FLAG5 - reserved + 6-7 name type + USER =0 (default, may be omitted) + ZONE =1 + HOST =2 (host or other end entity) + NTYP3 - reserved + 8 FLAG8 - reserved + 9 FLAG9 - reserved + + + +Eastlake Standards Track [Page 34] + +RFC 2535 DNS Security Extensions March 1999 + + + 10 FLAG10 - reserved + 11 FLAG11 - reserved + 12-15 signatory field, values 0 to 15 + can be represented by SIG0, SIG1, ... SIG15 + + No flag mnemonic need be present if the bit or field it represents is + zero. + + The protocol octet can be represented as either an unsigned integer + or symbolicly. The following initial symbols are defined: + + 000 NONE + 001 TLS + 002 EMAIL + 003 DNSSEC + 004 IPSEC + 255 ALL + + Note that if the type flags field has the NOKEY value, nothing + appears after the algorithm octet. + + The remaining public key portion is represented in base 64 (see + Appendix A) and may be divided up into any number of white space + separated substrings, down to single base 64 digits, which are + concatenated to obtain the full signature. These substrings can span + lines using the standard parenthesis. + + Note that the public key may have internal sub-fields but these do + not appear in the master file representation. For example, with + algorithm 1 there is a public exponent size, then a public exponent, + and then a modulus. With algorithm 254, there will be an OID size, + an OID, and algorithm dependent information. But in both cases only a + single logical base 64 string will appear in the master file. + +7.2 Presentation of SIG RRs + + A data SIG RR may be represented as a single logical line in a zone + data file [RFC 1033] but there are some special considerations as + described below. (It does not make sense to include a transaction or + request authenticating SIG RR in a file as they are a transient + authentication that covers data including an ephemeral transaction + number and so must be calculated in real time.) + + There is no particular problem with the signer, covered type, and + times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY + is the year, the first MM is the month number (01-12), DD is the day + of the month (01-31), HH is the hour in 24 hours notation (00-23), + the second MM is the minute (00-59), and SS is the second (00-59). + + + +Eastlake Standards Track [Page 35] + +RFC 2535 DNS Security Extensions March 1999 + + + The original TTL field appears as an unsigned integer. + + If the original TTL, which applies to the type signed, is the same as + the TTL of the SIG RR itself, it may be omitted. The date field + which follows it is larger than the maximum possible TTL so there is + no ambiguity. + + The "labels" field appears as an unsigned integer. + + The key tag appears as an unsigned number. + + However, the signature itself can be very long. It is the last data + field and is represented in base 64 (see Appendix A) and may be + divided up into any number of white space separated substrings, down + to single base 64 digits, which are concatenated to obtain the full + signature. These substrings can be split between lines using the + standard parenthesis. + +7.3 Presentation of NXT RRs + + NXT RRs do not appear in original unsigned zone master files since + they should be derived from the zone as it is being signed. If a + signed file with NXTs added is printed or NXTs are printed by + debugging code, they appear as the next domain name followed by the + RR type present bits as an unsigned interger or sequence of RR + mnemonics. + +8. Canonical Form and Order of Resource Records + + This section specifies, for purposes of domain name system (DNS) + security, the canonical form of resource records (RRs), their name + order, and their overall order. A canonical name order is necessary + to construct the NXT name chain. A canonical form and ordering + within an RRset is necessary in consistently constructing and + verifying SIG RRs. A canonical ordering of types within a name is + required in connection with incremental transfer (Section 5.6.2). + +8.1 Canonical RR Form + + For purposes of DNS security, the canonical form for an RR is the + wire format of the RR with domain names (1) fully expanded (no name + compression via pointers), (2) all domain name letters set to lower + case, (3) owner name wild cards in master file form (no substitution + made for *), and (4) the original TTL substituted for the current + TTL. + + + + + + +Eastlake Standards Track [Page 36] + +RFC 2535 DNS Security Extensions March 1999 + + +8.2 Canonical DNS Name Order + + For purposes of DNS security, the canonical ordering of owner names + is to sort individual labels as unsigned left justified octet strings + where the absence of a octet sorts before a zero value octet and + upper case letters are treated as lower case letters. Names in a + zone are sorted by sorting on the highest level label and then, + within those names with the same highest level label by the next + lower label, etc. down to leaf node labels. Within a zone, the zone + name itself always exists and all other names are the zone name with + some prefix of lower level labels. Thus the zone name itself always + sorts first. + + Example: + foo.example + a.foo.example + yljkjljk.a.foo.example + Z.a.foo.example + zABC.a.FOO.EXAMPLE + z.foo.example + *.z.foo.example + \200.z.foo.example + +8.3 Canonical RR Ordering Within An RRset + + Within any particular owner name and type, RRs are sorted by RDATA as + a left justified unsigned octet sequence where the absence of an + octet sorts before the zero octet. + +8.4 Canonical Ordering of RR Types + + When RRs of the same name but different types must be ordered, they + are ordered by type, considering the type to be an unsigned integer, + except that SIG RRs are placed immediately after the type they cover. + Thus, for example, an A record would be put before an MX record + because A is type 1 and MX is type 15 but if both were signed, the + order would be A < SIG(A) < MX < SIG(MX). + +9. Conformance + + Levels of server and resolver conformance are defined below. + +9.1 Server Conformance + + Two levels of server conformance for DNS security are defined as + follows: + + + + + +Eastlake Standards Track [Page 37] + +RFC 2535 DNS Security Extensions March 1999 + + + BASIC: Basic server compliance is the ability to store and retrieve + (including zone transfer) SIG, KEY, and NXT RRs. Any secondary or + caching server for a secure zone MUST have at least basic compliance + and even then some things, such as secure CNAMEs, will not work + without full compliance. + + FULL: Full server compliance adds the following to basic compliance: + (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) + ability, given a zone file and private key, to add appropriate SIG + and NXT RRs, possibly via a separate application, (3) proper + automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) + suppression of CNAME following on retrieval of the security type RRs, + (5) recognize the CD query header bit and set the AD query header + bit, as appropriate, and (6) proper handling of the two NXT RRs at + delegation points. Primary servers for secure zones MUST be fully + compliant and for complete secure operation, all secondary, caching, + and other servers handling the zone SHOULD be fully compliant as + well. + +9.2 Resolver Conformance + + Two levels of resolver compliance (including the resolver portion of + a server) are defined for DNS Security: + + BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs + when they are explicitly requested. + + FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT + RRs including verification of SIGs at least for the mandatory + algorithm, (2) maintains appropriate information in its local caches + and database to indicate which RRs have been authenticated and to + what extent they have been authenticated, (3) performs additional + queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when + needed, (4) normally sets the CD query header bit on its queries. + +10. Security Considerations + + This document specifies extensions to the Domain Name System (DNS) + protocol to provide data integrity and data origin authentication, + public key distribution, and optional transaction and request + security. + + It should be noted that, at most, these extensions guarantee the + validity of resource records, including KEY resource records, + retrieved from the DNS. They do not magically solve other security + problems. For example, using secure DNS you can have high confidence + in the IP address you retrieve for a host name; however, this does + not stop someone for substituting an unauthorized host at that + + + +Eastlake Standards Track [Page 38] + +RFC 2535 DNS Security Extensions March 1999 + + + address or capturing packets sent to that address and falsely + responding with packets apparently from that address. Any reasonably + complete security system will require the protection of many + additional facets of the Internet beyond DNS. + + The implementation of NXT RRs as described herein enables a resolver + to determine all the names in a zone even if zone transfers are + prohibited (section 5.6). This is an active area of work and may + change. + + A number of precautions in DNS implementation have evolved over the + years to harden the insecure DNS against spoofing. These precautions + should not be abandoned but should be considered to provide + additional protection in case of key compromise in secure DNS. + +11. IANA Considerations + + KEY RR flag bits 2 and 8-11 and all flag extension field bits can be + assigned by IETF consensus as defined in RFC 2434. The remaining + values of the NAMTYP flag field and flag bits 4 and 5 (which could + conceivably become an extension of the NAMTYP field) can only be + assigned by an IETF Standards Action [RFC 2434]. + + Algorithm numbers 5 through 251 are available for assignment should + sufficient reason arise. However, the designation of a new algorithm + could have a major impact on interoperability and requires an IETF + Standards Action [RFC 2434]. The existence of the private algorithm + types 253 and 254 should satify most needs for private or proprietary + algorithms. + + Additional values of the Protocol Octet (5-254) can be assigned by + IETF Consensus [RFC 2434]. + + The meaning of the first bit of the NXT RR "type bit map" being a one + can only be assigned by a standards action. + +References + + [RFC 1033] Lottor, M., "Domain Administrators Operations Guide", RFC + 1033, November 1987. + + [RFC 1034] Mockapetris, P., "Domain Names - Concepts and + Facilities", STD 13, RFC 1034, November 1987. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + + + + +Eastlake Standards Track [Page 39] + +RFC 2535 DNS Security Extensions March 1999 + + + [RFC 1305] Mills, D., "Network Time Protocol (v3)", RFC 1305, March + 1992. + + [RFC 1530] Malamud, C. and M. Rose, "Principles of Operation for the + TPC.INT Subdomain: General Principles and Policy", RFC + 1530, October 1993. + + [RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC + 1982, September 1996. + + [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 + for IPv4, IPv6 and OSI", RFC 2030, October 1996. + + [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic Update", + RFC 2137, April 1997. + + [RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name + System (DNS)", RFC 2537, March 1999. + + [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + + +Eastlake Standards Track [Page 40] + +RFC 2535 DNS Security Extensions March 1999 + + + [RFC 2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name + System (DNS)", RFC 2536, March 1999. + + [RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in + the Domain Name System", RFC 2538, March 1999. + + [RFC 2541] Eastlake, D., "DNS Operational Security Considerations", + RFC 2541, March 1999. + + [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. + +Author's Address + + Donald E. Eastlake 3rd + IBM + 65 Shindegan Hill Road + RR #1 + Carmel, NY 10512 + + Phone: +1-914-784-7913 (w) + +1-914-276-2668 (h) + Fax: +1-914-784-3833 (w-fax) + EMail: dee3@us.ibm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 41] + +RFC 2535 DNS Security Extensions March 1999 + + +Appendix A: Base 64 Encoding + + The following encoding technique is taken from [RFC 2045] by N. + Borenstein and N. Freed. It is reproduced here in an edited form for + convenience. + + A 65-character subset of US-ASCII is used, enabling 6 bits to be + represented per printable character. (The extra 65th character, "=", + is used to signify a special processing function.) + + The encoding process represents 24-bit groups of input bits as output + strings of 4 encoded characters. Proceeding from left to right, a + 24-bit input group is formed by concatenating 3 8-bit input groups. + These 24 bits are then treated as 4 concatenated 6-bit groups, each + of which is translated into a single digit in the base 64 alphabet. + + Each 6-bit group is used as an index into an array of 64 printable + characters. The character referenced by the index is placed in the + output string. + + Table 1: The Base 64 Alphabet + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y + + Special processing is performed if fewer than 24 bits are available + at the end of the data being encoded. A full encoding quantum is + always completed at the end of a quantity. When fewer than 24 input + bits are available in an input group, zero bits are added (on the + right) to form an integral number of 6-bit groups. Padding at the + end of the data is performed using the '=' character. Since all base + 64 input is an integral number of octets, only the following cases + + + +Eastlake Standards Track [Page 42] + +RFC 2535 DNS Security Extensions March 1999 + + + can arise: (1) the final quantum of encoding input is an integral + multiple of 24 bits; here, the final unit of encoded output will be + an integral multiple of 4 characters with no "=" padding, (2) the + final quantum of encoding input is exactly 8 bits; here, the final + unit of encoded output will be two characters followed by two "=" + padding characters, or (3) the final quantum of encoding input is + exactly 16 bits; here, the final unit of encoded output will be three + characters followed by one "=" padding character. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 43] + +RFC 2535 DNS Security Extensions March 1999 + + +Appendix B: Changes from RFC 2065 + + This section summarizes the most important changes that have been + made since RFC 2065. + + 1. Most of Section 7 of [RFC 2065] called "Operational + Considerations", has been removed and may be made into a separate + document [RFC 2541]. + + 2. The KEY RR has been changed by (2a) eliminating the "experimental" + flag as unnecessary, (2b) reserving a flag bit for flags + expansion, (2c) more compactly encoding a number of bit fields in + such a way as to leave unchanged bits actually used by the limited + code currently deployed, (2d) eliminating the IPSEC and email flag + bits which are replaced by values of the protocol field and adding + a protocol field value for DNS security itself, (2e) adding + material to indicate that zone KEY RRs occur only at delegation + points, and (2f) removing the description of the RSA/MD5 algorithm + to a separate document [RFC 2537]. Section 3.4 describing the + meaning of various combinations of "no-key" and key present KEY + RRs has been added and the secure / unsecure status of a zone has + been clarified as being per algorithm. + + 3. The SIG RR has been changed by (3a) renaming the "time signed" + field to be the "signature inception" field, (3b) clarifying that + signature expiration and inception use serial number ring + arithmetic, (3c) changing the definition of the key footprint/tag + for algorithms other than 1 and adding Appendix C to specify its + calculation. In addition, the SIG covering type AXFR has been + eliminated while one covering IXFR [RFC 1995] has been added (see + section 5.6). + + 4. Algorithm 3, the DSA algorithm, is now designated as the mandatory + to implement algorithm. Algorithm 1, the RSA/MD5 algorithm, is + now a recommended option. Algorithm 2 and 4 are designated as the + Diffie-Hellman key and elliptic cryptography algorithms + respectively, all to be defined in separate documents. Algorithm + code point 252 is designated to indicate "indirect" keys, to be + defined in a separate document, where the actual key is elsewhere. + Both the KEY and SIG RR definitions have been simplified by + eliminating the "null" algorithm 253 as defined in [RFC 2065]. + That algorithm had been included because at the time it was + thought it might be useful in DNS dynamic update [RFC 2136]. It + was in fact not so used and it is dropped to simplify DNS + security. Howver, that algorithm number has been re-used to + indicate private algorithms where a domain name specifies the + algorithm. + + + + +Eastlake Standards Track [Page 44] + +RFC 2535 DNS Security Extensions March 1999 + + + 5. The NXT RR has been changed so that (5a) the NXT RRs in a zone + cover all names, including wildcards as literal names without + expansion, except for glue address records whose names would not + otherwise appear, (5b) all NXT bit map areas whose first octet has + bit zero set have been reserved for future definition, (5c) the + number of and circumstances under which an NXT must be returned in + connection with wildcard names has been extended, and (5d) in + connection with the bit map, references to the WKS RR have been + removed and verticle bars ("|") have been added between the RR + type mnemonics in the ASCII representation. + + 6. Information on the canonical form and ordering of RRs has been + moved into a separate Section 8. + + 7. A subsection covering incremental and full zone transfer has been + added in Section 5. + + 8. Concerning DNS chaining: Further specification and policy + recommendations on secure resolution have been added, primarily in + Section 6.3.1. It is now clearly stated that authenticated data + has a validity period of the intersection of the validity periods + of the SIG RRs in its authentication chain. The requirement to + staticly configure a superzone's key signed by a zone in all of + the zone's authoritative servers has been removed. The + recommendation to continue DNS security checks in a secure island + of DNS data that is separated from other parts of the DNS tree by + insecure zones and does not contain a zone for which a key has + been staticly configured was dropped. + + 9. It was clarified that the presence of the AD bit in a response + does not apply to the additional information section or to glue + address or delegation point NS RRs. The AD bit only indicates + that the answer and authority sections of the response are + authoritative. + + 10. It is now required that KEY RRs and NXT RRs be signed only with + zone-level keys. + + 11. Add IANA Considerations section and references to RFC 2434. + + + + + + + + + + + + +Eastlake Standards Track [Page 45] + +RFC 2535 DNS Security Extensions March 1999 + + +Appendix C: Key Tag Calculation + + The key tag field in the SIG RR is just a means of more efficiently + selecting the correct KEY RR to use when there is more than one KEY + RR candidate available, for example, in verifying a signature. It is + possible for more than one candidate key to have the same tag, in + which case each must be tried until one works or all fail. The + following reference implementation of how to calculate the Key Tag, + for all algorithms other than algorithm 1, is in ANSI C. It is coded + for clarity, not efficiency. (See section 4.1.6 for how to determine + the Key Tag of an algorithm 1 key.) + + /* assumes int is at least 16 bits + first byte of the key tag is the most significant byte of return + value + second byte of the key tag is the least significant byte of + return value + */ + + int keytag ( + + unsigned char key[], /* the RDATA part of the KEY RR */ + unsigned int keysize, /* the RDLENGTH */ + ) + { + long int ac; /* assumed to be 32 bits or larger */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i&1) ? key[i] : key[i]<<8; + ac += (ac>>16) & 0xFFFF; + return ac & 0xFFFF; + } + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 46] + +RFC 2535 DNS Security Extensions March 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 47] + diff --git a/Documentation/en/rfc/rfc2646.txt b/Documentation/en/rfc/rfc2646.txt new file mode 100644 index 00000000..cd2e8dfd --- /dev/null +++ b/Documentation/en/rfc/rfc2646.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group R. Gellens, Editor +Request for Comments: 2646 Qualcomm +Updates: 2046 August 1999 +Category: Standards Track + + + The Text/Plain Format Parameter + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Table of Contents + + 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in this Document . . . . . . . . . . . . . 2 + 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . 3 + 3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3 + 3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4 + 4. The Format Parameter to the Text/Plain Media Type . . . . . 4 + 4.1. Generating Format=Flowed . . . . . . . . . . . . . . . 5 + 4.2. Interpreting Format=Flowed . . . . . . . . . . . . . . . 6 + 4.3. Usenet Signature Convention . . . . . . . . . . . . . . 7 + 4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . . 7 + 4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.6. Digital Signatures and Encryption . . . . . . . . . . . 9 + 4.7. Line Analysis Table . . . . . . . . . . . . . . . . . . 10 + 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Trailing White Space Corruption . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 + 9. Internationalization Considerations . . . . . . . . . . . . 12 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 12. Editor's Address . . . . . . . . . . . . . . . . . . . . . 13 + 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 + + + + +Gellens Standards Track [Page 1] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + +1. Abstract + + Interoperability problems have been observed with erroneous labelling + of paragraph text as Text/Plain, and with various forms of + "embarrassing line wrap." (See section 3.) + + Attempts to deploy new media types, such as Text/Enriched [RICH] and + Text/HTML [HTML] have suffered from a lack of backwards compatibility + and an often hostile user reaction at the receiving end. + + What is required is a format which is in all significant ways + Text/Plain, and therefore is quite suitable for display as + Text/Plain, and yet allows the sender to express to the receiver + which lines can be considered a logical paragraph, and thus flowed + (wrapped and joined) as appropriate. + + This memo proposes a new parameter to be used with Text/Plain, and, + in the presence of this parameter, the use of trailing whitespace to + indicate flowed lines. This results in an encoding which appears as + normal Text/Plain in older implementations, since it is in fact + normal Text/Plain. + +2. Conventions Used in this Document + + The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", + and "MAY" in this document are to be interpreted as described in "Key + words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. + +3. The Problem + + The Text/Plain media type is the lowest common denominator of + Internet email, with lines of no more than 997 characters (by + convention usually no more than 80), and where the CRLF sequence + represents a line break [MIME-IMT]. + + Text/Plain is usually displayed as preformatted text, often in a + fixed font. That is, the characters start at the left margin of the + display window, and advance to the right until a CRLF sequence is + seen, at which point a new line is started, again at the left margin. + When a line length exceeds the display window, some clients will wrap + the line, while others invoke a horizontal scroll bar. + + Text which meets this description is defined by this memo as "fixed". + + Some interoperability problems have been observed with this media + type: + + + + + +Gellens Standards Track [Page 2] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + +3.1. Paragraph Text + + Many modern programs use a proportional-spaced font and CRLF to + represent paragraph breaks. Line breaks are "soft", occurring as + needed on display. That is, characters are grouped into a paragraph + until a CRLF sequence is seen, at which point a new paragraph is + started. Each paragraph is displayed, starting at the left margin + (or paragraph indent), and continuing to the right until a word is + encountered which does not fit in the remaining display width. This + word is displayed at the left margin of the next line. This + continues until the paragraph ends (a CRLF is seen). Extra vertical + space is left between paragraphs. + + Text which meets this description is defined by this memo as + "flowed". + + Numerous software products erroneously label this media type as + Text/Plain, resulting in much user discomfort. + +3.2. Embarrassing Line Wrap + + As Text/Plain messages get quoted in replies or forwarded messages, + the length of each line gradually increases, resulting in + "embarrassing line wrap." This results in text which is at best hard + to read, and often confuses attributions. + + Example: + + >>>>>>This is a comment from the first message to show a + >quoting example. + >>>>>This is a comment from the second message to show a + >quoting example. + >>>>This is a comment from the third message. + >>>This is a comment from the fourth message. + + It can be confusing to assign attribution to lines 2 and 4 above. + + In addition, as devices with display widths smaller than 80 + characters become more popular, embarrassing line wrap has become + even more prevalent, even with unquoted text. + + + + + + + + + + + +Gellens Standards Track [Page 3] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + + Example: + + This is paragraph text that is + meant to be flowed across + several lines. + However, the sending mailer is + converting it to fixed text at + a width of 72 + characters, which causes it to + look like this when shown on a + PDA with only + 30 character lines. + +3.3. New Media Types + + Attempts to deploy new media types, such as Text/Enriched [RICH] and + Text/HTML [HTML] have suffered from a lack of backwards compatibility + and an often hostile user reaction at the receiving end. + + In particular, Text/Enriched requires that open angle brackets ("<") + and hard line breaks be doubled, with resulting user unhappiness when + viewed as Text/Plain. Text/HTML requires even more alteration of + text, with a corresponding increase in user complaints. + + A proposal to define a new media type to explicitly represent the + paragraph form suffered from a lack of interoperability with + currently deployed software. Some programs treat unknown subtypes of + Text as an attachment. + + What is desired is a format which is in all significant ways + Text/Plain, and therefore is quite suitable for display as + Text/Plain, and yet allows the sender to express to the receiver + which lines can be considered a logical paragraph, and thus flowed + (wrapped and joined) as appropriate. + +4. The Format Parameter to the Text/Plain Media Type + + This document defines a new MIME parameter for use with Text/Plain: + + Name: Format + Value: Fixed, Flowed + + (Neither the parameter name nor its value are case sensitive.) + + If not specified, a value of Fixed is assumed. The semantics of the + Fixed value are the usual associated with Text/Plain [MIME-IMT]. + + + + + +Gellens Standards Track [Page 4] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + + A value of Flowed indicates that the definition of flowed text (as + specified in this memo) was used on generation, and MAY be used on + reception. + + This section discusses flowed text; section 5 provides a formal + definition. + + Because flowed lines are all-but-indistinguishable from fixed lines, + currently deployed software treats flowed lines as normal Text/Plain + (which is what they are). Thus, no interoperability problems are + expected. + + Note that this memo describes an on-the-wire format. It does not + address formats for local file storage. + +4.1. Generating Format=Flowed + + When generating Format=Flowed text, lines SHOULD be shorter than 80 + characters. As suggested values, any paragraph longer than 79 + characters in total length could be wrapped using lines of 72 or + fewer characters. While the specific line length used is a matter of + aesthetics and preference, longer lines are more likely to require + rewrapping and to encounter difficulties with older mailers. It has + been suggested that 66 character lines are the most readable. + + (The reason for the restriction to 79 or fewer characters between + CRLFs on the wire is to ensure that all lines, even when displayed by + a non-flowed-aware program, will fit in a standard 80-column screen + without having to be wrapped. The limit is 79, not 80, because while + 80 fit on a line, the last column is often reserved for a line-wrap + indicator.) + + When creating flowed text, the generating agent wraps, that is, + inserts 'soft' line breaks as needed. Soft line breaks are added + between words. Because a soft line break is a SP CRLF sequence, the + generating agent creates one by inserting a CRLF after the occurance + of a space. + + A generating agent SHOULD NOT insert white space into a word (a + sequence of printable characters not containing spaces). If faced + with a word which exceeds 79 characters (but less than 998 + characters, the [SMTP] limit on line length), the agent SHOULD send + the word as is and exceed the 79-character limit on line length. + + + + + + + + +Gellens Standards Track [Page 5] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + + A generating agent SHOULD: + + 1. Ensure all lines (fixed and flowed) are 79 characters or + fewer in length, counting the trailing space but not + counting the CRLF, unless a word by itself exceeds 79 + characters. + 2. Trim spaces before user-inserted hard line breaks. + 3. Space-stuff lines which start with a space, "From ", or + ">". + + In order to create messages which do not require space-stuffing, and + are thus more aesthetically pleasing when viewed as Format=Fixed, a + generating agent MAY avoid wrapping immediately before ">", "From ", + or space. + + (See sections 4.4 and 4.5 for more information on space-stuffing and + quoting, respectively.) + + A Format=Flowed message consists of zero or more paragraphs, each + containing one or more flowed lines followed by one fixed line. The + usual case is a series of flowed text lines with blank (empty) fixed + lines between them. + + Any number of fixed lines can appear between paragraphs. + + [Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed + unless absolutely necessary (for example, non-US-ASCII (8-bit) + characters over a strictly 7-bit transport such as unextended SMTP). + In particular, a message SHOULD NOT be encoded in Quoted-Printable + for the sole purpose of protecting the trailing space on flowed lines + unless the body part is cryptographically signed or encrypted (see + Section 4.6). + + The intent of Format=Flowed is to allow user agents to generate + flowed text which is non-obnoxious when viewed as pure, raw + Text/Plain (without any decoding); use of Quoted-Printable hinders + this and may cause Format=Flowed to be rejected by end users. + +4.2. Interpreting Format=Flowed + + If the first character of a line is a quote mark (">"), the line is + considered to be quoted (see section 4.5). Logically, all quote + marks are counted and deleted, resulting in a line with a non-zero + quote depth, and content. (The agent is of course free to display the + content with quote marks or excerpt bars or anything else.) + Logically, this test for quoted lines is done before any other tests + (that is, before checking for space-stuffed and flowed). + + + + +Gellens Standards Track [Page 6] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + + If the first character of a line is a space, the line has been + space-stuffed (see section 4.4). Logically, this leading space is + deleted before examining the line further (that is, before checking + for flowed). + + If the line ends in one or more spaces, the line is flowed. + Otherwise it is fixed. Trailing spaces are part of the line's + content, but the CRLF of a soft line break is not. + + A series of one or more flowed lines followed by one fixed line is + considered a paragraph, and MAY be flowed (wrapped and unwrapped) as + appropriate on display and in the construction of new messages (see + section 4.5). + + A line consisting of one or more spaces (after deleting a stuffed + space) is considered a flowed line. + +4.3. Usenet Signature Convention + + There is a convention in Usenet news of using "-- " as the separator + line between the body and the signature of a message. When + generating a Format=Flowed message containing a Usenet-style + separator before the signature, the separator line is sent as-is. + This is a special case; an (optionally quoted) line consisting of + DASH DASH SP is not considered flowed. + +4.4. Space-Stuffing + + In order to allow for unquoted lines which start with ">", and to + protect against systems which "From-munge" in-transit messages + (modifying any line which starts with "From " to ">From "), + Format=Flowed provides for space-stuffing. + + Space-stuffing adds a single space to the start of any line which + needs protection when the message is generated. On reception, if the + first character of a line is a space, it is logically deleted. This + occurs after the test for a quoted line, and before the test for a + flowed line. + + On generation, any unquoted lines which start with ">", and any lines + which start with a space or "From " SHOULD be space-stuffed. Other + lines MAY be space-stuffed as desired. + + (Note that space-stuffing is similar to dot-stuffing as specified in + [SMTP].) + + + + + + +Gellens Standards Track [Page 7] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + + If a space-stuffed message is received by an agent which handles + Format=Flowed, the space-stuffing is reversed and thus the message + appears unchanged. An agent which is not aware of Format=Flowed will + of course not undo any space-stuffing, thus Format=Flowed messages + may appear with a leading space on some lines (those which start with + a space, ">" which is not a quote indicator, or "From "). Since + lines which require space-stuffing rarely occur, and the aesthetic + consequences of unreversed space-stuffing are minimal, this is not + expected to be a significant problem. + +4.5. Quoting + + In Format=Flowed, the canonical quote indicator (or quote mark) is + one or more close angle bracket (">") characters. Lines which start + with the quote indicator are considered quoted. The number of ">" + characters at the start of the line specifies the quote depth. + Flowed lines which are also quoted may require special handling on + display and when copied to new messages. + + When creating quoted flowed lines, each such line starts with the + quote indicator. + + Note that because of space-stuffing, the lines + >> Exit, Stage Left + and + >>Exit, Stage Left + are semantically identical; both have a quote-depth of two, and a + content of "Exit, Stage Left". + + However, the line + > > Exit, Stage Left + is different. It has a quote-depth of one, and a content of + "> Exit, Stage Left". + + When generating quoted flowed lines, an agent needs to pay attention + to changes in quote depth. A sequence of quoted lines of the same + quote depth SHOULD be encoded as a paragraph, with the last line + generated as fixed and prior lines generated as flowed. + + If a receiving agent wishes to reformat flowed quoted lines (joining + and/or wrapping them) on display or when generating new messages, the + lines SHOULD be de-quoted, reformatted, and then re-quoted. To + de-quote, the number of close angle brackets in the quote indicator + at the start of each line is counted. Consecutive lines with the + same quoting depth are considered one paragraph and are reformatted + together. To re-quote after reformatting, a quote indicator + containing the same number of close angle brackets originally present + is prefixed to each line. + + + +Gellens Standards Track [Page 8] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + + On reception, if a change in quoting depth occurs on a flowed line, + this is an improperly formatted message. The receiver SHOULD handle + this error by using the 'quote-depth-wins' rule, which is to ignore + the flowed indicator and treat the line as fixed. That is, the + change in quote depth ends the paragraph. + + For example, consider the following sequence of lines (using '*' to + indicate a soft line break, i.e., SP CRLF, and '#' to indicate a hard + line break, i.e., CRLF): + + > Thou villainous ill-breeding spongy dizzy-eyed* + > reeky elf-skinned pigeon-egg!* <--- problem ---< + >> Thou artless swag-bellied milk-livered* + >> dismal-dreaming idle-headed scut!# + >>> Thou errant folly-fallen spleeny reeling-ripe* + >>> unmuzzled ratsbane!# + >>>> Henceforth, the coding style is to be strictly* + >>>> enforced, including the use of only upper case.# + >>>>> I've noticed a lack of adherence to the coding* + >>>>> styles, of late.# + >>>>>> Any complaints?# + + The second line ends in a soft line break, even though it is the last + line of the one-deep quote block. The question then arises as to how + this line should be interpreted, considering that the next line is + the first line of the two-deep quote block. + + The example text above, when processed according to quote-depth wins, + results in the first two lines being considered as one quoted, flowed + section, with a quote depth of 1; the third and fourth lines become a + quoted, flowed section, with a quote depth of 2. + + A generating agent SHOULD NOT create this situation; a receiving + agent SHOULD handle it using quote-depth wins. + +4.6. Digital Signatures and Encryption + + If a message is digitally signed or encrypted it is important that + cryptographic processing use the on-the-wire Format=Flowed format. + That is, during generation the message SHOULD be prepared for + transmission, including addition of soft line breaks, space-stuffing, + and [Quoted-Printable] encoding (to protect soft line breaks) before + being digitally signed or encrypted; similarly, on receipt the + message SHOULD have the signature verified or be decrypted before + [Quoted-Printable] decoding and removal of stuffed spaces, soft line + breaks and quote marks, and reflowing. + + + + + +Gellens Standards Track [Page 9] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + +4.7. Line Analysis Table + + Lines contained in a Text/Plain body part with Format=Flowed can be + analyzed by examining the start and end of the line. If the line + starts with the quote indicator, it is quoted. If the line ends with + one or more space characters, it is flowed. This is summarized by + the following table: + + Starts Ends in + with One or Line + Quote More Spaces Type + ------ ----------- --------------- + no no unquoted, fixed + yes no quoted, fixed + no yes unquoted, flowed + yes yes quoted, flowed + +4.8. Examples + + The following example contains three paragraphs: + + `Take some more tea,' the March Hare said to Alice, very + earnestly. + + `I've had nothing yet,' Alice replied in an offended tone, `so I + can't take more.' + + `You mean you can't take LESS,' said the Hatter: `it's very easy + to take MORE than nothing.' + + This could be encoded as follows (using '*' to indicate a soft line + break, that is, SP CRLF sequence, and '#' to indicate a hard line + break, that is, CRLF): + + `Take some more tea,' the March Hare said to Alice, very* + earnestly.* + # + `I've had nothing yet,' Alice replied in an offended tone, `so* + I can't take more.'* + # + `You mean you can't take LESS,' said the Hatter: `it's very* + easy to take MORE than nothing.'# + + + + + + + + + +Gellens Standards Track [Page 10] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + + To show an example of quoting, here we have the same exchange, + presented as a series of direct quotes: + + >>>Take some more tea.# + >>I've had nothing yet, so I can't take more.# + >You mean you can't take LESS, it's very easy to take* + >MORE than nothing.# + +5. ABNF + + The constructs used in Text/Plain; Format=Flowed body parts are + described using [ABNF], including the Core Rules: + + paragraph = 1*flowed-line fixed-line + fixed-line = fixed / sig-sep + fixed = [quote] [stuffing] *text-char non-sp CRLF + flowed-line = flow-qt / flow-unqt + flow-qt = quote [stuffing] *text-char 1*SP CRLF + flow-unqt = [stuffing] *text-char 1*SP CRLF + non-sp = %x01-09 / %x0B / %x0C / %x0E-1F / %x21-7F + ; any 7-bit US-ASCII character, excluding + ; NUL, CR, LF, and SP + quote = 1*">" + sig-sep = [quote] "--" SP CRLF + stuffing = [SP] ; space-stuffed, added on generation if + ; needed, deleted on reception + text-char = non-sp / SP + +6. Failure Modes + +6.1. Trailing White Space Corruption + + There are systems in existence which alter trailing whitespace on + messages which pass through them. Such systems may strip, or in + rarer cases, add trailing whitespace, in violation of RFC 821 [SMTP] + section 4.5.2. + + Stripping trailing whitespace has the effect of converting flowed + lines to fixed lines, which results in a message no worse than if + Format=Flowed had not been used. + + Adding trailing whitespace to a Format=Flowed message may result in a + malformed display or reply. + + Since most systems which add trailing white space do so to create a + line which fills an internal record format, the result is almost + always a line which contains an even number of characters (counting + the added trailing white space). + + + +Gellens Standards Track [Page 11] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + + One possible avoidance, therefore, would be to define Format=Flowed + lines to use either one or two trailing space characters to indicate + a flowed line, such that the total line length is odd. However, + considering the scarcity of such systems today, it is not worth the + added complexity. + +7. Security Considerations + + This parameter introduces no security considerations beyond those + which apply to Text/Plain. + + Section 4.6 discusses the interaction between Format=Flowed and + digital signatures or encryption. + +8. IANA Considerations + + IANA is requested to add a reference to this specification in the + Text/Plain Media Type registration. + +9. Internationalization Considerations + + The line wrap and quoting specifications of Format=Flowed may not be + suitable for certain charsets, such as for Arabic and Hebrew + characters that read from right to left. Care should be taken in + applying format=flowed in these cases, as format=fixed combined with + quoted-printable encoding may be more suitable. + +10. Acknowledgments + + This proposal evolved from a discussion of Chris Newman's + Text/Paragraph draft which took place on the IETF 822 mailing list. + Special thanks to Ian Bell, Steve Dorner, Brian Kelley, Dan Kohn, + Laurence Lundblade, and Dan Wing for their reviews, comments, + suggestions, and discussions. + +11. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 2234, November + 1997. + + [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RICH] Resnick, P. and A. Walker, "The text/enriched MIME + Content-type", RFC 1896, February 1996. + + + + + +Gellens Standards Track [Page 12] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + + [MIME-IMT] Freed, N. and N. Borenstein, "Multipurpose + Internet Mail Extensions (MIME) Part Two: Media + Types", RFC 2046, November 1996. + + [Quoted-Printable] Freed, N. and N. Borenstein, "Multipurpose + Internet Mail Extensions (MIME) Part One: Format + of Internet Message Bodies", RFC 2045, November + 1996. + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD + 10, RFC 821, August 1982. + + [HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup + Language -- 2.0", RFC 1866, November 1995. + + +12. Editor's Address + + Randall Gellens + QUALCOMM Incorporated + 5775 Morehouse Dr. + San Diego, CA 92121-2779 + USA + + Phone: +1 619 651 5115 + EMail: randy@qualcomm.com + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 13] + +RFC 2646 The Text/Plain Format Parameter August 1999 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 14] + diff --git a/Documentation/en/rfc/rfc2845.txt b/Documentation/en/rfc/rfc2845.txt new file mode 100644 index 00000000..aa9f385a --- /dev/null +++ b/Documentation/en/rfc/rfc2845.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group P. Vixie +Request for Comments: 2845 ISC +Category: Standards Track O. Gudmundsson +Updates: 1035 NAI Labs + D. Eastlake 3rd + Motorola + B. Wellington + Nominum + May 2000 + + + Secret Key Transaction Authentication for DNS (TSIG) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This protocol allows for transaction level authentication using + shared secrets and one way hashing. It can be used to authenticate + dynamic updates as coming from an approved client, or to authenticate + responses as coming from an approved recursive name server. + + No provision has been made here for distributing the shared secrets; + it is expected that a network administrator will statically configure + name servers and clients using some out of band mechanism such as + sneaker-net until a secure automated mechanism for key distribution + is available. + +1 - Introduction + + 1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated + hierarchical distributed database system that provides information + fundamental to Internet operations, such as name <=> address + translation and mail handling information. DNS has recently been + extended [RFC2535] to provide for data origin authentication, and + public key distribution, all based on public key cryptography and + public key based digital signatures. To be practical, this form of + + + + +Vixie, et al. Standards Track [Page 1] + +RFC 2845 DNS TSIG May 2000 + + + security generally requires extensive local caching of keys and + tracing of authentication through multiple keys and signatures to a + pre-trusted locally configured key. + + 1.2. One difficulty with the [RFC2535] scheme is that common DNS + implementations include simple "stub" resolvers which do not have + caches. Such resolvers typically rely on a caching DNS server on + another host. It is impractical for these stub resolvers to perform + general [RFC2535] authentication and they would naturally depend on + their caching DNS server to perform such services for them. To do so + securely requires secure communication of queries and responses. + [RFC2535] provides public key transaction signatures to support this, + but such signatures are very expensive computationally to generate. + In general, these require the same complex public key logic that is + impractical for stubs. This document specifies use of a message + authentication code (MAC), specifically HMAC-MD5 (a keyed hash + function), to provide an efficient means of point-to-point + authentication and integrity checking for transactions. + + 1.3. A second area where use of straight [RFC2535] public key based + mechanisms may be impractical is authenticating dynamic update + [RFC2136] requests. [RFC2535] provides for request signatures but + with [RFC2535] they, like transaction signatures, require + computationally expensive public key cryptography and complex + authentication logic. Secure Domain Name System Dynamic Update + ([RFC2137]) describes how different keys are used in dynamically + updated zones. This document's secret key based MACs can be used to + authenticate DNS update requests as well as transaction responses, + providing a lightweight alternative to the protocol described by + [RFC2137]. + + 1.4. A further use of this mechanism is to protect zone transfers. + In this case the data covered would be the whole zone transfer + including any glue records sent. The protocol described by [RFC2535] + does not protect glue records and unsigned records unless SIG(0) + (transaction signature) is used. + + 1.5. The authentication mechanism proposed in this document uses + shared secret keys to establish a trust relationship between two + entities. Such keys must be protected in a fashion similar to + private keys, lest a third party masquerade as one of the intended + parties (forge MACs). There is an urgent need to provide simple and + efficient authentication between clients and local servers and this + proposal addresses that need. This proposal is unsuitable for + general server to server authentication for servers which speak with + many other servers, since key management would become unwieldy with + + + + + +Vixie, et al. Standards Track [Page 2] + +RFC 2845 DNS TSIG May 2000 + + + the number of shared keys going up quadratically. But it is suitable + for many resolvers on hosts that only talk to a few recursive + servers. + + 1.6. A server acting as an indirect caching resolver -- a "forwarder" + in common usage -- might use transaction-based authentication when + communicating with its small number of preconfigured "upstream" + servers. Other uses of DNS secret key authentication and possible + systems for automatic secret key distribution may be proposed in + separate future documents. + + 1.7. New Assigned Numbers + + RRTYPE = TSIG (250) + ERROR = 0..15 (a DNS RCODE) + ERROR = 16 (BADSIG) + ERROR = 17 (BADKEY) + ERROR = 18 (BADTIME) + + 1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and + "MAY" in this document are to be interpreted as described in [RFC + 2119]. + +2 - TSIG RR Format + + 2.1 TSIG RR Type + + To provide secret key authentication, we use a new RR type whose + mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and + MUST not be cached. TSIG RRs are used for authentication between DNS + entities that have established a shared secret key. TSIG RRs are + dynamically computed to cover a particular DNS transaction and are + not DNS RRs in the usual sense. + + 2.2 TSIG Calculation + + As the TSIG RRs are related to one DNS request/response, there is no + value in storing or retransmitting them, thus the TSIG RR is + discarded once it has been used to authenticate a DNS message. The + only message digest algorithm specified in this document is "HMAC- + MD5" (see [RFC1321], [RFC2104]). The "HMAC-MD5" algorithm is + mandatory to implement for interoperability. Other algorithms can be + specified at a later date. Names and definitions of new algorithms + MUST be registered with IANA. All multi-octet integers in the TSIG + record are sent in network byte order (see [RFC1035 2.3.2]). + + + + + + +Vixie, et al. Standards Track [Page 3] + +RFC 2845 DNS TSIG May 2000 + + + 2.3. Record Format + + NAME The name of the key used in domain name syntax. The name + should reflect the names of the hosts and uniquely identify + the key among a set of keys these two hosts may share at any + given time. If hosts A.site.example and B.example.net share a + key, possibilities for the key name include + <id>.A.site.example, <id>.B.example.net, and + <id>.A.site.example.B.example.net. It should be possible for + more than one key to be in simultaneous use among a set of + interacting hosts. The name only needs to be meaningful to + the communicating hosts but a meaningful mnemonic name as + above is strongly recommended. + + The name may be used as a local index to the key involved and + it is recommended that it be globally unique. Where a key is + just shared between two hosts, its name actually only need + only be meaningful to them but it is recommended that the key + name be mnemonic and incorporate the resolver and server host + names in that order. + + TYPE TSIG (250: Transaction SIGnature) + + CLASS ANY + + TTL 0 + + RdLen (variable) + + RDATA + + Field Name Data Type Notes + -------------------------------------------------------------- + Algorithm Name domain-name Name of the algorithm + in domain name syntax. + Time Signed u_int48_t seconds since 1-Jan-70 UTC. + Fudge u_int16_t seconds of error permitted + in Time Signed. + MAC Size u_int16_t number of octets in MAC. + MAC octet stream defined by Algorithm Name. + Original ID u_int16_t original message ID + Error u_int16_t expanded RCODE covering + TSIG processing. + Other Len u_int16_t length, in octets, of + Other Data. + Other Data octet stream empty unless Error == BADTIME + + + + + +Vixie, et al. Standards Track [Page 4] + +RFC 2845 DNS TSIG May 2000 + + + 2.4. Example + + NAME HOST.EXAMPLE. + + TYPE TSIG + + CLASS ANY + + TTL 0 + + RdLen as appropriate + + RDATA + + Field Name Contents + ------------------------------------- + Algorithm Name SAMPLE-ALG.EXAMPLE. + Time Signed 853804800 + Fudge 300 + MAC Size as appropriate + MAC as appropriate + Original ID as appropriate + Error 0 (NOERROR) + Other Len 0 + Other Data empty + +3 - Protocol Operation + + 3.1. Effects of adding TSIG to outgoing message + + Once the outgoing message has been constructed, the keyed message + digest operation can be performed. The resulting message digest will + then be stored in a TSIG which is appended to the additional data + section (the ARCOUNT is incremented to reflect this). If the TSIG + record cannot be added without causing the message to be truncated, + the server MUST alter the response so that a TSIG can be included. + This response consists of only the question and a TSIG record, and + has the TC bit set and RCODE 0 (NOERROR). The client SHOULD at this + point retry the request using TCP (per [RFC1035 4.2.2]). + + 3.2. TSIG processing on incoming messages + + If an incoming message contains a TSIG record, it MUST be the last + record in the additional section. Multiple TSIG records are not + allowed. If a TSIG record is present in any other position, the + packet is dropped and a response with RCODE 1 (FORMERR) MUST be + returned. Upon receipt of a message with a correctly placed TSIG RR, + the TSIG RR is copied to a safe location, removed from the DNS + + + +Vixie, et al. Standards Track [Page 5] + +RFC 2845 DNS TSIG May 2000 + + + Message, and decremented out of the DNS message header's ARCOUNT. At + this point the keyed message digest operation is performed. If the + algorithm name or key name is unknown to the recipient, or if the + message digests do not match, the whole DNS message MUST be + discarded. If the message is a query, a response with RCODE 9 + (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17 + (BADKEY) or TSIG ERROR 16 (BADSIG). If no key is available to sign + this message it MUST be sent unsigned (MAC size == 0 and empty MAC). + A message to the system operations log SHOULD be generated, to warn + the operations staff of a possible security incident in progress. + Care should be taken to ensure that logging of this type of event + does not open the system to a denial of service attack. + + 3.3. Time values used in TSIG calculations + + The data digested includes the two timer values in the TSIG header in + order to defend against replay attacks. If this were not done, an + attacker could replay old messages but update the "Time Signed" and + "Fudge" fields to make the message look new. This data is named + "TSIG Timers", and for the purpose of digest calculation they are + invoked in their "on the wire" format, in the following order: first + Time Signed, then Fudge. For example: + +Field Name Value Wire Format Meaning +---------------------------------------------------------------------- +Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997 +Fudge 300 01 2C 5 minutes + + 3.4. TSIG Variables and Coverage + + When generating or verifying the contents of a TSIG record, the + following data are digested, in network byte order or wire format, as + appropriate: + + 3.4.1. DNS Message + + A whole and complete DNS message in wire format, before the TSIG RR + has been added to the additional data section and before the DNS + Message Header's ARCOUNT field has been incremented to contain the + TSIG RR. If the message ID differs from the original message ID, the + original message ID is substituted for the message ID. This could + happen when forwarding a dynamic update request, for example. + + + + + + + + + +Vixie, et al. Standards Track [Page 6] + +RFC 2845 DNS TSIG May 2000 + + + 3.4.2. TSIG Variables + +Source Field Name Notes +----------------------------------------------------------------------- +TSIG RR NAME Key name, in canonical wire format +TSIG RR CLASS (Always ANY in the current specification) +TSIG RR TTL (Always 0 in the current specification) +TSIG RDATA Algorithm Name in canonical wire format +TSIG RDATA Time Signed in network byte order +TSIG RDATA Fudge in network byte order +TSIG RDATA Error in network byte order +TSIG RDATA Other Len in network byte order +TSIG RDATA Other Data exactly as transmitted + + The RR RDLEN and RDATA MAC Length are not included in the hash since + they are not guaranteed to be knowable before the MAC is generated. + + The Original ID field is not included in this section, as it has + already been substituted for the message ID in the DNS header and + hashed. + + For each label type, there must be a defined "Canonical wire format" + that specifies how to express a label in an unambiguous way. For + label type 00, this is defined in [RFC2535], for label type 01, this + is defined in [RFC2673]. The use of label types other than 00 and 01 + is not defined for this specification. + + 3.4.3. Request MAC + + When generating the MAC to be included in a response, the request MAC + must be included in the digest. The request's MAC is digested in + wire format, including the following fields: + + Field Type Description + --------------------------------------------------- + MAC Length u_int16_t in network byte order + MAC Data octet stream exactly as transmitted + + 3.5. Padding + + Digested components are fed into the hashing function as a continuous + octet stream with no interfield padding. + + + + + + + + + +Vixie, et al. Standards Track [Page 7] + +RFC 2845 DNS TSIG May 2000 + + +4 - Protocol Details + + 4.1. TSIG generation on requests + + Client performs the message digest operation and appends a TSIG + record to the additional data section and transmits the request to + the server. The client MUST store the message digest from the + request while awaiting an answer. The digest components for a + request are: + + DNS Message (request) + TSIG Variables (request) + + Note that some older name servers will not accept requests with a + nonempty additional data section. Clients SHOULD only attempt signed + transactions with servers who are known to support TSIG and share + some secret key with the client -- so, this is not a problem in + practice. + + 4.2. TSIG on Answers + + When a server has generated a response to a signed request, it signs + the response using the same algorithm and key. The server MUST not + generate a signed response to an unsigned request. The digest + components are: + + Request MAC + DNS Message (response) + TSIG Variables (response) + + 4.3. TSIG on TSIG Error returns + + When a server detects an error relating to the key or MAC, the server + SHOULD send back an unsigned error message (MAC size == 0 and empty + MAC). If an error is detected relating to the TSIG validity period, + the server SHOULD send back a signed error message. The digest + components are: + + Request MAC (if the request MAC validated) + DNS Message (response) + TSIG Variables (response) + + The reason that the request is not included in this digest in some + cases is to make it possible for the client to verify the error. If + the error is not a TSIG error the response MUST be generated as + specified in [4.2]. + + + + + +Vixie, et al. Standards Track [Page 8] + +RFC 2845 DNS TSIG May 2000 + + + 4.4. TSIG on TCP connection + + A DNS TCP session can include multiple DNS envelopes. This is, for + example, commonly used by zone transfer. Using TSIG on such a + connection can protect the connection from hijacking and provide data + integrity. The TSIG MUST be included on the first and last DNS + envelopes. It can be optionally placed on any intermediary + envelopes. It is expensive to include it on every envelopes, but it + MUST be placed on at least every 100'th envelope. The first envelope + is processed as a standard answer, and subsequent messages have the + following digest components: + + Prior Digest (running) + DNS Messages (any unsigned messages since the last TSIG) + TSIG Timers (current message) + + This allows the client to rapidly detect when the session has been + altered; at which point it can close the connection and retry. If a + client TSIG verification fails, the client MUST close the connection. + If the client does not receive TSIG records frequently enough (as + specified above) it SHOULD assume the connection has been hijacked + and it SHOULD close the connection. The client SHOULD treat this the + same way as they would any other interrupted transfer (although the + exact behavior is not specified). + + 4.5. Server TSIG checks + + Upon receipt of a message, server will check if there is a TSIG RR. + If one exists, the server is REQUIRED to return a TSIG RR in the + response. The server MUST perform the following checks in the + following order, check KEY, check TIME values, check MAC. + + 4.5.1. KEY check and error handling + + If a non-forwarding server does not recognize the key used by the + client, the server MUST generate an error response with RCODE 9 + (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned + as specified in [4.3]. The server SHOULD log the error. + + 4.5.2. TIME check and error handling + + If the server time is outside the time interval specified by the + request (which is: Time Signed, plus/minus Fudge), the server MUST + generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 + (BADTIME). The server SHOULD also cache the most recent time signed + value in a message generated by a key, and SHOULD return BADTIME if a + message received later has an earlier time signed value. A response + indicating a BADTIME error MUST be signed by the same key as the + + + +Vixie, et al. Standards Track [Page 9] + +RFC 2845 DNS TSIG May 2000 + + + request. It MUST include the client's current time in the time + signed field, the server's current time (a u_int48_t) in the other + data field, and 6 in the other data length field. This is done so + that the client can verify a message with a BADTIME error without the + verification failing due to another BADTIME error. The data signed + is specified in [4.3]. The server SHOULD log the error. + + 4.5.3. MAC check and error handling + + If a TSIG fails to verify, the server MUST generate an error response + as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16 + (BADSIG). This response MUST be unsigned as specified in [4.3]. The + server SHOULD log the error. + + 4.6. Client processing of answer + + When a client receives a response from a server and expects to see a + TSIG, it first checks if the TSIG RR is present in the response. + Otherwise, the response is treated as having a format error and + discarded. The client then extracts the TSIG, adjusts the ARCOUNT, + and calculates the keyed digest in the same way as the server. If + the TSIG does not validate, that response MUST be discarded, unless + the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to + verify the response as if it were a TSIG Error response, as specified + in [4.3]. A message containing an unsigned TSIG record or a TSIG + record which fails verification SHOULD not be considered an + acceptable response; the client SHOULD log an error and continue to + wait for a signed response until the request times out. + + 4.6.1. Key error handling + + If an RCODE on a response is 9 (NOTAUTH), and the response TSIG + validates, and the TSIG key is different from the key used on the + request, then this is a KEY error. The client MAY retry the request + using the key specified by the server. This should never occur, as a + server MUST NOT sign a response with a different key than signed the + request. + + 4.6.2. Time error handling + + If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18 + (BADTIME), or the current time does not fall in the range specified + in the TSIG record, then this is a TIME error. This is an indication + that the client and server clocks are not synchronized. In this case + the client SHOULD log the event. DNS resolvers MUST NOT adjust any + clocks in the client based on BADTIME errors, but the server's time + in the other data field SHOULD be logged. + + + + +Vixie, et al. Standards Track [Page 10] + +RFC 2845 DNS TSIG May 2000 + + + 4.6.3. MAC error handling + + If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), + this is a MAC error, and client MAY retry the request with a new + request ID but it would be better to try a different shared key if + one is available. Client SHOULD keep track of how many MAC errors + are associated with each key. Clients SHOULD log this event. + + 4.7. Special considerations for forwarding servers + + A server acting as a forwarding server of a DNS message SHOULD check + for the existence of a TSIG record. If the name on the TSIG is not + of a secret that the server shares with the originator the server + MUST forward the message unchanged including the TSIG. If the name + of the TSIG is of a key this server shares with the originator, it + MUST process the TSIG. If the TSIG passes all checks, the forwarding + server MUST, if possible, include a TSIG of his own, to the + destination or the next forwarder. If no transaction security is + available to the destination and the response has the AD flag (see + [RFC2535]), the forwarder MUST unset the AD flag before adding the + TSIG to the answer. + +5 - Shared Secrets + + 5.1. Secret keys are very sensitive information and all available + steps should be taken to protect them on every host on which they are + stored. Generally such hosts need to be physically protected. If + they are multi-user machines, great care should be taken that + unprivileged users have no access to keying material. Resolvers + often run unprivileged, which means all users of a host would be able + to see whatever configuration data is used by the resolver. + + 5.2. A name server usually runs privileged, which means its + configuration data need not be visible to all users of the host. For + this reason, a host that implements transaction-based authentication + should probably be configured with a "stub resolver" and a local + caching and forwarding name server. This presents a special problem + for [RFC2136] which otherwise depends on clients to communicate only + with a zone's authoritative name servers. + + 5.3. Use of strong random shared secrets is essential to the security + of TSIG. See [RFC1750] for a discussion of this issue. The secret + should be at least as long as the keyed message digest, i.e. 16 bytes + for HMAC-MD5 or 20 bytes for HMAC-SHA1. + + + + + + + +Vixie, et al. Standards Track [Page 11] + +RFC 2845 DNS TSIG May 2000 + + +6 - Security Considerations + + 6.1. The approach specified here is computationally much less + expensive than the signatures specified in [RFC2535]. As long as the + shared secret key is not compromised, strong authentication is + provided for the last hop from a local name server to the user + resolver. + + 6.2. Secret keys should be changed periodically. If the client host + has been compromised, the server should suspend the use of all + secrets known to that client. If possible, secrets should be stored + in encrypted form. Secrets should never be transmitted in the clear + over any network. This document does not address the issue on how to + distribute secrets. Secrets should never be shared by more than two + entities. + + 6.3. This mechanism does not authenticate source data, only its + transmission between two parties who share some secret. The original + source data can come from a compromised zone master or can be + corrupted during transit from an authentic zone master to some + "caching forwarder." However, if the server is faithfully performing + the full [RFC2535] security checks, then only security checked data + will be available to the client. + + 6.4. A fudge value that is too large may leave the server open to + replay attacks. A fudge value that is too small may cause failures + if machines are not time synchronized or there are unexpected network + delays. The recommended value in most situation is 300 seconds. + +7 - IANA Considerations + + IANA is expected to create and maintain a registry of algorithm names + to be used as "Algorithm Names" as defined in Section 2.3. The + initial value should be "HMAC-MD5.SIG-ALG.REG.INT". Algorithm names + are text strings encoded using the syntax of a domain name. There is + no structure required other than names for different algorithms must + be unique when compared as DNS names, i.e., comparison is case + insensitive. Note that the initial value mentioned above is not a + domain name, and therefore need not be a registered name within the + DNS. New algorithms are assigned using the IETF Consensus policy + defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT + looks like a FQDN for historical reasons; future algorithm names are + expected to be simple (i.e., single-component) names. + + + + + + + + +Vixie, et al. Standards Track [Page 12] + +RFC 2845 DNS TSIG May 2000 + + + IANA is expected to create and maintain a registry of "TSIG Error + values" to be used for "Error" values as defined in section 2.3. + Initial values should be those defined in section 1.7. New TSIG + error codes for the TSIG error field are assigned using the IETF + Consensus policy defined in RFC 2434. + +8 - References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1034, November 1987. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1995. + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5: + Keyed-MD5 for Message Authentication", RFC 2104, February + 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic + Updates in the Domain Name System", RFC 2136, April 1997. + + [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic + Update", RFC 2137, April 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + + + + + + + + + + + + +Vixie, et al. Standards Track [Page 13] + +RFC 2845 DNS TSIG May 2000 + + +9 - Authors' Addresses + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063 + + Phone: +1 650 779 7001 + EMail: vixie@isc.org + + + Olafur Gudmundsson + NAI Labs + 3060 Washington Road, Route 97 + Glenwood, MD 21738 + + Phone: +1 443 259 2389 + EMail: ogud@tislabs.com + + + Donald E. Eastlake 3rd + Motorola + 140 Forest Avenue + Hudson, MA 01749 USA + + Phone: +1 508 261 5434 + EMail: dee3@torque.pothole.com + + + Brian Wellington + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94063 + + Phone: +1 650 779 6022 + EMail: Brian.Wellington@nominum.com + + + + + + + + + + + + + + + +Vixie, et al. Standards Track [Page 14] + +RFC 2845 DNS TSIG May 2000 + + +10 Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Vixie, et al. Standards Track [Page 15] + diff --git a/Documentation/en/rfc/rfc2931.txt b/Documentation/en/rfc/rfc2931.txt new file mode 100644 index 00000000..84cc97e2 --- /dev/null +++ b/Documentation/en/rfc/rfc2931.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 2931 Motorola +Updates: 2535 September 2000 +Category: Standards Track + + + DNS Request and Transaction Signatures ( SIG(0)s ) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + Extensions to the Domain Name System (DNS) are described in [RFC + 2535] that can provide data origin and transaction integrity and + authentication to security aware resolvers and applications through + the use of cryptographic digital signatures. + + Implementation experience has indicated the need for minor but non- + interoperable changes in Request and Transaction signature resource + records ( SIG(0)s ). These changes are documented herein. + +Acknowledgments + + The contributions and suggestions of the following persons (in + alphabetic order) to this memo are gratefully acknowledged: + + Olafur Gudmundsson + + Ed Lewis + + Erik Nordmark + + Brian Wellington + + + + + + + + +Eastlake Standards Track [Page 1] + +RFC 2931 DNS SIG(0) September 2000 + + +Table of Contents + + 1. Introduction................................................. 2 + 2. SIG(0) Design Rationale...................................... 3 + 2.1 Transaction Authentication.................................. 3 + 2.2 Request Authentication...................................... 3 + 2.3 Keying...................................................... 3 + 2.4 Differences Between TSIG and SIG(0)......................... 4 + 3. The SIG(0) Resource Record................................... 4 + 3.1 Calculating Request and Transaction SIGs.................... 5 + 3.2 Processing Responses and SIG(0) RRs......................... 6 + 3.3 SIG(0) Lifetime and Expiration.............................. 7 + 4. Security Considerations...................................... 7 + 5. IANA Considerations.......................................... 7 + References...................................................... 7 + Author's Address................................................ 8 + Appendix: SIG(0) Changes from RFC 2535.......................... 9 + Full Copyright Statement........................................ 10 + +1. Introduction + + This document makes minor but non-interoperable changes to part of + [RFC 2535], familiarity with which is assumed, and includes + additional explanatory text. These changes concern SIG Resource + Records (RRs) that are used to digitally sign DNS requests and + transactions / responses. Such a resource record, because it has a + type covered field of zero, is frequently called a SIG(0). The + changes are based on implementation and attempted implementation + experience with TSIG [RFC 2845] and the [RFC 2535] specification for + SIG(0). + + Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2 + and 4.3. No changes are made herein related to the KEY or NXT RRs or + to the processing involved with data origin and denial authentication + for DNS data. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + + + + + + + + + + + + +Eastlake Standards Track [Page 2] + +RFC 2931 DNS SIG(0) September 2000 + + +2. SIG(0) Design Rationale + + SIG(0) provides protection for DNS transactions and requests that is + not provided by the regular SIG, KEY, and NXT RRs specified in [RFC + 2535]. The authenticated data origin services of secure DNS either + provide protected data resource records (RRs) or authenticatably deny + their nonexistence. These services provide no protection for glue + records, DNS requests, no protection for message headers on requests + or responses, and no protection of the overall integrity of a + response. + +2.1 Transaction Authentication + + Transaction authentication means that a requester can be sure it is + at least getting the messages from the server it queried and that the + received messages are in response to the query it sent. This is + accomplished by optionally adding either a TSIG RR [RFC 2845] or, as + described herein, a SIG(0) resource record at the end of the response + which digitally signs the concatenation of the server's response and + the corresponding resolver query. + +2.2 Request Authentication + + Requests can also be authenticated by including a TSIG or, as + described herein, a special SIG(0) RR at the end of the request. + Authenticating requests serves no function in DNS servers that + predate the specification of dynamic update. Requests with a non- + empty additional information section produce error returns or may + even be ignored by a few such older DNS servers. However, this syntax + for signing requests is defined for authenticating dynamic update + requests [RFC 2136], TKEY requests [RFC 2930], or future requests + requiring authentication. + +2.3 Keying + + The private keys used in transaction security belong to the host + composing the DNS response message, not to the zone involved. + Request authentication may also involve the private key of the host + or other entity composing the request or of a zone to be affected by + the request or other private keys depending on the request authority + it is sought to establish. The corresponding public key(s) are + normally stored in and retrieved from the DNS for verification as KEY + RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY). + + Because requests and replies are highly variable, message + authentication SIGs can not be pre-calculated. Thus it will be + necessary to keep the private key on-line, for example in software or + in a directly connected piece of hardware. + + + +Eastlake Standards Track [Page 3] + +RFC 2931 DNS SIG(0) September 2000 + + +2.4 Differences Between TSIG and SIG(0) + + There are significant differences between TSIG and SIG(0). + + Because TSIG involves secret keys installed at both the requester and + server the presence of such a key implies that the other party + understands TSIG and very likely has the same key installed. + Furthermore, TSIG uses keyed hash authentication codes which are + relatively inexpensive to compute. Thus it is common to authenticate + requests with TSIG and responses are authenticated with TSIG if the + corresponding request is authenticated. + + SIG(0) on the other hand, uses public key authentication, where the + public keys are stored in DNS as KEY RRs and a private key is stored + at the signer. Existence of such a KEY RR does not necessarily imply + implementation of SIG(0). In addition, SIG(0) involves relatively + expensive public key cryptographic operations that should be + minimized and the verification of a SIG(0) involves obtaining and + verifying the corresponding KEY which can be an expensive and lengthy + operation. Indeed, a policy of using SIG(0) on all requests and + verifying it before responding would, for some configurations, lead + to a deadly embrace with the attempt to obtain and verify the KEY + needed to authenticate the request SIG(0) resulting in additional + requests accompanied by a SIG(0) leading to further requests + accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not + required on requests halves the number of public key operations + required by the transaction. + + For these reasons, SIG(0)s SHOULD only be used on requests when + necessary to authenticate that the requester has some required + privilege or identity. SIG(0)s on replies are defined in such a way + as to not require a SIG(0) on the corresponding request and still + provide transaction protection. For other replies, whether they are + authenticated by the server or required to be authenticated by the + requester SHOULD be a local configuration option. + +3. The SIG(0) Resource Record + + The structure of and type number of SIG resource records (RRs) is + given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and + the parts of Sections 4.2 and 4.3 related to SIG(0) should be + considered replaced by the material below. Any conflict between [RFC + 2535] and this document concerning SIG(0) RRs should be resolved in + favor of this document. + + For all transaction SIG(0)s, the signer field MUST be a name of the + originating host and there MUST be a KEY RR at that name with the + public key corresponding to the private key used to calculate the + + + +Eastlake Standards Track [Page 4] + +RFC 2931 DNS SIG(0) September 2000 + + + signature. (The host domain name used may be the inverse IP address + mapping name for an IP address of the host if the relevant KEY is + stored there.) + + For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are + meaningless. The TTL fields SHOULD be zero and the CLASS field + SHOULD be ANY. To conserve space, the owner name SHOULD be root (a + single zero octet). When SIG(0) authentication on a response is + desired, that SIG RR MUST be considered the highest priority of any + additional information for inclusion in the response. If the SIG(0) + RR cannot be added without causing the message to be truncated, the + server MUST alter the response so that a SIG(0) can be included. + This response consists of only the question and a SIG(0) record, and + has the TC bit set and RCODE 0 (NOERROR). The client should at this + point retry the request using TCP. + +3.1 Calculating Request and Transaction SIGs + + A DNS request may be optionally signed by including one SIG(0)s at + the end of the query additional information section. Such a SIG is + identified by having a "type covered" field of zero. It signs the + preceding DNS request message including DNS header but not including + the UDP/IP header and before the request RR counts have been adjusted + for the inclusions of the request SIG(0). + + It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of + (1) the SIG's RDATA section entirely omitting (not just zeroing) the + signature subfield itself, (2) the DNS query messages, including DNS + header, but not the UDP/IP header and before the reply RR counts have + been adjusted for the inclusion of the SIG(0). That is + + data = RDATA | request - SIG(0) + + where "|" is concatenation and RDATA is the RDATA of the SIG(0) being + calculated less the signature itself. + + Similarly, a SIG(0) can be used to secure a response and the request + that produced it. Such transaction signatures are calculated by + using a "data" of (1) the SIG's RDATA section omitting the signature + itself, (2) the entire DNS query message that produced this response, + including the query's DNS header but not its UDP/IP header, and (3) + the entire DNS response message, including DNS header but not the + UDP/IP header and before the response RR counts have been adjusted + for the inclusion of the SIG(0). + + + + + + + +Eastlake Standards Track [Page 5] + +RFC 2931 DNS SIG(0) September 2000 + + + That is + + data = RDATA | full query | response - SIG(0) + + where "|" is concatenation and RDATA is the RDATA of the SIG(0) being + calculated less the signature itself. + + Verification of a response SIG(0) (which is signed by the server host + key, not the zone key) by the requesting resolver shows that the + query and response were not tampered with in transit, that the + response corresponds to the intended query, and that the response + comes from the queried server. + + In the case of a DNS message via TCP, a SIG(0) on the first data + packet is calculated with "data" as above and for each subsequent + packet, it is calculated as follows: + + data = RDATA | DNS payload - SIG(0) | previous packet + + where "|" is concatenations, RDATA is as above, and previous packet + is the previous DNS payload including DNS header and the SIG(0) but + not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an + alternative, TSIG may be used after, if necessary, setting up a key + with TKEY [RFC 2930]. + + Except where needed to authenticate an update, TKEY, or similar + privileged request, servers are not required to check a request + SIG(0). + + Note: requests and responses can either have a single TSIG or one + SIG(0) but not both a TSIG and a SIG(0). + +3.2 Processing Responses and SIG(0) RRs + + If a SIG RR is at the end of the additional information section of a + response and has a type covered of zero, it is a transaction + signature covering the response and the query that produced the + response. For TKEY responses, it MUST be checked and the message + rejected if the checks fail unless otherwise specified for the TKEY + mode in use. For all other responses, it MAY be checked and the + message rejected if the checks fail. + + If a response's SIG(0) check succeed, such a transaction + authentication SIG does NOT directly authenticate the validity any + data-RRs in the message. However, it authenticates that they were + sent by the queried server and have not been diddled. (Only a proper + SIG(0) RR signed by the zone or a key tracing its authority to the + zone or to static resolver configuration can directly authenticate + + + +Eastlake Standards Track [Page 6] + +RFC 2931 DNS SIG(0) September 2000 + + + data-RRs, depending on resolver policy.) If a resolver or server does + not implement transaction and/or request SIGs, it MUST ignore them + without error where they are optional and treat them as failing where + they are required. + +3.3 SIG(0) Lifetime and Expiration + + The inception and expiration times in SIG(0)s are for the purpose of + resisting replay attacks. They should be set to form a time bracket + such that messages outside that bracket can be ignored. In IP + networks, this time bracket should not normally extend further than 5 + minutes into the past and 5 minutes into the future. + +4. Security Considerations + + No additional considerations beyond those in [RFC 2535]. + + The inclusion of the SIG(0) inception and expiration time under the + signature improves resistance to replay attacks. + +5. IANA Considerations + + No new parameters are created or parameter values assigned by this + document. + +References + + [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + September 1996. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Signatures for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC + 2930, September 2000. + + + + + +Eastlake Standards Track [Page 7] + +RFC 2931 DNS SIG(0) September 2000 + + +Author's Address + + Donald E. Eastlake 3rd + Motorola + 140 Forest Avenue + Hudson, MA 01749 USA + + Phone: +1-978-562-2827(h) + +1-508-261-5434(w) + Fax: +1 978-567-7941(h) + +1-508-261-4447(w) + EMail: Donald.Eastlake@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 8] + +RFC 2931 DNS SIG(0) September 2000 + + +Appendix: SIG(0) Changes from RFC 2535 + + Add explanatory text concerning the differences between TSIG and + SIG(0). + + Change the data over which SIG(0) is calculated to include the SIG(0) + RDATA other than the signature itself so as to secure the signature + inception and expiration times and resist replay attacks. Specify + SIG(0) for TCP. + + Add discussion of appropriate inception and expiration times for + SIG(0). + + Add wording to indicate that either a TSIG or one or more SIG(0)s may + be present but not both. + + Reword some areas for clarity. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 9] + +RFC 2931 DNS SIG(0) September 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 10] + diff --git a/Documentation/en/rfc/rfc3007.txt b/Documentation/en/rfc/rfc3007.txt new file mode 100644 index 00000000..16974753 --- /dev/null +++ b/Documentation/en/rfc/rfc3007.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group B. Wellington +Request for Comments: 3007 Nominum +Updates: 2535, 2136 November 2000 +Obsoletes: 2137 +Category: Standards Track + + + Secure Domain Name System (DNS) Dynamic Update + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document proposes a method for performing secure Domain Name + System (DNS) dynamic updates. The method described here is intended + to be flexible and useful while requiring as few changes to the + protocol as possible. The authentication of the dynamic update + message is separate from later DNSSEC validation of the data. Secure + communication based on authenticated requests and transactions is + used to provide authorization. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1 - Introduction + + This document defines a means to secure dynamic updates of the Domain + Name System (DNS), allowing only authorized sources to make changes + to a zone's contents. The existing unsecured dynamic update + operations form the basis for this work. + + Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update + [RFC2136] is helpful and is assumed by this document. In addition, + knowledge of DNS security extensions [RFC2535], SIG(0) transaction + security [RFC2535, RFC2931], and TSIG transaction security [RFC2845] + is recommended. + + + + +Wellington Standards Track [Page 1] + +RFC 3007 Secure Dynamic Update November 2000 + + + This document updates portions of RFC 2535, in particular section + 3.1.2, and RFC 2136. This document obsoletes RFC 2137, an alternate + proposal for secure dynamic update, due to implementation experience. + +1.1 - Overview of DNS Dynamic Update + + DNS dynamic update defines a new DNS opcode and a new interpretation + of the DNS message if that opcode is used. An update can specify + insertions or deletions of data, along with prerequisites necessary + for the updates to occur. All tests and changes for a DNS update + request are restricted to a single zone, and are performed at the + primary server for the zone. The primary server for a dynamic zone + must increment the zone SOA serial number when an update occurs or + before the next retrieval of the SOA. + +1.2 - Overview of DNS Transaction Security + + Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0) + [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS + requests and responses sent between them. A TSIG MAC (message + authentication code) is derived from a shared secret, and a SIG(0) is + generated from a private key whose public counterpart is stored in + DNS. In both cases, a record containing the message signature/MAC is + included as the final resource record in a DNS message. Keyed + hashes, used in TSIG, are inexpensive to calculate and verify. + Public key encryption, as used in SIG(0), is more scalable as the + public keys are stored in DNS. + +1.3 - Comparison of data authentication and message authentication + + Message based authentication, using TSIG or SIG(0), provides + protection for the entire message with a single signing and single + verification which, in the case of TSIG, is a relatively inexpensive + MAC creation and check. For update requests, this signature can + establish, based on policy or key negotiation, the authority to make + the request. + + DNSSEC SIG records can be used to protect the integrity of individual + RRs or RRsets in a DNS message with the authority of the zone owner. + However, this cannot sufficiently protect the dynamic update request. + + Using SIG records to secure RRsets in an update request is + incompatible with the design of update, as described below, and would + in any case require multiple expensive public key signatures and + verifications. + + + + + + +Wellington Standards Track [Page 2] + +RFC 3007 Secure Dynamic Update November 2000 + + + SIG records do not cover the message header, which includes record + counts. Therefore, it is possible to maliciously insert or remove + RRsets in an update request without causing a verification failure. + + If SIG records were used to protect the prerequisite section, it + would be impossible to determine whether the SIGs themselves were a + prerequisite or simply used for validation. + + In the update section of an update request, signing requests to add + an RRset is straightforward, and this signature could be permanently + used to protect the data, as specified in [RFC2535]. However, if an + RRset is deleted, there is no data for a SIG to cover. + +1.4 - Data and message signatures + + As specified in [RFC3008], the DNSSEC validation process performed by + a resolver MUST NOT process any non-zone keys unless local policy + dictates otherwise. When performing secure dynamic update, all zone + data modified in a signed zone MUST be signed by a relevant zone key. + This completely disassociates authentication of an update request + from authentication of the data itself. + + The primary usefulness of host and user keys, with respect to DNSSEC, + is to authenticate messages, including dynamic updates. Thus, host + and user keys MAY be used to generate SIG(0) records to authenticate + updates and MAY be used in the TKEY [RFC2930] process to generate + TSIG shared secrets. In both cases, no SIG records generated by + non-zone keys will be used in a DNSSEC validation process unless + local policy dictates. + + Authentication of data, once it is present in DNS, only involves + DNSSEC zone keys and signatures generated by them. + +1.5 - Signatory strength + + [RFC2535, section 3.1.2] defines the signatory field of a key as the + final 4 bits of the flags field, but does not define its value. This + proposal leaves this field undefined. Updating [RFC2535], this field + SHOULD be set to 0 in KEY records, and MUST be ignored. + +2 - Authentication + + TSIG or SIG(0) records MUST be included in all secure dynamic update + messages. This allows the server to verifiably determine the + originator of a message. If the message contains authentication in + the form of a SIG(0), the identity of the sender (that is, the + principal) is the owner of the KEY RR that generated the SIG(0). If + the message contains a TSIG generated by a statically configured + + + +Wellington Standards Track [Page 3] + +RFC 3007 Secure Dynamic Update November 2000 + + + shared secret, the principal is the same as or derived from the + shared secret name. If the message contains a TSIG generated by a + dynamically configured shared secret, the principal is the same as + the one that authenticated the TKEY process; if the TKEY process was + unauthenticated, no information is known about the principal, and the + associated TSIG shared secret MUST NOT be used for secure dynamic + update. + + SIG(0) signatures SHOULD NOT be generated by zone keys, since + transactions are initiated by a host or user, not a zone. + + DNSSEC SIG records (other than SIG(0)) MAY be included in an update + message, but MUST NOT be used to authenticate the update request. + + If an update fails because it is signed with an unauthorized key, the + server MUST indicate failure by returning a message with RCODE + REFUSED. Other TSIG, SIG(0), or dynamic update errors are returned + as specified in the appropriate protocol description. + +3 - Policy + + All policy is configured by the zone administrator and enforced by + the zone's primary name server. Policy dictates the authorized + actions that an authenticated principal can take. Policy checks are + based on the principal and the desired action, where the principal is + derived from the message signing key and applied to dynamic update + messages signed with that key. + + The server's policy defines criteria which determine if the key used + to sign the update is permitted to perform the requested updates. By + default, a principal MUST NOT be permitted to make any changes to + zone data; any permissions MUST be enabled though configuration. + + The policy is fully implemented in the primary zone server's + configuration for several reasons. This removes limitations imposed + by encoding policy into a fixed number of bits (such as the KEY RR's + signatory field). Policy is only relevant in the server applying it, + so there is no reason to expose it. Finally, a change in policy or a + new type of policy should not affect the DNS protocol or data format, + and should not cause interoperability failures. + +3.1 - Standard policies + + Implementations SHOULD allow access control policies to use the + principal as an authorization token, and MAY also allow policies to + grant permission to a signed message regardless of principal. + + + + + +Wellington Standards Track [Page 4] + +RFC 3007 Secure Dynamic Update November 2000 + + + A common practice would be to restrict the permissions of a principal + by domain name. That is, a principal could be permitted to add, + delete, or modify entries corresponding to one or more domain names. + Implementations SHOULD allow per-name access control, and SHOULD + provide a concise representation of the principal's own name, its + subdomains, and all names in the zone. + + Additionally, a server SHOULD allow restricting updates by RR type, + so that a principal could add, delete, or modify specific record + types at certain names. Implementations SHOULD allow per-type access + control, and SHOULD provide concise representations of all types and + all "user" types, where a user type is defined as one that does not + affect the operation of DNS itself. + +3.1.1 - User types + + User types include all data types except SOA, NS, SIG, and NXT. SOA + and NS records SHOULD NOT be modified by normal users, since these + types create or modify delegation points. The addition of SIG + records can lead to attacks resulting in additional workload for + resolvers, and the deletion of SIG records could lead to extra work + for the server if the zone SIG was deleted. Note that these records + are not forbidden, but not recommended for normal users. + + NXT records MUST NOT be created, modified, or deleted by dynamic + update, as their update may cause instability in the protocol. This + is an update to RFC 2136. + + Issues concerning updates of KEY records are discussed in the + Security Considerations section. + +3.2 - Additional policies + + Users are free to implement any policies. Policies may be as + specific or general as desired, and as complex as desired. They may + depend on the principal or any other characteristics of the signed + message. + +4 - Interaction with DNSSEC + + Although this protocol does not change the way updates to secure + zones are processed, there are a number of issues that should be + clarified. + + + + + + + + +Wellington Standards Track [Page 5] + +RFC 3007 Secure Dynamic Update November 2000 + + +4.1 - Adding SIGs + + An authorized update request MAY include SIG records with each RRset. + Since SIG records (except SIG(0) records) MUST NOT be used for + authentication of the update message, they are not required. + + If a principal is authorized to update SIG records and there are SIG + records in the update, the SIG records are added without + verification. The server MAY examine SIG records and drop SIGs with + a temporal validity period in the past. + +4.2 - Deleting SIGs + + If a principal is authorized to update SIG records and the update + specifies the deletion of SIG records, the server MAY choose to + override the authority and refuse the update. For example, the + server may allow all SIG records not generated by a zone key to be + deleted. + +4.3 - Non-explicit updates to SIGs + + If the updated zone is secured, the RRset affected by an update + operation MUST, at the completion of the update, be signed in + accordance with the zone's signing policy. This will usually require + one or more SIG records to be generated by one or more zone keys + whose private components MUST be online [RFC3008]. + + When the contents of an RRset are updated, the server MAY delete all + associated SIG records, since they will no longer be valid. + +4.4 - Effects on the zone + + If any changes are made, the server MUST, if necessary, generate a + new SOA record and new NXT records, and sign these with the + appropriate zone keys. Changes to NXT records by secure dynamic + update are explicitly forbidden. SOA updates are allowed, since the + maintenance of SOA parameters is outside of the scope of the DNS + protocol. + +5 - Security Considerations + + This document requires that a zone key and possibly other + cryptographic secret material be held in an on-line, network- + connected host, most likely a name server. This material is at the + mercy of host security to remain a secret. Exposing this secret puts + DNS data at risk of masquerade attacks. The data at risk is that in + both zones served by the machine and delegated from this machine. + + + + +Wellington Standards Track [Page 6] + +RFC 3007 Secure Dynamic Update November 2000 + + + Allowing updates of KEY records may lead to undesirable results, + since a principal may be allowed to insert a public key without + holding the private key, and possibly masquerade as the key owner. + +6 - Acknowledgements + + The author would like to thank the following people for review and + informative comments (in alphabetical order): + + Harald Alvestrand + Donald Eastlake + Olafur Gudmundsson + Andreas Gustafsson + Bob Halley + Stuart Kwan + Ed Lewis + +7 - References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System", RFC 2136, + April 1997. + + [RFC2137] Eastlake, D., "Secure Domain Name System Dynamic Update", + RFC 2137, April 1997. + + [RFC2535] Eastlake, G., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Signatures for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + + + +Wellington Standards Track [Page 7] + +RFC 3007 Secure Dynamic Update November 2000 + + +8 - Author's Address + + Brian Wellington + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94063 + + Phone: +1 650 381 6022 + EMail: Brian.Wellington@nominum.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wellington Standards Track [Page 8] + +RFC 3007 Secure Dynamic Update November 2000 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Wellington Standards Track [Page 9] + diff --git a/Documentation/en/rfc/rfc3008.txt b/Documentation/en/rfc/rfc3008.txt new file mode 100644 index 00000000..08a4a8fa --- /dev/null +++ b/Documentation/en/rfc/rfc3008.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group B. Wellington +Request for Comments: 3008 Nominum +Updates: 2535 November 2000 +Category: Standards Track + + + Domain Name System Security (DNSSEC) Signing Authority + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document proposes a revised model of Domain Name System Security + (DNSSEC) Signing Authority. The revised model is designed to clarify + earlier documents and add additional restrictions to simplify the + secure resolution process. Specifically, this affects the + authorization of keys to sign sets of records. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1 - Introduction + + This document defines additional restrictions on DNSSEC signatures + (SIG) records relating to their authority to sign associated data. + The intent is to establish a standard policy followed by a secure + resolver; this policy can be augmented by local rules. This builds + upon [RFC2535], updating section 2.3.6 of that document. + + The most significant change is that in a secure zone, zone data is + required to be signed by the zone key. + + Familiarity with the DNS system [RFC1034, RFC1035] and the DNS + security extensions [RFC2535] is assumed. + + + + + + +Wellington Standards Track [Page 1] + +RFC 3008 DNSSEC Signing Authority November 2000 + + +2 - The SIG Record + + A SIG record is normally associated with an RRset, and "covers" (that + is, demonstrates the authenticity and integrity of) the RRset. This + is referred to as a "data SIG". Note that there can be multiple SIG + records covering an RRset, and the same validation process should be + repeated for each of them. Some data SIGs are considered "material", + that is, relevant to a DNSSEC capable resolver, and some are + "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC + validation. Immaterial SIGs may have application defined roles. SIG + records may exist which are not bound to any RRset; these are also + considered immaterial. The validation process determines which SIGs + are material; once a SIG is shown to be immaterial, no other + validation is necessary. + + SIGs may also be used for transaction security. In this case, a SIG + record with a type covered field of 0 is attached to a message, and + is used to protect message integrity. This is referred to as a + SIG(0) [RFC2535, RFC2931]. + + The following sections define requirements for all of the fields of a + SIG record. These requirements MUST be met in order for a DNSSEC + capable resolver to process this signature. If any of these + requirements are not met, the SIG cannot be further processed. + Additionally, once a KEY has been identified as having generated this + SIG, there are requirements that it MUST meet. + +2.1 - Type Covered + + For a data SIG, the type covered MUST be the same as the type of data + in the associated RRset. For a SIG(0), the type covered MUST be 0. + +2.2 - Algorithm Number + + The algorithm specified in a SIG MUST be recognized by the client, + and it MUST be an algorithm that has a defined SIG rdata format. + +2.3 - Labels + + The labels count MUST be less than or equal to the number of labels + in the SIG owner name, as specified in [RFC2535, section 4.1.3]. + +2.4 - Original TTL + + The original TTL MUST be greater than or equal to the TTL of the SIG + record itself, since the TTL cannot be increased by intermediate + servers. This field can be ignored for SIG(0) records. + + + + +Wellington Standards Track [Page 2] + +RFC 3008 DNSSEC Signing Authority November 2000 + + +2.5 - Signature Expiration and Inception + + The current time at the time of validation MUST lie within the + validity period bounded by the inception and expiration times. + +2.6 - Key Tag + + There are no restrictions on the Key Tag field, although it is + possible that future algorithms will impose constraints. + +2.7 - Signer's Name + + The signer's name field of a data SIG MUST contain the name of the + zone to which the data and signature belong. The combination of + signer's name, key tag, and algorithm MUST identify a zone key if the + SIG is to be considered material. The only exception that the + signer's name field in a SIG KEY at a zone apex SHOULD contain the + parent zone's name, unless the KEY set is self-signed. This document + defines a standard policy for DNSSEC validation; local policy may + override the standard policy. + + There are no restrictions on the signer field of a SIG(0) record. + The combination of signer's name, key tag, and algorithm MUST + identify a key if this SIG(0) is to be processed. + +2.8 - Signature + + There are no restrictions on the signature field. The signature will + be verified at some point, but does not need to be examined prior to + verification unless a future algorithm imposes constraints. + +3 - The Signing KEY Record + + Once a signature has been examined and its fields validated (but + before the signature has been verified), the resolver attempts to + locate a KEY that matches the signer name, key tag, and algorithm + fields in the SIG. If one is not found, the SIG cannot be verified + and is considered immaterial. If KEYs are found, several fields of + the KEY record MUST have specific values if the SIG is to be + considered material and authorized. If there are multiple KEYs, the + following checks are performed on all of them, as there is no way to + determine which one generated the signature until the verification is + performed. + + + + + + + + +Wellington Standards Track [Page 3] + +RFC 3008 DNSSEC Signing Authority November 2000 + + +3.1 - Type Flags + + The signing KEY record MUST have a flags value of 00 or 01 + (authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. + A DNSSEC resolver MUST only trust signatures generated by keys that + are permitted to authenticate data. + +3.2 - Name Flags + + The interpretation of this field is considerably different for data + SIGs and SIG(0) records. + +3.2.1 - Data SIG + + If the SIG record covers an RRset, the name type of the associated + KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, + section 2.3.6. The DNSSEC validation process performed by a resolver + MUST ignore all keys that are not zone keys unless local policy + dictates otherwise. + + The primary reason that RFC 2535 allows host and user keys to + generate material DNSSEC signatures is to allow dynamic update + without online zone keys; that is, avoid storing private keys in an + online server. The desire to avoid online signing keys cannot be + achieved, though, because they are necessary to sign NXT and SOA sets + [RFC3007]. These online zone keys can sign any incoming data. + Removing the goal of having no online keys removes the reason to + allow host and user keys to generate material signatures. + + Limiting material signatures to zone keys simplifies the validation + process. The length of the verification chain is bounded by the + name's label depth. The authority of a key is clearly defined; a + resolver does not need to make a potentially complicated decision to + determine whether a key has the proper authority to sign data. + + Finally, there is no additional flexibility granted by allowing + host/user key generated material signatures. As long as users and + hosts have the ability to authenticate update requests to the primary + zone server, signatures by zone keys are sufficient to protect the + integrity of the data to the world at large. + +3.2.2 - SIG(0) + + If the SIG record is a SIG(0) protecting a message, the name type of + the associated KEY SHOULD be 00 (user) or 10 (host/entity). + Transactions are initiated by a host or user, not a zone, so zone + keys SHOULD not generate SIG(0) records. + + + + +Wellington Standards Track [Page 4] + +RFC 3008 DNSSEC Signing Authority November 2000 + + + A client is either explicitly executed by a user or on behalf of a + host, therefore the name type of a SIG(0) generated by a client + SHOULD be either user or host. A nameserver is associated with a + host, and its use of SIG(0) is not associated with a particular zone, + so the name type of a SIG(0) generated by a nameserver SHOULD be + host. + +3.3 - Signatory Flags + + This document does not assign any values to the signatory field, nor + require any values to be present. + +3.4 - Protocol + + The signing KEY record MUST have a protocol value of 3 (DNSSEC) or + 255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC + resolver MUST NOT trust any signature that it generates. + +3.5 - Algorithm Number + + The algorithm field MUST be identical to that of the generated SIG + record, and MUST meet all requirements for an algorithm value in a + SIG record. + +4 - Security Considerations + + This document defines a standard baseline for a DNSSEC capable + resolver. This is necessary for a thorough security analysis of + DNSSEC, if one is to be done. + + Specifically, this document places additional restrictions on SIG + records that a resolver must validate before the signature can be + considered worthy of DNSSEC trust. This simplifies the protocol, + making it more robust and able to withstand scrutiny by the security + community. + +5 - Acknowledgements + + The author would like to thank the following people for review and + informative comments (in alphabetical order): + + Olafur Gudmundsson + Ed Lewis + + + + + + + + +Wellington Standards Track [Page 5] + +RFC 3008 DNSSEC Signing Authority November 2000 + + +6 - References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System", RFC 2136, + April 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s )", RFC 2931, September 2000. + + [RFC3007] Wellington, B., "Simple Secure Domain Name System + (DNS) Dynamic Update", RFC 3007, November 2000. + +7 - Author's Address + + Brian Wellington + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94063 + + Phone: +1 650 381 6022 + EMail: Brian.Wellington@nominum.com + + + + + + + + + + + + + + + + + + +Wellington Standards Track [Page 6] + +RFC 3008 DNSSEC Signing Authority November 2000 + + +8 Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Wellington Standards Track [Page 7] + diff --git a/Documentation/en/rfc/rfc3023.txt b/Documentation/en/rfc/rfc3023.txt new file mode 100644 index 00000000..7507859a --- /dev/null +++ b/Documentation/en/rfc/rfc3023.txt @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group M. Murata +Request for Comments: 3023 IBM Tokyo Research Laboratory +Obsoletes: 2376 S. St.Laurent +Updates: 2048 simonstl.com +Category: Standards Track D. Kohn + Skymoon Ventures + January 2001 + + + XML Media Types + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document standardizes five new media types -- text/xml, + application/xml, text/xml-external-parsed-entity, application/xml- + external-parsed-entity, and application/xml-dtd -- for use in + exchanging network entities that are related to the Extensible Markup + Language (XML). This document also standardizes a convention (using + the suffix '+xml') for naming media types outside of these five types + when those media types represent XML MIME (Multipurpose Internet Mail + Extensions) entities. XML MIME entities are currently exchanged via + the HyperText Transfer Protocol on the World Wide Web, are an + integral part of the WebDAV protocol for remote web authoring, and + are expected to have utility in many domains. + + Major differences from RFC 2376 are (1) the addition of text/xml- + external-parsed-entity, application/xml-external-parsed-entity, and + application/xml-dtd, (2) the '+xml' suffix convention (which also + updates the RFC 2048 registration process), and (3) the discussion of + "utf-16le" and "utf-16be". + + + + + + + + + +Murata, et al. Standards Track [Page 1] + +RFC 3023 XML Media Types January 2001 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 + 3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1 Text/xml Registration . . . . . . . . . . . . . . . . . . . 7 + 3.2 Application/xml Registration . . . . . . . . . . . . . . . . 9 + 3.3 Text/xml-external-parsed-entity Registration . . . . . . . . 11 + 3.4 Application/xml-external-parsed-entity Registration . . . . 12 + 3.5 Application/xml-dtd Registration . . . . . . . . . . . . . . 13 + 3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4. The Byte Order Mark (BOM) and Conversions to/from the UTF-16 + Charset . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 15 + 6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7. A Naming Convention for XML-Based Media Types . . . . . . . 16 + 7.1 Referencing . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8.1 Text/xml with UTF-8 Charset . . . . . . . . . . . . . . . . 19 + 8.2 Text/xml with UTF-16 Charset . . . . . . . . . . . . . . . . 19 + 8.3 Text/xml with UTF-16BE Charset . . . . . . . . . . . . . . . 19 + 8.4 Text/xml with ISO-2022-KR Charset . . . . . . . . . . . . . 20 + 8.5 Text/xml with Omitted Charset . . . . . . . . . . . . . . . 20 + 8.6 Application/xml with UTF-16 Charset . . . . . . . . . . . . 20 + 8.7 Application/xml with UTF-16BE Charset . . . . . . . . . . . 21 + 8.8 Application/xml with ISO-2022-KR Charset . . . . . . . . . . 21 + 8.9 Application/xml with Omitted Charset and UTF-16 XML MIME + Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.10 Application/xml with Omitted Charset and UTF-8 Entity . . . 22 + 8.11 Application/xml with Omitted Charset and Internal Encoding + Declaration . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.12 Text/xml-external-parsed-entity with UTF-8 Charset . . . . . 22 + 8.13 Application/xml-external-parsed-entity with UTF-16 Charset . 23 + 8.14 Application/xml-external-parsed-entity with UTF-16BE Charset 23 + 8.15 Application/xml-dtd . . . . . . . . . . . . . . . . . . . . 23 + 8.16 Application/mathml+xml . . . . . . . . . . . . . . . . . . . 24 + 8.17 Application/xslt+xml . . . . . . . . . . . . . . . . . . . . 24 + 8.18 Application/rdf+xml . . . . . . . . . . . . . . . . . . . . 24 + 8.19 Image/svg+xml . . . . . . . . . . . . . . . . . . . . . . . 24 + 8.20 INCONSISTENT EXAMPLE: Text/xml with UTF-8 Charset . . . . . 25 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 25 + References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 + A. Why Use the '+xml' Suffix for XML-Based MIME Types? . . . . 32 + A.1 Why not just use text/xml or application/xml and let the XML + processor dispatch to the correct application based on the + referenced DTD? . . . . . . . . . . . . . . . . . . . . . . 32 + + + +Murata, et al. Standards Track [Page 2] + +RFC 3023 XML Media Types January 2001 + + + A.2 Why not create a new subtree (e.g., image/xml.svg) to + represent XML MIME types? . . . . . . . . . . . . . . . . . 32 + A.3 Why not create a new top-level MIME type for XML-based media + types? . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + A.4 Why not just have the MIME processor 'sniff' the content to + determine whether it is XML? . . . . . . . . . . . . . . . . 33 + A.5 Why not use a MIME parameter to specify that a media type + uses XML syntax? . . . . . . . . . . . . . . . . . . . . . . 33 + A.6 How about labeling with parameters in the other direction + (e.g., application/xml; Content-Feature=iotp)? . . . . . . . 34 + A.7 How about a new superclass MIME parameter that is defined to + apply to all MIME types (e.g., Content-Type: + application/iotp; $superclass=xml)? . . . . . . . . . . . . 34 + A.8 What about adding a new parameter to the Content-Disposition + header or creating a new Content-Structure header to + indicate XML syntax? . . . . . . . . . . . . . . . . . . . . 35 + A.9 How about a new Alternative-Content-Type header? . . . . . . 35 + A.10 How about using a conneg tag instead (e.g., accept-features: + (syntax=xml))? . . . . . . . . . . . . . . . . . . . . . . . 35 + A.11 How about a third-level content-type, such as text/xml/rdf? 35 + A.12 Why use the plus ('+') character for the suffix '+xml'? . . 36 + A.13 What is the semantic difference between application/foo and + application/foo+xml? . . . . . . . . . . . . . . . . . . . . 36 + A.14 What happens when an even better markup language (e.g., + EBML) is defined, or a new category of data? . . . . . . . . 36 + A.15 Why must I use the '+xml' suffix for my new XML-based media + type? . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 + B. Changes from RFC 2376 . . . . . . . . . . . . . . . . . . . 37 + C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 39 + +1. Introduction + + The World Wide Web Consortium has issued Extensible Markup Language + (XML) 1.0 (Second Edition)[XML]. To enable the exchange of XML + network entities, this document standardizes five new media types -- + text/xml, application/xml, text/xml-external-parsed-entity, + application/xml-external-parsed-entity, and application/xml-dtd -- as + well as a naming convention for identifying XML-based MIME media + types. + + XML entities are currently exchanged on the World Wide Web, and XML + is also used for property values and parameter marshalling by the + WebDAV[RFC2518] protocol for remote web authoring. Thus, there is a + need for a media type to properly label the exchange of XML network + entities. + + + + + +Murata, et al. Standards Track [Page 3] + +RFC 3023 XML Media Types January 2001 + + + Although XML is a subset of the Standard Generalized Markup Language + (SGML) ISO 8879[SGML], which has been assigned the media types + text/sgml and application/sgml, there are several reasons why use of + text/sgml or application/sgml to label XML is inappropriate. First, + there exist many applications that can process XML, but that cannot + process SGML, due to SGML's larger feature set. Second, SGML + applications cannot always process XML entities, because XML uses + features of recent technical corrigenda to SGML. Third, the + definition of text/sgml and application/sgml in [RFC1874] includes + parameters for SGML bit combination transformation format (SGML- + bctf), and SGML boot attribute (SGML-boot). Since XML does not use + these parameters, it would be ambiguous if such parameters were given + for an XML MIME entity. For these reasons, the best approach for + labeling XML network entities is to provide new media types for XML. + + Since XML is an integral part of the WebDAV Distributed Authoring + Protocol, and since World Wide Web Consortium Recommendations have + conventionally been assigned IETF tree media types, and since similar + media types (HTML, SGML) have been assigned IETF tree media types, + the XML media types also belong in the IETF media types tree. + + Similarly, XML will be used as a foundation for other media types, + including types in every branch of the IETF media types tree. To + facilitate the processing of such types, media types based on XML, + but that are not identified using text/xml or application/xml, SHOULD + be named using a suffix of '+xml' as described in Section 7. This + will allow XML-based tools -- browsers, editors, search engines, and + other processors -- to work with all XML-based media types. + +2. Notational Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + As defined in [RFC2781], the three charsets "utf-16", "utf-16le", and + "utf-16be" are used to label UTF-16 text. In this document, "the + UTF-16 family" refers to those three charsets. By contrast, the + phrases "utf-16" or UTF-16 in this document refer specifically to the + single charset "utf-16". + + As sometimes happens between two communities, both MIME and XML have + defined the term entity, with different meanings. Section 2.4 of + [RFC2045] says: + + "The term 'entity' refers specifically to the MIME-defined header + fields and contents of either a message or one of the parts in the + body of a multipart entity." + + + +Murata, et al. Standards Track [Page 4] + +RFC 3023 XML Media Types January 2001 + + + Section 4 of [XML] says: + + "An XML document may consist of one or many storage units" called + entities that "have content" and are normally "identified by + name". + + In this document, "XML MIME entity" is defined as the latter (an XML + entity) encapsulated in the former (a MIME entity). + +3. XML Media Types + + This document standardizes five media types related to XML MIME + entities: text/xml, application/xml, text/xml-external-parsed-entity, + application/xml-external-parsed-entity, and application/xml-dtd. + Registration information for these media types is described in the + sections below. + + Within the XML specification, XML MIME entities can be classified + into four types. In the XML terminology, they are called "document + entities", "external DTD subsets", "external parsed entities", and + "external parameter entities". The media types text/xml and + application/xml MAY be used for "document entities", while text/xml- + external-parsed-entity or application/xml-external-parsed-entity + SHOULD be used for "external parsed entities". The media type + application/xml-dtd SHOULD be used for "external DTD subsets" or + "external parameter entities". application/xml and text/xml MUST NOT + be used for "external parameter entities" or "external DTD subsets", + and MUST NOT be used for "external parsed entities" unless they are + also well-formed "document entities" and are referenced as such. + Note that [RFC2376] (which this document obsoletes) allowed such + usage, although in practice it is likely to have been rare. + + Neither external DTD subsets nor external parameter entities parse as + XML documents, and while some XML document entities may be used as + external parsed entities and vice versa, there are many cases where + the two are not interchangeable. XML also has unparsed entities, + internal parsed entities, and internal parameter entities, but they + are not XML MIME entities. + + If an XML document -- that is, the unprocessed, source XML document + -- is readable by casual users, text/xml is preferable to + application/xml. MIME user agents (and web user agents) that do not + have explicit support for text/xml will treat it as text/plain, for + example, by displaying the XML MIME entity as plain text. + Application/xml is preferable when the XML MIME entity is unreadable + by casual users. Similarly, text/xml-external-parsed-entity is + + + + + +Murata, et al. Standards Track [Page 5] + +RFC 3023 XML Media Types January 2001 + + + preferable when an external parsed entity is readable by casual + users, but application/xml-external-parsed-entity is preferable when + a plain text display is inappropriate. + + NOTE: Users are in general not used to text containing tags such + as <price>, and often find such tags quite disorienting or + annoying. If one is not sure, the conservative principle would + suggest using application/* instead of text/* so as not to put + information in front of users that they will quite likely not + understand. + + The top-level media type "text" has some restrictions on MIME + entities and they are described in [RFC2045] and [RFC2046]. In + particular, the UTF-16 family, UCS-4, and UTF-32 are not allowed + (except over HTTP[RFC2616], which uses a MIME-like mechanism). Thus, + if an XML document or external parsed entity is encoded in such + character encoding schemes, it cannot be labeled as text/xml or + text/xml-external-parsed-entity (except for HTTP). + + Text/xml and application/xml behave differently when the charset + parameter is not explicitly specified. If the default charset (i.e., + US-ASCII) for text/xml is inconvenient for some reason (e.g., bad web + servers), application/xml provides an alternative (see "Optional + parameters" of application/xml registration in Section 3.2). The + same rules apply to the distinction between text/xml-external- + parsed-entity and application/xml-external-parsed-entity. + + XML provides a general framework for defining sequences of structured + data. In some cases, it may be desirable to define new media types + that use XML but define a specific application of XML, perhaps due to + domain-specific security considerations or runtime information. + Furthermore, such media types may allow UTF-8 or UTF-16 only and + prohibit other charsets. This document does not prohibit such media + types and in fact expects them to proliferate. However, developers + of such media types are STRONGLY RECOMMENDED to use this document as + a basis for their registration. In particular, the charset parameter + SHOULD be used in the same manner, as described in Section 7.1, in + order to enhance interoperability. + + An XML document labeled as text/xml or application/xml might contain + namespace declarations, stylesheet-linking processing instructions + (PIs), schema information, or other declarations that might be used + to suggest how the document is to be processed. For example, a + document might have the XHTML namespace and a reference to a CSS + stylesheet. Such a document might be handled by applications that + would use this information to dispatch the document for appropriate + processing. + + + + +Murata, et al. Standards Track [Page 6] + +RFC 3023 XML Media Types January 2001 + + +3.1 Text/xml Registration + + MIME media type name: text + + MIME subtype name: xml + + Mandatory parameters: none + + Optional parameters: charset + + Although listed as an optional parameter, the use of the charset + parameter is STRONGLY RECOMMENDED, since this information can be + used by XML processors to determine authoritatively the character + encoding of the XML MIME entity. The charset parameter can also + be used to provide protocol-specific operations, such as charset- + based content negotiation in HTTP. "utf-8" [RFC2279] is the + recommended value, representing the UTF-8 charset. UTF-8 is + supported by all conforming processors of [XML]. + + If the XML MIME entity is transmitted via HTTP, which uses a + MIME-like mechanism that is exempt from the restrictions on the + text top-level type (see section 19.4.1 of [RFC2616]), "utf-16" + [RFC2781]) is also recommended. UTF-16 is supported by all + conforming processors of [XML]. Since the handling of CR, LF and + NUL for text types in most MIME applications would cause undesired + transformations of individual octets in UTF-16 multi-octet + characters, gateways from HTTP to these MIME applications MUST + transform the XML MIME entity from text/xml; charset="utf-16" to + application/xml; charset="utf-16". + + Conformant with [RFC2046], if a text/xml entity is received with + the charset parameter omitted, MIME processors and XML processors + MUST use the default charset value of "us-ascii"[ASCII]. In cases + where the XML MIME entity is transmitted via HTTP, the default + charset value is still "us-ascii". (Note: There is an + inconsistency between this specification and HTTP/1.1, which uses + ISO-8859-1[ISO8859] as the default for a historical reason. Since + XML is a new format, a new default should be chosen for better + I18N. US-ASCII was chosen, since it is the intersection of UTF-8 + and ISO-8859-1 and since it is already used by MIME.) + + There are several reasons that the charset parameter is + authoritative. First, some MIME processing engines do transcoding + of MIME bodies of the top-level media type "text" without + reference to any of the internal content. Thus, it is possible + that some agent might change text/xml; charset="iso-2022-jp" to + text/xml; charset="utf-8" without modifying the encoding + declaration of an XML document. Second, text/xml must be + + + +Murata, et al. Standards Track [Page 7] + +RFC 3023 XML Media Types January 2001 + + + compatible with text/plain, since MIME agents that do not + understand text/xml will fallback to handling it as text/plain. + If the charset parameter for text/xml were not authoritative, such + fallback would cause data corruption. Third, recent web servers + have been improved so that users can specify the charset + parameter. Fourth, [RFC2130] specifies that the recommended + specification scheme is the "charset" parameter. + + Since the charset parameter is authoritative, the charset is not + always declared within an XML encoding declaration. Thus, special + care is needed when the recipient strips the MIME header and + provides persistent storage of the received XML MIME entity (e.g., + in a file system). Unless the charset is UTF-8 or UTF-16, the + recipient SHOULD also persistently store information about the + charset, perhaps by embedding a correct XML encoding declaration + within the XML MIME entity. + + Encoding considerations: This media type MAY be encoded as + appropriate for the charset and the capabilities of the underlying + MIME transport. For 7-bit transports, data in UTF-8 MUST be + encoded in quoted-printable or base64. For 8-bit clean transport + (e.g., 8BITMIME[RFC1652] ESMTP or NNTP[RFC0977]), UTF-8 does not + need to be encoded. Over HTTP[RFC2616], no content-transfer- + encoding is necessary and UTF-16 may also be used. + + Security considerations: See Section 10. + + Interoperability considerations: XML has proven to be interoperable + across WebDAV clients and servers, and for import and export from + multiple XML authoring tools. For maximum interoperability, + validating processors are recommended. Although non-validating + processors may be more efficient, they are not required to handle + all features of XML. For further information, see sub-section 2.9 + "Standalone Document Declaration" and section 5 "Conformance" of + [XML]. + + Published specification: Extensible Markup Language (XML) 1.0 (Second + Edition)[XML]. + + Applications which use this media type: XML is device-, platform-, + and vendor-neutral and is supported by a wide range of Web user + agents, WebDAV[RFC2518] clients and servers, as well as XML + authoring tools. + + Additional information: + + + + + + +Murata, et al. Standards Track [Page 8] + +RFC 3023 XML Media Types January 2001 + + + Magic number(s): None. + + Although no byte sequences can be counted on to always be + present, XML MIME entities in ASCII-compatible charsets + (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C + ("<?xml"), and those in UTF-16 often begin with hexadecimal FE + FF 00 3C 00 3F 00 78 00 6D 00 6C or FF FE 3C 00 3F 00 78 00 6D + 00 6C 00 (the Byte Order Mark (BOM) followed by "<?xml"). For + more information, see Appendix F of [XML]. + + File extension(s): .xml + + Macintosh File Type Code(s): "TEXT" + + Person and email address for further information: + + MURATA Makoto (FAMILY Given) <mmurata@trl.ibm.co.jp> + + Simon St.Laurent <simonstl@simonstl.com> + + Daniel Kohn <dan@dankohn.com> + + Intended usage: COMMON + + Author/Change controller: The XML specification is a work product of + the World Wide Web Consortium's XML Working Group, and was edited + by: + + Tim Bray <tbray@textuality.com> + + Jean Paoli <jeanpa@microsoft.com> + + C. M. Sperberg-McQueen <cmsmcq@uic.edu> + + Eve Maler <eve.maler@east.sun.com> + + The W3C, and the W3C XML Core Working Group, have change control + over the XML specification. + +3.2 Application/xml Registration + + MIME media type name: application + + MIME subtype name: xml + + Mandatory parameters: none + + + + + +Murata, et al. Standards Track [Page 9] + +RFC 3023 XML Media Types January 2001 + + + Optional parameters: charset + + Although listed as an optional parameter, the use of the charset + parameter is STRONGLY RECOMMENDED, since this information can be + used by XML processors to determine authoritatively the charset of + the XML MIME entity. The charset parameter can also be used to + provide protocol-specific operations, such as charset-based + content negotiation in HTTP. + + "utf-8" [RFC2279] and "utf-16" [RFC2781] are the recommended + values, representing the UTF-8 and UTF-16 charsets, respectively. + These charsets are preferred since they are supported by all + conforming processors of [XML]. + + If an application/xml entity is received where the charset + parameter is omitted, no information is being provided about the + charset by the MIME Content-Type header. Conforming XML + processors MUST follow the requirements in section 4.3.3 of [XML] + that directly address this contingency. However, MIME processors + that are not XML processors SHOULD NOT assume a default charset if + the charset parameter is omitted from an application/xml entity. + + There are several reasons that the charset parameter is + authoritative. First, recent web servers have been improved so + that users can specify the charset parameter. Second, [RFC2130] + specifies that the recommended specification scheme is the + "charset" parameter. + + On the other hand, it has been argued that the charset parameter + should be omitted and the mechanism described in Appendix F of + [XML] (which is non-normative) should be solely relied on. This + approach would allow users to avoid configuration of the charset + parameter; an XML document stored in a file is likely to contain a + correct encoding declaration or BOM (if necessary), since the + operating system does not typically provide charset information + for files. If users would like to rely on the encoding + declaration or BOM and to hide charset information from protocols, + they may determine not to use the parameter. + + Since the charset parameter is authoritative, the charset is not + always declared within an XML encoding declaration. Thus, special + care is needed when the recipient strips the MIME header and + provides persistent storage of the received XML MIME entity (e.g., + in a file system). Unless the charset is UTF-8 or UTF-16, the + recipient SHOULD also persistently store information about the + charset, perhaps by embedding a correct XML encoding declaration + within the XML MIME entity. + + + + +Murata, et al. Standards Track [Page 10] + +RFC 3023 XML Media Types January 2001 + + + Encoding considerations: This media type MAY be encoded as + appropriate for the charset and the capabilities of the underlying + MIME transport. For 7-bit transports, data in either UTF-8 or + UTF-16 MUST be encoded in quoted-printable or base64. For 8-bit + clean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP[RFC0977]), + UTF-8 is not encoded, but the UTF-16 family MUST be encoded in + base64. For binary clean transports (e.g., HTTP[RFC2616]), no + content-transfer-encoding is necessary. + + Security considerations: See Section 10. + + Interoperability considerations: Same as Section 3.1. + + Published specification: Same as Section 3.1. + + Applications which use this media type: Same as Section 3.1. + + Additional information: Same as Section 3.1. + + Person and email address for further information: Same as Section + 3.1. + + Intended usage: COMMON + + Author/Change controller: Same as Section 3.1. + +3.3 Text/xml-external-parsed-entity Registration + + MIME media type name: text + + MIME subtype name: xml-external-parsed-entity + + Mandatory parameters: none + + Optional parameters: charset + + The charset parameter of text/xml-external-parsed-entity is + handled the same as that of text/xml as described in Section 3.1. + + Encoding considerations: Same as Section 3.1. + + Security considerations: See Section 10. + + Interoperability considerations: XML external parsed entities are as + interoperable as XML documents, though they have a less tightly + constrained structure and therefore need to be referenced by XML + documents for proper handling by XML processors. Similarly, XML + documents cannot be reliably used as external parsed entities + + + +Murata, et al. Standards Track [Page 11] + +RFC 3023 XML Media Types January 2001 + + + because external parsed entities are prohibited from having + standalone document declarations or DTDs. Identifying XML + external parsed entities with their own content type should + enhance interoperability of both XML documents and XML external + parsed entities. + + Published specification: Same as Section 3.1. + + Applications which use this media type: Same as Section 3.1. + + Additional information: + + Magic number(s): Same as Section 3.1. + + File extension(s): .xml or .ent + + Macintosh File Type Code(s): "TEXT" + + Person and email address for further information: Same as Section + 3.1. + + Intended usage: COMMON + + Author/Change controller: Same as Section 3.1. + +3.4 Application/xml-external-parsed-entity Registration + + MIME media type name: application + + MIME subtype name: xml-external-parsed-entity + + Mandatory parameters: none + + Optional parameters: charset + + The charset parameter of application/xml-external-parsed-entity is + handled the same as that of application/xml as described in + Section 3.2. + + Encoding considerations: Same as Section 3.2. + + Security considerations: See Section 10. + + Interoperability considerations: Same as those for text/xml- + external-parsed-entity as described in Section 3.3. + + Published specification: Same as text/xml as described in Section + 3.1. + + + +Murata, et al. Standards Track [Page 12] + +RFC 3023 XML Media Types January 2001 + + + Applications which use this media type: Same as Section 3.1. + + Additional information: + + Magic number(s): Same as Section 3.1. + + File extension(s): .xml or .ent + + Macintosh File Type Code(s): "TEXT" + + Person and email address for further information: Same as Section + 3.1. + + Intended usage: COMMON + + Author/Change controller: Same as Section 3.1. + +3.5 Application/xml-dtd Registration + + MIME media type name: application + + MIME subtype name: xml-dtd + + Mandatory parameters: none + + Optional parameters: charset + + The charset parameter of application/xml-dtd is handled the same + as that of application/xml as described in Section 3.2. + + Encoding considerations: Same as Section 3.2. + + Security considerations: See Section 10. + + Interoperability considerations: XML DTDs have proven to be + interoperable by DTD authoring tools and XML browsers, among + others. + + Published specification: Same as text/xml as described in Section + 3.1. + + Applications which use this media type: DTD authoring tools handle + external DTD subsets as well as external parameter entities. XML + browsers may also access external DTD subsets and external + parameter entities. + + + + + + +Murata, et al. Standards Track [Page 13] + +RFC 3023 XML Media Types January 2001 + + + Additional information: + + Magic number(s): Same as Section 3.1. + + File extension(s): .dtd or .mod + + Macintosh File Type Code(s): "TEXT" + + Person and email address for further information: Same as Section + 3.1. + + Intended usage: COMMON + + Author/Change controller: Same as Section 3.1. + +3.6 Summary + + The following list applies to text/xml, text/xml-external-parsed- + entity, and XML-based media types under the top-level type "text" + that define the charset parameter according to this specification: + + o Charset parameter is strongly recommended. + + o If the charset parameter is not specified, the default is "us- + ascii". The default of "iso-8859-1" in HTTP is explicitly + overridden. + + o No error handling provisions. + + o An encoding declaration, if present, is irrelevant, but when + saving a received resource as a file, the correct encoding + declaration SHOULD be inserted. + + The next list applies to application/xml, application/xml-external- + parsed-entity, application/xml-dtd, and XML-based media types under + top-level types other than "text" that define the charset parameter + according to this specification: + + o Charset parameter is strongly recommended, and if present, it + takes precedence. + + o If the charset parameter is omitted, conforming XML processors + MUST follow the requirements in section 4.3.3 of [XML]. + + + + + + + + +Murata, et al. Standards Track [Page 14] + +RFC 3023 XML Media Types January 2001 + + +4. The Byte Order Mark (BOM) and Conversions to/from the UTF-16 Charset + + Section 4.3.3 of [XML] specifies that XML MIME entities in the + charset "utf-16" MUST begin with a byte order mark (BOM), which is a + hexadecimal octet sequence 0xFE 0xFF (or 0xFF 0xFE, depending on + endian). The XML Recommendation further states that the BOM is an + encoding signature, and is not part of either the markup or the + character data of the XML document. + + Due to the presence of the BOM, applications that convert XML from + "utf-16" to a non-Unicode encoding MUST strip the BOM before + conversion. Similarly, when converting from another encoding into + "utf-16", the BOM MUST be added after conversion is complete. + + In addition to the charset "utf-16", [RFC2781] introduces "utf-16le" + (little endian) and "utf-16be" (big endian) as well. The BOM is + prohibited for these charsets. When an XML MIME entity is encoded in + "utf-16le" or "utf-16be", it MUST NOT begin with the BOM but SHOULD + contain an encoding declaration. Conversion from "utf-16" to "utf- + 16be" or "utf-16le" and conversion in the other direction MUST strip + or add the BOM, respectively. + +5. Fragment Identifiers + + Section 4.1 of [RFC2396] notes that the semantics of a fragment + identifier (the part of a URI after a "#") is a property of the data + resulting from a retrieval action, and that the format and + interpretation of fragment identifiers is dependent on the media type + of the retrieval result. + + As of today, no established specifications define identifiers for XML + media types. However, a working draft published by W3C, namely "XML + Pointer Language (XPointer)", attempts to define fragment identifiers + for text/xml and application/xml. The current specification for + XPointer is available at http://www.w3.org/TR/xptr. + +6. The Base URI + + Section 5.1 of [RFC2396] specifies that the semantics of a relative + URI reference embedded in a MIME entity is dependent on the base URI. + The base URI is either (1) the base URI embedded in the MIME entity, + (2) the base URI of the encapsulating MIME entity, (3) the URI used + to retrieve the MIME entity, or (4) the application-dependent default + base URI, where (1) has the highest precedence. [RFC2396] further + specifies that the mechanism for embedding the base URI is dependent + on the media type. + + + + + +Murata, et al. Standards Track [Page 15] + +RFC 3023 XML Media Types January 2001 + + + As of today, no established specifications define mechanisms for + embedding the base URI in XML MIME entities. However, a Proposed + Recommendation published by W3C, namely "XML Base", attempts to + define such a mechanism for text/xml, application/xml, text/xml- + external-parsed-entity, and application/xml-external-parsed-entity. + The current specification for XML Base is available at + http://www.w3.org/TR/xmlbase. + +7. A Naming Convention for XML-Based Media Types + + This document recommends the use of a naming convention (a suffix of + '+xml') for identifying XML-based MIME media types, whatever their + particular content may represent. This allows the use of generic XML + processors and technologies on a wide variety of different XML + document types at a minimum cost, using existing frameworks for media + type registration. + + Although the use of a suffix was not considered as part of the + original MIME architecture, this choice is considered to provide the + most functionality with the least potential for interoperability + problems or lack of future extensibility. The alternatives to the ' + +xml' suffix and the reason for its selection are described in + Appendix A. + + As XML development continues, new XML document types are appearing + rapidly. Many of these XML document types would benefit from the + identification possibilities of a more specific MIME media type than + text/xml or application/xml can provide, and it is likely that many + new media types for XML-based document types will be registered in + the near and ongoing future. + + While the benefits of specific MIME types for particular types of XML + documents are significant, all XML documents share common structures + and syntax that make possible common processing. + + Some areas where 'generic' processing is useful include: + + o Browsing - An XML browser can display any XML document with a + provided [CSS] or [XSLT] style sheet, whatever the vocabulary of + that document. + + o Editing - Any XML editor can read, modify, and save any XML + document. + + o Fragment identification - XPointers (work in progress) can work + with any XML document, whatever vocabulary it uses and whether or + not it uses XPointer for its own fragment identification. + + + + +Murata, et al. Standards Track [Page 16] + +RFC 3023 XML Media Types January 2001 + + + o Hypertext linking - XLink (work in progress) hypertext linking is + designed to connect any XML documents, regardless of vocabulary. + + o Searching - XML-oriented search engines, web crawlers, agents, and + query tools should be able to read XML documents and extract the + names and content of elements and attributes even if the tools are + ignorant of the particular vocabulary used for elements and + attributes. + + o Storage - XML-oriented storage systems, which keep XML documents + internally in a parsed form, should similarly be able to process, + store, and recreate any XML document. + + o Well-formedness and validity checking - An XML processor can + confirm that any XML document is well-formed and that it is valid + (i.e., conforms to its declared DTD or Schema). + + When a new media type is introduced for an XML-based format, the name + of the media type SHOULD end with '+xml'. This convention will allow + applications that can process XML generically to detect that the MIME + entity is supposed to be an XML document, verify this assumption by + invoking some XML processor, and then process the XML document + accordingly. Applications may match for types that represent XML + MIME entities by comparing the subtype to the pattern '*/*+xml'. (Of + course, 4 of the 5 media types defined in this document -- text/xml, + application/xml, text/xml-external-parsed-entity, and + application/xml-external-parsed-entity -- also represent XML MIME + entities while not conforming to the '*/*+xml' pattern.) + + NOTE: Section 14.1 of HTTP[RFC2616] does not support Accept + headers of the form "Accept: */*+xml" and so this header MUST NOT + be used in this way. Instead, content negotiation[RFC2703] could + potentially be used if an XML-based MIME type were needed. + + XML generic processing is not always appropriate for XML-based media + types. For example, authors of some such media types may wish that + the types remain entirely opaque except to applications that are + specifically designed to deal with that media type. By NOT following + the naming convention '+xml', such media types can avoid XML-generic + processing. Since generic processing will be useful in many cases, + however -- including in some situations that are difficult to predict + ahead of time -- those registering media types SHOULD use the '+xml' + convention unless they have a particularly compelling reason not to. + + The registration process for these media types is described in + [RFC2048]. The registrar for the IETF tree will encourage new XML- + based media type registrations in the IETF tree to follow this + guideline. Registrars for other trees SHOULD follow this convention + + + +Murata, et al. Standards Track [Page 17] + +RFC 3023 XML Media Types January 2001 + + + in order to ensure maximum interoperability of their XML-based + documents. Similarly, media subtypes that do not represent XML MIME + entities MUST NOT be allowed to register with a '+xml' suffix. + +7.1 Referencing + + Registrations for new XML-based media types under the top-level type + "text" SHOULD, in specifying the charset parameter and encoding + considerations, define them as: "Same as [charset parameter / + encoding considerations] of text/xml as specified in RFC 3023." + + Registrations for new XML-based media types under top-level types + other than "text" SHOULD, in specifying the charset parameter and + encoding considerations, define them as: "Same as [charset parameter + / encoding considerations] of application/xml as specified in RFC + 3023." + + The use of the charset parameter is STRONGLY RECOMMENDED, since this + information can be used by XML processors to determine + authoritatively the charset of the XML MIME entity. + + These registrations SHOULD specify that the XML-based media type + being registered has all of the security considerations described in + RFC 3023 plus any additional considerations specific to that media + type. + + These registrations SHOULD also make reference to RFC 3023 in + specifying magic numbers, fragment identifiers, base URIs, and use of + the BOM. + + These registrations MAY reference the text/xml registration in RFC + 3023 in specifying interoperability considerations, if these + considerations are not overridden by issues specific to that media + type. + +8. Examples + + The examples below give the value of the MIME Content-type header and + the XML declaration (which includes the encoding declaration) inside + the XML MIME entity. For UTF-16 examples, the Byte Order Mark + character is denoted as "{BOM}", and the XML declaration is assumed + to come at the beginning of the XML MIME entity, immediately + following the BOM. Note that other MIME headers may be present, and + the XML MIME entity may contain other data in addition to the XML + declaration; the examples focus on the Content-type header and the + encoding declaration for clarity. + + + + + +Murata, et al. Standards Track [Page 18] + +RFC 3023 XML Media Types January 2001 + + +8.1 Text/xml with UTF-8 Charset + + Content-type: text/xml; charset="utf-8" + + <?xml version="1.0" encoding="utf-8"?> + + This is the recommended charset value for use with text/xml. Since + the charset parameter is provided, MIME and XML processors MUST treat + the enclosed entity as UTF-8 encoded. + + If sent using a 7-bit transport (e.g., SMTP[RFC0821]), the XML MIME + entity MUST use a content-transfer-encoding of either quoted- + printable or base64. For an 8-bit clean transport (e.g., 8BITMIME + ESMTP or NNTP), or a binary clean transport (e.g., HTTP), no + content-transfer-encoding is necessary. + +8.2 Text/xml with UTF-16 Charset + + Content-type: text/xml; charset="utf-16" + + {BOM}<?xml version='1.0' encoding='utf-16'?> + + or + + {BOM}<?xml version='1.0'?> + + This is possible only when the XML MIME entity is transmitted via + HTTP, which uses a MIME-like mechanism and is a binary-clean + protocol, hence does not perform CR and LF transformations and allows + NUL octets. As described in [RFC2781], the UTF-16 family MUST NOT be + used with media types under the top-level type "text" except over + HTTP (see section 19.4.1 of [RFC2616] for details). + + Since HTTP is binary clean, no content-transfer-encoding is + necessary. + +8.3 Text/xml with UTF-16BE Charset + + Content-type: text/xml; charset="utf-16be" + + <?xml version='1.0' encoding='utf-16be'?> + + Observe that the BOM does not exist. This is again possible only + when the XML MIME entity is transmitted via HTTP. + + + + + + + +Murata, et al. Standards Track [Page 19] + +RFC 3023 XML Media Types January 2001 + + +8.4 Text/xml with ISO-2022-KR Charset + + Content-type: text/xml; charset="iso-2022-kr" + + <?xml version="1.0" encoding='iso-2022-kr'?> + + This example shows text/xml with a Korean charset (e.g., Hangul) + encoded following the specification in [RFC1557]. Since the charset + parameter is provided, MIME and XML processors MUST treat the + enclosed entity as encoded per RFC 1557. + + Since ISO-2022-KR has been defined to use only 7 bits of data, no + content-transfer-encoding is necessary with any transport. + +8.5 Text/xml with Omitted Charset + + Content-type: text/xml + + {BOM}<?xml version="1.0" encoding="utf-16"?> + + or + + {BOM}<?xml version="1.0"?> + + This example shows text/xml with the charset parameter omitted. In + this case, MIME and XML processors MUST assume the charset is "us- + ascii", the default charset value for text media types specified in + [RFC2046]. The default of "us-ascii" holds even if the text/xml + entity is transported using HTTP. + + Omitting the charset parameter is NOT RECOMMENDED for text/xml. For + example, even if the contents of the XML MIME entity are UTF-16 or + UTF-8, or the XML MIME entity has an explicit encoding declaration, + XML and MIME processors MUST assume the charset is "us-ascii". + +8.6 Application/xml with UTF-16 Charset + + Content-type: application/xml; charset="utf-16" + + {BOM}<?xml version="1.0" encoding="utf-16"?> + + or + + {BOM}<?xml version="1.0"?> + + This is a recommended charset value for use with application/xml. + Since the charset parameter is provided, MIME and XML processors MUST + treat the enclosed entity as UTF-16 encoded. + + + +Murata, et al. Standards Track [Page 20] + +RFC 3023 XML Media Types January 2001 + + + If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean + transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be + encoded in quoted-printable or base64. For a binary clean transport + (e.g., HTTP), no content-transfer-encoding is necessary. + +8.7 Application/xml with UTF-16BE Charset + + Content-type: application/xml; charset="utf-16be" + + <?xml version='1.0' encoding='utf-16be'?> + + Observe that the BOM does not exist. Since the charset parameter is + provided, MIME and XML processors MUST treat the enclosed entity as + UTF-16BE encoded. + +8.8 Application/xml with ISO-2022-KR Charset + + Content-type: application/xml; charset="iso-2022-kr" + + <?xml version="1.0" encoding="iso-2022-kr"?> + + This example shows application/xml with a Korean charset (e.g., + Hangul) encoded following the specification in [RFC1557]. Since the + charset parameter is provided, MIME and XML processors MUST treat the + enclosed entity as encoded per RFC 1557, independent of whether the + XML MIME entity has an internal encoding declaration (this example + does show such a declaration, which agrees with the charset + parameter). + + Since ISO-2022-KR has been defined to use only 7 bits of data, no + content-transfer-encoding is necessary with any transport. + +8.9 Application/xml with Omitted Charset and UTF-16 XML MIME Entity + + Content-type: application/xml + + {BOM}<?xml version='1.0' encoding="utf-16"?> + + or + + {BOM}<?xml version='1.0'?> + + For this example, the XML MIME entity begins with a BOM. Since the + charset has been omitted, a conforming XML processor follows the + requirements of [XML], section 4.3.3. Specifically, the XML + processor reads the BOM, and thus knows deterministically that the + charset is UTF-16. + + + + +Murata, et al. Standards Track [Page 21] + +RFC 3023 XML Media Types January 2001 + + + An XML-unaware MIME processor SHOULD make no assumptions about the + charset of the XML MIME entity. + +8.10 Application/xml with Omitted Charset and UTF-8 Entity + + Content-type: application/xml + + <?xml version='1.0'?> + + In this example, the charset parameter has been omitted, and there is + no BOM. Since there is no BOM, the XML processor follows the + requirements in section 4.3.3 of [XML], and optionally applies the + mechanism described in Appendix F (which is non-normative) of [XML] + to determine the charset encoding of UTF-8. The XML MIME entity does + not contain an encoding declaration, but since the encoding is UTF-8, + this is still a conforming XML MIME entity. + + An XML-unaware MIME processor SHOULD make no assumptions about the + charset of the XML MIME entity. + +8.11 Application/xml with Omitted Charset and Internal Encoding + Declaration + + Content-type: application/xml + + <?xml version='1.0' encoding="iso-10646-ucs-4"?> + + In this example, the charset parameter has been omitted, and there is + no BOM. However, the XML MIME entity does have an encoding + declaration inside the XML MIME entity that specifies the entity's + charset. Following the requirements in section 4.3.3 of [XML], and + optionally applying the mechanism described in Appendix F (non- + normative) of [XML], the XML processor determines the charset of the + XML MIME entity (in this example, UCS-4). + + An XML-unaware MIME processor SHOULD make no assumptions about the + charset of the XML MIME entity. + +8.12 Text/xml-external-parsed-entity with UTF-8 Charset + + Content-type: text/xml-external-parsed-entity; charset="utf-8" + + <?xml encoding="utf-8"?> + + This is the recommended charset value for use with text/xml- + external-parsed-entity. Since the charset parameter is provided, + MIME and XML processors MUST treat the enclosed entity as UTF-8 + encoded. + + + +Murata, et al. Standards Track [Page 22] + +RFC 3023 XML Media Types January 2001 + + + If sent using a 7-bit transport (e.g., SMTP), the XML MIME entity + MUST use a content-transfer-encoding of either quoted-printable or + base64. For an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP), + or a binary clean transport (e.g., HTTP) no content-transfer-encoding + is necessary. + +8.13 Application/xml-external-parsed-entity with UTF-16 Charset + + Content-type: application/xml-external-parsed-entity; + charset="utf-16" + + {BOM}<?xml encoding="utf-16"?> + + or + + {BOM}<?xml?> + + This is a recommended charset value for use with application/xml- + external-parsed-entity. Since the charset parameter is provided, + MIME and XML processors MUST treat the enclosed entity as UTF-16 + encoded. + + If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean + transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be + encoded in quoted-printable or base64. For a binary clean transport + (e.g., HTTP), no content-transfer-encoding is necessary. + +8.14 Application/xml-external-parsed-entity with UTF-16BE Charset + + Content-type: application/xml-external-parsed-entity; + charset="utf-16be" + + <?xml encoding="utf-16be"?> + + Since the charset parameter is provided, MIME and XML processors MUST + treat the enclosed entity as UTF-16BE encoded. + +8.15 Application/xml-dtd + + Content-type: application/xml-dtd; charset="utf-8" + + <?xml encoding="utf-8"?> + + Charset "utf-8" is a recommended charset value for use with + application/xml-dtd. Since the charset parameter is provided, MIME + and XML processors MUST treat the enclosed entity as UTF-8 encoded. + + + + + +Murata, et al. Standards Track [Page 23] + +RFC 3023 XML Media Types January 2001 + + +8.16 Application/mathml+xml + + Content-type: application/mathml+xml + + <?xml version="1.0" ?> + + MathML documents are XML documents whose content describes + mathematical information, as defined by [MathML]. As a format based + on XML, MathML documents SHOULD use the '+xml' suffix convention in + their MIME content-type identifier. However, no content type has yet + been registered for MathML and so this media type should not be used + until such registration has been completed. + +8.17 Application/xslt+xml + + Content-type: application/xslt+xml + + <?xml version="1.0" ?> + + Extensible Stylesheet Language (XSLT) documents are XML documents + whose content describes stylesheets for other XML documents, as + defined by [XSLT]. As a format based on XML, XSLT documents SHOULD + use the '+xml' suffix convention in their MIME content-type + identifier. However, no content type has yet been registered for + XSLT and so this media type should not be used until such + registration has been completed. + +8.18 Application/rdf+xml + + Content-type: application/rdf+xml + + <?xml version="1.0" ?> + + RDF documents identified using this MIME type are XML documents whose + content describes metadata, as defined by [RDF]. As a format based + on XML, RDF documents SHOULD use the '+xml' suffix convention in + their MIME content-type identifier. However, no content type has yet + been registered for RDF and so this media type should not be used + until such registration has been completed. + +8.19 Image/svg+xml + + Content-type: image/svg+xml + + <?xml version="1.0" ?> + + + + + + +Murata, et al. Standards Track [Page 24] + +RFC 3023 XML Media Types January 2001 + + + Scalable Vector Graphics (SVG) documents are XML documents whose + content describes graphical information, as defined by [SVG]. As a + format based on XML, SVG documents SHOULD use the '+xml' suffix + convention in their MIME content-type identifier. However, no + content type has yet been registered for SVG and so this media type + should not be used until such registration has been completed. + +8.20 INCONSISTENT EXAMPLE: Text/xml with UTF-8 Charset + + Content-type: text/xml; charset="utf-8" + + <?xml version="1.0" encoding="iso-8859-1"?> + + Since the charset parameter is provided in the Content-Type header, + MIME and XML processors MUST treat the enclosed entity as UTF-8 + encoded. That is, the "iso-8859-1" encoding MUST be ignored. + + Processors generating XML MIME entities MUST NOT label conflicting + charset information between the MIME Content-Type and the XML + declaration. + +9. IANA Considerations + + As described in Section 7, this document updates the [RFC2048] + registration process for XML-based MIME types. + +10. Security Considerations + + XML, as a subset of SGML, has all of the same security considerations + as specified in [RFC1874], and likely more, due to its expected + ubiquitous deployment. + + To paraphrase section 3 of RFC 1874, XML MIME entities contain + information to be parsed and processed by the recipient's XML system. + These entities may contain and such systems may permit explicit + system level commands to be executed while processing the data. To + the extent that an XML system will execute arbitrary command strings, + recipients of XML MIME entities may be a risk. In general, it may be + possible to specify commands that perform unauthorized file + operations or make changes to the display processor's environment + that affect subsequent operations. + + In general, any information stored outside of the direct control of + the user -- including CSS style sheets, XSL transformations, entity + declarations, and DTDs -- can be a source of insecurity, by either + obvious or subtle means. For example, a tiny "whiteout attack" + modification made to a "master" style sheet could make words in + critical locations disappear in user documents, without directly + + + +Murata, et al. Standards Track [Page 25] + +RFC 3023 XML Media Types January 2001 + + + modifying the user document or the stylesheet it references. Thus, + the security of any XML document is vitally dependent on all of the + documents recursively referenced by that document. + + The entity lists and DTDs for XHTML 1.0[XHTML], for instance, are + likely to be a commonly used set of information. Many developers + will use and trust them, few of whom will know much about the level + of security on the W3C's servers, or on any similarly trusted + repository. + + The simplest attack involves adding declarations that break + validation. Adding extraneous declarations to a list of character + entities can effectively "break the contract" used by documents. A + tiny change that produces a fatal error in a DTD could halt XML + processing on a large scale. Extraneous declarations are fairly + obvious, but more sophisticated tricks, like changing attributes from + being optional to required, can be difficult to track down. Perhaps + the most dangerous option available to crackers is redefining default + values for attributes: e.g., if developers have relied on defaulted + attributes for security, a relatively small change might expose + enormous quantities of information. + + Apart from the structural possibilities, another option, "entity + spoofing," can be used to insert text into documents, vandalizing and + perhaps conveying an unintended message. Because XML 1.0 permits + multiple entity declarations, and the first declaration takes + precedence, it's possible to insert malicious content where an entity + is used, such as by inserting the full text of Winnie the Pooh in + every occurrence of —. + + Use of the digital signatures work currently underway by the xmldsig + working group may eventually ameliorate the dangers of referencing + external documents not under one's own control. + + Use of XML is expected to be varied, and widespread. XML is under + scrutiny by a wide range of communities for use as a common syntax + for community-specific metadata. For example, the Dublin + Core[RFC2413] group is using XML for document metadata, and a new + effort has begun that is considering use of XML for medical + information. Other groups view XML as a mechanism for marshalling + parameters for remote procedure calls. More uses of XML will + undoubtedly arise. + + Security considerations will vary by domain of use. For example, XML + medical records will have much more stringent privacy and security + considerations than XML library metadata. Similarly, use of XML as a + parameter marshalling syntax necessitates a case by case security + review. + + + +Murata, et al. Standards Track [Page 26] + +RFC 3023 XML Media Types January 2001 + + + XML may also have some of the same security concerns as plain text. + Like plain text, XML can contain escape sequences that, when + displayed, have the potential to change the display processor + environment in ways that adversely affect subsequent operations. + Possible effects include, but are not limited to, locking the + keyboard, changing display parameters so subsequent displayed text is + unreadable, or even changing display parameters to deliberately + obscure or distort subsequent displayed material so that its meaning + is lost or altered. Display processors SHOULD either filter such + material from displayed text or else make sure to reset all important + settings after a given display operation is complete. + + Some terminal devices have keys whose output, when pressed, can be + changed by sending the display processor a character sequence. If + this is possible the display of a text object containing such + character sequences could reprogram keys to perform some illicit or + dangerous action when the key is subsequently pressed by the user. + In some cases not only can keys be programmed, they can be triggered + remotely, making it possible for a text display operation to directly + perform some unwanted action. As such, the ability to program keys + SHOULD be blocked either by filtering or by disabling the ability to + program keys entirely. + + Note that it is also possible to construct XML documents that make + use of what XML terms "entity references" (using the XML meaning of + the term "entity" as described in Section 2), to construct repeated + expansions of text. Recursive expansions are prohibited by [XML] and + XML processors are required to detect them. However, even non- + recursive expansions may cause problems with the finite computing + resources of computers, if they are performed many times. + +References + + [ASCII] "US-ASCII. Coded Character Set -- 7-Bit American Standard + Code for Information Interchange", ANSI X3.4-1986, 1986. + + [CSS] Bos, B., Lie, H.W., Lilley, C. and I. Jacobs, "Cascading + Style Sheets, level 2 (CSS2) Specification", World Wide + Web Consortium Recommendation REC-CSS2, May 1998, + <http://www.w3.org/TR/REC-CSS2/>. + + [ISO8859] "ISO-8859. International Standard -- Information + Processing -- 8-bit Single-Byte Coded Graphic Character + Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987", + 1987. + + + + + + +Murata, et al. Standards Track [Page 27] + +RFC 3023 XML Media Types January 2001 + + + [MathML] Ion, P. and R. Miner, "Mathematical Markup Language + (MathML) 1.01", World Wide Web Consortium Recommendation + REC-MathML, July 1999, <http://www.w3.org/TR/REC-MathML/>. + + [PNG] Boutell, T., "PNG (Portable Network Graphics) + Specification", World Wide Web Consortium Recommendation + REC-png, October 1996, <http://www.w3.org/TR/REC-png>. + + [RDF] Lassila, O. and R.R. Swick, "Resource Description + Framework (RDF) Model and Syntax Specification", World + Wide Web Consortium Recommendation REC-rdf-syntax, + February 1999, <http://www.w3.org/TR/REC-rdf-syntax/>. + + [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + + [RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer + Protocol", RFC 977, February 1986. + + [RFC1557] Choi, U., Chon, K. and H. Park, "Korean Character Encoding + for Internet Messages", RFC 1557, December 1993. + + [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. + Crocker, "SMTP Service Extension for 8bit-MIMEtransport", + RFC 1652, July 1994. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December 1995. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: Registration + Procedures", RFC 2048, November 1996. + + [RFC2060] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [RFC2077] Nelson, S., Parks, C. and Mitra, "The Model Primary + Content Type for Multipurpose Internet Mail Extensions", + RFC 2077, January 1997. + + + + + +Murata, et al. Standards Track [Page 28] + +RFC 3023 XML Media Types January 2001 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., + Atkinson, R., Crispin, M. and P. Svanberg, "The Report of + the IAB Character Set Workshop held 29 February - 1 March, + 1996", RFC 2130, April 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, + July 1998. + + [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax.", RFC 2396, + August 1998. + + [RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin + Core Metadata for Resource Discovery", RFC 2413, September + 1998. + + [RFC2445] Dawson, F. and D. Stenerson, "Internet Calendaring and + Scheduling Core Object Specification (iCalendar)", RFC + 2445, November 1998. + + [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. + Jensen, "HTTP Extensions for Distributed Authoring -- + WEBDAV", RFC 2518, February 1999. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., + Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [RFC2703] Klyne, G., "Protocol-independent Content Negotiation + Framework", RFC 2703, September 1999. + + [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO + 10646", RFC 2781, Februrary 2000. + + [RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP + Version 1.0", RFC 2801, April 2000. + + + + + + +Murata, et al. Standards Track [Page 29] + +RFC 3023 XML Media Types January 2001 + + + [SGML] International Standard Organization, "Information + Processing -- Text and Office Systems -- Standard + Generalized Markup Language (SGML)", ISO 8879, October + 1986. + + [SVG] Ferraiolo, J., "Scalable Vector Graphics (SVG)", World + Wide Web Consortium Candidate Recommendation SVG, November + 2000, <http://www.w3.org/TR/SVG>. + + [XHTML] Pemberton, S. and et al, "XHTML 1.0: The Extensible + HyperText Markup Language", World Wide Web Consortium + Recommendation xhtml1, January 2000, + <http://www.w3.org/TR/xhtml1>. + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, + "Extensible Markup Language (XML) 1.0 (Second Edition)", + World Wide Web Consortium Recommendation REC-xml, October + 2000, <http://www.w3.org/TR/REC-xml>. + + [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World + Wide Web Consortium Recommendation xslt, November 1999, + <http://www.w3.org/TR/xslt>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Murata, et al. Standards Track [Page 30] + +RFC 3023 XML Media Types January 2001 + + +Authors' Addresses + + MURATA Makoto (FAMILY Given) + IBM Tokyo Research Laboratory + 1623-14, Shimotsuruma + Yamato-shi, Kanagawa-ken 242-8502 + Japan + + Phone: +81-46-215-4678 + EMail: mmurata@trl.ibm.co.jp + + + Simon St.Laurent + simonstl.com + 1259 Dryden Road + Ithaca, New York 14850 + USA + + EMail: simonstl@simonstl.com + URI: http://www.simonstl.com/ + + + Dan Kohn + Skymoon Ventures + 3045 Park Boulevard + Palo Alto, California 94306 + USA + + Phone: +1-650-327-2600 + EMail: dan@dankohn.com + URI: http://www.dankohn.com/ + + + + + + + + + + + + + + + + + + + + +Murata, et al. Standards Track [Page 31] + +RFC 3023 XML Media Types January 2001 + + +Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? + + Although the use of a suffix was not considered as part of the + original MIME architecture, this choice is considered to provide the + most functionality with the least potential for interoperability + problems or lack of future extensibility. The alternatives to the + '+xml' suffix and the reason for its selection are described below. + +A.1 Why not just use text/xml or application/xml and let the XML + processor dispatch to the correct application based on the + referenced DTD? + + text/xml and application/xml remain useful in many situations, + especially for document-oriented applications that involve combining + XML with a stylesheet in order to present the data. However, XML is + also used to define entirely new data types, and an XML-based format + such as image/svg+xml fits the definition of a MIME media type + exactly as well as image/png[PNG] does. (Note that image/svg+xml is + not yet registered.) Although extra functionality is available for + MIME processors that are also XML processors, XML-based media types + -- even when treated as opaque, non-XML media types -- are just as + useful as any other media type and should be treated as such. + + Since MIME dispatchers work off of the MIME type, use of text/xml or + application/xml to label discrete media types will hinder correct + dispatching and general interoperability. Finally, many XML + documents use neither DTDs nor namespaces, yet are perfectly legal + XML. + +A.2 Why not create a new subtree (e.g., image/xml.svg) to represent XML + MIME types? + + The subtree under which a media type is registered -- IETF, vendor + (*/vnd.*), or personal (*/prs.*); see [RFC2048] for details -- is + completely orthogonal from whether the media type uses XML syntax or + not. The suffix approach allows XML document types to be identified + within any subtree. The vendor subtree, for example, is likely to + include a large number of XML-based document types. By using a + suffix, rather than setting up a separate subtree, those types may + remain in the same location in the tree of MIME types that they would + have occupied had they not been based on XML. + +A.3 Why not create a new top-level MIME type for XML-based media types? + + The top-level MIME type (e.g., model/*[RFC2077]) determines what kind + of content the type is, not what syntax it uses. For example, agents + using image/* to signal acceptance of any image format should + certainly be given access to media type image/svg+xml, which is in + + + +Murata, et al. Standards Track [Page 32] + +RFC 3023 XML Media Types January 2001 + + + all respects a standard image subtype. It just happens to use XML to + describe its syntax. The two aspects of the media type are + completely orthogonal. + + XML-based data types will most likely be registered in ALL top-level + categories. Potential, though currently unregistered, examples could + include application/mathml+xml[MathML] and image/svg+xml[SVG]. + +A.4 Why not just have the MIME processor 'sniff' the content to + determine whether it is XML? + + Rather than explicitly labeling XML-based media types, the processor + could look inside each type and see whether or not it is XML. The + processor could also cache a list of XML-based media types. + + Although this method might work acceptably for some mail + applications, it would fail completely in many other uses of MIME. + For instance, an XML-based web crawler would have no way of + determining whether a file is XML except to fetch it and check. The + same issue applies in some IMAP4[RFC2060] mail applications, where + the client first fetches the MIME type as part of the message + structure and then decides whether to fetch the MIME entity. + Requiring these fetches just to determine whether the MIME type is + XML could have significant bandwidth and latency disadvantages in + many situations. + + Sniffing XML also isn't as simple as it might seem. DOCTYPE + declarations aren't required, and they can appear fairly deep into a + document under certain unpreventable circumstances. (E.g., the XML + declaration, comments, and processing instructions can occupy space + before the DOCTYPE declaration.) Even sniffing the DOCTYPE isn't + completely reliable, thanks to a variety of issues involving default + values for namespaces within external DTDs and overrides inside the + internal DTD. Finally, the variety in potential character encodings + (something XML provides tools to deal with), also makes reliable + sniffing less likely. + +A.5 Why not use a MIME parameter to specify that a media type uses XML + syntax? + + For example, one could use "Content-Type: application/iotp; + alternate-type=text/xml" or "Content-Type: application/iotp; + syntax=xml". + + Section 5 of [RFC2045] says that "Parameters are modifiers of the + media subtype, and as such do not fundamentally affect the nature of + the content". However, all XML-based media types are by their nature + + + + +Murata, et al. Standards Track [Page 33] + +RFC 3023 XML Media Types January 2001 + + + always XML. Parameters, as they have been defined in the MIME + architecture, are never invariant across all instantiations of a + media type. + + More practically, very few if any MIME dispatchers and other MIME + agents support dispatching off of a parameter. While MIME agents on + the receiving side will need to be updated in either case to support + (or fall back to) generic XML processing, it has been suggested that + it is easier to implement this functionality when acting off of the + media type rather than a parameter. More important, sending agents + require no update to properly tag an image as "image/svg+xml", but + few if any sending agents currently support always tagging certain + content types with a parameter. + +A.6 How about labeling with parameters in the other direction (e.g., + application/xml; Content-Feature=iotp)? + + This proposal fails under the simplest case, of a user with neither + knowledge of XML nor an XML-capable MIME dispatcher. In that case, + the user's MIME dispatcher is likely to dispatch the content to an + XML processing application when the correct default behavior should + be to dispatch the content to the application responsible for the + content type (e.g., an ecommerce engine for + application/iotp+xml[RFC2801], once this media type is registered). + + Note that even if the user had already installed the appropriate + application (e.g., the ecommerce engine), and that installation had + updated the MIME registry, many operating system level MIME + registries such as .mailcap in Unix and HKEY_CLASSES_ROOT in Windows + do not currently support dispatching off a parameter, and cannot + easily be upgraded to do so. And, even if the operating system were + upgraded to support this, each MIME dispatcher would also separately + need to be upgraded. + +A.7 How about a new superclass MIME parameter that is defined to apply + to all MIME types (e.g., Content-Type: application/iotp; + $superclass=xml)? + + This combines the problems of Appendix A.5 and Appendix A.6. + + If the sender attaches an image/svg+xml file to a message and + includes the instructions "Please copy the French text on the road + sign", someone with an XML-aware MIME client and an XML browser but + no support for SVG can still probably open the file and copy the + text. By contrast, with superclasses, the sender must add superclass + support to her existing mailer AND the receiver must add superclass + support to his before this transaction can work correctly. + + + + +Murata, et al. Standards Track [Page 34] + +RFC 3023 XML Media Types January 2001 + + + If the receiver comes to rely on the superclass tag being present and + applications are deployed relying on that tag (as always seems to + happen), then only upgraded senders will be able to interoperate with + those receiving applications. + +A.8 What about adding a new parameter to the Content-Disposition header + or creating a new Content-Structure header to indicate XML syntax? + + This has nearly identical problems to Appendix A.7, in that it + requires both senders and receivers to be upgraded, and few if any + operating systems and MIME dispatchers support working off of + anything other than the MIME type. + +A.9 How about a new Alternative-Content-Type header? + + This is better than Appendix A.8, in that no extra functionality + needs to be added to a MIME registry to support dispatching of + information other than standard content types. However, it still + requires both sender and receiver to be upgraded, and it will also + fail in many cases (e.g., web hosting to an outsourced server), where + the user can set MIME types (often through implicit mapping to file + extensions), but has no way of adding arbitrary HTTP headers. + +A.10 How about using a conneg tag instead (e.g., accept-features: + (syntax=xml))? + + When the conneg protocol is fully defined, this may potentially be a + reasonable thing to do. But given the limited current state of + conneg[RFC2703] development, it is not a credible replacement for a + MIME-based solution. + +A.11 How about a third-level content-type, such as text/xml/rdf? + + MIME explicitly defines two levels of content type, the top-level for + the kind of content and the second-level for the specific media type. + [RFC2048] extends this in an interoperable way by using prefixes to + specify separate trees for IETF, vendor, and personal registrations. + This specification also extends the two-level type by using the ' + +xml' suffix. In both cases, processors that are unaware of these + later specifications treat them as opaque and continue to + interoperate. By contrast, adding a third-level type would break the + current MIME architecture and cause numerous interoperability + failures. + + + + + + + + +Murata, et al. Standards Track [Page 35] + +RFC 3023 XML Media Types January 2001 + + +A.12 Why use the plus ('+') character for the suffix '+xml'? + + As specified in Section 5.1 of [RFC2045], a tspecial can't be used: + + tspecials := + "(" / ")" / "<" / ">" / "@" / + "," / ";" / ":" / "\" / <"> + "/" / "[" / "]" / "?" / "=" + + It was thought that "." would not be a good choice since it is + already used as an additional hierarchy delimiter. Also, "*" has a + common wildcard meaning, and "-" and "_" are common word separators + and easily confused. The characters %'`#& are frequently used for + quoting or comments and so are not ideal. + + That leaves: ~!$^+{}| + + Note that "-" is used heavily in the current registry. "$" and "_" + are used once each. The others are currently unused. + + It was thought that '+' expressed the semantics that a MIME type can + be treated (for example) as both scalable vector graphics AND ALSO as + XML; it is both simultaneously. + +A.13 What is the semantic difference between application/foo and + application/foo+xml? + + MIME processors that are unaware of XML will treat the '+xml' suffix + as completely opaque, so it is essential that no extra semantics be + assigned to its presence. Therefore, application/foo and + application/foo+xml SHOULD be treated as completely independent media + types. Although, for example, text/calendar+xml could be an XML + version of text/calendar[RFC2445], it is possible that this + (hypothetical) new media type would include new semantics as well as + new syntax, and in any case, there would be many applications that + support text/calendar but had not yet been upgraded to support + text/calendar+xml. + +A.14 What happens when an even better markup language (e.g., EBML) is + defined, or a new category of data? + + In the ten years that MIME has existed, XML is the first generic data + format that has seemed to justify special treatment, so it is hoped + that no further suffixes will be necessary. However, if some are + later defined, and these documents were also XML, they would need to + specify that the '+xml' suffix is always the outermost suffix (e.g., + + + + + +Murata, et al. Standards Track [Page 36] + +RFC 3023 XML Media Types January 2001 + + + application/foo+ebml+xml not application/foo+xml+ebml). If they were + not XML, then they would use a regular suffix (e.g., + application/foo+ebml). + +A.15 Why must I use the '+xml' suffix for my new XML-based media type? + + You don't have to, but unless you have a good reason to explicitly + disallow generic XML processing, you should use the suffix so as not + to curtail the options of future users and developers. + + Whether the inventors of a media type, today, design it for dispatch + to generic XML processing machinery (and most won't) is not the + critical issue. The core notion is that the knowledge that some + media type happens to use XML syntax opens the door to unanticipated + kinds of processing beyond those envisioned by its inventors, and on + this basis identifying such encoding is a good and useful thing. + + Developers of new media types are often tightly focused on a + particular type of processing that meets current needs. But there is + no need to rule out generic processing as well, which could make your + media type more valuable over time. It is believed that registering + with the '+xml' suffix will cause no interoperability problems + whatsoever, while it may enable significant new functionality and + interoperability now and in the future. So, the conservative + approach is to include the '+xml' suffix. + +Appendix B. Changes from RFC 2376 + + There are numerous and significant differences between this + specification and [RFC2376], which it obsoletes. This appendix + summarizes the major differences only. + + First, text/xml-external-parsed-entity and application/xml-external- + parsed-entity are added as media types for external parsed entities, + and text/xml and application/xml are now prohibited. + + Second, application/xml-dtd is added as a media type for external DTD + subsets and external parameter entities, and text/xml and + application/xml are now prohibited. + + Third, "utf-16le" and "utf-16be" are added. RFC 2781 has introduced + these BOM-less variations of the UTF-16 family. + + Fourth, a naming convention ('+xml') for XML-based media types has + been added, which also updates [RFC2048] as described in Section 7. + By following this convention, an XML-based media type can be easily + recognized as such. + + + + +Murata, et al. Standards Track [Page 37] + +RFC 3023 XML Media Types January 2001 + + +Appendix C. Acknowledgements + + This document reflects the input of numerous participants to the + ietf-xml-mime@imc.org mailing list, though any errors are the + responsibility of the authors. Special thanks to: + + Mark Baker, James Clark, Dan Connolly, Martin Duerst, Ned Freed, + Yaron Goland, Rick Jelliffe, Larry Masinter, David Megginson, Keith + Moore, Chris Newman, Gavin Nicol, Marshall Rose, Jim Whitehead and + participants of the XML activity at the W3C. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Murata, et al. Standards Track [Page 38] + +RFC 3023 XML Media Types January 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Murata, et al. Standards Track [Page 39] + diff --git a/Documentation/en/rfc/rfc3090.txt b/Documentation/en/rfc/rfc3090.txt new file mode 100644 index 00000000..08008f7a --- /dev/null +++ b/Documentation/en/rfc/rfc3090.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group E. Lewis +Request for Comments: 3090 NAI Labs +Category: Standards Track March 2001 + + + DNS Security Extension Clarification on Zone Status + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The definition of a secured zone is presented, clarifying and + updating sections of RFC 2535. RFC 2535 defines a zone to be secured + based on a per algorithm basis, e.g., a zone can be secured with RSA + keys, and not secured with DSA keys. This document changes this to + define a zone to be secured or not secured regardless of the key + algorithm used (or not used). To further simplify the determination + of a zone's status, "experimentally secure" status is deprecated. + +1 Introduction + + Whether a DNS zone is "secured" or not is a question asked in at + least four contexts. A zone administrator asks the question when + configuring a zone to use DNSSEC. A dynamic update server asks the + question when an update request arrives, which may require DNSSEC + processing. A delegating zone asks the question of a child zone when + the parent enters data indicating the status the child. A resolver + asks the question upon receipt of data belonging to the zone. + +1.1 When a Zone's Status is Important + + A zone administrator needs to be able to determine what steps are + needed to make the zone as secure as it can be. Realizing that due + to the distributed nature of DNS and its administration, any single + zone is at the mercy of other zones when it comes to the appearance + of security. This document will define what makes a zone qualify as + secure. + + + + +Lewis Standards Track [Page 1] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + + A name server performing dynamic updates needs to know whether a zone + being updated is to have signatures added to the updated data, NXT + records applied, and other required processing. In this case, it is + conceivable that the name server is configured with the knowledge, + but being able to determine the status of a zone by examining the + data is a desirable alternative to configuration parameters. + + A delegating zone is required to indicate whether a child zone is + secured. The reason for this requirement lies in the way in which a + resolver makes its own determination about a zone (next paragraph). + To shorten a long story, a parent needs to know whether a child + should be considered secured. This is a two part question. Under + what circumstances does a parent consider a child zone to be secure, + and how does a parent know if the child conforms? + + A resolver needs to know if a zone is secured when the resolver is + processing data from the zone. Ultimately, a resolver needs to know + whether or not to expect a usable signature covering the data. How + this determination is done is out of the scope of this document, + except that, in some cases, the resolver will need to contact the + parent of the zone to see if the parent states that the child is + secured. + +1.2 Islands of Security + + The goal of DNSSEC is to have each zone secured, from the root zone + and the top-level domains down the hierarchy to the leaf zones. + Transitioning from an unsecured DNS, as we have now, to a fully + secured - or "as much as will be secured" - tree will take some time. + During this time, DNSSEC will be applied in various locations in the + tree, not necessarily "top down." + + For example, at a particular instant, the root zone and the "test." + TLD might be secured, but region1.test. might not be. (For + reference, let's assume that region2.test. is secured.) However, + subarea1.region1.test. may have gone through the process of becoming + secured, along with its delegations. The dilemma here is that + subarea1 cannot get its zone keys properly signed as its parent zone, + region1, is not secured. + + The colloquial phrase describing the collection of contiguous secured + zones at or below subarea1.region1.test. is an "island of security." + The only way in which a DNSSEC resolver will come to trust any data + from this island is if the resolver is pre-configured with the zone + key(s) for subarea1.region1.test., i.e., the root of the island of + security. Other resolvers (not so configured) will recognize this + island as unsecured. + + + + +Lewis Standards Track [Page 2] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + + An island of security begins with one zone whose public key is pre- + configured in resolvers. Within this island are subzones which are + also secured. The "bottom" of the island is defined by delegations + to unsecured zones. One island may also be on top of another - + meaning that there is at least one unsecured zone between the bottom + of the upper island and the root of the lower secured island. + + Although both subarea1.region1.test. and region2.test. have both been + properly brought to a secured state by the administering staff, only + the latter of the two is actually "globally" secured - in the sense + that all DNSSEC resolvers can and will verify its data. The former, + subarea1, will be seen as secured by a subset of those resolvers, + just those appropriately configured. This document refers to such + zones as being "locally" secured. + + In RFC 2535, there is a provision for "certification authorities," + entities that will sign public keys for zones such as subarea1. + There is another document, [RFC3008], that restricts this activity. + Regardless of the other document, resolvers would still need proper + configuration to be able to use the certification authority to verify + the data for the subarea1 island. + +1.2.1 Determining the closest security root + + Given a domain, in order to determine whether it is secure or not, + the first step is to determine the closest security root. The + closest security root is the top of an island of security whose name + has the most matching (in order from the root) right-most labels to + the given domain. + + For example, given a name "sub.domain.testing.signed.exp.test.", and + given the secure roots "exp.test.", "testing.signed.exp.test." and + "not-the-same.xy.", the middle one is the closest. The first secure + root shares 2 labels, the middle 4, and the last 0. + + The reason why the closest is desired is to eliminate false senses of + insecurity because of a NULL key. Continuing with the example, the + reason both "testing..." and "exp.test." are listed as secure root is + presumably because "signed.exp.test." is unsecured (has a NULL key). + If we started to descend from "exp.test." to our given domain + (sub...), we would encounter a NULL key and conclude that sub... was + unsigned. However, if we descend from "testing..." and find keys + "domain...." then we can conclude that "sub..." is secured. + + Note that this example assumes one-label deep zones, and assumes that + we do not configure overlapping islands of security. To be clear, + the definition given should exclude "short.xy.test." from being a + closest security root for "short.xy." even though 2 labels match. + + + +Lewis Standards Track [Page 3] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + + Overlapping islands of security introduce no conceptually interesting + ideas and do not impact the protocol in anyway. However, protocol + implementers are advised to make sure their code is not thrown for a + loop by overlaps. Overlaps are sure to be configuration problems as + islands of security grow to encompass larger regions of the name + space. + +1.3 Parent Statement of Child Security + + In 1.1 of this document, there is the comment "the parent states that + the child is secured." This has caused quite a bit of confusion. + + The need to have the parent "state" the status of a child is derived + from the following observation. If you are looking to see if an + answer is secured, that it comes from an "island of security" and is + properly signed, you must begin at the (appropriate) root of the + island of security. + + To find the answer you are inspecting, you may have to descend + through zones within the island of security. Beginning with the + trusted root of the island, you descend into the next zone down. As + you trust the upper zone, you need to get data from it about the next + zone down, otherwise there is a vulnerable point in which a zone can + be hijacked. When or if you reach a point of traversing from a + secured zone to an unsecured zone, you have left the island of + security and should conclude that the answer is unsecured. + + However, in RFC 2535, section 2.3.4, these words seem to conflict + with the need to have the parent "state" something about a child: + + There MUST be a zone KEY RR, signed by its superzone, for every + subzone if the superzone is secure. This will normally appear in + the subzone and may also be included in the superzone. But, in + the case of an unsecured subzone which can not or will not be + modified to add any security RRs, a KEY declaring the subzone to + be unsecured MUST appear with the superzone signature in the + superzone, if the superzone is secure. + + The confusion here is that in RFC 2535, a secured parent states that + a child is secured by SAYING NOTHING ("may also be" as opposed to + "MUST also be"). This is counter intuitive, the fact that an absence + of data means something is "secured." This notion, while acceptable + in a theoretic setting has met with some discomfort in an operation + setting. However, the use of "silence" to state something does + indeed work in this case, so there hasn't been sufficient need + demonstrated to change the definition. + + + + + +Lewis Standards Track [Page 4] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +1.4 Impact on RFC 2535 + + This document updates sections of RFC 2535. The definition of a + secured zone is an update to section 3.4 of the RFC. Section 3.4 is + updated to eliminate the definition of experimental keys and + illustrate a way to still achieve the functionality they were + designed to provide. Section 3.1.3 is updated by the specifying the + value of the protocol octet in a zone key. + +1.5 "MUST" and other key words + + The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" + in this document are to be interpreted as described in [RFC 2119]. + Currently, only "MUST" is used in this document. + +2 Status of a Zone + + In this section, rules governing a zone's DNSSEC status are + presented. There are three levels of security defined: global, + local, and unsecured. A zone is globally secure when it complies + with the strictest set of DNSSEC processing rules. A zone is locally + secured when it is configured in such a way that only resolvers that + are appropriately configured see the zone as secured. All other + zones are unsecured. + + Note: there currently is no document completely defining DNSSEC + verification rules. For the purposes of this document, the strictest + rules are assumed to state that the verification chain of zone keys + parallels the delegation tree up to the root zone. (See 2.b below.) + This is not intended to disallow alternate verification paths, just + to establish a baseline definition. + + To avoid repetition in the rules below, the following terms are + defined. + + 2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01 + for name type (indicating a zone key) and either value 00 or value 01 + for key type (indicating a key permitted to authenticate data). (See + RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value + of DNSSEC (3) or ALL (255). + + The definition updates RFC 2535's definition of a zone key. The + requirement that the protocol field be either DNSSEC or ALL is a new + requirement (a change to section 3.1.3.) + + 2.b On-tree Validation - The authorization model in which only the + parent zone is recognized to supply a DNSSEC-meaningful signature + that is used by a resolver to build a chain of trust from the child's + + + +Lewis Standards Track [Page 5] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + + keys to a recognized root of security. The term "on-tree" refers to + following the DNS domain hierarchy (upwards) to reach a trusted key, + presumably the root key if no other key is available. The term + "validation" refers to the digital signature by the parent to prove + the integrity, authentication and authorization of the child's key to + sign the child's zone data. + + 2.c Off-tree Validation - Any authorization model that permits domain + names other than the parent's to provide a signature over a child's + zone keys that will enable a resolver to trust the keys. + +2.1 Globally Secured + + A globally secured zone, in a nutshell, is a zone that uses only + mandatory to implement algorithms (RFC 2535, section 3.2) and relies + on a key certification chain that parallels the delegation tree (on- + tree validation). Globally secured zones are defined by the + following rules. + + 2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at + least one zone signing KEY RR (2.a) of a mandatory to implement + algorithm in the set. + + 2.1.b. The zone's apex KEY RR set MUST be signed by a private key + belonging to the parent zone. The private key's public companion + MUST be a zone signing KEY RR (2.a) of a mandatory to implement + algorithm and owned by the parent's apex. + + If a zone cannot get a conforming signature from the parent zone, the + child zone cannot be considered globally secured. The only exception + to this is the root zone, for which there is no parent zone. + + 2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies + RFC 2535, section 2.3.2.) Note: there is some operational discomfort + with the current NXT record. This requirement is open to + modification when two things happen. First, an alternate mechanism + to the NXT is defined and second, a means by which a zone can + indicate that it is using an alternate method. + + 2.1.d. Each RR set that qualifies for zone membership MUST be signed + by a key that is in the apex's KEY RR set and is a zone signing KEY + RR (2.a) of a mandatory to implement algorithm. (Updates 2535, + section 2.3.1.) + + Mentioned earlier, the root zone is a special case. The root zone + will be considered to be globally secured provided that if conforms + to the rules for locally secured, with the exception that rule 2.1.a. + be also met (mandatory to implement requirement). + + + +Lewis Standards Track [Page 6] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +2.2 Locally Secured + + The term "locally" stems from the likely hood that the only resolvers + to be configured for a particular zone will be resolvers "local" to + an organization. + + A locally secured zone is a zone that complies with rules like those + for a globally secured zone with the following exceptions. The + signing keys may be of an algorithm that is not mandatory to + implement and/or the verification of the zone keys in use may rely on + a verification chain that is not parallel to the delegation tree + (off-tree validation). + + 2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at + least one zone signing KEY RR (2.a) in the set. + + 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and + one of the following two subclauses MUST hold true. + + 2.2.b.1 The private key's public companion MUST be pre-configured in + all the resolvers of interest. + + 2.2.b.2 The private key's public companion MUST be a zone signing KEY + RR (2.a) authorized to provide validation of the zone's apex KEY RR + set, as recognized by resolvers of interest. + + The previous sentence is trying to convey the notion of using a + trusted third party to provide validation of keys. If the domain + name owning the validating key is not the parent zone, the domain + name must represent someone the resolver trusts to provide + validation. + + 2.2.c. NXT records MUST be deployed throughout the zone. Note: see + the discussion following 2.1.c. + + 2.2.d. Each RR set that qualifies for zone membership MUST be signed + by a key that is in the apex's KEY RR set and is a zone signing KEY + RR (2.a). (Updates 2535, section 2.3.1.) + +2.3 Unsecured + + All other zones qualify as unsecured. This includes zones that are + designed to be experimentally secure, as defined in a later section + on that topic. + + + + + + + +Lewis Standards Track [Page 7] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +2.4 Wrap up + + The designation of globally secured, locally secured, and unsecured + are merely labels to apply to zones, based on their contents. + Resolvers, when determining whether a signature is expected or not, + will only see a zone as secured or unsecured. + + Resolvers that follow the most restrictive DNSSEC verification rules + will only see globally secured zones as secured, and all others as + unsecured, including zones which are locally secured. Resolvers that + are not as restrictive, such as those that implement algorithms in + addition to the mandatory to implement algorithms, will see some + locally secured zones as secured. + + The intent of the labels "global" and "local" is to identify the + specific attributes of a zone. The words are chosen to assist in the + writing of a document recommending the actions a zone administrator + take in making use of the DNS security extensions. The words are + explicitly not intended to convey a state of compliance with DNS + security standards. + +3 Experimental Status + + The purpose of an experimentally secured zone is to facilitate the + migration from an unsecured zone to a secured zone. This distinction + is dropped. + + The objective of facilitating the migration can be achieved without a + special designation of an experimentally secure status. + Experimentally secured is a special case of locally secured. A zone + administrator can achieve this by publishing a zone with signatures + and configuring a set of test resolvers with the corresponding public + keys. Even if the public key is published in a KEY RR, as long as + there is no parent signature, the resolvers will need some pre- + configuration to know to process the signatures. This allows a zone + to be secured with in the sphere of the experiment, yet still be + registered as unsecured in the general Internet. + +4 IANA Considerations + + This document does not request any action from an assigned number + authority nor recommends any actions. + + + + + + + + + +Lewis Standards Track [Page 8] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +5 Security Considerations + + Without a means to enforce compliance with specified protocols or + recommended actions, declaring a DNS zone to be "completely" secured + is impossible. Even if, assuming an omnipotent view of DNS, one can + declare a zone to be properly configured for security, and all of the + zones up to the root too, a misbehaving resolver could be duped into + believing bad data. If a zone and resolver comply, a non-compliant + or subverted parent could interrupt operations. The best that can be + hoped for is that all parties are prepared to be judged secure and + that security incidents can be traced to the cause in short order. + +6 Acknowledgements + + The need to refine the definition of a secured zone has become + apparent through the efforts of the participants at two DNSSEC + workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA- + funded research network), and other workshops. Further discussions + leading to the document include Olafur Gudmundsson, Russ Mundy, + Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen and + others have contributed significant input via the namedroppers + mailing list. + +7 References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System", RFC 2136, + April 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) + Dynamic Update", RFC 3007, November 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + + + + +Lewis Standards Track [Page 9] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +10 Author's Address + + Edward Lewis + NAI Labs + 3060 Washington Road Glenwood + MD 21738 + + Phone: +1 443 259 2352 + EMail: lewis@tislabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lewis Standards Track [Page 10] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +11 Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Lewis Standards Track [Page 11] + diff --git a/Documentation/en/rfc/rfc724.txt b/Documentation/en/rfc/rfc724.txt new file mode 100644 index 00000000..ff6b1239 --- /dev/null +++ b/Documentation/en/rfc/rfc724.txt @@ -0,0 +1,1869 @@ + + + + + RFC # 724 + NIC #37435 12 May 1977 + + + + + + + + + + + + + Proposed Official Standard for the + Format of ARPA Network Messages + + + + + + + + + + + by + + + Ken Pogran, MIT-LCS/CSR (Pogran at MIT-Multics) + John Vittal, BBN (Vittal at BBN-TENEXA) + Dave Crocker, RAND-ISD (DCrocker at Rand-Unix) + Austin Henderson, BBN (Henderson at BBN-TENEXD) + + + + Proposed Standard for Message Format / ii + + + + + + PREFACE + + + + ARPA's Committee on Computer-Aided Human Communication + (CAHCOM) wishes to promulgate an official standard for the format + of ARPA Network mail headers which will adequately meet the needs + of the various message service subsystems on the Network today. + The authors of this RFC constitute the CAHCOM subcommittee + charged with the task of developing this new standard; this + document presents our current thoughts on the matter and a + specific proposal. + + This document is organized as follows: First, we present a + history, of the development of what has become known as the ARPA + Network "mail" or "message" service, and the issues which we feel + are most pressing -- problems for which solutions are lacking + today, inhibiting the further development of message subsystems. + We then present the specification for the new ARPA Network + Message Header standard. This is followed by a References + section. + + Essentially, we propose a revision to Request for Comments + (RFC) 561, "Standardizing Network Mail Headers", and RFC 680, + "Message Transmission Protocol". This revision removes and + compacts portions of the previous syntax and adds several + features to network address specification. In particular, we + focus on people and not mailboxes as recipients and allow + reference to stored address lists. We expect this syntax to + provide sufficient capabilities to meet most users' immediate + needs and, therefore, give developers enough breathing room to + produce a new mail transmission protocol "properly". We believe + that there is enough of a consensus in the Network community in + favor of such a standard syntax to make possible its adoption at + this time. + + We would like to make clear the status of this proposed + standard: The CAHCOM Steering Committee has replaced the Message + Service Committee as the ARPANET standards-setting organization + in the area of message services. It is expected that the + proposal of this CAHCOM subcommittee, when in its final form, + will be adopted as an ARPANET standard by CAHCOM. In the + interests of making this standard the best possible one, we are + distributing this proposal as an RFC. + + Please send any comments and criticisms to any of the + authors of this RFC by 15 June 1977. It is planned that the + standard will be officially adopted by 1 September 1977, with + hosts expected to accept its syntax by 1 January 1978. + + + + Proposed Standard for Message Format / iii + + + + + + + + + + + + CONTENTS + + + + I. PROBLEMS WITH ARPANET + MESSAGE STANDARDS + + A. Background and History + B. Issues and Conclusions + C. Message Parts + D. Adoption of the Standard + + + + II. STANDARD FOR THE FORMAT + OF ARPA NETWORK MESSAGES + + A. Framework + B. Syntax + C. Semantics + D. Examples + + + + III. REFERENCES + + + + + APPENDIX + + A. Alphabetical Listing of Syntax Rules + + + + I. Problems with ARPANET Message Standards / 1 + A. Background and History + + + + + + I. PROBLEMS WITH ARPANET MESSAGE STANDARDS + + + + A. BACKGROUND AND HISTORY + + + Today's ARPA Network "mail" or "message" service uses, for + its delivery mechanism, two special commands of the File Transfer + Protocol. Viewed from within the structure of FTP, the entire + message, both header and text, is data for the FTP MAIL and MLFL + commands. This facility was added to the File Transfer Protocol + as an afterthought; it was an interim solution to be used only + until a separate mail transmission protocol was specified. + Several versions of such a protocol have been proposed, but none + has yet received general acceptance. Meanwhile, attempts have + been made to improve upon the original interim facility. + + As message service subsystems on various host systems + (especially TENEX) developed to the point where rudimentary + parsing of incoming messages was being done, it became clear that + it would be desirable to standardize the format and content of + the headers of messages transmitted between hosts using these FTP + commands. To this end, an ad hoc committee wrote RFC 561, which + suggested a standard message header format. The committee was + unofficial, so it could not legislate a standard, it could only + recommend. However, the standard it suggested adequately met an + urgent need, and was generally adopted. + + Several salient points should be noted: + + 1. RFC 561 defined the concept of a message header, and + specified the syntax which delimited it from the actual + text of a message; + + 2. It proposed a standard format for the most obvious and + most urgently-needed header items: "From:", "Date:", and + "Subject:"; + + 3. It proposed that a general standard syntax be used for + all other header items; + + 4. RFC 561 is still, today, an unofficial standard, adhered + to by most because of its utility; + + 5. Its syntax was designed to allow humans to read the text + easily, without the aid of special message processing + systems. + + + + I. Problems with ARPANET Message Standards / 2 + A. Background and History + + + + As message services grew in sophistication, the need for + specific header items in RFC 561's "miscellaneous" category grew: + "To:" and "cc:", especially, were generated and recognized by + several different message services. However, there was no + specific standard for the syntax of the contents of these items. + The message service subsystems on TENEX developed a particular + format for these items; since more messages originated from the + TENEX hosts on the Network than from any other type of host + system, the TENEX format for these fields soon became a de facto + standard. Message service subsystems on TENEX began to parse + these fields, expecting them to be in the TENEX-generated format. + Message service subsystems on other hosts -- Multics, for example + -- began to dabble with other formats for these fields, since + there was no standard for them, only to receive complaints from + users of TENEX message service subsystems that their "non- + standard" message headers could not be parsed according to the + (de facto) "standard" syntax. + + Recognizing that the time had come to make an attempt to + standardize the additional header fields that had come into use + since RFC 561 was published, ARPA's Message Service Committee + chartered a small group in 1975 to develop a revised version of + RFC 561 which would define the syntax of these additional message + header fields. Several things should be noted about this small + group of people: first, they were TENEX-oriented; when the + functionality of the message header items they desired was + matched by the functionality of an already-existing message + header item of the TENEX message subsystems, they adopted the + syntax used by the TENEX message subsystems. Second, they based + additional header items not already found on TENEX message + subsystems on the deliberations of the Message Service Committee. + Third, they were not familiar with the procedure for publication + of a document as a Network RFC. + + The document which this group produced, labelled RFC 680, + "Message Transmission Protocol", received only limited + distribution. Matters were further confused because its title + was misleading, since it was not a protocol for the transmission + of messages between ARPA Network hosts, but rather a standard for + the format of messages transmitted via the standard File Transfer + Protocol. Some, including the Message Service Committee, + believed that RFC 680 became a Network Standard. This was not + strictly true, because it never received proper distribution, and + it had never been "officially blessed" by anyone, to turn it from + a request for comments into an accepted official ARPA Network + standard document. Reflecting this confusion over the status of + the document are the facts that the document DOES currently + reside in the "official" ARPANET Protocol Handbook, and most + users and message system implementors remain unaware that this is + so. + + + + I. Problems with ARPANET Message Standards / 3 + A. Background and History + + + + For all its shortcomings, RFC 680 has performed a needed + service, just as did RFC 561 before it. It defined additional + message header items at a time when this needed to be done. + Unfortunately, since the group had not sought ideas and input + from others, the specification did not adequately respond to a + sufficient set of community needs. In addition, the manner in + which the document was promulgated -- or not promulgated -- left + a great deal to be desired. Implementators of message-processing + subsystems who had not received RFC 680 proceeded to go their own + ways, feeling justified in doing so, while those who accepted RFC + 680 as a standard felt justified in complaining to -- and about + -- those whom they considered to be maverick implementors of + idiosyncratic message service subsystems. + + Perhaps because of the ad-hoc nature of the interim mail + facility, users have not, until recently, attempted to push the + system to the limits of their imagination. Presently, however, + several different sites are using the "interim" mail facility for + more than it was designed and in ways which are incompatible both + with each other and with the original intent of the facility. + Mail subsystem implementors are increasingly being asked to + provide for the handling of mail from idiosyncratic hosts. Also, + it has become clear that there are a few very specific features, + too useful to ignore, which cannot reasonably be specified within + the syntax of RFC 680. + + + + B. ISSUES AND CONCLUSIONS + + + At first glance, it would seem that a resolution of today's + somewhat chaotic situation could best be obtained by immediately + junking the existing "interim" mail facility, and adopting a true + mail transmission protocol. We strongly believe that this would + be ill-advised at this time, for we feel that there is no general + understanding within the Network community today of how to + specify and implement a full and adequate mail transmission + protocol. However, we are convinced that there is, finally, a + strong commitment within the Network community to attack this + problem (which there was not at the time the "interim" mail + transmission facility was specified and developed). + + The frontal attacks on the mail protocol problem have, so + far, resulted in at least two suggestions for a mail transmission + protocol. Why should not one of these protocols be adopted + immediately? We feel that, in general, there has been a tendency + for experimental Network software to be prematurely treated as + though it were adequately designed and fully operational. + Typically, the system or protocol proposed is so much better than + what was previously available that its experimental nature is + disregarded, and it is pressed into service before it has had a + + + I. Problems with ARPANET Message Standards / 4 + B. Issues and Conclusions + + + + chance to properly develop and mature. We are very concerned + that this phenomenon not afflict the Network mail system any more + than it already has. + + While it is true that there are several sites in the ARPA + Community which have mail systems that understand the syntax + specified in RFC's 561 and 680, in addition to some of the "non- + standard" syntax provided by the mail generating programs at + several other sites, most mail systems do not parse much of the + contents of received messages. A consideration of the syntax + specified here is that messages which are sent to people should + be easily read by people. Parsers which can turn an ugly, + syntactically expedient form into something which is easy to read + are the exception, rather than the rule, in today's message + systems. Also, the modifications to the existing "non-standard" + syntax should be kept to a minimum, enhancing the probability + that the requirement of small perturbations to existing software + will be accepted. + + With this syntax, we introduce mechanisms so that: + + 1. Users of mail systems can have multiple mailboxes, either + on one machine or multiple machines, all of which are + treated identically; the default mailbox for a user is + not necessarily associated (directly) with his login + name. + + 2. Mail for a person can be sent to other than a single, + default mailbox. + + 3. Named groups may consist of both individuals and + (possibly) other named groups (i.e., nesting within + groups is permitted). + + 4. Address lists may contain references to other, stored, + lists. The complete path with which one can retrieve the + stored list may be specified in order to allow either + manual or automatic retrieval of the stored list. + + 5. Address lists may contain references to addresses which + are not accessible through the standard ARPANET message + system. For example, U.S. Postal system addresses can + be specified. Such addresses are, of course, expected to + be ignored by the ARPANET system, although individual + sites may provide services for using the information + (e.g., automatically sending a copy of the message to a + line printer, in preparation for transmission through the + Postal system). + + 6. Parenthetical remarks, or comments, can be included and + syntactically recognized as such within some header + items. + + + I. Problems with ARPANET Message Standards / 5 + B. Issues and Conclusions + + + + 7. Received messages are capable of being read by humans + without a program having to parse the message (or parts + of it) before presenting the message to the user; however + there is sufficient formal syntax to enable a parsing + program to modify the appearance and content of material + presented to users. Although message-display software + may exercise considerable control over message + appearance, the degree to which a message's actual format + is PLEASANT for humans to read is entirely the + responsibility of the message creation program. + + No mechanism for authentication is provided, since the Network + provides no mechanisms for enforcing mail security. The syntax + does provide for one aspect of "correctness": a distinction is + made between an address which is claimed to be a valid network + address and one which is simply free text, included for the + convenience of the human participants. + + + + + C. MESSAGE PARTS + + Some confusion has existed over the roles played by + different message parts. Einar Stefferud has suggested using the + perspective of envelope, letter head, and letter content. The + presence of structured portions in messages additionally requires + reference to "headers". + + In computer-based message systems, human users do not + generally encounter "envelopes", which are often constructed + automatically, to be used by the participating system(s) to + deliver the message. For example on TENEX, the envelope is the + name of the file containing a message awaiting transmission. For + FTP servers, it is the data portion of the MAIL or MLFL command + line. Some systems attach "envelope-like" information to the + message header, such as time-stamp and originating host name. + + In paper-based communications, headers occur both before + (e.g., "To:" and "From:" and after (e.g., "cc:" and "enclosure:") + the body of the message. Within this standard, all headers occur + before the body of the message, although local message display + programs may choose to alter that ordering. + + Wayne Hathaway has pointed out that ARPANET message format + does not support specification of letterheads, since these are a + type of organizational public relations symbol. Some + idiosyncrasies are supported, however, by way of choosing special + field names. + + In general, it is important to realize that the header + portion of a message plays several roles during the life of a + + + I. Problems with ARPANET Message Standards / 6 + C. Message Parts + + + + message, variously participating in each of the three functions + suggested by Stefferud. + + + + D. ADOPTION OF THE STANDARD + + + During the early phases of specifying this standard, a great + deal of concern was expressed over the problems which may be + experienced during the transition from the current standard to + this new one. We feel that the true problem is the lack of + realization that THERE IS NO CURRENT OFFICIAL STANDARD. Enough + systems have enough overlapping behaviors to allow the current + mail environment to function, but this in no way constitutes a + standard. + + In fact, we strongly believe that the new requirements + imposed by the proposed standard involve less complexity than the + ambiguities resulting from the current variations in system + behaviors. + + + + II. Standard for the Format of Messages / 7 + + + + + + + + II. STANDARD FOR THE FORMAT + OF ARPA NETWORK MESSAGES + + + + This standard supercedes the informal standards specified in + ARPANET Request for Comments numbers 561, "Standardizing Network + Mail Headers", and 680, "Message Transmission Protocol". In this + document, a general framework is described. The formal syntax is + then specified, followed by a discussion of the semantics. + Finally, a number of examples are given. + + This specification is intended strictly as a definition of + what is to be passed between hosts on the ARPANET. It is NOT + intended to dictate either features which systems on the Network + are expected to support, or user interfaces to message creating + or reading programs. + + A distinction should be made between what the specification + requires and what it allows. Certain equivalences are defined, + such as between a space character <space> and an end-of-line + character <crlf>, which both facilitate the formal specification + and indicate what the OFFICIAL semantics are for messages. + Particular implementations may wish to preserve further + distinctions which the specification does not require. + + + + A. FRAMEWORK + + + Since there are many message systems which exist outside the + ARPANET environment, as well as those within it, it may be useful + to consider the general framework, and resulting capabilities and + limitations, of this standard. + + Messages are expected to consist of lines of text. No + special provisions are made, at this time, for encoding drawings, + facimile, speech, or structured text. + + No significant consideration has been given to questions of + data compression or transmission/storage efficiency. The + standard, in fact, tends to be very free with the number of bits + consumed. For example, field names are specified as free text, + rather than special terse codes. + + A general "memo" framework is used. That is, a message + consists of some information, in a rigid format, followed by the + main part of the message, which is text and whose format is not + + + II. Standard for the Format of Messages / 8 + A. Framework + + + + specified in this document. The syntax of several fields of the + rigidly-formated ("header") section is defined in this + specification; some of the header fields must be included in all + messages. In addition to the fields specified in this document, + it is expected that other fields will gain common use. User- + defined header fields allow systems to extend their functionality + while maintaining a uniform framework. Our approach is similar + to that of the TELNET protocol, in that we are defining a basic + standard which includes a mechanism for (optionally) extending + itself. The authors of this document will regulate the + publishing of specifications for these extensions. + + Such a framework severely constrains document "tone" and + appearance and is primarily useful for most intra-organization + communications and relatively structured inter-organization + communication. A more robust environment might allow for multi- + font, multi-color, multi-dimension encoding of information. A + less robust environment, as is present in most single-machine + message systems, would more severely constrain the ability to add + fields and the decision to include specific fields. Relative to + paper-based communication, it is interesting to note that the + RECEIVER of a message can exercise an extraordinary amount of + control over the message's appearance. The amount of actual + control available to message receivers is contingent upon the + capabilties of their individual message systems. + + + + II. Standard for the Format of Messages / 9 + B. Syntax + + + + + + B. SYNTAX + + + This syntax is given in four parts. The first part + describes a base-level lexical analyzer which feeds the higher- + level parser described in the succeeding sections. The second + part gives a general syntax for messages and standard header + fields. The third part specifies the syntax of addresses. A + final section specifies some general syntax which supports the + other sections. + + + + 1. LEXICAL ANALYSIS OF MESSAGES + + + a. General Description + + A message consists of headers and, optionally, a body (i.e. + the <message-text>). The <message-text> part is just a + sequence of ASCII characters; it is separated from the + headers by a null line (i.e., a line with nothing preceding + the <crlf>). + + 1) Folding and unfolding of headers + + Each header item can be viewed as a single, logical, long + line of ASCII characters. For convenience, this + conceptual entity can be split into a multiple-line + representation (i.e., "folded"). The general rule is that + wherever there can be <linear-white-space> characters, you + can instead insert a <crlf> immediately followed by AT + LEAST one <linear-white-space> character. Thus, the + single line + + To: "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN + + can be represented as + + To: "Joe Dokes & J. Harvey" <ddd at Host>, + JJV at BBN + + and + + To: "Joe Dokes & J. Harvey" + <ddd at Host>, + JJV at BBN + + + + II. Standard for the Format of Messages / 10 + B. Syntax + 1. Lexical Analysis + + + + and + + To: "Joe Dokes + & J. Harvey" <ddd at Host>, JJV at BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line + representation will be called "unfolding". Unfolding is + accomplished by regarding <crlf> immediately followed by a + <linear-white-space-char> as equivalent to the <linear- + white-space-char>. + + + 2) Structure of header fields + + Once header fields have been unfolded, they may be viewed + as being composed of a <field-name> followed by a ":" + (colon), followed by a <field-body>. The <field-name> + must be composed of printable ASCII characters (i.e., + characters which have decimal values between 33 and 126) + and <linear-white-space> characters. The <field-body> may + composed of any ASCII characters (other than <cr> and + <lf>, which have been removed by unfolding). + + Certain header fields may be interpreted according to an + internal syntax which some systems may wish to parse. + These fields will be referred to as structured fields. + Examples include fields containing dates and addresses. + Other fields, such as the subject field, are regarded + simply as a single line of text. + + 3) Field names + + To aid in the creation and reading of <field-name>s, the + free insertion of <linear-white-space> characters is + allowed in reasonable places. Rather than obscuring the + syntax specification for <field-name> with the explicit + syntax for these <linear-white-space> characters, the + existence of a simple "lexical" analyzer is assumed. The + analyzer reinterprets the unfolded text which comprises + the <field-name> as a sequence of <atoms> separated by + <linear-white-space> characters. The field name may be + conveniently represented by the sequence of these atoms, + separated by a single ASCII space character. + + + + II. Standard for the Format of Messages / 11 + B. Syntax + 1. Lexical Analysis + + + + 4) Field bodies + + To aid in the creation and reading of structured fields, + the free insertion of <linear-white-space> characters is + allowed in reasonable places. Rather than obscuring the + syntax specifications for these structured fields with + explicit syntax for these <linear-white-space> characters, + the existence of another simple "lexical" analyzer is + assumed. It provides an interpretation of the unfolded + text comprising the body of the field as a sequence of + lexical symbols. These include + + - individual special characters + - quoted strings + - comments + - atoms + + The first three symbols are self-delimiting. Atoms are + not; they therefore are delimited by the self-delimiting + symbols and by <linear-white-space>. + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Host, + Muhammed(I am the greatest)Ali at WBA + + is analyzed into the following lexical symbols and types: + + ":sysmail" quoted string + @ special + Some-Host atom + , special + Muhammed atom + (I am the greatest) comment + Ali atom + at atom + WBA atom + + + b. Formal Definition + + <field> ::= <field-name> ":" <field-body> + <field-name> ::= <atom> + | <atom> <field-name> + + <field-body> ::= <field-body-contents> + | <field-body-contents> <crlf> + <linear-white-space-char> + <field-body> + + + + II. Standard for the Format of Messages / 12 + B. Syntax + 1. Lexical Analysis + + + + <field-body-contents> ::= <the TELNET ASCII characters making + up the <field-body>, as defined in + the following sections, and + consisting of combinations of + <atom>, <quoted-string>, <text-line>, + and <specials> tokens> + + <atom> ::= <a sequence of one or more TELNET + ASCII alpha-numeric or graphics + characters, excluding all control + characters (those characters with + a decimal value less than 33 or + equal to 127) and <delimeters> > + + <quoted-string> ::= <double quote mark ("), decimal 34> + <a sequence of one or more TELNET + ASCII characters, where two + adjacent quotes are treated as a + single quote and part of the + string> <"> + + <text-line> ::= <a sequence of one or more TELNET + ASCII characters excluding <cr> + and <lf> > + + <message-text> ::= <a sequence of zero of more TELNET + ASCII characters> + + <delimeters> ::= <specials> | <comment> + | <linear-white-space> | <crlf> + + <specials> ::= "(" | ")" | "<" | ">" + | "@" | "," | ";" | ":" | <"> + + <comment> ::= "(" <TELNET ASCII characters, except + <crlf> > ")" + + <linear-white-space>::= <linear-white-space-char> + | <linear-white-space-char> + <linear-white-space> + <linear-white-space-char>::= <space> | <horizontal-tab> + + <space> ::= <TELNET ASCII space (decimal 32)> + <tab> ::= <TELNET ASCII tab (decimal 9)> + <cr> ::= <TELNET ASCII carriage return + (decimal 13)> + <lf> ::= <TELNET ASCII line feed (decimal 10)> + <crlf> ::= <TELNET ASCII carriage return/line + feed (decimal 13, followed by + decimal 10)> + + + + II. Standard for the Format of Messages / 13 + B. Syntax + 1. Lexical Analysis + + + + c. Clarifications + + 1) Comments + + Comments may appear only within <field-body>s of + structured fields. A comment is any set of TELNET ASCII + characters, which is not within a quoted string, and which + is enclosed in matching parentheses; parentheses nest, so + that if a left paren occurs in a comment string, there + must also be a matching right paren. + + Comments are NOT passed to the FTP server, as part of a + MAIL or MLFL command, since comments are not part of the + "formal" address. + + + 2) "White space" + + Remember that in structured fields, MULTIPLE LINEAR WHITE + SPACE TELNET ASCII CHARACTERS (namely <tab>s and <space>s) + ARE TREATED AS SINGLE SPACES AND MAY FREELY SURROUND ANY + SYMBOL. In all header fields, at least one <space> is + REQUIRED only at the beginning of folded lines. + + Writers of mail-sending (i.e. header generating) programs + should realize that there is no Network-wide definition of + the effect of <tab> TELNET ASCII characters on the + appearance of text at another Network host; therefore, the + use of <tab>s in message headers, though permitted, is + discouraged. + + Note that the contents of messages are required to conform + with TELNET NVT conventions (e.g. <cr> must be followed + by either <lf>, making a <crlf>, or <null>, if the <cr> is + to stand alone). + + 3) Quoted strings + + Where permitted (i.e., in structured fields) quoted + strings are treated as a single symbol (i.e. equivalent + to an <atom> syntactically). However, if quoted strings + are to be "folded" onto multiple lines, then the syntax + for folding must be adhered to (See items II.B.1.a.1, + above, and II.B.1.c.6, below.) Note that the official + semantics do not encounter <crlf>s in quoted strings, + although particular parsing programs may wish to note + their presence. + + + + II. Standard for the Format of Messages / 14 + B. Syntax + 1. Lexical Analysis + + + + 4) Bracketing characters + + There are two types of brackets which must be well nested: + + - Parentheses are used to indicate comments. + + - Angle brackets ("<" and ">") are used + where there is a question of the presence + of machine-usable code (e.g. deliminating + mailboxes). + + 5) Case independence of certain specials <atom>s + + It should be assumed by all mail reading programs that + certain <atom>s can be represented in any combination of + upper and lower case. These are: + + - <field-name>s, + - "File", in a <path>, + - "at", in an <at-indicator>, + - <host-name>s, + - <day-of-week>s, + - <string-month>s, and + - <time-zone>s + + For example, the <field-name>s "From", "FROM", "from", and + even "FroM" should all be treated identically. Note that, + at the level of this specification, case IS relevant to + other <word>s and <text-line>s. Also see Section + II.C.1.a.4, below. + + 6) Folding long lines + + Each header item (field of the message) may be represented + on exactly one line consisting of the name of the field + and its body, and this is what the parser sees. For + readability, it is recommended that the <field-body> + portion of long header items be "folded" onto multiple + lines of the actual header. + + + 7) Backspace characters + + Backspace TELNET ASCII characters (ASCII BS, decimal 8) + may be included in <text-line> and <quoted-string> to + effect overstriking; however, any use of backspaces which + effects an overstrike to the left of the beginning of the + <text-line> or <quoted-string> is prohibited. + + + + + II. Standard for the Format of Messages / 15 + B. Syntax + 2. Messages + + + + 2. GENERAL SYNTAX OF MESSAGES: + + NOTE: The syntax indicates that items in <required-headers> + must be in a specific order and precede all other header + items. Header fields, in fact, are NOT required to occur in + any particular order. Required header items must be unique + (occur exactly once). This specification permits multiple + occurrences of most optional fields. However, the + interpretation of such multiple occurrences is not specified + here. + + <message> ::= <headers> + | <headers> <crlf> <message-text> + + <headers> ::= <required-headers> + | <required-headers> <optional-headers> + <required-headers> ::= <date-field> <originator> + <originator> ::= <mach-from-field> + | <mach-from-list> <sender-field> + | <mach-from-field> <reply-to-field> + | <any-from-field> <sender-field> + <reply-to-field> + + <date-field> ::= "Date" ":" <date-time> + <mach-from-field> ::= "From" ":" <mach-addr-item> + <mach-from-list> ::= "From" ":" <mach-addr-list> + <any-from-field> ::= "From" ":" <address-list> + <sender-field> ::= "Sender" ":" <host-phrase> + <reply-to-field> ::= "Reply-To" ":" <mach-addr-list> + + <optional-headers>::= <optional-header-field> + | <optional-headers> + <optional-header-field> + + <optional-header-field> ::= <addressee-field> + | <extension-field> + + <addressee-field> ::= "To" ":" <address-list> + | "cc" ":" <address-list> + | "bcc" ":" <address-list> + | "Fcc" ":" <path-list> + + <extension-field> ::= "In-Reply-To" ":" <reference-list> + | "Keywords" ":" <phrase-list> + | "Message-Id" ":" <mach-host-phrase> + | "References" ":" <reference-list> + | "Subject" ":" <text-line> + | "Comments" ":" <text-line> + | <user-defined-field> + + + + II. Standard for the Format of Messages / 16 + B. Syntax + 2. Messages + + + + <user-defined-field> ::= <A <field> which has a <field-name> + not defined in this specification> + + + + The following syntax for the bodies of various fields should be + thought of as describing each field body as a single long string + (or line). The section on Lexical Analysis (section II.B.1) + indicated how such long strings can be represented on more than + one line in the actual transmitted message. + + + 3. SYNTAX OF GENERAL ADDRESSEE ITEMS + + <mach-addr-list> ::= <mach-addr-item> + | <mach-addr-item> "," <address-list> + + <address-list> ::= <null> + | <address-item> + | <address-item> "," <address-list> + <address-item> ::= <mach-addr-item> + | <group-name> ":" <address-list> ";" + | <any-name> + | <path> + + <mach-addr-item> ::= <mailbox> + | <phrase> "<" <mailbox-list> ">" + + <group-name> ::= <phrase> + <any-name> ::= <quoted-string> + + <mailbox-list> ::= <mailbox> + | <mailbox> "," <mailbox-list> + <mailbox> ::= <host-phrase> + + <path> ::= ":" "File" ":" <path-name> + <path-name> ::= <path-item> + | "<" <path-list> ">" + <path-list> ::= <path-item> + | <path-item> "," <path-list> + <path-item> ::= <host-phrase> + + + + + II. Standard for the Format of Messages / 17 + B. Syntax + 4. Supporting Constructs + + + + 4. SUPPORTING SYNTAX + + <reference-list> ::= <null> + | <reference-item> + | <reference-item> "," <reference-list> + <reference-item> ::= <phrase> + | <mach-host-phrase> + + <mach-host-phrase>::= "<" <host-phrase> ">" + <host-phrase> ::= <phrase> <host-indicator> + <host-indicator> ::= <at-indicator> <host-name> + <at-indicator> ::= "at" | "@" + <host-name> ::= <atom> + | <decimal host address> + + <date-time> ::= <day> <date> <time> + <day> ::= <null> + | <day-of-week> "," + <day-of-week> ::= "Monday" | "Mon" + | "Tuesday" | "Tue" + | "Wednesday" | "Wed" + | "Thursday" | "Thu" + | "Friday" | "Fri" + | "Saturday" | "Sat" + | "Sunday" | "Sun" + <date> ::= <string-date> + | <slash-date> + <string-date> ::= <day-of-month> <string-month> + <4-digit-year> + <slash-date> ::= <numeric-month> "/" <date-of-month> + "/" <2-digit-year> + <numeric-month> ::= <one or two decimal digits> + <day-of-month> ::= <one or two decimal digits> + <string-month> ::= "January" | "Jan" + | "February" | "Feb" + | "March" | "Mar" + | "April" | "Apr" + | "May" + | "June" | "Jun" + | "July" | "Jul" + | "August" | "Aug" + | "September"| "Sep" + | "October" | "Oct" + | "November" | "Nov" + | "December" | "Dec" + <4-digit-year> ::= <four decimal digits> + <2-digit-year> ::= <two decimal digits> + <time> ::= <24-hour-time> "-" <time-zone> + <24-hour-time> ::= <hour> <minute> + <hour> ::= <two decimal digits> + <minute> ::= <two decimal digits> + + + II. Standard for the Format of Messages / 18 + B. Syntax + 4. Supporting Constructs + + + + <time-zone> ::= "GMT" | "Z" | "GDT" + | "AST" | "ADT" + | "EST" | "EDT" | "CST" | "CDT" + | "MST" | "MDT" | "PST" | "PDT" + | "YST" | "YDT" | "HST" | "HDT" + + <phrase> ::= <word> + | <word> <phrase> + <phrase-list> ::= <null> + | <phrase> + | <phrase> "," <phrase-list> + + <word> ::= <atom> + | <quoted-string> + + + + II. Standard for the Format of Messages / 19 + C. Semantics + 1. Address Fields + + + + + + C. SEMANTICS + + + 1. ADDRESS FIELDS + + a. General + + 1) <path>s are used to refer to a location, on the ARPANET, + containing a stored address list. The <phrase> should + contain text which the referenced host can resolve to a + file. This standard is not a protocol and so does not + prescribe HOW data is to be retrieved from the file. + However, the following requirements are made: + + - the file must be accessible through the local + operating system interface (if it exists), given + adequate user access rights; and + + - if a host has an FTP server and a user is able to + retrieve any files from the host using that server, + then the file must be accessible through FTP, using + DEFAULT transfer settings, given adequate user access + rights. + + It is intended that this mechanism will allow programs to + retrieve such lists automatically. + + The interpretation of a <path> follows. This is not + intended to imply any particular implementation scheme, but + is included to aid in understanding the notion of <path>s: + + - The contents of the file indicated by a <path-name> is + treated as an <address-list> and is inserted as an + <address-item> in the position of the <path-name> item + in the syntax. That is, the TELNET ASCII character + string of the <path-name> or, if present, the <path- + list> containing it, is replaced by the contents of + the file to which the <path-name> refers. Therefore, + the contents of the file indicated by a <path-name> + must be syntactically self-contained and must adhere + to the full syntax prescribed herein for <address- + list>. + + - <Path-item>s of a <path-list> are alternates and the + contents of ONLY ONE of them is to be included in the + resultant address list. + + 2) The <phrase> part of a <mailbox> is understood to be + whatever the receiving FTP Server allows (for example, + + + II. Standard for the Format of Messages / 20 + C. Semantics + 1. Address Fields + + + + TENEX systems do not now understand addresses of the form + "P. D. Q. Bach", but another system might). + + Note that a <mailbox> is a conceptual entity which does not + necessarily pertain to file storage. For example, some + sites may choose to print mail on their line printer and + deliver the output to the addressee's desk. + + A user may have several mailboxes. The use of the second + alternative of <mach-addr-item> (<phrase> "<" <mailbox- + list> ">") indicates that a copy of the message is to be + sent to EACH mailbox named. + + 3) <any-name> may contain any sequence of "words". This + sequence of words, used as an <address-item>, is used to + facilitate reference to non-standard (e.g. non-Network) + addresses. Such an address might be one which is + acceptable to the U.S. Postal Service. + + 4) The <host-name> in a <host-phrase> must be THE official + name of a Network host, or else a decimal number indicating + the Network address for that host. The USE OF NUMBERS IS + STRONGLY DISCOURAGED and is permitted only due to the + occasional necessity of bypassing local host-name tables. + + The <phrase> in a <host-phrase> is intended to be + meaningful only to the indicated host. To all other hosts, + the <phrase> is treated as a literal string. No case + transformations should be (automatically) performed on the + <phrase>. The <phrase> is passed to the local host's mail + sending program; it is the responsibility of the + destination host's mail receiving (distribution) program to + perform case mapping on this <phrase>, if required, to + deliver the mail. + + b. Originator Fields + + WARNING: The standard allows only a subset of the + combinations possible with the From, + Sender, and Reply-to fields. The + limitation is intentional; the permitted + alternatives have been carefully chosen + and are adequate for the purposes of this + standard. + + + + II. Standard for the Format of Messages / 21 + C. Semantics + 1. Address Fields + + + + 1) From: + + This field contains the identity of the person(s) who + wished this message to be sent. The message-creation + process should default this field to be a single machine + address, indicating the user entering the message; if and + only if this is done, the "Sender:" field need not be + present. + + 2) Sender: + + This field contains the identity of the person who sends + the message. It need not be present in the header of the + message if it is the SAME as the "From:" field. + + The <sender-field-body> includes a <phrase> which must + correspond to a user, rather than a standard <address- + item>, to indicate the expectation that the field will + refer to the PERSON responsible for sending the mail and + not simply include the name of a mailbox, from which the + mail was sent. For example in the case of a shared login + name, the name, by itself, would not be adequate. The + <phrase> (user) is a system entity, not a generalized + person reference. + + 3) Reply-to: + + This field provides a general mechanism for indicating any + mailbox(es) to which responses are to be sent. Three + different uses for this feature can be distinguished. In + the first case, the author(s) may not have regular + machine-based mailboxes and therefore wish to indicate an + alternate machine address. In the second case, an author + may wish additional persons to be made aware of, or + responsible for, responses; responders should send their + replies to the "Reply-to:" mailbox(es). More interesting + is a case such as text-message teleconferencing in which an + automatic distribution facility is provided and a user + submitting an "entry" for distribution only needs to send + their message to the mailbox(es) indicated in the "Reply- + to:" field. + + If there is no <reply-to-field>, then the <from-field> MUST + contain AT LEAST ONE machine address. In all cases when + used and even if a <sender> field is present, the Reply-to + field must contain at least one machine address. + + NOTE: For systems which automatically generate address lists + for replies to messages, the following requirements are made: + + + + II. Standard for the Format of Messages / 22 + C. Semantics + 1. Address Fields + + + + - The receiver, when replying to a message, must NEVER + automatically include the <sender-field-body> in the + reply's address list + + - If the <reply-to-field> exists, then the reply should + go ONLY to the <reply-to-field-body> addressees. + + (Extensive examples are provided in Section II.D.) This + recommendation is intended only for <originator-field>s and in + no way is intended to reflect that replies should not be sent, + also, to the other recipients of this message. It is up to + the respective mail handling programs as to what additional + facilities will be provided. + + c. Receiver Fields + + 1) To: + + This field contains the identity of the primary recipients + of the message. + + 2) cc: + + This field contains the identity of the secondary + recipients of the message. + + 3) Bcc: + + This field contains the identity of additional recipients + of the message who are to remain hidden from the primary + and secondary recipients. Some systems may choose to + include the text of the "Bcc:" field only in the + author(s)'s copy, while others may include it in the text + sent to all those indicated in the "Bcc:" list. + + 4) Fcc: + + This field contains the identity of any message files in + which copies of this message are being placed by the + originator. Note that the presence of this field does NOT + guarantee long-term availability of the message in any of + the indicated files. + + + + + II. Standard for the Format of Messages / 23 + C. Semantics + 2. Reference Specification Fields + + + + 2. REFERENCE SPECIFICATION FIELDS + + a. Message-Id: + + This field contains a unique identifier (the <phrase>) to + refer to this version of this message. The uniqueness of the + message identifier is guaranteed by each host. This + identifier is intended to be machine readable, and not + necessarily meaningful to humans. A message-id pertains to + exactly one instantiation of a particular message; subsequent + revisions to the message should receive new message-id's. + + b. In-Reply-To: + + The contents of this field identify previous correspondence + which this message answers. If message identifiers are used + in this field, they should be enclosed in angle brackets (<>). + + c. References: + + The contents of this field identify other correspondence which + this message references. If message identifiers are used, + they should be enclosed in angle brackets (<>). + + d. Keywords: + + This field contains keywords or phrases, separated by commas. + + + 3. OTHER FIELDS AND SYNTACTIC ITEMS + + a. Subject: + + The "subject:" field is intended to provide as much + information as necessary to adequately summarize or indicate + the nature of the message. + + b. Comments: + + Permits adding text comments onto the message without + disturbing the contents of the message's body. + + + + + II. Standard for the Format of Messages / 24 + C. Semantics + 4. Dates + + + + 4. DATES + + It is recommended that, because of differing international + interpretations, the <string-day> option be used instead of + the <slash-day> option in the specification of a <day>. + + If included, <day-of-week> must be the day implied by the + <date> specification. + + <Time-zones> allow reference to Greenwich and to each of the + zones in the United States. The zone references beginning + with "A" are for Atlantic time which are one hour faster than + the corresponding Eastern times. "Y" indicates Yukon time in + Alaska, which is one hour slower than the corresponding + Pacific times, and "H" indicates Hawaiian times, which are two + hours slower. + + + + II. Standard for the Format of Messages / 25 + D. Examples + + + + + + + D. EXAMPLES + + + 1. ADDRESSES + + a. Alfred E. Newman <Newman at BBN-TENEXA> + Newman@BBN-TENEXA + + These two "Alfred E. Newman" examples have identical + semantics, as far as the operation of the local host's mailer + and the remote host's FTP server are concerned. In the first + example, the "Alfred E. Newman" is ignored by the mailer, as + "Newman at BBN-TENEXA" completely specifies the recipient. + The second example contains no superfluous information, and, + again, "Newman@BBN-TENEXA" is the intended recipient. + + b. Al Newman at BBN-TENEXA + + This is identical with "Al Newman<Al Newman at BBN-TENEXA>." + That is, the full <phrase>, "Al Newman", is passed to the FTP + server. Note that not all FTP servers accept multi-word + identifiers; and some that do accept them will treat each word + as a different addressee (in this case, attempting to send a + copy of the message to "Al" and a copy to "Newman"). + + c. "George Lovell, Ted Hackle" <Shared-Mailbox at Office-1> + + This form might be used to indicate that a single mailbox is + shared by several users. The quoted string is ignored by the + originating host's mailer, as "Shared-Mailbox at Office-1" + completely specifies the destination mailbox. + + d. Wilt (the Stilt) Chamberlain at NBA + + The "(the Stilt)" is a comment, which is NOT included in the + destination mailbox address handed to the originating system's + mailer. The address is the string "Wilt Chamberlain", with + exactly one space between the first and second words. (The + quotation marks are not included.) + + + + + II. Standard for the Format of Messages / 26 + D. Examples + + + + + 2. ADDRESS LISTS + + Gourmets: Pompous Person <WhoZiWhatZit at Cordon-Bleu>, + Cooks: Childs at WGBH, Galloping Gourmet at + ANT (Australian National Television); + Wine Lovers: Drunk at Discount-Liquors, + Port at Portugal;;, + Jones at SEA + + This group list example points out the use of comments, the + nesting of groups, and the mixing of addresses and groups. + Note that the two consecutive semi-colons preceding "Jones at + SEA" mean that Jones is NOT a member of the Gourmets group. + + + 3. ORIGINATOR ITEMS + + a. George Jones logs into his Host as "Jones". He sends mail + himself. + + From: Jones at Host + or + From: George Jones <Jones at Host> + + b. George Jones logs in as Jones on his Host. His secretary, who + logs in as Secy on her Host (SHost) sends mail for him. + Replies to the mail should go to George, of course. + + From: George Jones <Jones at Host> + Sender: Secy at SHost + + c. George Jones logs in as Group at Host. He sends mail himself; + replies should go to the Group mailbox. + + From: George Jones <Group at Host> + + d. George Jones' secretary sends mail for George in his capacity + as a member of Group while logged in as Secy at Host. Replies + should go to Group. + + From: George Jones<Group at Host> + Sender: Secy at Host + + Note that there need not be a space between "Jones" and the + "<", but adding a space enhances readability (as is the case + in other examples). + + e. George Jones asks his secretary (Secy at Host) to send a + message for him in his capacity as Group. He wants his + secretary to handle all replies. + + + + II. Standard for the Format of Messages / 27 + D. Examples + + + + + From: George Jones <Group at Host> + Sender: Secy at Host + Reply-to: Secy at Host + + f. A non-ARPANET user friend of George's, Sarah, is visting. + George's secretary sends some mail to a friend of Sarah in + computer-land. Replies should go to George, whose mailbox is + Jones at Host. + + From: Sarah Friendly + Sender: Secy at Host + Reply-to: Jones at Host + + g. George is a member of a committee. He wishes to have any + replies to his message go to all committee members. + + From: George Jones + Sender: Jones at Host + Reply-To: Big-committee: Jones at Host, + Smith at Other-Host, + Doe at Somewhere-Else; + + Note that if George had not included himself in the + enumeration of Big-committee, he would not have gotten a + reply; the presence of the "Reply-to:" field SUPERSEDES the + sending of a reply to the person named in the "From:" field. + + h. (Example of INCORRECT USE) + + George desires a reply to go to his secretary; therefore his + secretary leaves his mailbox address off the "From:" field, + leaving only his name, which is not, itself, a mailbox + address. + + From: George Jones + Sender: Secy at SHost + + THIS IS NOT PERMITTED. Replies are NEVER implicitly sent to + the "Sender:"; George's secretary should have used the + "Reply-to:" field, or the mail creating program she was using + should have forced her to. + + i. George's secretary sends out a message which was authored + jointly by all the members of the "Big-committee". + + From: Big-committee: Jones at Host, + Smith at Other-Host, + Doe at Somewhere-Else; + Sender: Secy at SHost + + + + II. Standard for the Format of Messages / 28 + D. Examples + + + + + 4. COMPLETE HEADERS + + a. Minimum required: + + Date: 26 August 1976 1429-EDT + From: Jones at Host + + b. Using some of the additional fields: + + Date 26 August 1976 1430-EDT + From: George Jones<Group at Host> + Sender: Secy at SHOST + To: Al Newman at Mad-Host, + Sam Irving at Other-Host + Message-id: some string at SHOST + + c. About as complex as you're going to get: + + Date: 27 Aug 1976 0932-PDT + From: Ken Davis <KDavis at Other-Host> + Sender: KSecy at Other-Host + Reply-to: Sam Irving at Other-Host + Subject: Re: The Syntax in the RFC + To: George Jones <Group at Host>, + Al Newman at Mad-Host + cc: Tom Softwood <Balsa at Another-Host>, + Sam Irving at Other-Host, + Standard Distribution: + :File: + </main/davis/people/standard at Other Host, + "<Jones>standard.dist.3" at Tops-20-Host> + In-Reply-to: <some string at SHOST> + Message-ID: 4231.629.XYzi-What at Other-Host + Comment: Sam is away on business. He asked me to handle + his mail for him today. He'll be able to + provide a more accurate explanation tomorrow + when he returns. + + + + III. References + + + + + + + + III. REFERENCES + + + --- TELNET Protocol Specification. Network Information Center + No. 18639; Augmentation Research Center, Stanford Research + Institute: Menlo Park, August 1973. + + Bhushan, A.K. The File Transfer Protocol. ARPANET Request for + Comments, No. 354, Network Information Center No. 10596; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, July 1972. + + Bhushan, A.K. Comments on the File Transfer Protocol. ARPANET + Request for Comments, No. 385, Network Information Center No. + 11357; Augmentation Research Center, Stanford Research + Institute: Menlo Park, August 1972. + + Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. + Standardizing Network Mail Headers. ARPANET Request for + Comments, No. 561, Network Information Center No. 18516; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, September 1973. + + Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook. + Network Information Center No. 7104; Augmentation Research + Center, Stanford Research Institute: Menlo Park, April 1976. + (NTIS AD A003890). + + McKenzie, A. File Transfer Protocol. ARPANET Request for + Comments, No. 454, Network Information Center No. 14333; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, February 1973. + + Myer, T.H. and Henderson, D.A. Message Transmission Protocol. + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116; Augmentation Research Center, Stanford + Research Institute: Menlo Park, 1975. + + Neigus, N. File Transfer Protocol. ARPANET Request for + Comments, No. 542, Network Information Center No. 17759; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, July 1973. + + Postel, J.B. Revised FTP Reply Codes. ARPANET Request for + Comments, No. 640, Network Information Center No. 30843; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, June 1974. + + + + Appendix / 30 + Alphabetical Listing of Syntax Rules + + + + + + + APPENDIX + + + A. ALPHABETICAL LISTING OF SYNTAX RULES + + <2-digit-year> ::= <two decimal digits> + <4-digit-year> ::= <four decimal digits> + <24-hour-time> ::= <hour> <minute> + + <addressee-field> ::= "To" ":" <address-list> + | "cc" ":" <address-list> + | "bcc" ":" <address-list> + | "Fcc" ":" <path-list> + <address-item> ::= <mach-addr-item> + | <group-name> ":" <address-list> ";" + | <any-name> + | <path> + <address-list> ::= <null> | <address-item> + | <address-item> "," <address-list> + + <any-from-field> ::= "From" ":" <address-list> + + <any-name> ::= <quoted-string> + + <at-indicator> ::= "at" | "@" + + <atom> ::= <a sequence of one or more TELNET ASCII + alpha-numeric or graphics characters, + excluding all control characters + (those characters with a decimal value + less than 33 or equal to 127) and + <delimeters> > + + <comment> ::= "(" <TELNET ASCII characters, except + <crlf> > ")" + + <cr> ::= <TELNET ASCII carriage return (decimal 13)> + <crlf> ::= <TELNET ASCII carriage return/line feed + (decimal 13, followed by decimal 10)> + + <date> ::= <string-date> | <slash-date> + <date-field> ::= "Date" ":" <date-time> + <date-time> ::= <day> <date> <time> + <day> ::= <null> | <day-of-week> "," + <day-of-month> ::= <one or two decimal digits> + <day-of-week> ::= "Monday" | "Mon" + | "Tuesday" | "Tue" + | "Wednesday" | "Wed" + | "Thursday" | "Thu" + + + Appendix / 31 + Alphabetical Listing of Syntax Rules + + + + + | "Friday" | "Fri" + | "Saturday" | "Sat" + | "Sunday" | "Sun" + + <delimeter> ::= <specials> | <comment> + | <linear-white-space> | <crlf> + + <field> ::= <field-name> ":" <field-body> + <field-body> ::= <field-body-contents> + | <field-body-contents> <crlf> + <linear-white-space-CHAR> <field-body> + <field-body-contents> ::= <the TELNET ASCII characters making up + the field body, as defined in the + following sections and consisting of + combinations of <atom>, <quoted- + string>, <text-line>, and <specials> + tokens> + + <field-name> ::= <atom> | <atom> <field-name> + + <group-name> ::= <phrase> + + <headers> ::= <required-headers> + | <required-headers> <optional-headers> + + <host-indicator> ::= <at-indicator> <host-name> + <host-name> ::= <atom> | <decimal host address> + <host-phrase> ::= <phrase> <host-indicator> + + <hour> ::= <two decimal digits> + + <lf> ::= <TELNET ASCII line feed (decimal 10)> + <linear-white-space>::= <linear-white-space-char> + | <linear-white-space-char> + <linear-white-space> + <linear-white-space-char>::= <space> | <horizontal-tab> + + <mach-addr-item> ::= <mailbox> | <phrase> "<" <mailbox-list> ">" + <mach-addr-list> ::= <mach-addr-item> + | <mach-addr-item> "," <address-list> + + <mach-from-field> ::= "From" ":" <mach-addr-item> + <mach-from-list> ::= "From" ":" <mach-addr-list> + + <mach-host-phrase>::= "<" <host-phrase> ">" + + <mailbox> ::= <host-phrase> + <mailbox-list> ::= <mailbox> | <mailbox> "," <mailbox-list> + + <message> ::= <headers> + | <headers> <crlf> <message-text> + + + Appendix / 32 + Alphabetical Listing of Syntax Rules + + + + + <message-text> ::= <a sequence of zero of more TELNET ASCII + characters> + + <minute> ::= <two decimal digits> + + <numeric-month> ::= <one or two decimal digits> + + <optional-headers>::= <optional-header-field> + | <optional-headers> <optional-header-field> + <optional-header-field> ::= <addressee-field> | <extension-field> + + <originator> ::= <mach-from-field> + | <mach-from-list> <sender-field> + | <mach-from-field> <reply-to-field> + | <any-from-field> <sender-field> + <reply-to-field> + + <path> ::= ":" "File" ":" <path-name> + <path-item> ::= <host-phrase> + <path-list> ::= <path-item> | <path-item> "," <path-list> + <path-name> ::= <path-item> | "<" <path-list> ">" + + <phrase> ::= <word> | <word> <phrase> + <phrase-list> ::= <null> | <phrase> + | <phrase> "," <phrase-list> + + <reference-item> ::= <phrase> | <mach-host-phrase> + <reference-list> ::= <null> | <reference-item> + | <reference-item> "," <reference-list> + + <quoted-string> ::= <double quote mark ("), decimal 34> + <a sequence of one or more TELNET + ASCII characters, where two adjacent + quotes are treated as a single quote + and part of the string> <"> + + <reply-to-field> ::= "Reply-To" ":" <mach-addr-list> + + <required-headers> ::= <date-field> <originator> + + <sender-field> ::= "Sender" ":" <host-phrase> + + <slash-date> ::= <numeric-month> "/" <date-of-month> + "/" <2-digit-year> + <space> ::= <TELNET ASCII space (decimal 32)> + + <specials> ::= "(" | ")" | "<" | ">" + | "@" | "," | ";" | ":" | <"> + + <string-date> ::= <day-of-month> <string-month> + <string-month> ::= "January" | "Jan" | "February" | "Feb" + + + Appendix / 33 + Alphabetical Listing of Syntax Rules + + + + + | "March" | "Mar" | "April" | "Apr" + | "May" | "June" | "Jun" + | "July" | "Jul" | "August" | "Aug" + | "September"| "Sep" | "October" | "Oct" + | "November" | "Nov" | "December" | "Dec" + + <tab> ::= <TELNET ASCII tab (decimal 9)> + + <text-line> ::= <a sequence of one or more TELNET ASCII + characters excluding <cr> and <lf> > + + <time> ::= <24-hour-time> "-" <time-zone> + <time-zone> ::= "GMT" | "Z" | "GDT" | "AST" | "ADT + | "EST" | "EDT" | "CST" | "CDT" + | "MST" | "MDT" | "PST" | "PDT" + | "YST" | "YDT" | "HST" | "HDT" + + <user-defined-field> ::= <A <field> which has a <field-name> not + defined in this specification> + + <word> ::= <atom> | <quoted-string> + + + + diff --git a/Documentation/en/rfc/rfc733.txt b/Documentation/en/rfc/rfc733.txt new file mode 100644 index 00000000..a2a1472e --- /dev/null +++ b/Documentation/en/rfc/rfc733.txt @@ -0,0 +1,1958 @@ + + + + +RFC # 733 +NIC # 41952 + +Obsoletes: RFC #561 (NIC #18516) + RFC #680 (NIC #32116) + RFC #724 (NIC #37435) + + + + + + + + STANDARD FOR THE FORMAT OF + + ARPA NETWORK TEXT MESSAGES(1) + + + + + 21 November 1977 + + + + + by + + + David H. Crocker + The Rand Corporation + + John J. Vittal + Bolt Beranek and Newman Inc. + + Kenneth T. Pogran + Massachusets Institute of Technology + + D. Austin Henderson, Jr.(2) + Bolt Beranek and Newman Inc. + + + +_________________________________________________________________ +(1)This work was supported by the Defense Advanced Research +Projects Agency of the Department of Defense, under contract Nos. +N00014-75-C-0661, MDA903-76-C-0212, and DAHC15-73-C0181. + +(2)The authors' postal addresses are: D. Crocker, The Rand +Corporation, Information Sciences Dept., 1700 Main St., Santa +Monica, California 90406; J. Vittal & D. A. Henderson, Bolt +Beranek & Newman, 50 Moulton St., Cambridge, Massachusetts 02138; +and K. Pogran, MIT Laboratory for Computer Science, 545 +Technology Square, Cambridge, Massachusetts 02139. The authors' +ARPANET addresses are: DCrocker at Rand-Unix, Vittal at BBN- +TenexD, Pogran at MIT-Multics, and Henderson at BBN-TenexD. + + -iii- + + + + + + PREFACE + + + + ARPA's Committee on Computer-Aided Human Communication +(CAHCOM) wishes to promulgate a standard for the format of ARPA +Network text message (mail) headers which will reasonably meet +the needs of the various message service subsystems on the +Network today. The authors of this document constitute the +CAHCOM subcommittee charged with the task of developing this new +standard. + + Essentially, we specify a revision to ARPANET Request for +Comments (RFC) 561, "Standardizing Network Mail Headers", and RFC +680, "Message Transmission Protocol". This revision removes and +compacts portions of the previous syntax and adds several +features to network address specification. In particular, we +focus on people and not mailboxes as recipients and allow +reference to stored address lists. We expect this syntax to +provide sufficient capabilities to meet most users' immediate +needs and, therefore, give developers enough breathing room to +produce a new mail transmission protocol "properly". We believe +that there is enough of a consensus in the Network community in +favor of such a standard syntax to make possible its adoption at +this time. An earlier draft of this specification was published +as RFC #724, "Proposed Official Standard for the Format of ARPA +Network Messages" and contained extensive discussion of the +background and issues in ARPANET mail standards. + + This specification was developed over the course of one +year, using the ARPANET mail environment, itself, to provide an +on-going forum for discussing the capabilities to be included. +More than twenty individuals, from across the country, +participated in this discussion and we would like to acknowledge +their considerable efforts. The syntax of the standard was +originally specified in the Backus-Naur Form (BNF) meta-language. +Ken L. Harrenstien, of SRI International, was responsible for +re-coding the BNF into an augmented BNF which compacts the +specification and allows increased comprehensibility. + + + + -v- + + + + + + CONTENTS + + + +PREFACE..................................................... iii + + +Section + I. INTRODUCTION......................................... 1 + + II. FRAMEWORK............................................ 2 + + III. SYNTAX............................................... 4 + A. Notational Conventions............................ 4 + B. Lexical Analysis of Messages...................... 5 + C. General Syntax of Messages........................ 13 + D. Syntax of General Addressee Items................. 15 + E. Supporting Constructs............................. 15 + + IV. SEMANTICS............................................ 17 + A. Address Fields.................................... 17 + B. Reference Specification Fields.................... 22 + C. Other Fields and Syntactic Items.................. 23 + D. Dates and Times................................... 24 + + V. EXAMPLES............................................. 25 + A. Addresses......................................... 25 + B. Address Lists..................................... 26 + C. Originator Items.................................. 26 + D. Complete Headers.................................. 28 + + +Appendix + A. ALPHABETICAL LISTING OF SYNTAX RULES................. 31 + B. SIMPLE PARSING....................................... 35 + +BIBLIOGRAPHY................................................ 37 + + +Standard for the Format of Text Messages 1 +I. Introduction + + + + + + I. INTRODUCTION + + + + + This standard specifies a syntax for text messages which are +passed between computer users within the framework of "electronic +mail". The standard supersedes the informal standards specified +in ARPANET Request for Comments numbers 561, "Standardizing +Network Mail Headers", and 680, "Message Transmission Protocol". +In this document, a general framework is first described; the +formal syntax is then specified, followed by a discussion of the +semantics. Finally, a number of examples are given. + + This specification is intended strictly as a definition of +what is to be passed between hosts on the ARPANET. It is NOT +intended to dictate either features which systems on the Network +are expected to support, or user interfaces to message creating +or reading programs. + + A distinction should be made between what the specification +REQUIRES and what it ALLOWS. Messages can be made complex and +rich with formally-structured components of information or can be +kept small and simple, with a minimum of such information. Also, +the standard simplifies the interpretation of differing visual +formats in messages. These simplifications facilitate the formal +specification and indicate what the OFFICIAL semantics are for +messages. Only the visual aspect of a message is affected and +not the interpretation of information within it. Implementors +may choose to retain such visual distinctions. + + + + +Standard for the Format of Text Messages 2 +II. Framework + + + + + + II. FRAMEWORK + + + + + Since there are many message systems which exist outside the +ARPANET environment, as well as those within it, it may be useful +to consider the general framework, and resulting capabilities and +limitations, provided by this standard. + + Messages are expected to consist of lines of text. No +special provisions are made, at this time, for encoding drawings, +facsimile, speech, or structured text. + + No significant consideration has been given to questions of +data compression or transmission/storage efficiency. The +standard, in fact, tends to be very free with the number of bits +consumed. For example, field names are specified as free text, +rather than special terse codes. + + A general "memo" framework is used. That is, a message +consists of some information, in a rigid format, followed by the +main part of the message, which is text and whose format is not +specified in this document. The syntax of several fields of the +rigidly-formated ("header") section is defined in this +specification; some of the header fields must be included in all +messages. The syntax which distinguishes between headers is +specified separately from the internal syntax for particular +headers. This separation is intended to allow extremely simple +parsers to operate on the overall structure of messages, without +concern for the detailed structure of individual headers. +Appendix B is provided to facilitate construction of these simple +parsers. In addition to the fields specified in this document, +it is expected that other fields will gain common use. User- +defined header fields allow systems to extend their functionality +while maintaining a uniform framework. The approach is similar +to that of the TELNET protocol, in that a basic standard is +defined which includes a mechanism for (optionally) extending +itself. As necessary, the authors of this document will regulate +the publishing of specifications for these "extension-fields", +through the same mechanisms used to publish this document. + + Such a framework severely constrains document tone and +appearance and is primarily useful for most intra-organization +communications and relatively structured inter-organization +communication. A more robust environment might allow for multi- +font, multi-color, multi-dimension encoding of information. A +less robust environment, as is present in most single-machine +message systems, would more severely constrain the ability to add +fields and the decision to include specific fields. In contrast +to paper-based communication, it is interesting to note that the + +Standard for the Format of Text Messages 3 +II. Framework + + + +RECEIVER of a message can exercise an extraordinary amount of +control over the message's appearance. The amount of actual +control available to message receivers is contingent upon the +capabilities of their individual message systems. + + +Standard for the Format of Text Messages 4 +III. Syntax + + + + + + III. SYNTAX + + + + This syntax is given in five parts. The first part +describes the notation used in the specification. The second +part describes the base-level lexical analyzers which feed the +higher-level parser described in the succeeding sections. The +third part gives a general syntax for messages and standard +header fields; and the fourth part specifies the syntax of +addresses. A final part specifies some general syntax which +supports the other sections. + + + +A. NOTATIONAL CONVENTIONS + +These specifications are made in an augmented Backus-Naur Form +(BNF). Differences from standard BNF involve the naming of +rules, the indication of repetition and of "local" alternatives. + + +1. Rule naming + +Angle brackets ("<", ">") are not used, in general. The name of +a rule is simply the name itself, rather than "<name>". +Quotation-marks enclose literal text (which may be upper and/or +lower case). Certain basic rules are in uppercase, such as +SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in +rule definitions, and in the rest of this document, whenever +their presence will facilitate discerning the use of rule names. + + +2. Parentheses: Local alternatives + +Elements enclosed in parentheses are treated as a single element. +Thus, "(elem (foo / bar) elem)" allows "(elem foo elem)" and +"(elem bar elem)". + + +3. * construct: Repetition + +The character "*" preceding an element indicates repetition. The +full form is: + + <l>*<m>element + +indicating at least <l> and at most <m> occurrences of element. +Default values are 0 and infinity so that "*(element)" allows any +number, including zero; "1*element" requires at least one; and +"1*2element" allows one or two. + +Standard for the Format of Text Messages 5 +III. Syntax + A. Notational Conventions + + + +4. <number>element + +"<n>(element)" is equivalent to "<n>*<n>(element)"; that is, +exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit +number, and 3ALPHA is a string of three alphabetic characters. + + +5. # construct: Lists + +A construct "#" is defined, similar to "*", as follows: + + <l>#<m>element + +indicating at least <l> and at most <m> elements, each separated +by one or more commas (","). This makes the usual form of lists +very easy; a rule such as '(element *("," element))' can be shown +as "1#element". Wherever this construct is used, null elements +are allowed, but do not contribute to the count of elements +present. That is, "(element),,(element)" is permitted, but +counts as only two elements. Therefore, where at least one +element is required, at least one non-null element must be +present. + + +6. [optional] + +Square brackets enclose optional elements; "[foo bar]" is +equivalent to "*1(foo bar)". + + +7. ; Comments + +A semi-colon, set off some distance to the right of rule text, +starts a comment which continues to the end of line. This is a +simple way of including useful notes in parallel with the +specifications. + + + +B. LEXICAL ANALYSIS OF MESSAGES + + +1. General Description + +A message consists of headers and, optionally, a body (i.e. a +series of text lines). The text part is just a sequence of lines +containing ASCII characters; it is separated from the headers by +a null line (i.e., a line with nothing preceding the CRLF). + + +Standard for the Format of Text Messages 6 +III. Syntax + B. Lexical Analysis + + + +a. Folding and unfolding of headers + + Each header item can be viewed as a single, logical line of + ASCII characters. For convenience, the field-body portion of + this conceptual entity can be split into a multiple-line + representation (i.e., "folded"). The general rule is that + wherever there can be linear-white-space (NOT simply LWSP- + chars), a CRLF immediately followed by AT LEAST one LWSP-char + can instead be inserted. (However, a header's name and the + following colon (":"), which occur at the beginning of the + header item, may NOT be folded onto multiple lines.) Thus, + the single line + + To: "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN + + can be represented as + + To: "Joe Dokes & J. Harvey" <ddd at Host>, + JJV at BBN + + and + + To: "Joe Dokes & J. Harvey" + <ddd at Host>, + JJV at BBN + + and + + To: "Joe Dokes + & J. Harvey" <ddd at Host>, JJV at BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line + representation will be called "unfolding". Unfolding is + accomplished by regarding CRLF immediately followed by a + LWSP-char as equivalent to the LWSP-char. + +b. Structure of header fields + + Once header fields have been unfolded, they may be viewed as + being composed of a field-name followed by a colon (":"), + followed by a field-body. The field-name must be composed of + printable ASCII characters (i.e., characters which have + values between 33. and 126., decimal, except colon) and + LWSP-chars. The field-body may be composed of any ASCII + characters (other than an unquoted CRLF, which has been + removed by unfolding). + + Certain field-bodies of header fields may be interpreted + according to an internal syntax which some systems may wish + to parse. These fields will be referred to as "structured" + fields. Examples include fields containing dates and + +Standard for the Format of Text Messages 7 +III. Syntax + B. Lexical Analysis + + + + addresses. Other fields, such as "Subject" and "Comments", + are regarded simply as strings of text. + + NOTE: Field-names, unstructured field bodies and structured + field bodies each are scanned by their own, INDEPENDENT + "lexical" analyzer. + +c. Field-names + + To aid in the creation and reading of field-names, the free + insertion of LWSP-chars is allowed in reasonable places. + + Rather than obscuring the syntax specification for field-name + with the explicit syntax for these LWSP-chars, the existence + of a "lexical" analyzer is assumed. The analyzer interprets + the text which comprises the field-name as a sequence of + field-name atoms (fnatoms) separated by LWSP-chars + + Note that ONLY LWSP-chars may occur between the fnatoms of a + field-name and that CRLFs may NOT. In addition, comments are + NOT lexically recognized, as such, but parenthesized strings + are legal as part of field-names. These constraints are + different from what is permissible within structured field + bodies. In particular, this means that header field-names + must wholly occur on the FIRST line of a folded header item + and may NOT be split across two or more lines. + +d. Unstructured field bodies + + For some fields, such as "Subject" and "Comments", no + structuring is assumed; and they are treated simply as texts, + like those in the message body. Rules of folding apply to + these fields, so that such field bodies which occupy several + lines must therefore have the second and successive lines + indented by at least one LWSP-char. + +e. Structured field bodies + + To aid in the creation and reading of structured fields, the + free insertion of linear-white-space (which permits folding + by inclusion of CRLFs) is allowed in reasonable places. + Rather than obscuring the syntax specifications for these + structured fields with explicit syntax for this linear- + white-space, the existence of another "lexical" analyzer is + assumed. This analyzer does not apply for field bodies which + are simply unstructured strings of text, as described above. + It provides an interpretation of the unfolded text comprising + the body of the field as a sequence of lexical symbols. + These symbols are: + + - individual special characters + - quoted-strings + +Standard for the Format of Text Messages 8 +III. Syntax + B. Lexical Analysis + + + + - comments + - atoms + + The first three of these symbols are self-delimiting. Atoms + are not; they therefore are delimited by the self-delimiting + symbols and by linear-white-space. For the purposes of re- + generating sequences of atoms and quoted-strings, exactly one + SPACE is assumed to exist and should be used between them. + (Also, in Section III.B.3.a, note the rules concerning + treatment of multiple continguous LWSP-chars.) + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Host, + Muhammed(I am the greatest)Ali at(the)WBA + + is analyzed into the following lexical symbols and types: + + ":sysmail" quoted string + @ special + Some-Host atom + , special + Muhammed atom + (I am the greatest) comment + Ali atom + at atom + (the) comment + WBA atom + + The cononical representations for the data in these addresses + are the following strings (note that there is exactly one + SPACE between words): + + :sysmail at Some-Host + + and + + Muhammed Ali at WBA + + + +2. Formal Definitions + +The first four rules, below, indicate a meta-syntax for fields, +without regard to their particular type or internal syntax. The +remaining rules define basic syntactic structures which are used +by the rules in Sections III.C, III.D, and III.E. + +field = field-name ":" [ field-body ] CRLF + +field-name = fnatom *( LWSP-char [fnatom] ) + + +Standard for the Format of Text Messages 9 +III. Syntax + B. Lexical Analysis + + + +fnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":"> + +field-body = field-body-contents + [CRLF LWSP-char field-body] + +field-body-contents = <the TELNET ASCII characters making up the + field-body, as defined in the following sections, + and consisting of combinations of atom, quoted- + string, and specials tokens, or else consisting of + texts> + + ; ( Octal, Decimal.) +CHAR = <any TELNET ASCII character> ; ( 0-177, 0.-127.) +ALPHA = <any TELNET ASCII alphabetic character> + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) +DIGIT = <any TELNET ASCII digit> ; ( 60- 71, 48.- 57.) +CTL = <any TELNET ASCII control ; ( 0- 37, 0.- 31.) + character and DEL> ; ( 177, 127.) +CR = <TELNET ASCII carriage return>;( 15, 13.) +LF = <TELNET ASCII linefeed> ; ( 12, 10.) +SPACE = <TELNET ASCII space> ; ( 40, 32.) +HTAB = <TELNET ASCII horizontal-tab>; ( 11, 9.) +<"> = <TELNET ASCII quote mark> ; ( 42, 34.) +CRLF = CR LF + +LWSP-char = SPACE / HTAB ; semantics = SPACE +linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + +specials = "(" / ")" / "<" / ">" / "@" ; To use in a word, + / "," / ";" / ":" / "\" / <"> ; word must be a + ; quoted-string. + +delimiters = specials / comment / linear-white-space + +text = <any CHAR, including bare ; => atoms, specials, + CR and/or bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT interpreted. + +atom = 1*<any CHAR except specials and CTLs> + +quoted-string = <"> *(qtext/quoted-pair) <">; Any number of qtext + ; chars or any + ; quoted char. + +qtext = <any CHAR excepting <"> ; => may be folded + and CR, and including + linear-white-space> + + +Standard for the Format of Text Messages 10 +III. Syntax + B. Lexical Analysis + + + +comment = "(" *(ctext / comment / quoted-pair) ")" +ctext = <any CHAR excluding "(", ; => may be folded + ")" and CR, and including + linear-white-space> + +quoted-pair = "\" CHAR + + +3. Clarifications + +a. "White space" + + Remember that in field-names and structured field bodies, + MULTIPLE LINEAR WHITE SPACE TELNET ASCII CHARACTERS (namely + HTABs and SPACEs) ARE TREATED AS SINGLE SPACES AND MAY FREELY + SURROUND ANY SYMBOL. In all header fields, the only place in + which at least one space is REQUIRED is at the beginning of + continuation lines in a folded field. When passing text to + processes which do not interpret text according to this + standard (e.g., ARPANET FTP mail servers), then exactly one + SPACE should be used in place of arbitrary linear-white-space + and comment sequences. + + WHEREVER A MEMBER OF THE LIST OF <DELIMITER>S IS ALLOWED, + LWSP-CHARS MAY ALSO OCCUR BEFORE AND/OR AFTER IT. + + Writers of mail-sending (i.e. header generating) programs + should realize that there is no Network-wide definition of + the effect of horizontal-tab TELNET ASCII characters on the + appearance of text at another Network host; therefore, the + use of tabs in message headers, though permitted, is + discouraged. + + Note that during transmissions across the ARPANET using + TELNET NVT connections, data must conform to TELNET NVT + conventions (e.g., CR must be followed by either LF, making a + CRLF, or <null>, if the CR is to stand alone). + +b. Comments + + Comments are detected as such only within field-bodies of + structured fields. A comment is a set of TELNET ASCII + characters, which is not within a quoted-string and which is + enclosed in matching parentheses; parentheses nest, so that + if an unquoted left parenthesis occurs in a comment string, + there must also be a matching right parenthesis. When a + comment is used to act as the delimiter between a sequence of + two lexical symbols, such as two atoms, it is lexically + equivalent with one SPACE, for the purposes of regenerating + the sequence, such as when passing the sequence onto an FTP + mail server. + + +Standard for the Format of Text Messages 11 +III. Syntax + B. Lexical Analysis + + + + In particular comments are NOT passed to the FTP server, as + part of a MAIL or MLFL command, since comments are not part + of the "formal" address. + + If a comment is to be "folded" onto multiple lines, then the + syntax for folding must be adhered to. (See items III.B.1.a, + above, and III.B.3.f, below.) Note that the official + semantics therefore do not "see" any unquoted CRLFs which are + in comments, although particular parsing programs may wish to + note their presence. For these programs, it would be + reasonable to interpret a "CRLF LWSP-char" as being a CRLF + which is part of the comment; i.e., the CRLF is kept and the + LWSP-char is discarded. Quoted CRLFs (i.e., a backslash + followed by a CR followed by a LF) still must be followed by + at least one LWSP-char. + +c. Delimiting and quoting characters + + The quote character (backslash) and characters which delimit + syntactic units are not, generally, to be taken as data which + are part of the delimited or quoted unit(s). The one + exception is SPACE. In particular, the quotation-marks which + define a quoted-string, the parentheses which define a + comment and the backslash which quotes a following character + are NOT part of the quoted-string, comment or quoted + character. A quotation-mark which is to be part of a + quoted-string, a parenthesis which is to be part of a comment + and a backslash which is to be part of either must each be + preceded by the quote-character backslash ("\"). Note that + the syntax allows any character to be quoted within a + quoted-string or comment; however only certain characters + MUST be quoted to be included as data. These characters are + those which are not part of the alternate text group (i.e., + ctext or qtext). + + A single SPACE is assumed to exist between contiguous words + in a phrase, and this interpretation is independent of the + actual number of LWSP-chars which the creator places between + the words. To include more than one SPACE, the creator must + make the LWSP-chars be part of a quoted-string. + + Quotation marks which delimit a quoted string and backslashes + which quote the following character should NOT accompany the + quoted-string when the string is used with processes that do + not interpret data according to this specification (e.g., + ARPANET FTP mail servers). + + +Standard for the Format of Text Messages 12 +III. Syntax + B. Lexical Analysis + + + +d. Quoted-strings + + Where permitted (i.e., in words in structured fields) + quoted-strings are treated as a single symbol (i.e. + equivalent to an atom, syntactically). If a quoted-string is + to be "folded" onto multiple lines, then the syntax for + folding must be adhered to. (See items III.B.1.a, above, and + III.B.3.f, below.) Note that the official semantics + therefore do not "see" any bare CRLFs which are in quoted- + strings, although particular parsing programs may wish to + note their presence. For these programs, it would be + reasonable to interpret a "CRLF LWSP-char" as being a CRLF + which is part of the quoted-string; i.e., the CRLF is kept + and the LWSP-char is discarded. Quoted CRLFs (i.e., a + backslash followed by a CR followed by a LF) are also subject + to rules of folding, but the presence of the quoting + character (backslash) explicitly indicates that the CRLF is + data to the quoted string. Stripping off the first following + LWSP-char is also appropriate when parsing quoted CRLFs. + +e. Bracketing characters + + There are three types of brackets which must be well nested: + + o Parentheses are used to indicate comments. + + o Angle brackets ("<" and ">") are generally used + to indicate the presence of at least one machine- + usable code (e.g., delimiting mailboxes). + + o Colon/semi-colon (":" and ";") are used in + address specifications to indicate that the + included list of addresses are to be treated as a + group. + +f. Case independence of certain specials atoms + + Certain atoms, which are represented in the syntax as literal + alphabetic strings, can be represented in any combination of + upper and lower case. These are: + + - field-name, + - "Include", "Postal" and equivalent atoms in a + ":"<atom>":" address specification, + - "at", in a host-indicator, + - node, + - day-of-week, + - month, and + - zones. + + When matching an atom against one of these literals, case is + to be ignored. For example, the field-names "From", "FROM", + +Standard for the Format of Text Messages 13 +III. Syntax + B. Lexical Analysis + + + + "from", and even "FroM" should all be treated identically. + However, the case shown in this specification is suggested + for message-creating processes. Note that, at the level of + this specification, case IS relevant to other words and + texts. Also see Section IV.A.1.f, below. + +g. Folding long lines + + Each header item (field of the message) may be represented on + exactly one line consisting of the name of the field and its + body; this is what the parser sees. For readability, it is + recommended that the field-body portion of long header items + be "folded" onto multiple lines of the actual header. "Long" + is commonly interpreted to mean greater than 65 or 72 + characters. The former length is recommended as a limit, but + it is not imposed by this standard. + +h. Backspace characters + + Backspace TELNET ASCII characters (ASCII BS, decimal 8.) may + be included in texts and quoted-strings to effect + overstriking; however, any use of backspaces which effects an + overstrike to the left of the beginning of the text or + quoted-string is prohibited. + + + +C. GENERAL SYNTAX OF MESSAGES: + + + NOTE: Due to an artifact of the notational conventions, + the syntax indicates that, when present, "Date", + "From", "Sender", and "Reply-To" fields must be + in a particular order. These header items must + be unique (occur exactly once). However header + fields, in fact, are NOT required to occur in any + particular order, except that the message body + must occur AFTER the headers. For readability + and ease of parsing by simple systems, it is + recommended that headers be sent in the order + "Date", "From", "Subject", "Sender", "To", "cc", + etc. This specification permits multiple + occurrences of most optional-fields. However, + their interpretation is not specified here, and + their use is strongly discouraged. + +The following syntax for the bodies of various fields should be +thought of as describing each field body as a single long string +(or line). The section on Lexical Analysis (section II.B) +indicates how such long strings can be represented on more than +one line in the actual transmitted message. + + +Standard for the Format of Text Messages 14 +III. Syntax + C. Messages + + + +message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + +fields = date-field ; Creation time-stamp + originator-fields ; & author id are + *optional-field ; required: others + ; are all optional + +originator-fields = + ( "From" ":" mailbox ; Single author + ["Reply-To" ":" #address] ) + / ( "From" ":" 1#address ; Multiple authors & + "Sender" ":" mailbox ; may have non-mach- + ["Reply-To" ":" #address] ); ine addresses + +date-field = "Date" ":" date-time + +optional-field = + "To" ":" #address + / "cc" ":" #address + / "bcc" ":" #address ; Blind carbon + / "Subject" ":" *text + / "Comments" ":" *text + / "Message-ID" ":" mach-id ; Only one allowed + / "In-Reply-To"":" #(phrase / mach-id) + / "References" ":" #(phrase / mach-id) + / "Keywords" ":" #phrase + / extension-field ; To be defined in + ; supplemental + ; specifications + / user-defined-field ; Must have unique + ; field-name & may + ; be pre-empted + +extension-field = <Any field which is defined in a document + published as a formal extension to this + specification> + +user-defined-field = <Any field which has not been defined in + this specification or published as an extension to + this specification; names for such fields must be + unique and may be preempted by published + extensions> + + + + +Standard for the Format of Text Messages 15 +III. Syntax + D. Addressee Items + + + +D. SYNTAX OF GENERAL ADDRESSEE ITEMS + + +address = host-phrase ; Machine mailbox + / ( [phrase] "<" #address ">") ; Individual / List + / ( [phrase] ":" #address ";") ; Group + / quoted-string ; Arbitrary text + / (":" ( "Include" ; File, w/ addr list + / "Postal" ; (U.S.) Postal addr + / atom ) ; Extended data type + ":" address) + +mailbox = host-phrase / (phrase mach-id) + +mach-id = "<" host-phrase ">" ; Contents must never + ; be modified! + + + +E. SUPPORTING CONSTRUCTS + + +host-phrase = phrase host-indicator ; Basic address + +host-indicator = 1*( ("at" / "@") node ) ; Right-most node is + ; at top of network + ; hierarchy; left- + ; most must be host + +node = word / 1*DIGIT ; Official host or + ; network name or + ; decimal address + + +date-time = [ day-of-week "," ] date time + +day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue" + / "Wednesday" / "Wed" / "Thursday" / "Thu" + / "Friday" / "Fri" / "Saturday" / "Sat" + / "Sunday" / "Sun" + +date = 1*2DIGIT ["-"] month ; day month year + ["-"] (2DIGIT /4DIGIT) ; e.g. 20 Aug [19]77 + +month = "January" / "Jan" / "February" / "Feb" + / "March" / "Mar" / "April" / "Apr" + / "May" / "June" / "Jun" + / "July" / "Jul" / "August" / "Aug" + / "September" / "Sep" / "October" / "Oct" + / "November" / "Nov" / "December" / "Dec" + + +Standard for the Format of Text Messages 16 +III. Syntax + E. Supporting Constructs + + + +time = hour zone ; ANSI and Military + ; (seconds optional) + +hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ] + ; 0000[00] - 2359[59] + +zone = ( ["-"] ( "GMT" ; Relative to GMT: + ; North American + / "NST" / ; Newfoundland:-3:30 + / "AST" / "ADT" ; Atlantic: - 4/ - 3 + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / "YST" / "YDT" ; Yukon: - 9/ - 8 + / "HST" / "HDT" ; Haw/Ala -10/ - 9 + / "BST" / "BDT" ; Bering: -11/ -10 + 1ALPHA )) ; Military: Z = GMT; + ; A:-1; (J not used) + ; M:-12; N:+1; Y:+12 + / ( ("+" / "-") 4DIGIT ) ; Local differential + ; hours/min. (HHMM) + +phrase = 1*word ; Sequence of words. + ; Separation seman- + ; tically = SPACE + +word = atom / quoted-string + + + +Standard for the Format of Text Messages 17 +IV. Semantics + A. Address Fields + + + + + + IV. SEMANTICS + + + +A. ADDRESS FIELDS + + +1. General + +a. The phrase part of a host-phrase in an address specification + (i.e., the host's name for the mailbox) is understood to be + whatever the receiving FTP Server allows (for example, TENEX + systems do not now understand addresses of the form "P. D. + Q. Bach", but another system might). + + Note that a mailbox is a conceptual entity which does not + necessarily pertain to file storage. For example, some sites + may choose to print mail on their line printer and deliver + the output to the addressee's desk. + + An individual may have several mailboxes and a group of + individuals may wish to receive mail as a single unit (i.e., + a distribution list). The second and third alternatives of + an address list (#address) allow naming a collection of + subordinate addresses list(s). Recipient mailboxes are + specified within the bracketed part ("<" - ">" or ":" - ";") + of such named lists. The use of angle-brackets ("<", ">") is + intended for the cases of individuals with multiple mailboxes + and of special mailbox lists; it is not expected to be nested + more than one level, although the specification allows such + nesting. The use of colon/semi-colon (":", ";") is intended + for the case of groups. Groups can be expected to nest + (i.e., to contain subgroups). For both individuals and + groups, a copy of the transmitted message is to be sent to + EACH mailbox listed. For the case of a special list, + treatment of addresses is defined in the relevant subsections + of this section. + +b. The inclusion of bare quoted-strings as addresses (i.e., the + fourth address-form alternative) is allowed as a syntactic + convenience, but no semantics are defined for their use. + However, it is reasonable, when replicating an address list, + to replicate ALL of its members, including quoted-strings. + +c. ":Include:" specifications are used to refer to one or more + locations containing stored address lists (#address). If + more than one location is referenced, the address part of the + Include phrase must be a list (#address) surrounded by + angle-brackets, as per the "Individual / List" alternative of + <address>. Constituent addresses must resolve to a host- + +Standard for the Format of Text Messages 18 +IV. Semantics + A. Address Fields + + + + phrase; only they have any meaning within this construct. + The phrase part of indicated host-phrases should contain text + which the referenced host can resolve to a file. This + standard is not a protocol and so does not prescribe HOW data + is to be retrieved from the file. However, the following + requirements are made: + + o The file must be accessible through the local + operating system interface (if it exists), given + adequate user access rights; and + + o If a host has an FTP server and a user is able + to retrieve any files from the host using that + server, then the file must be accessible through + FTP, using DEFAULT transfer settings, given + adequate user access rights. + + It is intended that this mechanism allow programs to retrieve + such lists automatically. + + The interpretation of such a file reference follows. This is + not intended to imply any particular implementation scheme, + but is presented to aid in understanding the notion of + including file contents in address lists: + + o Elements of the address list part are alternates + and the contents of ONLY ONE of them are to be + included in the resultant address list. + + o The contents of the file indicated by a member + host-phrase are treated as an address list and + are inserted as an address list (#address) in + the position of the path item in the syntax. + That is, the TELNET ASCII characters specifying + the entire Include <address> is replaced by the + contents of one of the files to which the host- + phrase(s), of the address list (#address), + refers. Therefore, the contents of each file, + indicated by an Include address, must be + syntactically self-contained and must adhere to + the full syntax prescribed herein for an address + list. + +d. ":Postal:" specifications are used to indicate (U.S.) postal + addresses, but can be treated the same as quoted-string + addresses. To reference a list of postal addresses, the list + must conform to the "Individual / List" alternative of + <address>. The ":Include:" alternative also is valid. + +e. The "':' atom ':'" syntax is intended as a general mechanism + for indicating specially data-typed addresses. As with + extension-fields, the authors of this document will regulate + +Standard for the Format of Text Messages 19 +IV. Semantics + A. Address Fields + + + + the publishing of specifications for these extended data- + types. In the absence of defined semantics, any occurrence + of an address in this form may be treated as a quoted-string + address. + +f. A node name must be THE official name of a network or a host, + or else a decimal number indicating the Network address for + that network or host, at the time the message is created. + The USE OF NUMBERS IS STRONGLY DISCOURAGED and is permitted + only due to the occasional necessity of bypassing local name + tables. For the ARPANET, official names are maintained by + the Network Information Center at SRI International, Menlo + Park, California. + + Whenever a message might be transmitted or migrate to a host + on another network, full hierarchical addresses must be + specified. These are indicated as a series of words, + separated by at-sign or "at" indications. The communication + environment is assumed to consist of a collection of networks + organized as independent "trees" except for connections + between the root nodes. That is, only the roots can act as + gateways between these independent networks. While other + actual connections may exist, it is believed that presuming + this type of organization will provide a reliable method for + describing VALID, if not EFFICIENT, paths between hosts. A + typical full mailbox specification might therefore look like: + + Friendly User @ hosta @ local-net1 @ major-netq + + In the simplest case, a mail-sending host should transmit the + message to the node which is mentioned last (farthest to the + right), strip off that node reference from the specification, + and then pass the remaining host-phrase to the recipient host + (in the ARPANET, its FTP server) for it to process. This + treats the remaining portion of the host-indicator merely as + the terminating part of the phrase. + + NOTE: When passing any portion of a host-indicator + onto a process which does not interpret data + according to this standard (e.g., ARPANET + FTP servers), "@" must be used and not "at" + and it must not be preceded or followed by + any LWSP-chars. Using the above example, + the following string would be passed to the + major-netq gateway: + + Friendly User@hosta@local-net1 + + When the sending host has more knowledge of the network + environment, then it should send the message along a more + efficient path, making appropriate changes to the form of the + host-phrase which it gives to the recipient host. + +Standard for the Format of Text Messages 20 +IV. Semantics + A. Address Fields + + + + To use the above specification as an example: If a sending + hostb also were part of local-net1, then it could send the + message directly to hosta and would give only the phrase + "Friendly User" to hosta's mail-receiving program. If hostb + were part of local-net2, along with hostc, and happened to + know that hosta and hostc were part of another local-net, + then hostb could send the message to hostc to the address + "Friendly User@hosta". + + The phrase in a host-phrase is intended to be meaningful only + to the indicated receiving host. To all other hosts, the + phrase is to be treated as an uninterpreted string. No case + transformations should be (automatically) performed on the + phrase. The phrase is passed to the local host's mail + sending program; it is the responsibility of the destination + host's mail receiving (distribution) program to perform case + mapping on this phrase, if required, to deliver the mail. + + +2. Originator Fields + + WARNING: The standard allows only a subset of the + combinations possible with the From, Sender, + and Reply-To fields. The limitation is + intentional. + +a. From + + This field contains the identity of the person(s) who wished + this message to be sent. The message-creation process should + default this field to be a single machine address, indicating + the AGENT (person or process) entering the message. If this + is NOT done, the "Sender" field MUST be present; if this IS + done, the "Sender" field is optional. + +b. Sender + + This field contains the identity of the AGENT (person or + process) who sends the message. It is intended for use when + the sender is not the author of the message, or to indicate + who among a group of authors actually sent the message. If + the contents of the "Sender" field would be completely + redundant with the "From" field, then the "Sender" field need + not be present and its use is discouraged (though still + legal); in particular, the "Sender" field MUST be present + if it is NOT the same as the "From" Field. + + The Sender host-phrase includes a phrase which must + correspond to a specific agent (i.e., a human user or a + computer program) rather than a standard address. This + indicates the expectation that the field will identify the + single AGENT (person or process) responsible for sending the + +Standard for the Format of Text Messages 21 +IV. Semantics + A. Address Fields + + + + mail and not simply include the name of a mailbox from which + the mail was sent. For example in the case of a shared login + name, the name, by itself, would not be adequate. The phrase + part of the host-phrase, which refers to this agent, is + expected to be a computer system term, and not (for example) + a generalized person reference which can be used outside the + network text message context. + + Since the critical function served by the "Sender" field is + the identification of the agent responsible for sending mail + and since computer programs cannot be held accountable for + their behavior, is strongly recommended that when a computer + program generates a message, the HUMAN who is responsible for + that program be referenced as part of the "Sender" field + host-phrase. + +c. Reply-To + + This field provides a general mechanism for indicating any + mailbox(es) to which responses are to be sent. Three typical + uses for this feature can be distinguished. In the first + case, the author(s) may not have regular machine-based + mailboxes and therefore wish(es) to indicate an alternate + machine address. In the second case, an author may wish + additional persons to be made aware of, or responsible for, + responses; responders should send their replies to the + "Reply-To" mailbox(es) listed in the original message. A + somewhat different use may be of some help to "text message + teleconferencing" groups equipped with automatic distribution + services: include the address of that service in the + "Reply-To" field of all messages submitted to the + teleconference; then participants can "reply" to conference + submissions to guarantee the correct distribution of any + submission of their own. + + Reply-To fields are NOT required to contain any machine + addresses (i.e., host-phrases). Note, however, that the + absence of even one valid network address will tend to + prevent software systems from automatically assisting users + in conveniently responding to mail. + +NOTE: For systems which automatically generate address lists for +replies to messages, the following recommendations are made: + + o The receiver, when replying to a message, should + NEVER automatically include the "Sender" host-phrase + in the reply's address list; + + o If the "Reply-To" field exists, then the reply + should go ONLY to the addresses indicated in that + field and not to the addresses indicated in the + "From" field. + +Standard for the Format of Text Messages 22 +IV. Semantics + A. Address Fields + + + +(Extensive examples are provided in Section V.) This +recommendation is intended only for originator-fields and is not +intended to suggest that replies should not also be sent to the +other recipients of this message. It is up to the respective +mail handling programs to decide what additional facilities will +be provided. + + +3. Receiver Fields + +a. To + + This field contains the identity of the primary recipients of + the message. + +b. cc + + This field contains the identity of the secondary recipients + of the message. + +b. Bcc + + This field contains the identity of additional recipients of + the message. The contents of this field are not included in + copies of the message sent to the primary and secondary + recipients. Some systems may choose to include the text of + the "Bcc" field only in the author(s)'s copy, while others + may also include it in the text sent to all those indicated + in the "Bcc" list. + + + +B. REFERENCE SPECIFICATION FIELDS + + +1. Message-ID + +This field contains a unique identifier (the phrase) which refers +to THIS version of THIS message. The uniqueness of the message +identifier is guaranteed by the host which generates it. This +identifier is intended to be machine readable and not necessarily +meaningful to humans. A message identifier pertains to exactly +one instantiation of a particular message; subsequent revisions +to the message should each receive a new message identifier. + + +2. In-Reply-To + +The contents of this field identify previous correspondence which +this message answers. Note that if message identifiers are used +in this field, they must use the mach-id specification format. + + +Standard for the Format of Text Messages 23 +IV. Semantics + B. Reference Specification Fields + + + +3. References + +The contents of this field identify other correspondence which +this message references. Note that if message identifiers +are used, they must use the mach-id specification format. + + +4. Keywords + +This field contains keywords or phrases, separated by commas. + + + +C. OTHER FIELDS AND SYNTACTIC ITEMS + + +1. Subject + +The "Subject" field is intended to provide as much information as +necessary to adequately summarize or indicate the nature of the +message. + + +2. Comments + +Permits adding text comments onto the message without disturbing +the contents of the message's body. + + +3. Extension-field + +A relatively limited number of common fields have been defined in +this document. As network mail requirements dictate, additional +fields may be standardized. The authors of this document will +regulate the publishing of such definitions as extensions to the +basic specification. + + +4. User-defined-field + +Individual users of network mail are free to define and use +additional header fields. Such fields must have names which are +not already used in the current specification or in any +definitions of extension-fields, and the overall syntax of these +user-defined-fields must conform to this specification's rules +for delimiting and folding fields. Due to the extension-field +publishing process, the name of a user-defined-field may be pre- +empted. + + + + +Standard for the Format of Text Messages 24 +IV. Semantics + D. Dates + + + +D. DATES AND TIMES + +If included, day-of-week must be the day implied by the date +specification. + +Time zone may be indicated in several ways. The military +standard uses a single character for each zone. "Z" is +Greenwhich Mean Time; "A" indicates one hour earlier, and "M" +indicates 12 hours earlier; "N" is one hour later, and "Y" is 12 +hours later. The letter "J" is not used. The other remaining +two forms are taken from ANSI standard X3.51-1975. One allows +explicit indication of the amount of offset from GMT; the other +uses common 3-character strings for indicating time zones in +North America. + + +Standard for the Format of Text Messages 25 +V. Examples +A. Addresses + + + + + + V. EXAMPLES + + +A. ADDRESSES + + +1. Alfred E. Neuman <Neuman at BBN-TENEXA> + +2. Neuman@BBN-TENEXA + +These two "Alfred E. Neuman" examples have identical semantics, +as far as the operation of the local host's mail sending +(distribution) program (also sometimes called its "mailer") and +the remote host's FTP server are concerned. In the first +example, the "Alfred E. Neuman" is ignored by the mailer, as +"Neuman at BBN-TENEXA" completely specifies the recipient. The +second example contains no superfluous information, and, again, +"Neuman@BBN-TENEXA" is the intended recipient. + + +3. Al Neuman at BBN-TENEXA + +This is identical to "Al Neuman <Al Neuman at BBN-TENEXA>". That +is, the full phrase, "Al Neuman", is passed to the FTP server. +Note that not all FTP servers accept multi-word identifiers; and +some that do accept them will treat each word as a different +addressee (in this case, attempting to send a copy of the message +to "Al" and a copy to "Neuman"). + + +4. "George Lovell, Ted Hackle" <Shared-Mailbox at Office-1> + +This form might be used to indicate that a single mailbox is +shared by several users. The quoted string is ignored by the +originating host's mailer, as "Shared-Mailbox at Office-1" +completely specifies the destination mailbox. + + +4. Wilt (the Stilt) Chamberlain at NBA + +The "(the Stilt)" is a comment, which is NOT included in the +destination mailbox address handed to the originating system's +mailer. The address is the string "Wilt Chamberlain", with +exactly one space between the first and second words. (The +quotation marks are not included.) + + + + +Standard for the Format of Text Messages 26 +V. Examples +B. Address Lists + + + +B. ADDRESS LISTS + + Gourmets: Pompous Person <WhoZiWhatZit at Cordon-Bleu>, + Cooks: Childs at WGBH, Galloping Gourmet at + ANT (Australian National Television);, + Wine Lovers: Cheapie at Discount-Liquors, + Port at Portugal;;, + Jones at SEA + +This group list example points out the use of comments, the +nesting of groups, and the mixing of addresses and groups. Note +that the two consecutive semi-colons preceding "Jones at SEA" +mean that Jones is NOT a member of the Gourmets group. + + +C. ORIGINATOR ITEMS + + +1. Author-sent + +George Jones logs into his Host as "Jones". He sends mail +himself. + + From: Jones at Host +or + From: George Jones <Jones at Host> + + +2. Secretary-sent + +George Jones logs in as Jones on his Host. His secretary, who +logs in as Secy on Shost sends mail for him. Replies to the mail +should go to George, of course. + + From: George Jones <Jones at Host> + Sender: Secy at SHost + + +3. Shared directory or unrepresentative directory-name + +George Jones logs in as Group at Host. He sends mail himself; +replies should go to the Group mailbox. + + From: George Jones <Group at Host> + + + +Standard for the Format of Text Messages 27 +V. Examples +C. Originator Items + + + +4. Secretary-sent, for user of shared directory + +George Jones' secretary sends mail for George in his capacity as +a member of Group while logged in as Secy at Host. Replies +should go to Group. + + From: George Jones<Group at Host> + Sender: Secy at Host + +Note that there need not be a space between "Jones" and the "<", +but adding a space enhances readability (as is the case in other +examples). + + +5. Secretary acting as full agent of author + +George Jones asks his secretary (Secy at Host) to send a message +for him in his capacity as Group. He wants his secretary to +handle all replies. + + From: George Jones <Group at Host> + Sender: Secy at Host + Reply-To: Secy at Host + + +6. Agent for user without online mailbox + +A non-ARPANET user friend of George's, Sarah, is visting. +George's secretary sends some mail to a friend of Sarah in +computer-land. Replies should go to George, whose mailbox is +Jones at Host. + + From: Sarah Friendly + Sender: Secy at Host + Reply-To: Jones at Host + + +7. Sent by member of a committee + +George is a member of a committee. He wishes to have any replies +to his message go to all committee members. + + From: George Jones + Sender: Jones at Host + Reply-To: Big-committee: Jones at Host, + Smith at Other-Host, + Doe at Somewhere-Else; + +Note that if George had not included himself in the enumeration +of Big-committee, he would not have gotten an implicit reply; the +presence of the "Reply-to" field SUPERSEDES the sending of a +reply to the person named in the "From" field. + +Standard for the Format of Text Messages 28 +V. Examples +C. Originator Items + + + +8. Example of INCORRECT use + +George desires a reply to go to his secretary; therefore his +secretary leaves his mailbox address off the "From" field, +leaving only his name, which is not, itself, a mailbox address. + + From: George Jones + Sender: Secy at SHost + +THIS IS NOT PERMITTED. Replies are NEVER implicitly sent to the +"Sender"; George's secretary should have used the "Reply-To" +field, or the mail creating program should have forced the +secretary to. + +9. Agent for member of a committee + +George's secretary sends out a message which was authored jointly +by all the members of the "Big-committee". + + From: Big-committee: Jones at Host, + Smith at Other-Host, + Doe at Somewhere-Else; + Sender: Secy at SHost + + + +D. COMPLETE HEADERS + + +1. Minimum required: + + Date: 26 August 1976 1429-EDT + From: Jones at Host + + +2. Using some of the additional fields: + + Date: 26 August 1976 1430-EDT + From:George Jones<Group at Host> + Sender:Secy at SHOST + To:Al Neuman at Mad-Host, + Sam Irving at Other-Host + Message-ID: <some string at SHOST> + + + +Standard for the Format of Text Messages 29 +V. Examples +D. Complete Headers + + + +3. About as complex as you're going to get: + + Date : 27 Aug 1976 0932-PDT + From : Ken Davis <KDavis at Other-Host> + Subject : Re: The Syntax in the RFC + Sender : KSecy at Other-Host + Reply-To : Sam Irving at Other-Host + To : George Jones <Group at Host>, + Al Neuman at Mad-Host + cc : Important folk: + Tom Softwood <Balsa at Another-Host>, + Sam Irving at Other-Host;, + Standard Distribution::Include: + </main/davis/people/standard at Other-Host, + "<Jones>standard.dist.3" at Tops-20-Host>, + (The following Included Postal list is part + of Standard Distribution.) + :Postal::Include: Non-net-addrs@Other-host;, + :Postal: "Sam Irving, P.O. Box 001, Las Vegas, + Nevada" (So that he can stay + apprised of the situation) + Comment : Sam is away on business. He asked me to handle + his mail for him. He'll be able to provide a + more accurate explanation when he returns + next week. + In-Reply-To: <some string at SHOST> + Special (action): This is a sample of multi-word field- + names, using a range of characters. There + could also be a field-name "Special (info)". + Message-ID: <4231.629.XYzi-What at Other-Host> + + +Standard for the Format of Text Messages 31 +Appendix +A. Alphabetical Listing of Syntax Rules + + + + + + APPENDIX + + + +A. ALPHABETICAL LISTING OF SYNTAX RULES + + +address = host-phrase / quoted-string + / (*phrase "<" #address ">" ) + / (*phrase ":" #address ";" ) + / (":" ("Include" / "Postal" / atom) ":" address) +ALPHA = <any TELNET ASCII alphabetic character> +atom = 1*<any CHAR except specials and CTLs> + +CHAR = <any TELNET ASCII character> +comment = "(" *(ctext / comment / quoted-pair) ")" +CR = <TELNET ASCII carriage return> +CRLF = CR LF +ctext = <any CHAR excluding "(", ")", CR, LF and + including linear-white-space> +CTL = <any TELNET ASCII control character and DEL> + +date = 1*2DIGIT ["-"] month ["-"] (2DIGIT /4DIGIT) +date-field = "Date" ":" date-time +date-time = [ day-of-week "," ] date time +day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue" + / "Wednesday" / "Wed" / "Thursday" / "Thu" + / "Friday" / "Fri" / "Saturday" / "Sat" + / "Sunday" / "Sun" +delimiters = specials / comment / linear-white-space +DIGIT = <any TELNET ASCII digit> + +extension-field = <Any field which is defined in a document + published as a formal extension to this + specification> + +field = field-name ":" [ field-body ] CRLF + +fields = date-field originator-fields *optional-field +field-body = field-body-contents + [CRLF LWSP-char field-body] +field-body-contents = <the TELNET ASCII characters making up the + field-body, as defined in the following sections, + and consisting of combinations of atom, quoted- + string, and specials tokens, or else consisting of + texts> +field-name = fnatom *(LWSP-char [fnatom]) +fnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":"> + + +Standard for the Format of Text Messages 32 +Appendix +A. Alphabetical Listing of Syntax Rules + + + +host-indicator = 1*( ("at" / "@") node ) +host-phrase = phrase host-indicator +hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ] +HTAB = <TELNET ASCII horizontal-tab> + +LF = <TELNET ASCII linefeed> +linear-white-space = 1*([CRLF] LWSP-char) +LWSP-char = SPACE / HTAB + +mach-id = "<" host-phrase ">" +mailbox = host-phrase / (phrase mach-id) +message = fields *(CRLF *text) +month = "January" / "Jan" / "February" / "Feb" + / "March" / "Mar" / "April" / "Apr" + / "May" / "June" / "Jun" + / "July" / "Jul" / "August" / "Aug" + / "September" / "Sep" / "October" / "Oct" + / "November" / "Nov" / "December" / "Dec" + +node = word / 1*DIGIT + +optional-field = + "To" ":" #address + / "cc" ":" #address + / "bcc" ":" #address + / "Subject" ":" *text + / "Comments" ":" *text + / "Message-ID" ":" mach-id + / "In-Reply-To"":" #(phrase / mach-id) + / "References" ":" #(phrase / mach-id) + / "Keywords" ":" #phrase + / extension-field + / user-defined-field +originator-fields = + ( "From" ":" mailbox + ["Reply-To" ":" #address] ) + / ( "From" ":" 1#address + "Sender" ":" mailbox + ["Reply-To" ":" #address] ) + +phrase = 1*word + +quoted-pair = "\" CHAR +quoted-string = <"> *(qtext / quoted-pair) <"> +qtext = <any CHAR except <">, CR, or LF and including + linear-white-space> +SPACE = <TELNET ASCII space> +specials = "(" / ")" / "<" / ">" / "@"/ "," / ";" / ":" + / "\" / <"> + +text = <any CHAR, including bare CR and/or bare LF, but + NOT including CRLF> + +Standard for the Format of Text Messages 33 +Appendix +A. Alphabetical Listing of Syntax Rules + + + +time = hour zone + +user-defined-field = <Any field which has not been defined in + this specification or published as an extension to + this specification; names for such fields must be + unique and may be preempted by putlished + extensions> + +word = atom / quoted-string + +zone = ( ("+" / "-") 4DIGIT ) + / ( ["-"] (1ALPHA + / "GMT" / "NST" / "AST" / "ADT" / "EST" / "EDT" + / "CST" / "CDT" / "MST" / "MDT" / "PST" / "PDT" + / "YST" / "YDT" / "HST" / "HDT" / "BST" / "BDT" )) + +<"> = <TELNET ASCII quote mark> + + +Standard for the Format of Text Messages 35 +Appendix +B. Simple Parsing + + + + +B. SIMPLE PARSING + + + Some mail-reading software systems may wish to perform only +minimal processing, ignoring the internal syntax of structured +field-bodies and treating them the same as unstructured-field- +bodies. Such software will need only to distinguish: + + - Header fields from the message body, + - Beginnings of fields from lines which continue fields, + - Field-names from field-contents. + + The abbreviated set of syntactic rules which follows will +suffice for this purpose. They describe a limited view of +messages and are a subset of the syntactic rules provided in the +main part of this specification. One small exception is that the +contents of field-bodies consist only of text: + + +SYNTAX: + +message = *field *(CRLF *text) + +field = field-name ":" [field-body] CRLF + +field-name = fnatom *( LWSP-char [fnatom] ) + +fnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":"> + + +field-body = *text [CRLF LWSP-char field-body] + + +SEMANTICS: + + Headers occur before the message body and are terminated by +a null line (i.e., two contiguous CRLFs). + + A line which continues a header field begins with a SPACE or +HTAB character, while a line beginning a field starts with a +printable character which is not a colon. + + A field-name consists of one or more printable characters +(excluding colon), each separated by one or more SPACES or HTABS. +A field-name MUST be contained on one line. Upper and lower case +are not distinguished when comparing field-names. + + +Standard for the Format of Text Messages 37 +Bibliography + + + + + + + BIBLIOGRAPHY + + +ANSI. Representations of universal time, local time + differentials, and United States time zone references for + information interchange. ANSI X3.51-1975; American National + Standards Institute: New York, 1975. + +Bhushan, A.K. The File Transfer Protocol. ARPANET Request for + Comments, No. 354, Network Information Center No. 10596; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, July 1972. + +Bhushan, A.K. Comments on the File Transfer Protocol. ARPANET + Request for Comments, No. 385, Network Information Center No. + 11357; Augmentation Research Center, Stanford Research + Institute: Menlo Park, August 1972. + +Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. + Standardizing Network Mail Headers. ARPANET Request for + Comments, No. 561, Network Information Center No. 18516; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, September 1973. + +Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook. + Network Information Center No. 7104; Augmentation Research + Center, Stanford Research Institute: Menlo Park, April 1976. + (NTIS AD A003890). + +McKenzie, A. File Transfer Protocol. ARPANET Request for + Comments, No. 454, Network Information Center No. 14333; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, February 1973. + +McKenzie, A. TELNET Protocol Specification. Network Information + Center No. 18639; Augmentation Research Center, Stanford + Research Institute: Menlo Park, August 1973. + +Myer, T.H. and Henderson, D.A. Message Transmission Protocol. + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116; Augmentation Research Center, Stanford + Research Institute: Menlo Park, 1975. + +Neigus, N. File Transfer Protocol. ARPANET Request for + Comments, No. 542, Network Information Center No. 17759; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, July 1973. + +Pogran, K., Vittal, J., Crocker, D. and Henderson, A. Proposed + official standard for the format of ARPA network messages. + +Standard for the Format of Text Messages 38 +Bibliography + + + + + ARPANET Request for Comments, No. 724, Network Information + Center No. 37435; Augmentation Research Center, Stanford + Research Institute: Menlo Park, May 1977. + +Postel, J.B. Revised FTP Reply Codes. ARPANET Request for + Comments, No. 640, Network Information Center No. 30843; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, June 1974. +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc772.txt b/Documentation/en/rfc/rfc772.txt new file mode 100644 index 00000000..bd6fdefb --- /dev/null +++ b/Documentation/en/rfc/rfc772.txt @@ -0,0 +1,1798 @@ + + +Network Working Group S. Sluizer +Request for Comments: 772 J. Postel + ISI + September 1980 + + MAIL TRANSFER PROTOCOL + + +PREFACE + + This is a first draft of this protocol and comments are very + definitely requested. + +INTRODUCTION + + The objective of Mail Transfer Protocol (MTP) is to transfer mail + reliably and efficiently. + + This paper assumes knowledge of the following protocols described in + the ARPA Internet Protocol Handbook. The reader will note strong + similarities to portions of the File Transfer Protocol; in part, this + is due to the original ARPA Network implementation of computer mail + as a feature of FTP. + + The ARPANET Host-to-Host Protocol [Network Control Protocol] (NCP) + + The Transmission Control Protocol (TCP) + + The TELNET Protocol (TELNET) + + The File Transfer Protocol (FTP) + +DISCUSSION + + In this section, the terminology and the MTP model are discussed. + The terms defined in this section are only those that have special + significance in MTP. Some of the terminology is very specific to the + MTP model; some readers may wish to turn to the section on the MTP + model while reviewing the terminology. + + TERMINOLOGY + + ASCII + + The ASCII character set as defined in the ARPA Internet + Protocol Handbook. In MTP, ASCII characters are defined to be + the lower half of an eight-bit code set (i.e., the most + significant bit is zero) and is called NVT-ASCII. + + + + + + + 1 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + control connection + + The TCP full-duplex communication path or two NCP simplex + communication paths between a sender-MTP and a receiver-MTP for + the exchange of commands, replies, and mail text. The control + connection operates according to the TELNET Protocol. + + data mode + + The mail is transmitted over the control connection as a stream + of octets. (In FTP terminology this is called stream mode.) + + data structure + + The internal structure of mail is considered to be a continuous + sequence of data octets. (In FTP terminology this is called + file-structure.) + + data representation + + The internal representation of all data (i.e., mail) is in + NVT-ASCII. + + host + + A computer in the internetwork environment on which mailboxes + reside. + + MTP commands + + A set of commands which comprise the control information + flowing from the sender-MTP to the receiver-MTP. + + mail + + An ordered set of computer data of arbitrary length, which + conforms to the standard set in RFC 733 (Standard for the + Format of ARPA Network Text Messages). + + mailbox + + A character string (address) which identifies a user to whom + mail is to be sent. Mailbox normally consists of the host and + user specifications. The standard mailbox naming convention is + defined to be "user@host". Additionally, the "container" in + which mail is stored. + + + + 2 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + NVT + + The Network Virtual Terminal as defined in the TELNET Protocol. + + octet + + Bytes in MTP are octets (8 bits). This is not necessarily the + same byte size in which data is stored in a host. + + reply + + A reply is an acknowledgment (positive or negative) sent from + receiver to sender via the control connection in response to a + MTP command. The general form of a reply is a completion code + (including error codes) followed by a text string. The codes + are for use by programs and the text is usually intended for + human users. + + receiver-MTP process + + A process which transfers mail in cooperation with a sender-MTP + process. It "listens" on its port/socket L for a connection + from a sender-MTP and establishes a control connection using + the TELNET Protocol. It receives MTP commands from the + sender-MTP, sends replies, and governs the transfer of mail. + + sender-MTP process + + A process which transfers mail in cooperation with a + receiver-MTP process. A local language may be used in the user + interface command/reply dialogue. The sender-MTP initiates the + control connection from its port/socket U to the receiver-MTP + process. It initiates MTP commands, receives replies, and + governs the transfer of mail. + + user + + A human being (or a process on behalf of a human being) wishing + to obtain mail transfer service. In addition, a recipient of + computer mail. + + + + + + + + + + 3 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + THE MTP MODEL + + With the above definitions in mind, the following model (shown in + Figure 1) may be diagrammed for an MTP service. + + ------------ ------------ + | | | | -------- + | | MTP | |<-->| User | + | Receiver-|Commands/Replies| Sender- | -------- + -------- | MTP |<-------------->| MTP | -------- + | Mail |<-->| | Mail | |<-->| Mail | + |System| | | | | |System| + -------- ------------ ------------ -------- + + + Receiver-MTP Sender-MTP + + Model for MTP Use + + Figure 1 + + In the model described in Figure 1, the sender-MTP initiates the + TCP/NCP control connection which follows the TELNET Protocol. At + the initiation of the user, standard MTP commands are generated by + the sender-MTP and transmitted to the receiver-MTP via the control + connection. Standard replies are sent from the receiver-MTP to + the sender-MTP over the control connection in response to the + commands. In addition, mail is sent over the control connection. + +MAIL TRANSFER FUNCTIONS + + The control connection is used for the transfer of commands which + describe the functions to be performed, the replies to commands, as + well as the actual transfer of mail. Mail is transferred only via + the control connection. + + The communication channel from the sender-MTP to the receiver-MTP is + established by a TCP/NCP control connection from the sender to a + standard receiver port/socket. The sender-MTP is responsible for + sending MTP commands, interpreting the replies received, and sending + the mail; the receiver-MTP interprets commands, sends replies, and + receives the mail. + + + + + + + + 4 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + MAIL REPRESENTATION AND STORAGE + + Mail is transferred from a storage device in the sending host to a + storage device in the receiving host. It may be necessary to + perform certain transformations on the mail because data storage + representations in the two systems are different. For example, + NVT-ASCII has different data storage representations in different + systems. PDP-10's generally store NVT-ASCII as five 7-bit ASCII + characters, left-justified in a 36-bit word. 360's store + NVT-ASCII as four 8-bit EBCDIC codes in a 32-bit word. Multics + stores NVT-ASCII as four 9-bit characters in a 36-bit word. + + For the sake of simplicity, all data must be represented in MTP as + NVT-ASCII. This means that characters must be converted into the + standard NVT-ASCII representation when transmitting text, + regardless of whether the sending and receiving hosts are + dissimilar. The sender converts the data from its internal + character representation to the standard 8-bit NVT-ASCII + representation (see the TELNET specification). The receiver + converts the data from the standard form to its own internal form. + In accordance with this standard, the <CRLF> sequence should be + used to denote the end of a line of text. + + The mail in MTP has no internal structure and is considered to be + a continuous sequence of data octets. + + ERROR RECOVERY AND RESTART + + There is no provision for detecting bits lost or scrambled in data + transfer; this level of error control is handled by the TCP/NCP. + In addition, there is no restart procedure provided to protect + senders from gross system failures (including failures of a host, + an MTP-process, or the underlying network). + +MTP COMMANDS + + COMMAND SEMANTICS + + The MTP commands define the mail transfer or the mail system + function requested by the user. The syntax of mailboxes must + conform to receiver site conventions (with standard defaults + applicable). In response to an MTP transfer command, the mail + shall always be transferred over the control connection. + + The Mail Transfer Protocol follows the specifications of the + TELNET Protocol for all communications over the control + + + + 5 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + connection. Although the language used for TELNET communication + can be a negotiated option, the "TELNET language" and the + corresponding "TELNET end of line code" are required to be + NVT-ASCII and <CRLF> respectively. No other specifications of the + TELNET Protocol will be cited. + + MTP commands are NVT-ASCII strings terminated by <CRLF>. The + command codes themselves are alphabetic characters terminated by + the character <SP> (space) if parameters follow and <CRLF> + otherwise. + + The MTP commands are discussed below. In the description of a few + of the commands in this section the possible replies are given + explicitly. MTP replies are discussed in the next section. + + MAIL (MAIL) + + This command allows a sender-MTP to send mail over the + control connection. The argument field contains a sender + and optional path sequence. If the path sequence is + present, it consists of an optional list of hosts and a + destination mailbox. When the list of hosts is present, it + is source routing information and indicates that the mail + must be forwarded to the first host on the list. Following + this command line the receiver treats all subsequent + characters as mail text from the sender. The mail text is + terminated by the character sequence "CRLF.CRLF". + + As mail is forwarded along the path sequence, each + forwarding host must remove itself from the list. When mail + reaches its ultimate destination (the path sequence has only + a (possibly empty) destination mailbox), the receiver + inserts it into the destination mailbox in accordance with + its host mail conventions. If the second argument field is + blank (one or more spaces) or empty (<CRLF>), the mail is + destined for a printer or other designated place for site + general delivery mail. The mail may be marked as sent from + the sender as specified by the first argument field. + + MAIL RECIPIENT SCHEME QUESTION (MRSQ) + + This MTP command is used to select a scheme for the + transmission of mail to several users at the same host. The + schemes are to list the recipients first, or to send the + mail first. + + + + + 6 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + MAIL RECIPIENT (MRCP) + + This command is used to identify the individual recipients + of the mail in the transmission of mail for multiple users + at one host. + + HELP (HELP) + + This command causes the receiver to send helpful information + regarding its implementation status over the control + connection to the receiver. The command may take an + argument (e.g., any command name) and return more specific + information as a response. The reply is type 211 or 214. + + QUIT (QUIT) + + This command specifies that the receiver must close the + control connection. + + NOOP (NOOP) + + This command does not affect any parameters or previously + entered commands. It specifies no action other than that + the receiver send an OK reply. + + COMMAND SYNTAX + + The commands (and their functions and semantics) are TELNET + NVT-ASCII strings transmitted over the control connection. The + functions and semantics of commands are described in the section + on MTP Commands. The reply sequences are discussed in the section + on Sequencing of Commands and Replies. Scenarios illustrating the + use of commands are provided in the section on Typical MTP + Scenarios. The command syntax is specified in this section. + + The commands begin with a command code followed by an argument + field. The command codes are four alphabetic characters. Upper + and lower case alphabetic characters are to be treated + identically. Thus any of the following may represent the mail + command: + + MAIL Mail mail MaIl mAIl + + This also applies to any symbols representing parameter values, + such as R or r for RECIPIENT first. The command codes and the + argument fields are separated by one or more spaces. + + + + 7 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + The argument field consists of a variable length character string + ending with the character sequence <CRLF>. It should be noted + that the receiver is to take no action until the end of line code + is received. + + The syntax is specified below in NVT-ASCII. All characters in the + argument field are ASCII characters. Square brackets denote an + optional argument field. If the option is not taken, the + appropriate default is implied. + + The following are the MTP commands: + + MAIL <SP> FROM:<sender> [<SP> TO:<path>] <CRLF> + + MRSQ [<SP> <scheme>] <CRLF> + + MRCP <SP> TO:<path> <CRLF> + + HELP [<SP> <string>] <CRLF> + + QUIT <CRLF> + + NOOP <CRLF> + + The syntax of the above argument fields (using BNF notation where + applicable) is given below. The "..." notation indicates that a + field may be repeated one or more times. + + <sender> ::= "<" <mailbox> ">" + + <path> ::= "<" ["@" <host> "," ...] <mailbox> ">" + + <scheme> ::= "R" | "T" | "?" + + <string> ::= <char> | <char><string> + + <mailbox> ::= <user> "@" <host> + + <host> ::= <string> + + <user> ::= <string> + + <char> ::= any of the 128 ASCII characters except <CR> and <LF> + + + + + + + 8 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + CONTROL FUNCTIONS + + Most time-sharing systems provide mechanisms to allow a terminal + user to regain control of a "runaway" process. When used locally, + such systems have access to all user-supplied signals, whether + these are normal characters or special "out of band" signals. + When terminals are connected to the system through the network, + the system does not necessarily have access to all user signals; + the network's flow control mechanisms may cause such signals to be + buffered elsewhere, for example in the user's host. + + To counter this problem, the TELNET "Synch" mechanism is used. A + Synch signal consists of a TCP Urgent or an NCP Interrupt + notification, coupled with the TELNET command DATA MARK (DM). + This notification, which is not subject to the flow control + pertaining to the TELNET connection, is used to invoke special + handling of the data stream by the process which receives it. In + this mode the data stream is immediately scanned for a TELNET + Interrupt Process (IP) command. (The rationale for the use of the + TELNET IP command is to allow an existing server TELNET module to + sit "under" the MTP. If this code were directly implemented in + the MTP the IP command would be unnecessary.) The TELNET command + DM is the synchronizing mark in the data stream which indicates + that any special signal has already occurred and the recipient can + return to normal processing of the data stream. For a more + complete understanding of this mechanism, see the TELNET Protocol + Specification in the Internet Protocol Handbook. + + The effect of this mechanism is to to discard all characters (up + to the DM) between the sender of the Synch and its recipeint. + Thus, all characters in the control connection are ignored until + the TELNET command DM is received. The full sequence is + illustrated below. Each vertical bar (|) represents the boundary + between data octets; IAC refers to the TELNET command code + Interpret As Command. + + Old New + -+-+-+-+-+-----+---+--+---+--+- + ...|M|A|I|L| ... |IAC|IP|IAC|DM|... + -+-+-+-+-+-----+---+--+---+--+- + + + + + + + + + + 9 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + +MTP REPLIES + + Replies to Mail Transfer Protocol commands are devised to ensure the + synchronization of requests and actions in the process of mail + transfer, and to guarantee that the sender-MTP always knows the state + of the receiver. Every command must generate at least one reply, + although there may be more than one. In the latter case, the + multiple replies must be easily distinguished. Additionally, some + commands must occur sequentially, such as MRSQ T->MAIL->MRCP or + MRSQ R->MRCP->MAIL. Replies to these sequences show the existence of + an intermediate state if all preceding commands have been successful. + A failure at any point in the sequence necessitates the repetition of + the entire sequence from the beginning. + + The details of the command-reply sequence are made explicit in the + section on State Diagrams. + + An MTP reply consists of a three digit number (transmitted as three + alphanumeric characters) followed by some text. The number is + intended for use by automata to determine what state to enter next; + the text is meant for the human user. It is intended that the three + digits contain enough encoded information that the sender-MTP will + not need to examine the text and may either discard it or pass it on + to the user, as appropriate. In particular, the text may be + receiver-dependent, so there are likely to be varying texts for each + reply code. + + Formally, a reply is defined to be the sequence: a three-digit code, + space <SP>, one line of text (where the maximum line length is 65), + and a terminal <CRLF>. Occasionally the text is longer than a single + line; in these cases the complete text must be bracketed so the + sender-MTP knows when it can stop reading the reply. This requires a + special first line format to indicate a multiple line reply, and + another on the last line to so designate it. Both lines will contain + the appropriate reply code which indicates the transaction state. + + Thus the format for multi-line replies is that the first line will + begin with the exact required reply code, followed immediately by + a Hyphen, "-" (also known as minus), followed by text. The last + line will begin with the same code, followed immediately by space + <SP>, optionally some text, and <CRLF>. + + + + + + + + + 10 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + For example: + 123-First line + Second line + 234 A line beginning with numbers + 123 The last line + + The sender-MTP then simply needs to search for the second + occurrence of the same reply code followed by <SP> (space> at the + beginning of a line, and ignore all intermediary lines. If an + intermediary line begins with a three-digit number, the receiver + must pad the front to avoid confusion. + + This scheme allows standard system routines to be used for + reply information, with "artificial" first and last lines + tacked on. In the rare cases where these routines are able to + generate three digits and a space at the beginning of any line, + the beginning of each text line should be offset by some + neutral text, like space. + + This scheme assumes that multi-line replies may not be nested. In + general, reply nesting will not occur except for random system + messages (also called spontaneous replies) which may interrupt + another reply. System messages (i.e., those not processed by the + receiver-MTP) will NOT carry reply codes and may occur anywhere in + the command-reply sequence. They may be ignored by the sender-MTP + as they are only information for the human user. + + The three digits of the reply each have a special significance. This + is intended to allow a range of very simple to very sophisticated + response by the sender-MTP. The first digit denotes whether the + response is good, bad or incomplete. (Referring to the state + diagram) an unsophisticated sender-MTP will be able to determine its + next action (proceed as planned, redo, retrench, etc.) by simply + examining this first digit. A sender-MTP that wants to know + approximately what kind of error occurred (e.g., mail system error, + command syntax error) may examine the second digit, reserving the + third digit for the finest gradation of information. + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + + The requested action is being initiated; expect another + reply before proceeding with a new command. (The sender-MTP + sending another command before the completion reply would be + + + + + 11 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + in violation of protocol. However, receiver-MTP processes + should queue any commands that arrive while a preceding + command is in progress.) + + 2yz Positive Completion reply + + The requested action has been successfully completed. A new + request may be initiated. + + 3yz Positive Intermediate reply + + The command has been accepted, but the requested action is + being held in abeyance, pending receipt of further + information. The sender-MTP should send another command + specifying this information. This reply is used in command + sequence groups. + + 4yz Transient Negative Completion reply + + The command was not accepted and the requested action did + not occur. However, the error condition is temporary and + the action may be requested again. The sender should return + to the beginning of the command sequence (if any). It is + difficult to assign a meaning to "transient" when two + different sites (receiver- and sender- MTPs) must agree on + the interpretation. Each reply in this category might have + a different time value, but the sender-MTP is encouraged to + try again. A rule of thumb to determine if a reply fits + into the 4yz or the 5yz category (see below) is that replies + are 4yz if they can be repeated without any change in + command form or in properties of the sender or receiver. + (E.g., the command is repeated identically; the receiver + does not put up a new implementation). + + 5yz Permanent Negative Completion reply + + The command was not accepted and the requested action did + not occur. The sender-MTP is discouraged from repeating the + exact request (in the same sequence). Even some "permanent" + error conditions can be corrected, so the human user may + want to direct the sender-MTP to reinitiate the command + sequence by direct action at some point in the future (e.g., + after the spelling has been changed, or the user has altered + his/her directory status.) + + + + + + 12 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + The second digit encodes responses in specific categories: + + x0z Syntax -- These replies refer to syntax errors, + syntactically correct commands that don't fit any + functional category, and unimplemented or superfluous + commands. + + x1z Information -- These are replies to requests for + information, such as status or help. + + x2z Connections -- These are replies referring to the control + connection. + + x3z Unspecified as yet. + + x4z Unspecified as yet. + + x5z Mail system -- These replies indicate the status of the + receiver mail system vis-a-vis the requested transfer or + other mail system action. + + The third digit gives a finer gradation of meaning in each + category specified by the second digit. The list of replies below + will illustrate this. Each reply text is recommended rather than + mandatory, and may even change according to the command with which + it is associated. On the other hand, the reply codes must + strictly follow the specifications in this section. Receiver + implementations should not invent new codes for slightly different + situations from the ones described here, but rather adapt codes + already defined. + + A command such as NOOP whose successful execution does not + offer the sender-MTP any new information will return a 200 + reply. The response is 502 when the command requests an + unimplemented non-site-specific action. A refinement of that + is the 504 reply for a command that IS implemented, but that + requests an unimplemented parameter. + + REPLY CODES BY FUNCTION GROUPS + + 200 Command okay + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + + + + 13 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only to + the human user] + 215 <scheme> is the preferred scheme + + 120 <host> Service ready in nnn minutes + 220 <host> Service ready for new user + 221 <host> Service closing control connection + 421 <host> Service not available, closing control connection + [This may be a reply to any command if the service knows it + must shut down] + + 151 User not local; will forward to <user>@<host> + 152 User unknown; mail will be forwarded by the operator + 250 Requested mail action okay, completed + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage space + 552 Requested mail action aborted: exceeded storage allocation + [For current mailbox location] + 553 Requested action not taken: mailbox name not allowed + 354 Start mail input; end with <CR><LF>.<CR><LF> + + + NUMERIC ORDER LIST OF REPLY CODES + + 120 <host> Service ready in nnn minutes + 151 User not local; will forward to <user>@<host> + 152 User unknown; mail will be forwarded by the operator + 200 Command okay + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only to + the human user] + 215 <scheme> is the preferred scheme + 220 <host> Service ready for new user + 221 <host> Service closing control connection + 250 Requested mail action okay, completed + 354 Start mail input; end with <CR><LF>.<CR><LF> + + + + 14 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + 421 <host> Service not available, closing control connection + [This may be a reply to any command if the service knows it + must shut down] + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage space + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 552 Requested mail action aborted: exceeded storage allocation + [For current mailbox location] + 553 Requested action not taken: mailbox name not allowed + + +DISCUSSION OF MAIL TRANSFER + + The basic command for transmitting mail is MAIL. This command causes + the transmitted data to be entered into the recipient's mailbox. + + MAIL <SP> "FROM:" <sender> [<SP> "TO:" <path>] <CRLF> + + <sender> is a mailbox and <path> is a source routing list of + hosts and destination mailbox. If accepted, it returns a 354 + reply and considers all succeeding lines to be the message + text. It is terminated by a line containing only a period, + upon which a 250 completion reply is returned. Various errors + are possible. + + There are two possible preliminary replies that a receiver may use to + indicate that it is accepting mail for a user whose mailbox is not at + that receiver. + + 151 User not local; will forward to <user>@<host> + + This reply indicates that the receiver knows the user's mailbox + is on another host and will take responsibility for forwarding + the mail to that host. For example, at BBN (or ISI) there are + several hosts. Each has a list of many of the users on the + hosts. Each host can accept mail for any user on their list + and forward it to the correct host. + + + + + 15 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + 152 User Unknown; mail will be forwarded by the operator + + This reply indicates that the host does not recognize the user + name, but that it will accept the mail and have the operator + attempt to deliver it. This is useful if the user name is + misspelled, but may be a disservice if the mail is really + undeliverable. + + If forwarding by the operator is unacceptable or if the user would + prefer to send the mail directly to the recipient's actual host, the + dialogue may be terminated upon receipt of one of these preliminary + responses. + + There are two MTP commands which allow the text of a message to be + mailed to several recipients simultaneously; such message + transmission is far more efficient than the practice of sending the + text again and again for each additional recipient at a site. In + one, all recipients are specified first, and then the text is sent. + In the other, the order is reversed and the text is sent first, + followed by the recipients. Both schemes are necessary because + neither by itself is optimal for all systems, as will be explained + later. To select a particular scheme, the MRSQ command is used; to + specify recipients after a scheme is chosen, MRCP commands are given; + and to furnish text, the MAIL command is used. + + SCHEME SELECTION: MRSQ + + MRSQ is the means by which a sender-MTP can test for MRSQ/MRCP + implementation, select a particular scheme, reset its state, and + even do some rudimentary negotiation. Its format is as follows: + + MRSQ [<SP> <scheme>] <CRLF> + + <scheme> is a single character. The following are defined: + R Recipients first. If this is not implemented, T must be. + T Text first. If this is not implemented, R must be. + ? Request for preference. This must always be implemented. + + No argument means a "selection" of none of the schemes (the + default). + + Possible replies are: + 200 OK, we'll use specified scheme + 215 <scheme> This is the scheme I prefer + 501 I understand MRSQ but can't use that scheme + 5xx Command unrecognized or unimplemented + + + + 16 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + There are three aspects of MRSQ. The first is that an MRSQ with + no argument must always return a 200 reply and restore the default + state of having no scheme selected. Any other reply implies that + MRSQ and hence MRCP are not understood or cannot be performed + correctly. + + The second is that the use of "?" as a <scheme> asks the MTP + receiver to return a 215 reply in which the receiver specifies a + "preferred" scheme. The format of this reply is simple: + + 215 <SP> <scheme> [<SP> <arbitrary text>] <CRLF> + + Any other reply (e.g., 4xx or 5xx) implies that MRSQ and MRCP + are not implemented, because "?" must always be implemented if + MRSQ is. + + The third important point about MRSQ is that it always has the + side effect of resetting all schemes to their initial state. This + reset must be done no matter what the reply will be -- 200, 215, + or 501. The actions necessary for a reset will be explained when + discussing how each scheme actually works. + + MESSAGE TEXT SPECIFICATION: MAIL + + Regardless of which scheme (if any) has been selected, a MAIL + command with a non-null "TO" argument will behave exactly as + before; the MRSQ/MRCP commands have no effect on it. However, a + normal MAIL command does have the same side effect as MRSQ; it + "resets" the current scheme to its initial state. + + It is only when the "TO" argument is null (e.g., MAIL FROM:<X@Y> + <CRLF>) that the particular scheme chosen is important. Rather + than producing an error (as most receivers currently do), the + receiver will accept message text for this "null" specification. + What it does with it depends on which scheme is in effect, and + will be described in the section on Scheme Mechanics. + + + + + + + + + + + + + + 17 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + RECIPIENT SPECIFICATION: MRCP + + In order to specify recipient names (i.e., mailboxes) and receive + some acknowledgment (or refusal) for each name, the following + command is used: + + MRCP <SP> TO:<path> <CRLF> + + Reply for no scheme: + 503 No scheme specified yet; use MRSQ + Replies for scheme T are identical to those for MAIL. + Replies for scheme R (recipients first): + 200 OK, name stored + 452 Recipient table full, this name not stored + 553 Recipient name rejected + 4xx Temporary error, try this name again later + 5xx Permanent error, report to sender + + Note that use of this command is an error if no scheme has been + selected yet; an MRSQ <scheme> must have been given if MRCP is to + be used. + + SCHEME MECHANICS: MRSQ R (RECIPIENTS-FIRST) + + In the recipients-first scheme, MRCP is used to specify names + which the MTP receiver stores in a list or table. Normally the + reply for each MRCP will be either a 200 for acceptance or a + 4xx/5xx rejection code. All 5xx codes are permanent rejections + (e.g., user not known) which should be reported to the human user, + whereas 4xx codes in general connote some temporary error that may + be rectified later. None of the 4xx/5xx replies impinge on + previous or succeeding MRCP commands, except for 452 which + indicates that no further MRCPs will succeed unless a message is + sent to the already stored recipients or a reset is done. + + + + + + + + + + + + + + + + 18 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + Sending message text to stored recipients is done by giving a MAIL + command with no "TO" argument; that is, just MAIL <SP> <sender> + <CRLF>. Transmission of the message text is exactly the same as + for normal MAIL. However, a positive acknowledgment at the end of + transmission means the message has been sent to ALL recipients + that were remembered with MRCP, and a failure code means that it + should be considered to have failed for ALL of these specified + recipients. This applies regardless of the actual error code. + Regardless of what the reply signifies, all stored recipient names + are flushed and forgotten -- in other words, things are reset to + their initial state. This purging of the recipient name list must + also be done as the reset side effect of any use of MRSQ. + + A 452 reply to an MRCP can be handled by using MAIL to specify the + message for currently stored recipients, and then sending more + MRCPs and another MAIL, as many times as necessary. For example, + if a receiver only had room for 10 names this would result in a + 50-recipient message being sent 5 times, to 10 different + recipients each time. + + If a sender attempts to specify message text (MAIL with no "TO" + argument) before any successful MRCPs have been given, this should + be treated exactly as a "normal" MAIL with a null recipient would + be; some receivers return an error, such as "550 Null recipient". + + See the example in Appendix A for a mail transfer using MRSQ R. + + SCHEME MECHANICS: MRSQ T (TEXT-FIRST) + + In the text-first scheme, MAIL with no "TO" argument is used to + specify message text, which the receiver stores away. Succeeding + MRCPs are then treated as if they were MAIL commands, except that + none of the text transfer manipulations are done; the stored + message text is sent to the specified recipient, and a reply code + is returned identical to that which an actual MAIL would invoke. + (Note that ANY 2xx code indicates success.) + + The stored message text is not forgotten until the next MAIL or + MRSQ, which will either replace it with new text or flush it + entirely. Any use of MRSQ will reset this scheme by flushing + stored text, as will any use of MAIL with a non-null argument. + + If an MRCP is seen before any message text has been stored, the + sender in effect is trying to send a null message; some receivers + might allow this, others would return an error code. + + + + + 19 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + See the example in Appendix B for a mail transfer using MRSQ T. + + WHY TWO SCHEMES ANYWAY? + + Because neither by itself is optimal for all systems. MRSQ R + allows more of a "bulk" mailing because everything is saved up and + then mailed simultaneously. This is very useful for systems such + as ITS where the MTP-receiver does not itself write mail directly, + but hands it on to a central mailer demon of great power. The + more information (e.g., recipients) associated with a single + "hand-off", the more efficiently mail can be delivered. + + By contrast, MRSQ T is geared to receiver-MTPs which want to + deliver mail directly, in one-by-one incremental fashion. For + each given recipient this scheme returns an individual + success/failure reply code which may depend on variable mail + system factors such as exceeding disk allocation, mailbox access + conflicts, and so forth. If these receiver-MTPs tried to emulate + MRSQ Rs bulk mailing, they would have to ensure that a success + reply to the MAIL indeed meant that it had been delivered to ALL + recipients specified -- not just some. + + NOTES: + + * Because these commands are not required in the minimum + implementation of MTP, one must be prepared to deal with sites + which don't recognize either MRSQ or MRCP. "MRSQ" and "MRSQ ?" + are explicitly designed as tests to see whether either scheme is + implemented. MRCP is not designed as a test, and a failure + return of the "unimplemented" variety could be confused with "No + scheme selected yet", or even with "Recipient unknown". + + * There is no way to indicate in a positive response to "MRSQ ?" + that the preferred "scheme" for a receiver is that of the + default state; i.e., none of the multi-recipient schemes. The + rationale is that in this case, it would be pointless to + implement MRSQ/MRCP at all, and the response would therefore be + negative. + + + + + + + + + + + + 20 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + * One reason that the use of MAIL is restricted to null "TO" + arguments with this multi-recipient extension is the ambiguity + that would result if a non-null "TO" argument were allowed. For + example, if MRSQ R was in effect and some MRCPs had been given, + and a MAIL FROM:<X@Y> TO:<FOO><CRLF> was done, there would be no + way to distinguish a failure reply for mailbox "FOO" from a + global failure for all recipients specified. A similar + situation exists for MRSQ T; it would not be clear whether the + text was stored and the mailbox failed, or vice versa, or both. + + * "Resets" are done by all MRSQs and "normal" MAILs to avoid + confusion and overly complicated implementation. The MRSQ + command implies a change or uncertainty of status, and the MAIL + command would otherwise have to use some independent mechanisms + to avoid clobbering the data bases (e.g., message text storage + area) used by the T/R schemes. However, once a scheme is + selected, it remains "in effect" just as an FTP "TYPE A" remains + selected. The recommended way for doing a reset, without + changing the current selection, is with "MRSQ ?". Remember that + "MRSQ" alone reverts to the no-scheme state. + + * It is permissible to intersperse other MTP commands among the + MRSQ/MRCP/MAIL sequences. + + + + + + + + + + + + + + + + + + + + + + + + + + + 21 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + +DECLARATIVE SPECIFICATIONS + + MINIMUM IMPLEMENTATION + + In order to make MTP workable without needless error messages, the + following minimum implementation is required for all receivers: + + COMMANDS -- QUIT + MAIL + NOOP + + In terms of FTP, the values of the transfer parameters must be: + + TYPE -- ASCII + MODE -- STREAM + STRU -- FILE-STRUCTURE + + All hosts must use the above values for mail transfer. + + CONNECTIONS + + The receiver-MTP shall "listen" on Port L. The sender-MTP shall + initiate the TCP/NCP control connection. The control connection + consists of a full-duplex connection under TCP; it is two simplex + connections under NCP. Receiver- and sender- MTPs should follow + the conventions of the TELNET Protocol as specified in the ARPA + Internet Protocol Handbook. Receivers are under no obligation to + provide for editing of command lines and may specify that it be + done in the sender host. The control connection shall be closed + by the receiver at the sender's request after all transfers and + replies are completed. + + SEQUENCING OF COMMANDS AND REPLIES + + The communication between the sender and receiver is intended to + be an alternating dialogue. As such, the sender issues an MTP + command and the receiver responds with a prompt primary reply. + The sender should wait for this initial primary success or failure + response before sending further commands. + + Certain commands require a second reply for which the sender + should also wait. These replies may, for example, report on the + progress or completion of mail transfer. They are secondary + replies to mail transfer commands. + + One important group of informational replies is the connection + + + + 22 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + greetings. Under normal circumstances, a receiver will send a 220 + reply, "awaiting input", when the connection is completed. The + sender should wait for this greeting message before sending any + commands. If the receiver is unable to accept input right away, + it should send a 120 "expected delay" reply immediately and a 220 + reply when ready. The sender will then know not to hang up if + there is a delay. + + Note: all the greeting type replies have the official name of + the server host as the first word following the reply code. + + The table below lists alternative success and failure replies for + each command. These must be strictly adhered to; a receiver may + substitute text in the replies, but the meaning and action implied + by the code numbers and by the specific command reply sequence + cannot be altered. + + COMMAND-REPLY SEQUENCES + + In this section, the command-reply sequence is presented. Each + command is listed with its possible replies; command groups are + listed together. Preliminary replies are listed first (with + their succeeding replies indented under them), then positive + and negative completion, and finally intermediary replies with + the remaining commands from the sequence following. The 421 + reply (service not available, closing control connection) may + be given at any point if the MTP-receiver knows it must shut + down. This listing forms the basis for the state diagrams, + which will be presented separately. + + CONNECTION ESTABLISHMENT + 120 + 220 + 220 + 421 + MAIL ACTION COMMANDS + MAIL + 151, 152 + 354 + 250 + 451, 552 + 354 + 250 + 451, 552 + 450, 550, 452, 553 + 500, 501, 502, 421 + + + + 23 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + MRSQ + 200, 215 + 500, 501, 502, 421 + MRCP + 151, 152 + 200 + 200 + 450, 550, 452, 553 + 500, 501, 502, 503, 421 + QUIT + 221 + INFORMATIONAL COMMANDS + HELP + 211, 214 + 500, 501, 502, 421 + MISCELLANEOUS COMMANDS + NOOP + 200 + 500 421 + +STATE DIAGRAMS + + Here we present state diagrams for a very simple minded MTP + implementation. Only the first digit of the reply codes is used. + There is one state diagram for each group of MTP commands. + + The command groupings were determined by constructing a model for + each command and then collecting together the commands with + structurally identical models. + + For each command there are three possible outcomes: "success" (S), + "failure" (F), and "error" (E). In the state diagrams below we use + the symbol B for "begin", and the symbol W for "wait for reply". + + + + + + + + + + + + + + + + + 24 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + We first present the diagram that represents the most MTP commands: + + + 1,3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ +---+ +---+ + | + | 4,5 +---+ + ----------->| F | + +---+ + + + This diagram models the commands: + + HELP, MRCP, MRSQ, NOOP, QUIT. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 25 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + + A more complex diagram models the MAIL command: + + + ---- 1 + | | + +---+ cmd -->+---+ 2 +---+ + | B |---------->| W |---------->| E | + +---+ +---+ -->+---+ + | | | + 3 | | 4,5 | + -------------- ------ | + | | | +---+ + | ------------->| S | + | | 1,3 | | +---+ + | 2| -------- + | | | | + V | | | + +---+ text +---+ 4,5 ----->+---+ + | |---------->| W |---------->| F | + +---+ +---+ +---+ + + + Note that the "text" here is a series of lines sent from the + sender to the receiver with no response expected until the last + line is sent. (The last line must consist of only a single + period.) + + + + + + + + + + + + + + + + + + + + + + + + 26 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + Finally we present a generalized diagram that could be used to model + the command and reply interchange: + + + ------------------------------------ + | | + Begin | | + | V | + | +---+ cmd +---+ 2 +---+ | + -->| |------->| |---------->| | | + | | | W | | S |-----| + -->| | -->| |----- | | | + | +---+ | +---+ 4,5 | +---+ | + | | | | | | | + | | | 1| |3 | +---+ | + | | | | | | | | | + | | ---- | ---->| F |----- + | | | | | + | | | +---+ + ------------------- + | + | + V + End + + + + + + + + + + + + + + + + + + + + + + + + + + 27 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + +CONNECTION ESTABLISHMENT + + The MTP control connection is established via TCP/NCP between the + receiver process port/socket L and the sender process port/socket U. + This protocol is assigned the service port/socket 57 (71 octal), that + is L=57. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 28 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + +APPENDIX A + + Example of MRSQ R (Recipients-first) + + This is an example of how MRSQ R is used. First the sender must + establish that the receiver in fact implements MRSQ. + + S: MRSQ <CRLF> + R: 200 OK, no scheme selected + + An MRSQ with a null argument always returns a 200 if implemented, + selecting the default "scheme", i.e., none of them. If MRSQ were not + implemented, a code of 4xx or 5xx would be returned. + + S: MRSQ R <CRLF> + R: 200 OK, using that scheme + + All is well; now the recipients can be specified. + + S: MRCP TO:<Foo@Y> <CRLF> + R: 200 OK + + S: MRCP TO:<Raboof@Y> <CRLF> + R: 553 No such user here + + S: MRCP TO:<bar@Y> <CRLF> + R: 200 OK + + S: MRCP TO:<@Y,@X,fubar@Z> <CRLF> + R: 200 OK + + Note that the failure of "Raboof" has no effect on the storage of + mail for "Foo", "bar" or the mail to be forwarded to "fubar@Z" + through host "X". Now the message text is furnished, by giving a + MAIL command with no "TO" argument. + + S: MAIL FROM:<waldo@A><CRLF> + R: 354 Type mail, ended by <CRLF>.<CRLF> + S: Blah blah blah blah....etc. etc. etc. + S: <CRLF>.<CRLF> + R: 250 Mail sent + + The mail text has now been sent to "Foo" and "bar" as well as + forwarded to "fubar@Z". + + + + + + 29 + + + +September 1980 RFC 772 +Mail Transfer Protocol + + + +APPENDIX B + + Example of MRSQ T (Text-first) + + Using the same message as the previous example to establish that the + receiver implements MRSQ. + + S: MRSQ ? <CRLF> + R: 215 T Text first, please + + MRSQ is indeed implemented, and the receiver says that it prefers + "T", but that needn't stop the sender from trying something else. + + S: MRSQ R <CRLF> + R: 501 Sorry, I really can't do that + + It's possible that it could have understood "R" also, but in general + it's best to use the "preferred" scheme, since the receiver knows + which is most efficient for its particular site. + + S: MRSQ T <CRLF> + R: 200 OK, using that scheme + + Scheme "T" is now selected, and the message text is sent by giving a + mail command with no "TO" argument. + + S: MAIL FROM:<WALDO@A><CRLF> + R: 354 Type mail, ended by <CRLF>.<CRLF> + S: Blah blah blah blah....etc. etc. etc. + S: <CRLF>.<CRLF> + R: 250 Mail stored + + Now recipients can be specified. + + S: MRCP TO:<Foo@Y> <CRLF> + R: 250 Stored mail sent + + S: MRCP TO:<Raboof@Y> <CRLF> + R: 553 No such user here + + S: MRCP TO:<bar@Y> <CRLF> + R: 250 Stored mail sent + + S: MRCP TO:<@Y,@X,fubar@Z> <CRLF> + R: 200 OK + + + + + 30 + + + +RFC 772 September 1980 + Mail Transfer Protocol + + + + The text has now been sent to "Foo" and "bar" at host "Y" and will be + forwarded to "fubar@Z" through host "X", and still remains stored. A + new message can be sent with another MAIL/MRCP ... sequence, but a + careful sender would reset the state using the exchange below. + + S: MRSQ ? <CRLF> + R: 215 T Text first, please + + Which resets the state without altering the scheme in effect. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 31 +
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc780.txt b/Documentation/en/rfc/rfc780.txt new file mode 100644 index 00000000..29dddded --- /dev/null +++ b/Documentation/en/rfc/rfc780.txt @@ -0,0 +1,2599 @@ + + + + + + + + + MAIL TRANSFER PROTOCOL + + + + Suzanne Sluizer + + and + + Jonathan B. Postel + + + + + + + + + + RFC 780 + + + + + + + + + + + + May 1981 + + + + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, California 90291 + + (213) 822-1511 + + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + TABLE OF CONTENTS + + 1. INTRODUCTION .................................................. 1 + + 2. THE MTP MODEL ................................................. 2 + + 3. BASIC MAIL .................................................... 4 + + 3.1. Forwarding ............................................... 5 + 3.2. Source Routing ........................................... 6 + + 4. MULTI-RECIPIENT MAIL .......................................... 8 + + 4.1. Scheme Selection: MRSQ ................................... 8 + 4.2. Message Text Specification: MAIL ......................... 9 + 4.3. Recipient Specification: MRCP ........................... 10 + 4.4. Scheme Mechanics: Recipients First ...................... 10 + 4.5. Scheme Mechanics: Text First ............................ 12 + 4.6. Discussion .............................................. 12 + + 5. SPECIFICATIONS ............................................... 16 + + 5.1. MTP Commands ............................................ 16 + 5.1.1. Command Semantics ..................................... 16 + 5.1.2. Command Syntax ........................................ 18 + 5.2. MTP Replies ............................................. 22 + 5.2.1. Reply Codes by Function Group ......................... 23 + 5.2.2. Reply Codes in Numeric Order .......................... 24 + 5.3. Sequencing of Commands and Replies ...................... 25 + 5.4. State Diagrams .......................................... 28 + 5.5. Details ................................................. 30 + 5.5.1. Minimum Implementation ................................ 30 + 5.5.2. Transparency .......................................... 30 + 5.5.3. Sizes ................................................. 30 + + APPENDIX A: TCP ................................................. 32 + APPENDIX B: NCP ................................................. 33 + APPENDIX C: NITS ................................................ 34 + APPENDIX D: X.25 ................................................ 35 + APPENDIX E: Theory of Reply Codes ............................... 36 + + GLOSSARY ......................................................... 39 + + REFERENCES ....................................................... 42 + + + + + + +Network Working Group S. Sluizer +Request for Comments: 780 J. Postel + ISI +Replaces: RFC 772 May 1981 + + MAIL TRANSFER PROTOCOL + + +1. INTRODUCTION + + The objective of Mail Transfer Protocol (MTP) is to transfer mail + reliably and efficiently. + + MTP is designed to be independent of the particular transmission + subsystem and requires only a reliable ordered data stream channel. + Appendices describe the use of MTP with various transport services. + A Glossary provides the definitions of terms as used in this + document. + + An important feature of MTP is its capability to relay mail from one + transport environment to another. A transport service provides an + interprocess communication environment (IPCE). An IPCE may cover one + network, several networks, or a subset of a network. A process can + communicate directly with another process anywhere in its own IPCE. + Mail is a special case of interprocess communication. Mail can be + communicated between proceses in different IPCEs by relaying through + a process connected to two (or more) IPCEs. More specifically, mail + can be relayed between hosts on different transport systems by a host + on both transport systems. It is important to realize that transport + systems (or IPCEs) are not one-to-one with networks. + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 1] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + +2. THE MTP MODEL + + The MTP design is based on the following model of communication: at + the initiation of the user, the sender-MTP establishes the + full-duplex transmission channel. MTP commands are generated by the + sender-MTP and sent to the receiver-MTP. MTP replies are sent from + the receiver-MTP to the sender-MTP in response to the commands. + + In the simplest case, once the transmission channel is established + the MTP-sender sends a MAIL command indicating the sender and + receiver of the mail. If the MTP-receiver can accept the mail it + responds with a go ahead reply. Then the MTP-sender sends the mail + data, terminating with a special sequence. If the MTP-receiver + successfully processes the mail it responds with an OK reply. + + ------------------------------------------------------------- + + + +----------+ +----------+ + +------+ | | | | + | User |<-->| | MTP | | + +------+ | Sender- |Commands/Replies| Receiver-| + +------+ | MTP |<-------------->| MTP | +------+ + | File |<-->| | and Mail | |<-->| File | + |System| | | | | |System| + +------+ +----------+ +----------+ +------+ + + + Sender-MTP Receiver-MTP + + Model for MTP Use + + Figure 1 + + ------------------------------------------------------------- + + The MTP provides mechanisms for the transmission of mail; directly + from the sending user's host to the receiving user's host when the + two host are connected to the same transport service, or via one or + more relay MTP-servers when the source and destination hosts are not + connected to the same transport service. + + To be able to provide the relay capability the MTP-server must be + supplied with the name of the ultimate destination host as well as + the destination mailbox name. + + + + +[Page 2] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + The arguments to the MAIL command are a FROM path and a TO path. The + TO path is a source route while the FROM path is a return route + (which may be used to return a message to the sender when an error + occurs with a relayed message). + + The preceding discussion has outlined the transmission of one copy of + one message from a source to a destination host and the possibility + of relaying messages between different transport services. The MTP + additionally supports the transmission of one copy of a message + addressed to multiple recipients. + + In order for mail to be successfully transmitted the destination + users must be known at the destination receiver-MTP and the mail data + must be correctly received and stored. In the single recipient case + discussed above the positive response to the MAIL command indicated + the recipient was known, and the final OK response indicated the mail + was received and stored. + + To support multi-recipient mail, MTP provides two procedures: + Text-First, and Recipients-First. In the text-first scheme the mail + data is sent and acknowledged, then each recipient identification is + sent and acknowledged (or refused) separately. In the + recipients-first scheme the recipients are negotiated first, then the + text is sent and acknowledged (for all recipients at once). The + choice of scheme is up to the MTP-receiver, and depends on the way + mail is handled in the destination host. + + The multi-recipient mail procedures are optional and the + determination of which scheme to use is negotiated. The use of the + multi-recipient schemes is strongly encouraged by the economy they + provide in transmission and processing. + + The mail commands and replies have a rigid syntax. Replies also have + a numeric code. In the following, examples appear which use actual + commands and replies. The complete lists of commands and replies + appears in Section 5 on specifications. + + Commands and replies are not case sensitive. That is, a command or + reply word may be upper case, lower case, or any mixture of upper and + lower case. Note that this is not true of mailbox user names. For + some hosts the user name is case sensitive, and MTP implementations + must take case to preserve the case of user names as they appear in + mailbox arguments. + + + + + + +Sluizer & Postel [Page 3] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + +3. BASIC MAIL + + The basic command for transmitting mail is MAIL. This command causes + the transmitted data to be entered into the recipient's mailbox, or + accepted for relaying to the destination host. + + The mail text is also sent on the transmission channel. This + requires that the end of the text be signalled so that the command + and reply dialog can be resumed. MTP signals the end of the mail + text by sending a line containing only a period. A transparency + procedure is used to prevent this interfering with the users text + (see Section 5.5.2). + + MAIL <SP> FROM:<sender-path> <SP> TO:<receiver-path> <CRLF> + + The <sender-path> contains the source mailbox; the + <receiver-path> contains the destination mailbox. If accepted, + the receiver-MTP returns a 354 reply and considers all + succeeding lines to be the message text. The message text is + terminated by a line containing only a period, upon which a 250 + completion reply is returned. Various errors are possible. + + Actually the <sender-path> and <receiver-path> are more than + just the mailboxes, they may be source routes. The + <receiver-path> is a source routing list of hosts and + destination mailbox; the <sender-path> is a reverse source + routing list of hosts and source mailbox. + + + + + + + + + + + + + + + + + + + + + + +[Page 4] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of MAIL (Basic Mail) + + This MAIL command specifies the mail is sent by Waldo at host A, + and is to be delivered to Foo at host Y. Here we assume that host + A contacts host Y directly. + + S: MAIL FROM:<waldo@A> TO:<Foo@Y> <CRLF> + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah blah....etc. etc. etc. + S: <CRLF>.<CRLF> + R: 250 Mail sent + + The mail text has now been sent to "Foo". + + Example 1 + + ------------------------------------------------------------- + + 3.1. FORWARDING + + There are two possible preliminary replies that a receiver may use + to indicate that it is accepting mail for a user whose mailbox is + not at that host. + + 151 User not local; will forward to <user>@<host> + + This reply indicates that the receiver-MTP knows the user's + mailbox is on another host and will take responsibility for + forwarding the mail to that host. This reply is only sent + when the sender would not expect the mail to be forwarded. + That is, when <receiver-path> as given in the command + indicates mail relaying, this reply will not be used. This + reply could be used for an organization with several hosts + when each has a list of many of the users on the hosts. A + host can accept mail for any user on its list and forward it + to the correct host. + + 152 User Unknown; mail will be forwarded by the operator + + This reply indicates that the host does not recognize the + user name, but that it will accept the mail and have the + operator attempt to deliver it. This is useful if the user + name is misspelled, but may be a disservice if the mail is + really undeliverable. + + + +Sluizer & Postel [Page 5] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + If forwarding by the operator is unacceptable or if the + sending-user would prefer to send the mail directly to the + recipient's actual host, the action may be aborted. + + The MTP-sender must accept or reject the proposal in the + preliminary reply by sending a continue (CONT) or abort (ABRT) + command. In the case of the continue, the next reply from the + MTP-receiver will be any of the replies expected for the MAIL + command, most likely "354 Start mail input, ...". In the case of + the abort, the next reply from the MTP-receiver will be "201 + Command okay, action aborted". + + 3.2. SOURCE ROUTING + + The receiver-path may be a source route of the form + "@ONE,@TWO,JOE@THREE", where ONE, TWO, and THREE are hosts. This + form is used to emphasize the distinction between an address and a + route. + + At some distant future time it might be necessary to expand the + mailbox format to include a region identifier, such as + "user@host@region". If this occured the MTP path convention + could be expanded to + "host@region,host@region,...user@host@region". For example, + "ONE@R1,TWO@R2,JOE@THREE@R3". + + The mailbox is an absolute address, and the route is information + about how to get there. The two concepts should not be confused. + + The elements of the receiver-path are to be moved to the + sender-path as the message is relayed from one MTP to another. The + sender-path is a reverse source route, that is, a source route to + the originator of the message. When an MTP deletes its identifier + from the receiver-path and inserts it into the sender-path, it + must use the name it is known by in the environment it is sending + into, not the environment the mail came from, in case the MTP is + known be different names in different environments. + + When source routing is used the receiver-MTP will receive mail to + be relayed to another MTP. The receiver-MTP may accept the task + of relaying the mail or reject it in the same way it accepts or + reject mail for a local user. It does not use the 151 "User not + local" or 152 "User unknown" preliminary replies. Once the + receiver-MTP accepts the relaying task it receives the mail text + and transforms the command arguments by removing its own + identifier from the receiver-path and inserting it in the + + + +[Page 6] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + beginning of the sender-path. The receiver-MTP then becomes a + sender-MTP and establishes a transmission channel to the next MTP + in the receiver-path and sends it the mail. + + If an MTP has accepted the task of relaying the mail and later + finds that the receiver-path is incorrect or that the mail cannot + be delivered for whatever reason, then it must construct a + notification message and send it to the originator of the + undeliverable mail as indicated by the sender-path. This + notification message must be from the MTP at this host. That is, + the sender-path of the notification message itself will be + "MTP@<host>", and in the notification message header the From + field will be "MTP at <host>". Of course, MTPs should not send + notification messages about problems with notification messages. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 7] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + +4. MULTI-RECIPIENT MAIL + + There are two MTP commands which allow the text of a message to be + mailed to several recipients simultaneously; such message + transmission is far more efficient than the practice of sending the + text again and again for each additional recipient at a host. In one + scheme, all recipients are specified first, and then the text is + sent. In the other scheme, the order is reversed and the text is + sent first, followed by the recipients. The sender-MTP suggests the + scheme it would prefer, but receiver-MTP controls which scheme is + actually used. To select a particular scheme, the MRSQ command is + used; to specify recipients after a scheme is chosen, MRCP commands + are given; and to furnish text, the MAIL command is used. + + Both schemes are necessary because neither by itself is optimal for + all systems. MRSQ R allows more of a "bulk" mailing because + everything is saved up and then mailed simultaneously. This is very + useful for systems such as ITS where the MTP-receiver does not itself + write mail directly, but hands it on to a central mailer demon. The + more information (e.g., recipients) associated with a single + "hand-off", the more efficiently mail can be delivered. + + By contrast, MRSQ T is geared to receiver-MTPs which want to deliver + mail directly, in one-by-one incremental fashion. For each given + recipient this scheme returns an individual success/failure reply + code which may depend on variable mail system factors such as + exceeding disk allocation, mailbox access conflicts, and so forth. + If these receiver-MTPs tried to emulate MRSQ Rs bulk mailing, they + would have to ensure that a success reply to the MAIL indeed meant + that it had been delivered to ALL recipients specified -- not just + some. + + 4.1. SCHEME SELECTION: MRSQ + + MRSQ is the means by which a sender-MTP can test for MRSQ/MRCP + implementation, select a particular scheme, reset its state, and + even do some rudimentary negotiation. Its format is as follows: + + MRSQ [<SP> <scheme>] <CRLF> + + <scheme> is a single character. The following are defined: + R Recipients first. If this is not implemented, T must be. + T Text first. If this is not implemented, R must be. + ? Request for preference. This must always be implemented. + + + + + +[Page 8] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + No argument means a "selection" of none of the schemes (the + default). + + Possible replies are: + 200 OK, use the specified scheme + 215 <scheme> This is the scheme I prefer + 504 I understand MRSQ but can't use that scheme + 5xx Command unrecognized or unimplemented + + There are three aspects of MRSQ. The first is that an MRSQ with + no argument must always return a 200 reply and restore the default + state of having no scheme selected. Any other reply implies that + MRSQ and hence MRCP are not understood or cannot be performed + correctly. + + The second is that the use of "?" as a <scheme> asks the MTP + receiver to return a 215 reply in which the receiver specifies a + "preferred" scheme. The format of this reply is simple: + + 215 <SP> <scheme> [<SP> <string>] <CRLF> + + Any other reply (e.g., 4xx or 5xx) implies that MRSQ and MRCP + are not implemented, because "?" must always be implemented if + MRSQ is. + + The third important point about MRSQ is that it always has the + side effect of reseting all schemes to their initial state. This + reset must be done no matter what the reply will be -- 200, 215, + or 504. The actions necessary for a reset will be explained when + discussing how each scheme actually works. + + Note that the receiver gets to choose which scheme is used. The + sender must be prepared to do either. + + 4.2. MESSAGE TEXT SPECIFICATION: MAIL + + Regardless of which scheme (if any) has been selected, a MAIL + command with a non-null receiver-path argument will behave exactly + as before; the MRSQ/MRCP commands have no effect on it. However, + a normal MAIL command does have the same side effect as MRSQ; it + "resets" all schemes to their initial state. + + It is only when the receiver-path argument is null that the + particular scheme chosen is important. + + MAIL FROM:<sender-path> <CRLF> + + + +Sluizer & Postel [Page 9] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + Rather than producing an error, the receiver will accept message + text for this "null" recipient specification. What it does with + it depends on which scheme is in effect, and will be described in + the section on Scheme Mechanics. + + 4.3. RECIPIENT SPECIFICATION: MRCP + + In order to specify recipient names (i.e., mailboxes) and receive + some acknowledgment (or refusal) for each name, the following + command is used: + + MRCP <SP> TO:<receiver-path> <CRLF> + + Reply for no scheme: + 503 No scheme specified yet; use MRSQ + Replies for scheme T are identical to those for MAIL. + Replies for scheme R (recipients first): + 200 OK, name stored + 452 Recipient table full, this name not stored + 550 Recipient name rejected + 4xx Temporary error, try this name again later + 5xx Permanent error, report to sender + + Note that use of this command is an error if no scheme has been + selected yet; an MRSQ <scheme> must have been given if MRCP is to + be used. + + 4.4. SCHEME MECHANICS: MRSQ R (RECIPIENTS-FIRST) + + In the recipients-first scheme, MRCP is used to specify names + which the MTP receiver stores in a list or table. Normally the + reply for each MRCP will be either a 200 for acceptance or a + 4xx/5xx rejection code. All 5xx codes are permanent rejections + (e.g., user not known) which should be reported to the human user, + whereas 4xx codes in general connote some temporary error that may + be rectified later. None of the 4xx/5xx replies impinge on + previous or succeeding MRCP commands, except for 452 which + indicates that no further MRCPs will succeed unless a message is + sent to the already stored recipients or a reset is done. + + Sending message text to stored recipients is done by giving a MAIL + command with no receiver-path argument; that is, just MAIL <SP> + FROM: <sender-path> <CRLF>. Transmission of the message text is + exactly the same as for normal MAIL. However, a positive + acknowledgment at the end of transmission means the message has + been sent to ALL recipients that were remembered with MRCP, and a + + + +[Page 10] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + failure code means that it should be considered to have failed for + ALL of these specified recipients. This applies regardless of the + actual error code. Regardless of what the reply signifies, all + stored recipient names are flushed and forgotten -- in other + words, things are reset to their initial state. This purging of + the recipient name list must also be done as the reset side effect + of any use of MRSQ (or MAIL with a non-null receiver-path + argument). + + A 452 reply (out of storage space) to an MRCP can be handled by + using MAIL to specify the message for currently stored recipients, + and then sending more MRCPs and another MAIL, as many times as + necessary. For example, if a receiver only had room for 10 names + this would result in a 50-recipient message being sent 5 times, to + 10 different recipients each time. + + If a sender attempts to specify message text (MAIL with no + receiver-path argument) before any successful MRCPs have been + given, this should be treated exactly as a "normal" MAIL with a + null recipient would be; some receivers return an error, such as + "550 Null recipient". + + ------------------------------------------------------------- + + Example of MRSQ R (Recipients First) + + First the sender must establish that the receiver implements + MRSQ. + + S: MRSQ <CRLF> + R: 200 OK, no scheme selected + + An MRSQ with a null argument always returns a 200 if + implemented, selecting the default "scheme", i.e., none of + them. If MRSQ were not implemented, a code of 4xx or 5xx would + be returned. + + S: MRSQ R <CRLF> + R: 200 OK, using that scheme + + All is well; now the recipients can be specified. + + S: MRCP TO:<Foo@Y> <CRLF> + R: 200 OK + + + + + +Sluizer & Postel [Page 11] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + S: MRCP TO:<Raboof@Y> <CRLF> + R: 550 No such user here + + S: MRCP TO:<bar@Y> <CRLF> + R: 200 OK + + S: MRCP TO:<@Y,@X,fubar@Z> <CRLF> + R: 200 OK + + Note that the failure of "Raboof" has no effect on the storage + of mail for "Foo", "bar" or the mail to be relayed to "fubar@Z" + through host "X". Now the message text is furnished, by giving + a MAIL command with no receiver-path argument. + + S: MAIL FROM:<waldo@A><CRLF> + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah blah....etc. etc. etc. + S: <CRLF>.<CRLF> + R: 250 Mail sent + + The mail text has now been sent to "Foo" and "bar" as well as + relayed to "fubar@Z". + + Example 2 + + ------------------------------------------------------------- + + 4.5. SCHEME MECHANICS: MRSQ T (TEXT-FIRST) + + In the text-first scheme, MAIL with no receiver-path argument is + used to specify message text, which the receiver stores away. + Succeeding MRCPs are then treated as if they were MAIL commands, + except that none of the text transfer manipulations are done; the + stored message text is sent to the specified recipient, and a + reply code is returned identical to that which an actual MAIL + would invoke. (Note that any 2xx code indicates success.) + + The stored message text is not forgotten until the next MAIL or + MRSQ, which will either replace it with new text or flush it + entirely. Any use of MRSQ will reset this scheme by flushing + stored text, as will any use of MAIL with a non-null receiver-path + argument. + + If an MRCP is seen before any message text has been stored, the + sender in effect is trying to send a null message; some receivers + might allow this, others would return an error code. + + + +[Page 12] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of MRSQ T (Text First) + + First the sender must establish that the receiver implements + MRSQ. + + S: MRSQ ? <CRLF> + R: 215 T Text first, please + + MRSQ is indeed implemented, and the receiver says that it + prefers "T", but that needn't stop the sender from trying + something else. + + S: MRSQ R <CRLF> + R: 504 Sorry, I really can't do that + + It's possible that it could have understood "R" also, but in + general it's best to use the "preferred" scheme, since the + receiver knows which is most efficient for its particular site. + + S: MRSQ T <CRLF> + R: 200 OK, using that scheme + + Scheme "T" is now selected, and the message text is sent by + giving a mail command with no receiver-path argument. + + S: MAIL FROM:<WALDO@A><CRLF> + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah blah....etc. etc. etc. + S: <CRLF>.<CRLF> + R: 250 Mail stored + + Now recipients can be specified. + + S: MRCP TO:<Foo@Y> <CRLF> + R: 250 Stored mail sent + + S: MRCP TO:<Raboof@Y> <CRLF> + R: 550 No such user here + + S: MRCP TO:<bar@Y> <CRLF> + R: 250 Stored mail sent + + S: MRCP TO:<@Y,@X,fubar@Z> <CRLF> + R: 250 Mail accepted for relaying + + + +Sluizer & Postel [Page 13] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + The text has now been sent to "Foo" and "bar" at host "Y" and + will be relayed to "fubar@Z" through host "X", and still + remains stored. A new message can be sent with another + MAIL/MRCP ... sequence, but a careful sender would reset the + state using the exchange below. + + S: MRSQ ? <CRLF> + R: 215 T Text first, please + + Which resets the state without altering the scheme in effect. + + Example 3 + + ------------------------------------------------------------- + + 4.6. DISCUSSION + + Because these commands are not required in the minimum + implementation of MTP, one must be prepared to deal with sites + which don't recognize either MRSQ or MRCP. "MRSQ" and "MRSQ ?" + are explicitly designed as tests to see whether either scheme is + implemented. MRCP is not designed as a test, and a failure return + of the "unimplemented" variety could be confused with "No scheme + selected yet", or even with "Recipient unknown". + + There is no way to indicate in a positive response to "MRSQ ?" + that the preferred "scheme" for a receiver is that of the default + state; i.e., none of the multi-recipient schemes. The rationale + is that in this case, it would be pointless to implement MRSQ/MRCP + at all, and the response would therefore be negative. + + One reason that the use of MAIL is restricted to null + receiver-path arguments with this multi-recipient extension is the + ambiguity that would result if a non-null receiver-path argument + were allowed. For example, if MRSQ R was in effect and some MRCPs + had been given, and a MAIL FROM:<X@Y> TO:<FOO@Z><CRLF> was done, + there would be no way to distinguish a failure reply for mailbox + "FOO" from a global failure for all recipients specified. A + similar situation exists for MRSQ T; it would not be clear whether + the text was stored and the mailbox failed, or vice versa, or + both. + + "Resets" of all schemes are done by all MRSQs and "normal" MAILs + to avoid confusion and overly complicated implementation. The + MRSQ command implies a change or uncertainty of status, and the + MAIL command would otherwise have to use some independent + + + +[Page 14] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + mechanisms to avoid clobbering the data bases (e.g., message text + storage area) used by the T/R schemes. However, once a scheme is + selected, it remains in effect. The recommended way for doing a + reset, without changing the current selection, is with "MRSQ ?". + Remember that "MRSQ" alone reverts to the no-scheme state. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 15] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + +5. SPECIFICATIONS + + 5.1. MTP COMMANDS + + 5.1.1. COMMAND SEMANTICS + + The MTP commands define the mail transfer or the mail system + function requested by the user. MTP commands are character + strings terminated by <CRLF>. The command codes themselves are + alphabetic characters terminated by <SP> if parameters follow + and <CRLF> otherwise. The syntax of mailboxes must conform to + receiver site conventions. The MTP commands are discussed + below. MTP replies are discussed in the Section 5.2. + + MAIL (MAIL) + + This command is used to send mail over the transmission + channel. The argument field contains a sender-path sequence + and optional receiver-path sequence. + + The sender-path sequence consists of an optional list of + hosts and the sender mailbox. When the list of hosts is + present, it is "reverse" source routing information and + indicates that the mail was relayed through each host on the + list (the first host in the list was the most recent relay). + This list is used as source routing to return non-delivery + notices to the sender. As each relay host adds itself to + the beginning of the list, it must use its name as known in + the network to which it is relaying the mail rather than the + network from which the mail came (if they are different). + + If the receiver-path sequence is present, it consists of an + optional list of hosts and a destination mailbox. When the + list of hosts is present, it is source routing information + and indicates that the mail must be relayed to the first + host on the list. + + The receiver treats the lines following the command as mail + text from the sender. The mail text is terminated by the + character sequence "<CRLF>.<CRLF>", (see Section 5.5.2 on + Transparency). + + As mail is relayed along the receiver-path sequence, each + relay host must remove itself from the path sequence and put + itself at the beginning of the sender-path sequence. When + mail reaches its ultimate destination (the receiver-path + + + +[Page 16] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + sequence has only a destination mailbox), the receiver-MTP + inserts it into the destination mailbox in accordance with + its host mail conventions. (For example, "MAIL FROM:<X@Y> + TO:<@A,@B,C@D> <CRLF>" will eventually be relayed as "MAIL + FROM:<@A,X@Y> TO:<@B,C@D> <CRLF>.) + + If the receiver-path sequence is empty, the mail is destined + for a printer or other designated place for host general + delivery mail (if allowed at this host). The mail may be + marked as sent from the sender as specified in the + sender-path sequence field. + + MAIL RECIPIENT SCHEME QUESTION (MRSQ) + + This MTP command is used to select a scheme for the + transmission of mail to several users at the same host. The + schemes are recipients-first, or text-first. + + MAIL RECIPIENT (MRCP) + + This command is used to identify the individual recipients + of the mail in the transmission of mail for multiple users + at one host. + + HELP (HELP) + + This command causes the receiver to send helpful information + regarding its implementation status over the transmission + channel to the receiver. The command may take an argument + (e.g., any command name) and return more specific + information as a response. + + QUIT (QUIT) + + This command specifies that the receiver must close the + transmission channel. + + NOOP (NOOP) + + This command does not affect any parameters or previously + entered commands. It specifies no action other than that + the receiver send an OK reply. + + + + + + + +Sluizer & Postel [Page 17] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + CONTINUE (CONT) + + This command specifies that the previously specified action + is to be continued. This is sent only following a + preliminary reply. + + ABORT (ABRT) + + This command specifies that the previously specified action + is to be aborted. This is sent only following a preliminary + reply. It specifies no further action other than that the + receiver send an OK reply. + + 5.1.2. COMMAND SYNTAX + + The commands begin with a command code followed by an argument + field. The command codes are four alphabetic characters. + Upper and lower case alphabetic characters are to be treated + identically. Thus any of the following may represent the mail + command: + + MAIL Mail mail MaIl mAIl + + This also applies to any symbols representing parameter values, + such as R or r for RECIPIENT first. The command codes and the + argument fields are separated by one or more spaces. + + But, note that in the sender-path and receiver-path arguments + case is important. In particular, in some hosts the user "foo" + is different from the user "Foo". + + The argument field consists of a variable length character + string ending with the character sequence <CRLF>. It should be + noted that the receiver is to take no action until the end of + the line is received. + + Square brackets denote an optional argument field. If the + option is not taken, the appropriate default is implied. All + characters are in the ASCII characters set. + + + + + + + + + + +[Page 18] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + The following are the MTP commands: + + MAIL <SP> FROM:<sender-path> [<SP> TO:<receiver-path>] <CRLF> + + MRSQ [<SP> <scheme>] <CRLF> + + MRCP <SP> TO:<receiver-path> <CRLF> + + HELP [<SP> <string>] <CRLF> + + QUIT <CRLF> + + NOOP <CRLF> + + CONT <CRLF> + + ABRT <CRLF> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 19] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + The syntax of the above argument fields (using BNF notation + where applicable) is given below. The "..." notation indicates + that a field may be repeated one or more times. + + <sender-path> ::= <path> + + <receiver-path> ::= <path> + + <scheme> ::= "R" | "T" | "?" + + <string> ::= <char> | <char> <string> + + <path> ::= "<" ["@" <host> "," ...] <mailbox> ">" + + <host> ::= <a> <string> | "#" <number> | "[" <dotnum> "]" + + <mailbox> ::= <user> "@" <host> + + <user> ::= <string> + + <char> ::= <c> | '\' <c> | '\' <s> + + <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> + + <number> ::= <d> | <d> <number> + + <snum> ::= three digits representing an integer value in the + range 0 through 255 + + <specials> ::= '<', '>', '(', ')', '\', ',', ';', ':', '@', + '"', and the control characters (ASCII codes 0 through 37 + octal inclusive and 177 octal) + + <a> ::= any one of the 26 letters A through Z in either case + + <c> ::= any one of the 128 ASCII characters except + <specials> + + <d> ::= any one of the ten digits 0 through 9 + + <s> ::= any one of <specials> + + Note that the backslash, '\', is a quote character, which is + used to indicate that the next character is to be used + literally instead of with its normal interpretation. For + + + + +[Page 20] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + example, "Joe\,Smith" could be used to indicate a single + nine character user field with comma being the fourth + character of the field. + + Hosts are generally known by names which are translated to + addresses in each host. Sometimes a host is not known to the + translation function and communication is blocked. To bypass + this barrier numeric forms are also allowed for host "names". + One form is a decimal integer prefixed by a pound sign, "#", + which indicates the number is the address of the host. Another + form is four small decimal integers separated by dots and + enclosed by brackets, e.g., "[123.255.37.321]", which indicates + a 32 bit ARPA Internet Address in four eight bit fields. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 21] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + 5.2. MTP REPLIES + + Replies to MTP commands are devised to ensure the synchronization + of requests and actions in the process of mail transfer, and to + guarantee that the sender-MTP always knows the state of the + receiver-MTP. Every command must generate exactly one reply. + Additionally, some commands must occur sequentially, such as + MRSQ T->MAIL->MRCP or MRSQ R->MRCP->MAIL. + + The details of the command-reply sequence are made explicit in + the Sections 5.3 and 5.4 on Sequencing and State Diagrams. + + An MTP reply consists of a three digit number (transmitted as + three alphanumeric characters) followed by some text. The number + is intended for use by automata to determine what state to enter + next; the text is meant for the human user. It is intended that + the three digits contain enough encoded information that the + sender-MTP will not need to examine the text and may either + discard it or pass it on to the user, as appropriate. In + particular, the text may be receiver-dependent, so there are + likely to be varying texts for each reply code. Further + explanation of the assignment of reply codes is given in the + Appendix E on the Theory of Reply Codes. Formally, a reply is + defined to be the sequence: a three-digit code, <SP>, one line of + text, and <CRLF>. + + + + + + + + + + + + + + + + + + + + + + + + +[Page 22] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + 5.2.1. REPLY CODES BY FUNCTION GROUPS + + 200 Command okay + 201 Command okay, action aborted + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + 215 <scheme> is the preferred scheme + + 120 <host> Service ready in nnn minutes + 220 <host> Service ready for new user + 221 <host> Service closing transmission channel + 421 <host> Service not available, closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + + 151 User not local; will forward to <user>@<host> + 152 User unknown; mail will be forwarded by the operator + 250 Requested mail action okay, completed + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage + 552 Requested mail action aborted: exceeded storage allocation + [For current mailbox location] + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 354 Start mail input; end with <CRLF>.<CRLF> + + + + + + + + + + +Sluizer & Postel [Page 23] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + 5.2.2. NUMERIC ORDER LIST OF REPLY CODES + + 120 <host> Service ready in nnn minutes + 151 User not local; will forward to <user>@<host> + 152 User unknown; mail will be forwarded by the operator + + 200 Command okay + 201 Command okay, action aborted + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + 215 <scheme> is the preferred scheme + 220 <host> Service ready for new user + 221 <host> Service closing transmission channel + 250 Requested mail action okay, completed + + 354 Start mail input; end with <CRLF>.<CRLF> + + 421 <host> Service not available, closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 552 Requested mail action aborted: exceeded storage allocation + [For current mailbox location] + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + + + + + + + + + +[Page 24] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + 5.3. SEQUENCING OF COMMANDS AND REPLIES + + The communication between the sender and receiver is intended to + be an alternating dialogue. As such, the sender issues an MTP + command and the receiver responds with a prompt primary reply. + The sender should wait for this response before sending further + commands. + + The preliminary (1xx) and intermediate (3xx) replies indicate that + further commands and information are required to complete the + required action. The preliminary replies require either a + continue or abort command to proceed; the intermediate replies + require action dependent further commands. + + One important reply is the connection greetings. Under normal + circumstances, a receiver will send a 220 "Awaiting input" reply + when the connection is completed. The sender should wait for this + greeting message before sending any commands. If the receiver is + unable to accept input right away, it should send a 120 "Expected + delay" reply immediately. The sender can then indicate it is + willing to wait via a continue command, or not via the abort + command. The receiver will respond to the abort with a 201 reply, + and to the continue with the 220 reply when ready. + + Note: all the greeting type replies have the official name of + the server host as the first word following the reply code. + + For example, + + 220 <SP> USC-ISIF <SP> Service ready <CRLF> + + The table below lists alternative success and failure replies for + each command. These must be strictly adhered to; a receiver may + substitute text in the replies, but the meaning and action implied + by the code numbers and by the specific command reply sequence + cannot be altered. + + COMMAND-REPLY SEQUENCES + + Each command is listed with its possible replies. Preliminary + replies are listed first with their succeeding replies indented + under them, then success and failure completion, and finally + intermediary replies with the remaining commands from the + sequence following. The prefixes used before the possible + replies are "P" for preliminary, "I" for intermediate, "S" for + success, "F" for failure, and "E" for error. The 421 reply + + + +Sluizer & Postel [Page 25] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + (service not available, closing transmission channel) may be + given to any command if the MTP-receiver knows it must shut + down. This listing forms the basis for the State Diagrams, in + Section 5.4. + + CONNECTION ESTABLISHMENT + P: 120 -> CONT -> S: 220 + F: 421 + ABRT S: 201 + F: 421 + S: 220 + F: 421 + MAIL + P: 151 -> CONT -> I: 354 -> text -> S: 250 + 152 F: 451,552,450, + 550,452,553 + ABRT -> S: 201 + F: 451,552,450,550,452,553 + I: 354 -> text -> S: 250 + F: 451,552,450,550,452,553 + F: 451, 552, 450, 550, 452, 553 + E: 500, 501, 502, 421 + MRSQ + S: 200, 215 + E: 500, 501, 502, 504, 421 + MRCP + P: 151 -> CONT -> S: 200, 215, 250 + 152 F: 451,552,450,550,452,553 + ABRT -> S: 201 + F: 451,552,450,550,452,553 + S: 200, 215, 250 + F: 451, 552, 450, 550, 452, 553 + E: 500, 501, 502, 503, 421 + + + + + + + + + + + + + + + + +[Page 26] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + QUIT + S: 221 + E: 500, 421 + HELP + S: 211, 214 + E: 500, 501, 502, 504, 421 + NOOP + S: 200 + E: 500, 421 + CONT + S: depends on previous command + F: depends on previous command + E: 500, 501, 502, 504, 421 + ABRT + S: 201, + E: 500, 501, 502, 504, 421 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 27] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + 5.4. STATE DIAGRAMS + + Following are state diagrams for a very simple minded MTP + implementation. Only the first digit of the reply codes is used. + There is one state diagram for each group of MTP commands. + + The command groupings were determined by constructing a model for + each command and then collecting together the commands with + structurally identical models. + + For each command there are three possible outcomes: "success" + (S), "failure" (F), and "error" (E). In the state diagrams below + we use the symbol B for "begin", and the symbol W for "wait for + reply". + + First, the diagram that represents most of the MTP commands: + + + 1,3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ +---+ +---+ + | + | 4,5 +---+ + ----------->| F | + +---+ + + + This diagram models the commands: + + HELP, MRCP, MRSQ, NOOP, QUIT, ABRT. + + + + + + + + + + + + + + + +[Page 28] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + A more complex diagram models the MAIL command: + + + ABRT +---+ 1,3 + CONT ---- ------------->| W |------- + | | +---+ | + | |1 4,5| |2 V + +---+ cmd -->+---+ 2 | | +---+ + | B |---------->| W |-------------------->| E | + +---+ +---+ ------------>+---+ + 3| |4,5 | | | + | | | | | + -------------- ------ | | | + | | | | ---->+---+ + | ----------------------->| S | + | | | | | +---+ + | | -------- | + | | | | | + V 2| |1,3 | | + +---+ text +---+ | ------->+---+ + | |---------->| W | --------------->| F | + +---+ +---+-------------------->+---+ + 4,5 + + + Note that the "text" here is a series of lines sent from the + sender to the receiver with no response expected until the last + line is sent. + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 29] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + 5.5. DETAILS + + 5.5.1. MINIMUM IMPLEMENTATION + + In order to make MTP workable, the following minimum + implementation is required for all receivers: + + COMMANDS -- MAIL + QUIT + NOOP + + 5.5.2. TRANSPARENCY + + Without some provision for data transparency the character + sequence "<CRLF>.<CRLF>" ends the the mail text and cannot be + sent by the user. In general, users are not aware of such + "forbidden" sequences. To allow all user composed text to be + transmitted transparently the following procedures are used. + + 1. Before sending a line of mail text the sender-MTP checks the + first character of the line. If it is a period, one additional + period is inserted at the beginning of the line. + + 2. When a line of mail text is received by the receiver-MTP it + checks the the line. If the line is composed of a single + period it is the end of mail. If the first character is a + period and there are other characters on the line, the first + character is deleted. + + 5.5.3. SIZES + + There are several objects that ought to have defined maximum + sizes. + + user + + The maximum total length of a user name is 40 characters. + + host + + The maximum total length of a host name or number is 20 + characters. + + + + + + + +[Page 30] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + path + + The maximum total length of a sender-path or + receiver-path is 100 characters. + + command line + + The maximum total length of a command line including the + command word and the <CRLF> is 200 characters. + + reply line + + The maximum total length of a reply line including the + reply code and the <CRLF> is 65 characters. + + text line + + The maximum total length of a text line including the the + <CRLF> is 1000 characters. + + To the maximum extent possible implementation techniques which + impose no limits at all to the length of these objects should + be used. + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 31] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + +APPENDIX A + + TCP Transport service + + The Transmission Control Protocol [1] is used in the ARPA + Internet, and in any network following the US DoD standards for + internetwork protocols. + + Connection Establishment + + The MTP transmission channel is a TCP connection established + between the sender process port U and the receiver process port + L. This single full duplex connection is used as the + transmission channel. This protocol is assigned the service + port 57 (71 octal), that is L=57. + + Data Transfer + + The TCP connection supports the transmission of 8-bit bytes. + The MTP data is 7-bit ASCII characters. Each character is + transmitted as a 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 32] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + +APPENDIX B + + NCP Transport service + + The ARPANET Host-to-Host Protocol [2] (implemented by the Network + Control Program) may be used in the ARPANET. + + Connection Establishment + + The MTP transmission channel is established via NCP between the + the sender process socket U and receiver process socket L. The + Initial Connection Protocol [3] is followed resulting in a pair + of simplex connections. This pair of connections is used as + the transmission channel. This protocol is assigned the + contact socket 57 (71 octal), that is L=57. + + Data Transfer + + The NCP data connections are established in 8-bit byte mode. + The MTP data is 7-bit ASCII characters. Each character is + transmitted as a 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 33] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + +APPENDIX C + + NITS + + The Network Independent Transport Service [4] may be used. + + Connection Establishment + + The MTP transmission channel is established via NITS between + the the sender process and receiver process. The sender + process executes the CONNECT primitive, and the waiting + receiver process executes the ACCEPT primitive. + + Data Transfer + + The NITS connection supports the transmission of 8-bit bytes. + The MTP data is 7-bit ASCII characters. Each character is + transmitted as a 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 34] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + +APPENDIX D + + X.25 Transport service + + It may be possible to use the X.25 service [5] as provided by the + Public Data Networks directly, but there are indications that it + is too error prone to qualify as a reliable channel. It is + suggested that a reliable end-to-end protocol such as TCP be used + on top of X.25 connections. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 35] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + +APPENDIX E + + Theory of Reply Codes + + The three digits of the reply each have a special significance. + The first digit denotes whether the response is good, bad or + incomplete. An unsophisticated sender-MTP will be able to + determine its next action (proceed as planned, redo, retrench, + etc.) by simply examining this first digit. A sender-MTP that + wants to know approximately what kind of error occurred (e.g., + mail system error, command syntax error) may examine the second + digit, reserving the third digit for the finest gradation of + information. + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + + The command has been accepted, but the requested action + is being held in abeyance, pending confirmation of the + information in this reply. The sender-MTP should send + another command specifying whether to continue or abort + the action. + + 2yz Positive Completion reply + + The requested action has been successfully completed. A + new request may be initiated. + + 3yz Positive Intermediate reply + + The command has been accepted, but the requested action + is being held in abeyance, pending receipt of further + information. The sender-MTP should send another command + specifying this information. This reply is used in + command sequence groups. + + 4yz Transient Negative Completion reply + + The command was not accepted and the requested action did + not occur. However, the error condition is temporary and + the action may be requested again. The sender should + return to the beginning of the command sequence (if any). + It is difficult to assign a meaning to "transient" when + two different sites (receiver- and sender- MTPs) must + agree on the interpretation. Each reply in this category + + + +[Page 36] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + might have a different time value, but the sender-MTP is + encouraged to try again. A rule of thumb to determine if + a reply fits into the 4yz or the 5yz category (see below) + is that replies are 4yz if they can be repeated without + any change in command form or in properties of the sender + or receiver. (E.g., the command is repeated identically; + the receiver does not put up a new implementation). + + 5yz Permanent Negative Completion reply + + The command was not accepted and the requested action did + not occur. The sender-MTP is discouraged from repeating + the exact request (in the same sequence). Even some + "permanent" error conditions can be corrected, so the + human user may want to direct the sender-MTP to + reinitiate the command sequence by direct action at some + point in the future (e.g., after the spelling has been + changed, or the user has altered the account status.) + + The second digit encodes responses in specific categories: + + x0z Syntax -- These replies refer to syntax errors, + syntactically correct commands that don't fit any + functional category, and unimplemented or superfluous + commands. + + x1z Information -- These are replies to requests for + information, such as status or help. + + x2z Connections -- These are replies referring to the + transmission channel. + + x3z Unspecified as yet. + + x4z Unspecified as yet. + + x5z Mail system -- These replies indicate the status of + the receiver mail system vis-a-vis the requested + transfer or other mail system action. + + The third digit gives a finer gradation of meaning in each + category specified by the second digit. The list of replies + illustrates this. Each reply text is recommended rather than + mandatory, and may even change according to the command with + which it is associated. On the other hand, the reply codes + must strictly follow the specifications in this section. + + + +Sluizer & Postel [Page 37] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + Receiver implementations should not invent new codes for + slightly different situations from the ones described here, but + rather adapt codes already defined. + + For example, a command such as NOOP whose successful execution + does not offer the sender-MTP any new information will return a + 200 reply. The response is 502 when the command requests an + unimplemented non-site-specific action. A refinement of that + is the 504 reply for a command that is implemented, but that + requests an unimplemented parameter. + + The reply text may be longer than a single line; in these cases + the complete text must be marked so the sender-MTP knows when it + can stop reading the reply. This requires a special format to + indicate a multiple line reply. + + The format for multi-line replies requires that every line, + except the last, begin with the reply code, followed + immediately by a hyphen, "-" (also known as minus), followed by + text. The last line will begin with the reply code, followed + immediately by <SP>, optionally some text, and <CRLF>. + + For example: + 123-First line + 123-Second line + 123-234 text beginning with numbers + 123 The last line + + The sender-MTP then simply needs to search for the reply code + followed by <SP> at the beginning of a line, and ignore all + preceding lines. + + + + + + + + + + + + + + + + + + +[Page 38] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + +GLOSSARY + + ASCII + + American Standard Code for Information Interchange [6]. + + command + + A request for a mail service action sent by the sender-MTP to the + receiver-MTP. + + host + + A computer in the internetwork environment on which mailboxes or + MTP processes reside. + + line + + A line of text ending with a <CRLF>. + + mail + + A sequence of ASCII characters of arbitrary length, which conforms + to the standard set in RFC 733 (Standard for the Format of ARPA + Network Text Messages [7]). + + mailbox + + A character string (address) which identifies a user to whom mail + is to be sent. Mailbox normally consists of the host and user + specifications. The standard mailbox naming convention is defined + to be "user@host". Additionally, the "container" in which mail is + stored. + + receiver-MTP process + + A process which transfers mail in cooperation with a sender-MTP + process. It waits for a connection to be established via the + transport service. It receives MTP commands from the sender-MTP, + sends replies, and governs the transfer of mail. + + + + + + + + + +Sluizer & Postel [Page 39] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + + reply + + A reply is an acknowledgment (positive or negative) sent from + receiver to sender via the transmission channel in response to a + MTP command. The general form of a reply is a completion code + (including error codes) followed by a text string. The codes are + for use by programs and the text is usually intended for human + users. + + sender-MTP process + + A process which transfers mail in cooperation with a receiver-MTP + process. A local language may be used in the user interface + command/reply dialogue. The sender-MTP initiates the transport + service connection. It initiates MTP commands, receives replies, + and governs the transfer of mail. + + transmission channel + + A full-duplex communication path between a sender-MTP and a + receiver-MTP for the exchange of commands, replies, and mail text. + + transport service + + Any reliable stream-oriented data communication services. For + example, NCP, TCP, NITS. + + user + + A human being (or a process on behalf of a human being) wishing to + obtain mail transfer service. In addition, a recipient of + computer mail. + + word + + A human being (or a process on behalf of a human being) wishing to + obtain mail transfer service. In addition, a recipient of + computer mail. + + <CRLF> + + The characters carriage return and line feed (in that order). + + + + + + + +[Page 40] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + <SP> + + The space character. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 41] + + + +May 1981 RFC 780 +Mail Transfer Protocol + + + +REFERENCES + + [1] TCP + + Postel, J., ed., "DOD Standard Transmission Control Protocol", + IEN 129, RFC 761, USC/Information Sciences Institute, + NTIS ADA082609, January 1980. Appears in: Computer Communication + Review, Special Interest Group on Data Communications, ACM, V.10, + N.4, October 1980. + + [2] NCP + + McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, + January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [3] Initial Connection Protocol + + Postel, J., "Official Initial Connection Protocol", NIC 7101, + 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [4] NITS + + PSS/SG3, "A Network Independent Transport Service", Study Group 3, + The Post Office PSS Users Group, February 1980. Available from + the DCPU, National Physical Laboratory, Teddington, UK. + + [5] X.25 + + CCITT, "Recommendation X.25 - Interface Between Data Terminal + Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for + Terminals Operating in the Packet Mode on Public Data Networks," + CCITT Orange Book, Vol. VIII.2, International Telephone and + Telegraph Consultative Committee, Geneva, 1976. + + + + + + + + + + +[Page 42] Sluizer & Postel + + + +RFC 780 May 1981 + Mail Transfer Protocol + + + + [6] ASCII + + ASCII, "USA Code for Information Interchange", United States of + America Standards Institute, X3.4, 1968. Also in: Feinler, E. + and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for + the Defense Communications Agency by SRI International, Menlo + Park, California, Revised January 1978. + + [7] RFC 733 + + Crocker, D., J. Vittal, K. Pogran, and D. Henderson, "Standard for + the Format of ARPA Network Text Messages," RFC 733, NIC 41952, + November 1977. Also in: Feinler, E. and J. Postel, eds., + "ARPANET Protocol Handbook", NIC 7104, for the Defense + Communications Agency by SRI International, Menlo Park, + California, Revised January 1978. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sluizer & Postel [Page 43] + diff --git a/Documentation/en/rfc/rfc788.txt b/Documentation/en/rfc/rfc788.txt new file mode 100644 index 00000000..b4b01fcb --- /dev/null +++ b/Documentation/en/rfc/rfc788.txt @@ -0,0 +1,3697 @@ +RFC788 + + + + + + + + SIMPLE MAIL TRANSFER PROTOCOL + + + + Jonathan B. Postel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + November 1981 + + + + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, California 90291 + + (213) 822-1511 + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + TABLE OF CONTENTS + + 1. INTRODUCTION .................................................. 1 + + 2. THE SMTP MODEL ................................................ 2 + + 3. THE SMTP PROCEDURE ............................................ 4 + + 3.1. Mail ..................................................... 4 + 3.2. Forwarding ............................................... 7 + 3.3. Verifying and Expanding .................................. 8 + 3.4. Sending and Mailing ..................................... 10 + 3.5. Opening and Closing ..................................... 12 + 3.6. Relaying ................................................ 13 + 3.7. Domains ................................................. 15 + + 4. THE SMTP SPECIFICATIONS ...................................... 16 + + 4.1. SMTP Commands ........................................... 16 + 4.1.1. Command Semantics ..................................... 16 + 4.1.2. Command Syntax ........................................ 23 + 4.2. SMTP Replies ............................................ 28 + 4.2.1. Reply Codes by Function Group ......................... 29 + 4.2.2. Reply Codes in Numeric Order .......................... 30 + 4.3. Sequencing of Commands and Replies ...................... 31 + 4.4. State Diagrams .......................................... 33 + 4.5. Details ................................................. 35 + 4.5.1. Minimum Implementation ................................ 35 + 4.5.2. Transparency .......................................... 35 + 4.5.3. Sizes ................................................. 36 + + APPENDIX A: TCP ................................................. 38 + APPENDIX B: NCP ................................................. 39 + APPENDIX C: NITS ................................................ 40 + APPENDIX D: X.25 ................................................ 41 + APPENDIX E: Theory of Reply Codes ............................... 42 + APPENDIX F: Scenarios ........................................... 45 + + GLOSSARY ......................................................... 58 + + REFERENCES ....................................................... 61 + + +Network Working Group J. Postel +Request for Comments: 788 ISI +Replaces: RFC 780, 772 November 1981 + + SIMPLE MAIL TRANSFER PROTOCOL + + +1. INTRODUCTION + + The objective of Simple Mail Transfer Protocol (SMTP) is to transfer + mail reliably and efficiently. + + SMTP is independent of the particular transmission subsystem and + requires only a reliable ordered data stream channel. Appendices A, + B, C, and D describe the use of SMTP with various transport services. + A Glossary provides the definitions of terms as used in this + document. + + An important feature of SMTP is its capability to relay mail across + transport service environments. A transport service provides an + interprocess communication environment (IPCE). An IPCE may cover one + network, several networks, or a subset of a network. It is important + to realize that transport systems (or IPCEs) are not one-to-one with + networks. A process can communicate directly with another process + through any mutually known IPCE. Mail is an application or use of + interprocess communication. Mail can be communicated between + processes in different IPCEs by relaying through a process connected + to two (or more) IPCEs. More specifically, mail can be relayed + between hosts on different transport systems by a host on both + transport systems. + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 1] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + +2. THE SMTP MODEL + + The SMTP design is based on the following model of communication: as + the result of a user mail request, the sender-SMTP establishes a + full-duplex transmission channel to a receiver-SMTP. The + receiver-SMTP may be either the ultimate destination or an + intermediate. SMTP commands are generated by the sender-SMTP and + sent to the receiver-SMTP. SMTP replies are sent from the + receiver-SMTP to the sender-SMTP in response to the commands. + + Once the transmission channel is established, the SMTP-sender sends a + MAIL command indicating the sender of the mail. If the SMTP-receiver + can accept mail it responds with an OK reply. The SMTP-sender then + sends a RCPT command identifying a recipient of the mail. If the + SMTP-receiver can accept mail for that recipient it responds with an + OK reply; if not, it responds with a reply rejecting that recipient + (but not the whole mail transaction). The SMTP-sender and + SMTP-receiver may negotiate several recipients. When the recipients + have been negotiated the SMTP-sender sends the mail data, terminating + with a special sequence. If the SMTP-receiver successfully processes + the mail data it responds with an OK reply. The dialog is purposely + lock-step, one-at-a-time. + + ------------------------------------------------------------- + + + +----------+ +----------+ + +------+ | | | | + | User |<-->| | SMTP | | + +------+ | Sender- |Commands/Replies| Receiver-| + +------+ | SMTP |<-------------->| SMTP | +------+ + | File |<-->| | and Mail | |<-->| File | + |System| | | | | |System| + +------+ +----------+ +----------+ +------+ + + + Sender-SMTP Receiver-SMTP + + Model for SMTP Use + + Figure 1 + + ------------------------------------------------------------- + + The SMTP provides mechanisms for the transmission of mail; directly + from the sending user's host to the receiving user's host when the + + + +[Page 2] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + two host are connected to the same transport service, or via one or + more relay SMTP-servers when the source and destination hosts are not + connected to the same transport service. + + To be able to provide the relay capability the SMTP-server must be + supplied with the name of the ultimate destination host as well as + the destination mailbox name. + + The argument to the MAIL command is a reverse-path, which specifies + who the mail is from. The argument to the RCPT command is a + forward-path, which specifies who the mail is to. The forward-path + is a source route while the reverse-path, is a return route (which + may be used to return a message to the sender when an error occurs + with a relayed message). + + When the same message is sent to multiple recipients the SMTP + encourages the transmission of only one copy of the data for all the + recipients at the same destination host. + + The mail commands and replies have a rigid syntax. Replies also have + a numeric code. In the following, examples appear which use actual + commands and replies. The complete lists of commands and replies + appears in Section 4 on specifications. + + Commands and replies are not case sensitive. That is, a command or + reply word may be upper case, lower case, or any mixture of upper and + lower case. Note that this is not true of mailbox user names. For + some hosts the user name is case sensitive, and SMTP implementations + must take case to preserve the case of user names as they appear in + mailbox arguments. Host names are not case sensitive. + + Commands and replies are composed of characters from the ASCII + character set [1]. Each 7-bit character is transmitted right + justified in an 8-bit byte (or octet) with the high order bit cleared + to zero. + + When specifying the general form of a command or reply, an argument + (or special symbol) will be denoted by a meta-linguistic variable (or + constant), for example, "<string>" or "<reverse-path>". Here the + angle brackets indicate these are a meta-linguistic variables. + However, some arguments use the angle brackets literally. For + example, an actual reverse-path is enclosed in angle brackets, i.e., + "<Smith@ISIA>" is an instance of <reverse-path> (the angle brackets + are actually transmitted in the command or reply). + + + + + +Postel [Page 3] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + +3. THE SMTP PROCEDURES + + This section presents the procedures used in SMTP in several parts. + First comes the basic mail procedure defined as a mail transaction. + Following this are descriptions of forwarding mail, verifying mailbox + names and expanding mailing lists, sending to terminals instead of or + in combination with mailboxes, and the opening and closing exchanges. + At the end of this section are comments on relaying, and a note on + mail domains. Throughout this section are examples of partial + command and reply sequences, several complete scenarios are presented + in Appendix F. + + 3.1. MAIL + + There are three steps to a SMTP mail transaction. The transaction + is started with a MAIL command which gives the sender + identification. A series of one or more RCPT commands follow + giving the receiver information. Then a DATA command gives the + mail data. And finally, the end of mail data indicator confirms + the transaction. + + The first step in the procedure is the MAIL command. The + <reverse-path> contains the source mailbox. + + MAIL <SP> FROM:<reverse-path> <CRLF> + + This command tells the the SMTP-receiver that a new mail + transaction is starting and to reset all its state tables and + buffers including any recipients or mail data. It gives the + reverse-path which can be used to report errors. If accepted, + the receiver-SMTP returns a 250 OK reply. + + The <reverse-path> can contain more than just a mailbox. The + <reverse-path> is a reverse source routing list of hosts and + source mailbox. The first host in the <reverse-path> should be + the host sending this command. + + The second step in the procedure is the RCPT command. + + RCPT <SP> TO:<forward-path> <CRLF> + + This command gives a forward-path identifying one recipient. + If accepted, the receiver-SMTP returns a 250 OK reply, and + stores the forward-path. If the recipient is unknown the + receiver-SMTP returns a 550 Failure reply. This second step of + the procedure can be repeated any number of times. + + + +[Page 4] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + The <forward-path> can contain more than just a mailbox. The + <forward-path> is a source routing list of hosts and + destination mailbox. The first host in the <forward-path> + should be the host receiving this command. + + The third step in the procedure is the DATA command. + + DATA <CRLF> + + If accepted, the receiver-SMTP returns a 354 Intermediate reply + and considers all succeeding lines to be the message text. + When the end of text is received and stored the SMTP-receiver + sends a 250 OK reply. + + Since the mail data is sent on the transmission channel the end + of the mail data must be indicated so that the command and + reply dialog can be resumed. SMTP indicates the end of the + mail data by sending a line containing only a period. A + transparency procedure is used to prevent this interfering with + the user's text (see Section 4.5.2). + + Please note that the mail data includes the memo header + items such as Date, Subject, To, Cc, From [2]. + + The end of mail data indicator also confirms the mail + transaction and tells the receiver-SMTP to now process the + stored recipients and mail data. If accepted, the + receiver-SMTP returns a 250 OK reply. The DATA command should + fail only if the mail transaction was incomplete (for example, + no recipients), or if resources are not available. + + The above procedure is an example of a SMTP mail transaction. + These commands must be used only in the order discussed above. + Example 1 (below) illustrates the use of these commands in a mail + transaction. + + + + + + + + + + + + + + +Postel [Page 5] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of the SMTP Procedure + + This SMTP example shows mail sent by Smith at host Alpha, to + Jones, Green, and Brown at host Beta. Here we assume that host + Alpha contacts host Beta directly. + + S: MAIL FROM:<Smith@Alpha> + R: 250 OK + + S: RCPT TO:<Jones@Beta> + R: 250 OK + + S: RCPT TO:<Green@Beta> + R: 550 No such user here + + S: RCPT TO:<Brown@Beta> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: <CRLF>.<CRLF> + R: 250 OK + + The mail has now been accepted for Jones and Brown. Green did + not have a mailbox at host Beta. + + Example 1 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + +[Page 6] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + 3.2. FORWARDING + + There are some cases where the destination information in the + <forward-path> is incorrect, but the receiver-SMTP knows the + correct destination. In such cases, one the following replies + should be used to allow the sender to contact the correct + destination. + + 251 User not local; will forward to <forward-path> + + This reply indicates that the receiver-SMTP knows the user's + mailbox is on another host and indicates the correct + forward-path to use in the future. Note that either the + host or user or both may be different. The receiver takes + responsibility for delivering the message. + + 551 User not local; please try <forward-path> + + This reply indicates that the receiver-SMTP knows the user's + mailbox is on another host and indicates the correct + forward-path to use. Note that either the host or user or + both may be different. The receiver refuses to accept mail + for this user, and the sender must either redirect the mail + according to the information provided or return an error + response to the originating user. + + Example 2 illustrates the use of these responses. + + ------------------------------------------------------------- + + Example of Forwarding + + Either + + S: RCPT TO:<Postel@ISI> + R: 251 User not local; will forward to <Postel@ISIF> + + Or + + S: RCPT TO:<Paul@ISIB> + R: 551 User not local; please try <Mockapetris@ISIF> + + Example 2 + + ------------------------------------------------------------- + + + + +Postel [Page 7] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + 3.3. VERIFYING AND EXPANDING + + SMTP provides as additional features, commands to verify a user + name or expand a mailing list. This is done with the VRFY and + EXPN commands, which have a character string arguments. For the + VRFY command, the string is a user name, and the the response may + include the full name of the user and must include the mailbox of + the user. For the EXPN command, the string identifies a mailing + list, and the multiline response may include the full name of the + users and must give the mailboxes on the mailing list. + + The case of verifying a user name is straightforward as shown in + example 3. + + ------------------------------------------------------------- + + Example of Verifying a User Name + + Either + + S: VRFY Postel + R: 250 Jon Postel <Postel@ISIF> + + Or + + S: VRFY Jones + R: 550 String does not match anything. + + Example 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + +[Page 8] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + The case of expanding a mailbox list requires a multiline reply as + shown in example 4. + + ------------------------------------------------------------- + + Example of Expanding a Mailing List + + Either + + S: EXPN Example-People + R: 250-Jon Postel <Postel@ISIF> + R: 250-Fred Fonebone <Fonebone@ISIQ> + R: 250-Sam Q. Smith <SQSmith@ISIQ> + R: 250-Quincy Smith <@ISIF,Q-Smith@ISI-VAXA> + R: 250-<joe@foo-unix> + R: 250 <xyz@bar-unix> + + Or + + S: EXPN Executive-Washroom-List + R: 550 Access Denied to You. + + Example 4 + + ------------------------------------------------------------- + + The character string arguments of the VRFY and EXPN commands + cannot be further restricted due to the variety of implementations + of the user name and mailbox list concepts. On some systems it + may be appropriate for the argument of the EXPN command to be a + file name for a file containing a mailing list, but again there is + a variety of file naming conventions in the internet. + + The VRFY and EXPN commands are not included in the minimum + implementation (Section 4.5.1), and are not required to work + across relays when they are implemented. + + + + + + + + + + + + + +Postel [Page 9] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + 3.4. SENDING AND MAILING + + The main purpose of SMTP is to deliver messages to user's + mailboxes. A very similar service provided by some hosts is to + deliver messages to user's terminals (provided the user is active + on the host). The delivery to the user's mailbox is called + "mailing", the delivery to the user's terminal is called + "sending". Because in many hosts the implementation of sending is + nearly identical to the implementation of mailing these two + functions are combined in SMTP. However the sending commands are + not included in the required minimum implementation + (Section 4.5.1). User's should have the ability to control the + writing of messages on their terminals. Most hosts permit the + user's to accept or refuse such messages. + + The following three command are defined to support the sending + options, these are used in the mail transaction instead of the + MAIL command and inform the receiver-SMTP of the special semantics + of this transaction: + + SEND <SP> FROM:<reverse-path> <CRLF> + + The SEND command requires that the mail data be delivered to + the user's terminal. If the user is not active (or not + accepting terminal messages) on the host a 450 reply may + returned to a RCPT command. The mail transaction is + successful if the message is delivered the terminal. + + SOML <SP> FROM:<reverse-path> <CRLF> + + The Send Or MaiL command requires that the mail data be + delivered to the user's terminal if the user is active (and + accepting terminal messages) on the host. If the user is + not active (or not accepting terminal messages) then the + mail data is entered into the user's mailbox. The mail + transaction is successful if the message is delivered either + to the terminal or the mailbox. + + SAML <SP> FROM:<reverse-path> <CRLF> + + The Send And MaiL command requires that the mail data be + delivered to the user's terminal if the user is active (and + accepting terminal messages) on the host. In any case the + mail data is entered into the user's mailbox. The mail + transaction is successful if the message is delivered the + mailbox. + + + +[Page 10] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + The same reply codes that are used for the MAIL commands are used + for these commands. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 11] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + 3.5. OPENING AND CLOSING + + At the time the transmission channel is opened there is an + exchange to ensure that the hosts are communicating with the hosts + they think they are. + + The following two commands are used in transmission channel + opening and closing: + + HELO <SP> <host> <CRLF> + + QUIT <CRLF> + + In the HELO command the host sending the command identifies + itself; the command may be interpreted as saying "Hello, i am + <host>". + + ------------------------------------------------------------- + + Example of Connection Opening + + R: 220 BBN-UNIX Simple Mail Transfer Service Ready + S: HELO USC-ISIF + R: 250 BBN-UNIX + + Example 5 + + ------------------------------------------------------------- + + ------------------------------------------------------------- + + Example of Connection Closing + + S: QUIT + R: 221 BBN-UNIX Service closing transmission channel + + Example 6 + + ------------------------------------------------------------- + + + + + + + + + + +[Page 12] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + 3.6. RELAYING + + The forward-path may be a source route of the form + "@ONE,@TWO,JOE@THREE", where ONE, TWO, and THREE are hosts. This + form is used to emphasize the distinction between an address and a + route. The mailbox is an absolute address, and the route is + information about how to get there. The two concepts should not + be confused. + + The elements of the forward-path are moved to the reverse-path as + the message is relayed from one server-SMTP to another. The + reverse-path is a reverse source route, (i.e., a source route from + the current location of the message to the originator of the + message). When a server-SMTP deletes its identifier from the + forward-path and inserts it into the reverse-path, it must use the + name it is known by in the environment it is sending into, not the + environment the mail came from, in case the server-SMTP is known + by different names in different environments. + + Using source routing the receiver-SMTP receives mail to be relayed + to another server-SMTP The receiver-SMTP may accept or reject the + task of relaying the mail in the same way it accepts or rejects + mail for a local user. The receiver-SMTP transforms the command + arguments by moving its own identifier from the forward-path to + the beginning of the reverse-path. The receiver-SMTP then becomes + a sender-SMTP, establishes a transmission channel to the next SMTP + in the forward-path, and sends it the mail. + + The first host in the reverse-path should be the host sending the + SMTP commands, and the first host in the forward-path should be + the host receiving the SMTP commands. + + Notice that the forward-path and reverse-path appear in the SMTP + commands and replies, but not necessarily in the message. That + is, there is no need for these paths and especially this syntax to + appear in the "To:" , "From:", "CC:", etc. fields of the message + header. + + If a server-SMTP has accepted the task of relaying the mail and + later finds that the forward-path is incorrect or that the mail + cannot be delivered for whatever reason, then it must construct an + "undeliverable mail" notification message and send it to the + originator of the undeliverable mail (as indicated by the + reverse-path). + + + + + +Postel [Page 13] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + This notification message must be from the server-SMTP at this + host. Of course, server-SMTPs should not send notification + messages about problems with notification messages. One way to + prevent loops in error reporting is to specify a null reverse-path + in the MAIL command of a notification message. When such a + message is relayed it is permissible to leave the reverse-path + null. A MAIL command with a null reverse-path appears as follows: + + MAIL FROM:<> + + An undeliverable mail notification message is shown in example 7. + This notification is in response to a message originated by JOE at + HOSTW and sent via HOSTX to HOSTY with instructions to relay it on + to HOSTZ. What we see in the example is the transaction between + HOSTY and HOSTX, which is the first step in the return of the + notification message. + + ------------------------------------------------------------- + + Example Undeliverable Mail Notification Message + + S: MAIL FROM:<> + R: 250 ok + S: RCPT TO:<@HOSTX,JOE@HOSTW> + R: 250 ok + S: DATA + R: 354 send the mail data, end with . + S: Date: 23 Oct 81 + S: Sender: SMTP@HOSTY + S: Subject: Mail System Problem + S: + S: Sorry JOE, your message to SAM@HOSTZ lost. + S: HOSTZ said this: + S: "550 No Such User" + S: . + R: 250 ok + + Example 7 + + ------------------------------------------------------------- + + + + + + + + + +[Page 14] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + 3.7. DOMAINS + + At some not too distant future time it might be necessary to + expand the mailbox format to include a region or name domain + identifier. There is quite a bit of discussion on this at + present, and is likely that SMTP will be revised in the future to + take into account naming domains. + + The examples in this document do not show mail domains. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 15] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + +4. THE SMTP SPECIFICATIONS + + 4.1. SMTP COMMANDS + + 4.1.1. COMMAND SEMANTICS + + The SMTP commands define the mail transfer or the mail system + function requested by the user. SMTP commands are character + strings terminated by <CRLF>. The command codes themselves are + alphabetic characters terminated by <SP> if parameters follow + and <CRLF> otherwise. The syntax of mailboxes must conform to + receiver site conventions. The SMTP commands are discussed + below. The SMTP replies are discussed in the Section 4.2. + + A mail transaction involves several data objects which are + communicated as arguments to different commands. The + reverse-path is the argument of the MAIL command, the + forward-path is the argument of the RCPT command, and the mail + data is the argument of the DATA command. These arguments or + data objects must be transmitted and held pending the + confirmation communicated by the end of mail data indication + which finalizes the transaction. The model for this is that + distinct buffers are provided to hold the types of data + objects, that is, there is a reverse-path buffer, a + forward-path buffer, and a mail data buffer. Specific commands + cause information to be appended to a specific buffer, or cause + one or more buffers to be cleared. + + HELLO (HELO) + + This command is used to identify the sender-SMTP to the + receiver-SMTP. The argument field contains the host name of + the sender-SMTP. + + The receiver-SMTP identifies itself to the sender-SMTP in + the connection greeting reply, and in the response to this + command. + + MAIL (MAIL) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more mailboxes. The + argument field contains a reverse-path. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + + + +[Page 16] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). In some types of error + reporting messages (for example, undeliverable mail + notifications) the reverse-path may be null (see Example 7). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + RECIPIENT (RCPT) + + This command is used to identify an individual recipient of + the mail data; multiple recipients are specified by multiple + use of this command. + + The forward-path consists of an optional list of hosts and a + required destination mailbox. When the list of hosts is + present, it is a source route and indicates that the mail + must be relayed to the next host on the list. If the + receiver-SMTP is does not implement the relay function it + may user the same reply it would for an unknown local user + (550). + + When mail is relayed, the relay host must remove itself from + the beginning forward-path and put itself at the beginning + of the reverse-path. When mail reaches its ultimate + destination (the forward-path contains only a destination + mailbox), the receiver-SMTP inserts it into the destination + mailbox in accordance with its host mail conventions. + + For example, mail received at relay host A with arguments + + FROM:<X@Y> + TO:<@A,@B,C@D> + + will be relayed on to host B with arguments + + FROM:<@A,X@Y> + TO:<@B,C@D>. + + + +Postel [Page 17] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + This command causes its forward-path argument to be appended + to the forward-path buffer. + + DATA (DATA) + + The receiver treats the lines following the command as mail + data from the sender. This command causes the mail data + from this command to be appended to the mail data buffer. + The mail data may contain any of the 128 ASCII character + codes. + + The mail data is terminated by a line containing only a + period, that is the character sequence "<CRLF>.<CRLF>" (see + Section 4.5.2 on Transparency). This is the end of mail + data indication. + + The end of mail data indication requires that the receiver + must now process the stored mail transaction information. + This processing consumes the information in the reverse-path + buffer, the forward-path buffer, and the mail data buffer, + and on the completion of this command these buffers are + cleared. If the processing is successful the receiver must + send an OK reply. If the processing fails completely the + receiver must send a failure reply. + + When the receiver-SMTP accepts a message either for relaying + or for final delivery it inserts at the beginning of the + mail data a time stamp line. The time stamp line indicates + the identity of the host that sent the message, and the + identity of the host that received the message (and is + inserting this time stamp), and the date and time the + message was received. Relayed messages will have multiple + time stamp lines. + + When the receiver-SMTP makes the "final delivery" of a + message it inserts at the beginning of the mail data a + return path line. The return path line preserves the + information in the <reverse-path> from the MAIL command. + Here, final delivery means the message leaves the SMTP + world. Normally, this would mean it has been delivered to + the destination user, but in some cases it may be further + processed and transmitted by another mail system. + + The preceding two paragraphs imply that the final mail data + + + + + +[Page 18] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + will begin with a return path line, followed by one or more + time stamp lines. These lines will be followed by the mail + data header and body [2]. For example: + + Return-Path: <@GHI,@DEF,@ABC,JOE@ABC> + Mail-From: GHI received by JKL at 27-Oct-81 15:27:39-PST + Mail-From: DEF received by GHI at 27-Oct-81 15:15:13-PST + Mail-From: ABC received by DEF at 27-Oct-81 15:01:59-PST + Date: 27-Oct-81 15:01:01-PST + From: JOE@ABC + Subject: Improved Mailing System Installed + To: SAM@JKL + + This is to inform you that ... + + Special mention is needed of the response and further action + required when the processing following the end of mail data + indication is partially successful. This could arise if + after accepting several recipients and the mail data, the + receiver-SMTP finds that the mail data can be successfully + delivered to some of the recipients, but it cannot be to + others (for example, due to mailbox space allocation + problems). In such a situation, the response to the DATA + command must be an OK reply. But, the receiver-SMTP must + compose and send an "undeliverable mail" notification + message to the originator of the message. Either a single + notification which lists all of the recipients that failed + to get the message, or separate notification messages must + be sent for each failed recipient (see Example 7). All + undeliverable mail notification messages are sent using the + MAIL command (even if they result from processing a SEND, + SOML, or SAML command). + + SEND (SEND) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals. The + argument field contains a reverse-path. This command is + successful if the message is delivered to the terminal. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + + + +Postel [Page 19] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + SEND OR MAIL (SOML) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals or + mailboxes. For each recipient the mail data is delivered to + the recipient's terminal if the recipient is active on the + host (and accepting terminal messages), otherwise to the + recipient's mailbox. The argument field contains a + reverse-path. This command is successful if the message is + delivered to the terminal or the mailbox. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + SEND AND MAIL (SAML) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals and + mailboxes. For each recipient the mail data is delivered to + the recipient's terminal if the recipient is active on the + host (and accepting terminal messages), and for all + + + + + +[Page 20] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + recipients to the recipient's mailbox. The argument field + contains a reverse-path. This command is successful if the + message is delivered to the mailbox. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + RESET (RSET) + + This command specifies that the current mail transaction is + to be aborted. Any stored sender, recipients, and mail data + must be discarded, and all buffers and state tables cleared. + The receiver must send an OK reply. + + VERIFY (VRFY) + + This command asks the receiver to confirm that the argument + identifies a user. If it is a user name, the full name of + the user (if known) and the fully specified mailbox are + returned. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + EXPAND (EXPN) + + This command asks the receiver to confirm that the argument + identifies a mailing list, and if so, to return the + membership of that list. The full name of the users (if + known) and the fully specified mailboxes are returned in a + multiline reply. + + + + + +Postel [Page 21] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + HELP (HELP) + + This command causes the receiver to send helpful information + to the sender of the HELP command. The command may take an + argument (e.g., any command name) and return more specific + information as a response. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + NOOP (NOOP) + + This command does not affect any parameters or previously + entered commands. It specifies no action other than that + the receiver send an OK reply. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + QUIT (QUIT) + + This command specifies that the receiver must send an OK + reply, and then close the transmission channel. + + The receiver should not close the transmission channel until + it receives and replies to a QUIT command (even if there was + an error). The sender should not close the transmission + channel until it send a QUIT command and receives the reply + (even if there was an error response to a previous command). + If the connection is closed prematurely the receiver should + act as if a RSET command had been received (canceling any + pending transaction, but not undoing any previously + completed transaction), the sender should act as if the + command or transaction in progress had received a temporary + error (4xx). + + There are restrictions on the order in which these command may + be used. + + The first command in a session must be the HELO command. + The HELO command may be used later in a session as well. + + + + + +[Page 22] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + The NOOP, HELP, EXPN, and VRFY commands can be used at any + time during a session. + + The MAIL, SEND, SOML, or SAML commands begin a mail + transaction. Once started a mail transaction consists of + one of the transaction beginning commands, one or more RCPT + commands, and a DATA command, in that order. A mail + transaction may be aborted by the RSET command. There may + be zero or more transactions in a session. + + The last command in a session must be the QUIT command. The + QUIT command can not be used at any other time in a session. + + 4.1.2. COMMAND SYNTAX + + The commands consist of a command code followed by an argument + field. Command codes are four alphabetic characters. Upper + and lower case alphabetic characters are to be treated + identically. Thus, any of the following may represent the mail + command: + + MAIL Mail mail MaIl mAIl + + This also applies to any symbols representing parameter values, + such as "TO" or "to" for the forward-path. Command codes and + the argument fields are separated by one or more spaces. + However, within the reverse-path and forward-path arguments + case is important. In particular, in some hosts the user + "smith" is different from the user "Smith". + + The argument field consists of a variable length character + string ending with the character sequence <CRLF>. The receiver + is to take no action until this sequence is received. + + Square brackets denote an optional argument field. If the + option is not taken, the appropriate default is implied. + + + + + + + + + + + + + +Postel [Page 23] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + The following are the SMTP commands: + + HELO <SP> <host> <CRLF> + + MAIL <SP> FROM:<reverse-path> <CRLF> + + RCPT <SP> TO:<forward-path> <CRLF> + + DATA <CRLF> + + RSET <CRLF> + + SEND <SP> FROM:<reverse-path> <CRLF> + + SOML <SP> FROM:<reverse-path> <CRLF> + + SAML <SP> FROM:<reverse-path> <CRLF> + + VRFY <SP> <string> <CRLF> + + EXPN <SP> <string> <CRLF> + + HELP [<SP> <string>] <CRLF> + + NOOP <CRLF> + + QUIT <CRLF> + + + + + + + + + + + + + + + + + + + + + + +[Page 24] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + The syntax of the above argument fields (using BNF notation + where applicable) is given below. The "..." notation indicates + that a field may be repeated one or more times. + + <reverse-path> ::= <path> + + <forward-path> ::= <path> + + <path> ::= "<" ["@" <host> "," ...] <mailbox> ">" + + <host> ::= <a> <string> | "#" <number> | "[" <dotnum> "]" + + <mailbox> ::= <user> "@" <host> + + <user> ::= <string> + + <string> ::= <char> | <char> <string> + + <char> ::= <c> | '\' <c> | '\' <s> + + <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> + + <number> ::= <d> | <d> <number> + + <snum> ::= 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 + <specials> + + <d> ::= any one of the ten digits 0 through 9 + + <s> ::= any one of <specials> + + <specials> ::= '<', '>', '(', ')', '\', ',', ';', ':', '@', + '"', and the control characters (ASCII codes 0 through 37 + octal inclusive and 177 octal) + + 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. + + + +Postel [Page 25] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + Hosts are generally known by names which are translated to + addresses in each host. Sometimes a host is not known to the + translation function and communication is blocked. To bypass + this barrier two numeric forms are also allowed for host + "names". One form is a decimal integer prefixed by a pound + sign, "#", which indicates the number is the address of the + host. Another form 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. + + The time stamp line and the return path line are formally + defined as follows: + + <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF> + + <time-stamp-line> ::= "Mail-From:" <SP> <stamp> <CRLF> + + <stamp> ::= [<ptcl>] <from-host> <this-host> <daytime> + + <ptcl> ::= <protocol> <SP> "host" <SP> + + <from-host> ::= <host> <SP> + + <this-host> ::= "received by" <SP> <host> <SP> + + <protocol> ::= "TCP" | "NCP" | "NITS" | "X25" | "INTERNET" | + "ARPANET" + + Note: INTERNET = TCP, ARPANET = NCP, and if the <ptcl> is + not present INTERNET is assumed. + + <daytime> ::= "at" <SP> <date> <SP> <time> + + <date> ::= <dd> "-" <mon> "-" <yy> + + <time> ::= <hh> ":" <mm> ":" <ss> "-" <zone> + + <dd> ::= the one or two decimal integer day of the month in + the range 1 to 31. + + <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | + "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" + + <yy> ::= the two decimal integer year of the century in the + range 01 to 99. + + + + +[Page 26] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + <hh> ::= the two decimal integer hour of the day in the + range 00 to 24. + + <mm> ::= the two decimal integer minute of the hour in the + range 00 to 59. + + <ss> ::= the two decimal integer second of the minute in the + range 00 to 59. + + <zone> ::= a time zone designator (as in [2]) or "UT" for + Universal Time (the default). + + Return Path Example: + + Return-Path: <@CHARLIE,@BAKER,JOE@ABLE> + + Mail From Example: + + Mail-From: ABC received by XYZ at 22-OCT-81 09:23:59-PDT + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 27] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + 4.2. SMTP REPLIES + + Replies to SMTP commands are devised to ensure the synchronization + of requests and actions in the process of mail transfer, and to + guarantee that the sender-SMTP always knows the state of the + receiver-SMTP. Every command must generate exactly one reply. + + The details of the command-reply sequence are made explicit in + Section 5.3 on Sequencing and Section 5.4 State Diagrams. + + An SMTP reply consists of a three digit number (transmitted as + three alphanumeric characters) followed by some text. The number + is intended for use by automata to determine what state to enter + next; the text is meant for the human user. It is intended that + the three digits contain enough encoded information that the + sender-SMTP need not examine the text and may either discard it or + pass it on to the user, as appropriate. In particular, the text + may be receiver-dependent, so there are likely to be varying texts + for each reply code. A discussion of the theory of reply codes is + given in the Appendix E. Formally, a reply is defined to be the + sequence: a three-digit code, <SP>, one line of text, and <CRLF>, + or a multiline reply (as defined in Appendix E). Only the EXPN + and HELP command are expected to result in multiline replies in + normal circumstances, however multiline replies are allowed for + any command. + + + + + + + + + + + + + + + + + + + + + + + + +[Page 28] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + 4.2.1. REPLY CODES BY FUNCTION GROUPS + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + + 220 <host> Service ready + 221 <host> Service closing transmission channel + 421 <host> Service not available, closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + + 250 Requested mail action okay, completed + 251 User not local; will forward to <forward-path> + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 451 Requested action aborted: error in processing + 551 User not local; please try <forward-path> + 452 Requested action not taken: insufficient system storage + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 354 Start mail input; end with <CRLF>.<CRLF> + 554 Transaction failed + + + + + + + + + + + + + + +Postel [Page 29] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + 4.2.2. NUMERIC ORDER LIST OF REPLY CODES + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + 220 <host> Service ready + 221 <host> Service closing transmission channel + 250 Requested mail action okay, completed + 251 User not local; will forward to <forward-path> + + 354 Start mail input; end with <CRLF>.<CRLF> + + 421 <host> Service not available, closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 551 User not local; please try <forward-path> + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 554 Transaction failed + + + + + + + + + + + + + + +[Page 30] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + 4.3. SEQUENCING OF COMMANDS AND REPLIES + + The communication between the sender and receiver is intended to + be an alternating dialogue, controlled by the sender. As such, + the sender issues a command and the receiver responds with a + reply. The sender must wait for this response before sending + further commands. + + One important reply is the connection greeting. Normally, a + receiver will send a 220 "Awaiting input" reply when the + connection is completed. The sender should wait for this greeting + message before sending any commands. + + Note: all the greeting type replies have the official name of + the server host as the first word following the reply code. + + For example, + + 220 <SP> USC-ISIF <SP> Service ready <CRLF> + + The table below lists alternative success and failure replies for + each command. These must be strictly adhered to; a receiver may + substitute text in the replies, but the meaning and action implied + by the code numbers and by the specific command reply sequence + cannot be altered. + + COMMAND-REPLY SEQUENCES + + Each command is listed with its possible replies. The prefixes + used before the possible replies are "P" for preliminary (not + used in SMTP), "I" for intermediate, "S" for success, "F" for + failure, and "E" for error. The 421 reply (service not + available, closing transmission channel) may be given to any + command if the SMTP-receiver knows it must shut down. This + listing forms the basis for the State Diagrams in Section 4.4. + + CONNECTION ESTABLISHMENT + S: 220 + F: 421 + HELO + S: 250 + E: 500, 501, 504, 421 + MAIL + S: 250 + F: 552, 451, 452 + E: 500, 501, 421 + + + +Postel [Page 31] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + RCPT + S: 250, 251 + F: 550, 551, 552, 553, 450, 451, 452 + E: 500, 501, 421 + DATA + I: 354 -> data -> S: 250 + F: 552, 554, 451, 452 + F: 451, 554 + E: 500, 501, 421 + RSET + S: 250 + E: 500, 501, 504, 421 + SEND + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SOML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SAML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + VRFY + S: 250 + F: 550 + E: 500, 501, 502, 504, 421 + EXPN + S: 250 + F: 550 + E: 500, 501, 502, 504, 421 + HELP + S: 211, 214 + E: 500, 501, 502, 504, 421 + NOOP + S: 250 + E: 500, 421 + QUIT + S: 221 + E: 500 + + + + + + + + +[Page 32] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + 4.4. STATE DIAGRAMS + + Following are state diagrams for a simple-minded SMTP + implementation. Only the first digit of the reply codes is used. + There is one state diagram for each group of SMTP commands. The + command groupings were determined by constructing a model for each + command and then collecting together the commands with + structurally identical models. + + For each command there are three possible outcomes: "success" + (S), "failure" (F), and "error" (E). In the state diagrams below + we use the symbol B for "begin", and the symbol W for "wait for + reply". + + First, the diagram that represents most of the SMTP commands: + + + 1,3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ +---+ +---+ + | + | 4,5 +---+ + ----------->| F | + +---+ + + + This diagram models the commands: + + HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, + NOOP, QUIT. + + + + + + + + + + + + + + + +Postel [Page 33] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + A more complex diagram models the DATA command: + + + +---+ DATA +---+ 1,2 +---+ + | B |---------->| W |-------------------->| E | + +---+ +---+ ------------>+---+ + 3| |4,5 | + | | | + -------------- ----- | + | | | +---+ + | ---------- -------->| S | + | | | | +---+ + | | ------------ + | | | | + V 1,3| |2 | + +---+ data +---+ --------------->+---+ + | |---------->| W | | F | + +---+ +---+-------------------->+---+ + 4,5 + + + Note that the "data" here is a series of lines sent from the + sender to the receiver with no response expected until the last + line is sent. + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 34] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + 4.5. DETAILS + + 4.5.1. MINIMUM IMPLEMENTATION + + In order to make SMTP workable, the following minimum + implementation is required for all receivers: + + COMMANDS -- HELO + MAIL + RCPT + DATA + RSET + NOOP + QUIT + + 4.5.2. TRANSPARENCY + + Without some provision for data transparency the character + sequence "<CRLF>.<CRLF>" ends the the mail text and cannot be + sent by the user. In general, users are not aware of such + "forbidden" sequences. To allow all user composed text to be + transmitted transparently the following procedures are used. + + 1. Before sending a line of mail text the sender-SMTP checks + the first character of the line. If it is a period, one + additional period is inserted at the beginning of the line. + + 2. When a line of mail text is received by the receiver-SMTP + it checks the the line. If the line is composed of a single + period it is the end of mail. If the first character is a + period and there are other characters on the line, the first + character is deleted. + + The mail data may contain any of the 128 ASCII characters. All + characters are to be delivered to the recipients mailbox + including format effectors and other control characters. The + 7-bit ASCII codes are transmitted right justified in 8-bit + bytes (octets) with the high order bits cleared to zero. + + In some systems it may be necessary to transform the data as + it is received and stored. This may be necessary for hosts + that use a different character set than ASCII as their local + character set, or that store data in records rather than + strings. If such transforms are necessary, they must be + reversible -- especially if such transforms are applied to + mail being relayed. + + + +Postel [Page 35] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + 4.5.3. SIZES + + There are several objects that have required minimum maximum + sizes. That is every implementation must be able to receive + objects of at least these sizes, but must not send objects + larger than these sizes. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + user + + The maximum total length of a user name is 64 characters. + + host + + The maximum total length of a host name or number is 40 + characters. + + path + + The maximum total length of a reverse-path or + forward-path is 256 characters (including the punctuation + and element separators). + + command line + + The maximum total length of a command line including the + command word and the <CRLF> is 512 characters. + + reply line + + The maximum total length of a reply line including the + reply code and the <CRLF> is 512 characters. + + text line + + The maximum total length of a text line including the + <CRLF> is 1000 characters (but not counting the leading + dot duplicated for transparency). + + + +[Page 36] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + recipients buffer + + The maximum total number of recipients that must be + buffered is 100 recipients. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + Errors due to exceeding these limits may be reported by using + the reply codes, for example: + + 500 Line too long. + + 501 Path too long + + 552 Too many recipients. + + 552 Too much mail data. + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 37] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + +APPENDIX A + + TCP Transport service + + The Transmission Control Protocol [3] is used in the ARPA + Internet, and in any network following the US DoD standards for + internetwork protocols. + + Connection Establishment + + The SMTP transmission channel is a TCP connection established + between the sender process port U and the receiver process port + L. This single full duplex connection is used as the + transmission channel. This protocol is assigned the service + port 25 (31 octal), that is L=25. + + Data Transfer + + The TCP connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as a 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 38] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + +APPENDIX B + + NCP Transport service + + The ARPANET Host-to-Host Protocol [4] (implemented by the Network + Control Program) may be used in the ARPANET. + + Connection Establishment + + The SMTP transmission channel is established via NCP between + the the sender process socket U and receiver process socket L. + The Initial Connection Protocol [5] is followed resulting in a + pair of simplex connections. This pair of connections is used + as the transmission channel. This protocol is assigned the + contact socket 25 (31 octal), that is L=25. + + Data Transfer + + The NCP data connections are established in 8-bit byte mode. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as a 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 39] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + +APPENDIX C + + NITS + + The Network Independent Transport Service [6] may be used. + + Connection Establishment + + The SMTP transmission channel is established via NITS between + the sender process and receiver process. The sender process + executes the CONNECT primitive, and the waiting receiver + process executes the ACCEPT primitive. + + Data Transfer + + The NITS connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as a 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 40] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + +APPENDIX D + + X.25 Transport service + + It may be possible to use the X.25 service [7] as provided by the + Public Data Networks directly, but there are indications that it + is too error prone to qualify as a reliable channel. It is + suggested that a reliable end-to-end protocol such as TCP be used + on top of X.25 connections. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 41] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + +APPENDIX E + + Theory of Reply Codes + + The three digits of the reply each have a special significance. + The first digit denotes whether the response is good, bad or + incomplete. An unsophisticated sender-SMTP will be able to + determine its next action (proceed as planned, redo, retrench, + etc.) by simply examining this first digit. A sender-SMTP that + wants to know approximately what kind of error occurred (e.g., + mail system error, command syntax error) may examine the second + digit, reserving the third digit for the finest gradation of + information. + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + + The command has been accepted, but the requested action + is being held in abeyance, pending confirmation of the + information in this reply. The sender-SMTP should send + another command specifying whether to continue or abort + the action. + + [Note: SMTP does not have any commands that allow this + type of reply, and so does not have the continue or + abort commands.] + + 2yz Positive Completion reply + + The requested action has been successfully completed. A + new request may be initiated. + + 3yz Positive Intermediate reply + + The command has been accepted, but the requested action + is being held in abeyance, pending receipt of further + information. The sender-SMTP should send another command + specifying this information. This reply is used in + command sequence groups. + + 4yz Transient Negative Completion reply + + The command was not accepted and the requested action did + not occur. However, the error condition is temporary and + the action may be requested again. The sender should + + + +[Page 42] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + return to the beginning of the command sequence (if any). + It is difficult to assign a meaning to "transient" when + two different sites (receiver- and sender- SMTPs) must + agree on the interpretation. Each reply in this category + might have a different time value, but the sender-SMTP is + encouraged to try again. A rule of thumb to determine if + a reply fits into the 4yz or the 5yz category (see below) + is that replies are 4yz if they can be repeated without + any change in command form or in properties of the sender + or receiver. (E.g., the command is repeated identically + and the receiver does not put up a new implementation.) + + 5yz Permanent Negative Completion reply + + The command was not accepted and the requested action did + not occur. The sender-SMTP is discouraged from repeating + the exact request (in the same sequence). Even some + "permanent" error conditions can be corrected, so the + human user may want to direct the sender-SMTP to + reinitiate the command sequence by direct action at some + point in the future (e.g., after the spelling has been + changed, or the user has altered the account status). + + The second digit encodes responses in specific categories: + + x0z Syntax -- These replies refer to syntax errors, + syntactically correct commands that don't fit any + functional category, and unimplemented or superfluous + commands. + + x1z Information -- These are replies to requests for + information, such as status or help. + + x2z Connections -- These are replies referring to the + transmission channel. + + x3z Unspecified as yet. + + x4z Unspecified as yet. + + x5z Mail system -- These replies indicate the status of + the receiver mail system vis-a-vis the requested + transfer or other mail system action. + + The third digit gives a finer gradation of meaning in each + category specified by the second digit. The list of replies + + + +Postel [Page 43] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + illustrates this. Each reply text is recommended rather than + mandatory, and may even change according to the command with + which it is associated. On the other hand, the reply codes + must strictly follow the specifications in this section. + Receiver implementations should not invent new codes for + slightly different situations from the ones described here, but + rather adapt codes already defined. + + For example, a command such as NOOP whose successful execution + does not offer the sender-SMTP any new information will return + a 250 reply. The response is 502 when the command requests an + unimplemented non-site-specific action. A refinement of that + is the 504 reply for a command that is implemented, but that + requests an unimplemented parameter. + + The reply text may be longer than a single line; in these cases + the complete text must be marked so the sender-SMTP knows when it + can stop reading the reply. This requires a special format to + indicate a multiple line reply. + + The format for multi-line replies requires that every line, + except the last, begin with the reply code, followed + immediately by a hyphen, "-" (also known as minus), followed by + text. The last line will begin with the reply code, followed + immediately by <SP>, optionally some text, and <CRLF>. + + For example: + 123-First line + 123-Second line + 123-234 text beginning with numbers + 123 The last line + + The sender-SMTP then simply needs to search for the reply code + followed by <SP> at the beginning of a line, and ignore all + preceding lines. + + + + + + + + + + + + + + +[Page 44] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + +APPENDIX F + + Scenarios + + This section presents complete scenarios of several types of SMTP + sessions. + + A Typical SMTP Transaction Scenario + + This SMTP example shows mail sent by Smith at host USC-ISIF, to + Jones, Green, and Brown at host BBN-UNIX. Here we assume that + host USC-ISIF contacts host BBN-UNIX directly. The mail is + accepted for Jones and Brown. Green does not have a mailbox at + host BBN-UNIX. + + ------------------------------------------------------------- + + R: 220 BBN-UNIX Simple Mail Transfer Service Ready + S: HELO USC-ISIF + R: 250 BBN-UNIX + + S: MAIL FROM:<Smith@USC-ISIF> + R: 250 OK + + S: RCPT TO:<Jones@BBN-UNIX> + R: 250 OK + + S: RCPT TO:<Green@BBN-UNIX> + R: 550 No such user here + + S: RCPT TO:<Brown@BBN-UNIX> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BBN-UNIX Service closing transmission channel + + Scenario 1 + + ------------------------------------------------------------- + + + +Postel [Page 45] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + Aborted SMTP Transaction Scenario + + ------------------------------------------------------------- + + R: 220 MIT-Multics Simple Mail Transfer Service Ready + S: HELO ISI-VAXA + R: 250 MIT-Multics + + S: MAIL FROM:<Smith@ISI-VAXA> + R: 250 OK + + S: RCPT TO:<Jones@MIT-Multics> + R: 250 OK + + S: RCPT TO:<Green@MIT-Multics> + R: 550 No such user here + + S: RSET + R: 250 OK + + S: QUIT + R: 221 MIT-Multics Service closing transmission channel + + Scenario 2 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + +[Page 46] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + Relayed Mail Scenario + + ------------------------------------------------------------- + + Step 1 -- Source Host to Relay Host + + R: 220 USC-ISIE Simple Mail Transfer Service Ready + S: HELO MIT-AI + R: 250 USC-ISIE + + S: MAIL FROM:<JQP@MIT-AI> + R: 250 OK + + S: RCPT TO:<@ISIE,Jones@BBN-VAX> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Date: 2-Nov-81 22:33:44 + S: From: John Q. Public <JQP at MIT-AI> + S: Subject: The Next Meeting of the Board + S: To: Jones at BBN-Vax + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE Service closing transmission channel + + + + + + + + + + + + + + + + + +Postel [Page 47] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + Step 2 -- Relay Host to Destination Host + + R: 220 BBN-VAX Simple Mail Transfer Service Ready + S: HELO USC-ISIE + R: 250 BBN-VAX + + S: MAIL FROM:<@ISIE,JQP@MIT-AI> + R: 250 OK + + S: RCPT TO:<Jones@BBN-VAX> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Mail-From: NCP host MIT-AI received by USC-ISIE at + 2-Nov-81 22:40:10 + S: Date: 2-Nov-81 22:33:44 + S: From: John Q. Public <JQP at MIT-AI> + S: Subject: The Next Meeting of the Board + S: To: Jones at BBN-Vax + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE Service closing transmission channel + + Scenario 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + +[Page 48] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + Verifying and Sending Scenario + + ------------------------------------------------------------- + + R: 220 SU-SCORE Simple Mail Transfer Service Ready + S: HELO MIT-MC + R: 250 SU-SCORE + + S: VRFY Crispin + R: 250 Mark Crispin <Admin.MRC@SU-SCORE> + + S: SEND FROM:<EAK@MIT-MC> + R: 250 OK + + S: RCPT TO:<Admin.MRC@SU-SCORE> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE Service closing transmission channel + + Scenario 4 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 49] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + Sending and Mailing Scenarios + + First the user's name is verified, then an attempt is made to + send to the user's terminal. When that fails, the messages is + mailed to the user's mailbox. + + ------------------------------------------------------------- + + R: 220 SU-SCORE Simple Mail Transfer Service Ready + S: HELO MIT-MC + R: 250 SU-SCORE + + S: VRFY Crispin + R: 250 Mark Crispin <Admin.MRC@SU-SCORE> + + S: SEND FROM:<EAK@MIT-MC> + R: 250 OK + + S: RCPT TO:<Admin.MRC@SU-SCORE> + R: 450 User not active now + + S: RSET + R: 250 OK + + S: MAIL FROM:<EAK@MIT-MC> + R: 250 OK + + S: RCPT TO:<Admin.MRC@SU-SCORE> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE Service closing transmission channel + + Scenario 5 + + ------------------------------------------------------------- + + + + + + +[Page 50] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + Doing the preceding scenario more efficiently. + + ------------------------------------------------------------- + + R: 220 SU-SCORE Simple Mail Transfer Service Ready + S: HELO MIT-MC + R: 250 SU-SCORE + + S: VRFY Crispin + R: 250 Mark Crispin <Admin.MRC@SU-SCORE> + + S: SOML FROM:<EAK@MIT-MC> + R: 250 OK + + S: RCPT TO:<Admin.MRC@SU-SCORE> + R: 250 User not active now, so will do mail. + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE Service closing transmission channel + + Scenario 6 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 51] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + Mailing List Scenario + + First each of two mailing lists are expanded in separate sessions + with different hosts. Then the message is sent to everyone that + appeared on either list (but no duplicates) via a relay host. + + ------------------------------------------------------------- + + Step 1 -- Expanding the First List + + R: 220 MIT-AI Simple Mail Transfer Service Ready + S: HELO SU-SCORE + R: 250 MIT-AI + + S: EXPN Example-People + R: 250-<ABC@MIT-MC> + R: 250-Fred Fonebone <Fonebone@ISIQ> + R: 250-Xenon Y. Zither <XYZ@MIT-AI> + R: 250-Quincy Smith <@ISIF,Q-Smith@ISI-VAXA> + R: 250-<joe@foo-unix> + R: 250 <xyz@bar-unix> + + S: QUIT + R: 221 MIT-AI Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 52] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + Step 2 -- Expanding the Second List + + R: 220 MIT-MC Simple Mail Transfer Service Ready + S: HELO SU-SCORE + R: 250 MIT-MC + + S: EXPN Interested-Parties + R: 250-Al Calico <ABC@MIT-MC> + R: 250-<XYZ@MIT-AI> + R: 250-Quincy Smith <@ISIF,Q-Smith@ISI-VAXA> + R: 250-<fred@BBN-UNIX> + R: 250 <xyz@bar-unix> + + S: QUIT + R: 221 MIT-MC Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 53] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + Step 3 -- Mailing to All via a Relay Host + + R: 220 USC-ISIE Simple Mail Transfer Service Ready + S: HELO SU-SCORE + R: 250 USC-ISIE + + S: MAIL FROM:<Account.Person@SU-SCORE> + R: 250 OK + S: RCPT TO:<@ISIE,ABC@MIT-MC> + R: 250 OK + S: RCPT TO:<@ISIE,Fonebone@ISIQ> + R: 250 OK + S: RCPT TO:<@ISIE,XYZ@MIT-AI> + R: 250 OK + S: RCPT TO:<@ISIE,@ISIF,Q-Smith@ISI-VAXA> + R: 250 OK + S: RCPT TO:<@ISIE,joe@FOO-UNIX> + R: 250 OK + S: RCPT TO:<@ISIE,xyz@BAR-UNIX> + R: 250 OK + S: RCPT TO:<@ISIE,fred@BBN-UNIX> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE Service closing transmission channel + + Scenario 7 + + ------------------------------------------------------------- + + + + + + + + + + + + + +[Page 54] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + Forwarding Scenarios + + ------------------------------------------------------------- + + R: 220 USC-ISIF Simple Mail Transfer Service Ready + S: HELO LBL-UNIX + R: 250 USC-ISIF + + S: MAIL FROM:<mo@LBL-UNIX> + R: 250 OK + + S: RCPT TO:<fred@USC-ISIF> + R: 251 User not local; will forward to <Jones@USC-ISIA> + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIF Service closing transmission channel + + Scenario 8 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 55] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Step 1 -- Trying the Mailbox at the First Host + + R: 220 USC-ISIF Simple Mail Transfer Service Ready + S: HELO LBL-UNIX + R: 250 USC-ISIF + + S: MAIL FROM:<mo@LBL-UNIX> + R: 250 OK + + S: RCPT TO:<fred@USC-ISIF> + R: 251 User not local; will forward to <Jones@USC-ISIA> + + S: RSET + R: 250 OK + + S: QUIT + R: 221 USC-ISIF Service closing transmission channel + + Step 2 -- Delivering the Mail at the Second Host + + R: 220 USC-ISIA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX + R: 250 USC-ISIA + + S: MAIL FROM:<mo@LBL-UNIX> + R: 250 OK + + S: RCPT TO:<Jones@USC-ISIA> + R: OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIA Service closing transmission channel + + Scenario 9 + + ------------------------------------------------------------- + + + + +[Page 56] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + Too Many Recipients Scenario + + ------------------------------------------------------------- + + R: 220 BERKELEY Simple Mail Transfer Service Ready + S: HELO USC-ISIF + R: 250 BERKELEY + + S: MAIL FROM:<Postel@USC-ISIF> + R: 250 OK + + S: RCPT TO:<fabry@BERKELEY> + R: 250 OK + + S: RCPT TO:<eric@BERKELEY> + R: 552 Recipient storage full, try again in another transaction + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: MAIL FROM:<Postel@USC-ISIF> + R: 250 OK + + S: RCPT TO:<eric@BERKELEY> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BERKELEY Service closing transmission channel + + Scenario 10 + + ------------------------------------------------------------- + + + + + + +Postel [Page 57] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + +GLOSSARY + + ASCII + + American Standard Code for Information Interchange [1]. + + command + + A request for a mail service action sent by the sender-SMTP to the + receiver-SMTP. + + end of mail data indication + + A special sequence of characters that indicates the end of the + mail data. In particular, the five characters carriage return, + line feed, period, carriage return, line feed, in that order. + + host + + A computer in the internetwork environment on which mailboxes or + SMTP processes reside. + + line + + A line of text ending with a <CRLF>. + + mail data + + A sequence of ASCII characters of arbitrary length, which conforms + to the standard set in the Standard for the Format of ARPA Network + Text Messages (RFC 733 [2]). + + mailbox + + A character string (address) which identifies a user to whom mail + is to be sent. Mailbox normally consists of the host and user + specifications. The standard mailbox naming convention is defined + to be "user@host". Additionally, the "container" in which mail is + stored. + + receiver-SMTP process + + A process which transfers mail in cooperation with a sender-SMTP + process. It waits for a connection to be established via the + transport service. It receives SMTP commands from the + sender-SMTP, sends replies, and performs the specified operations. + + + +[Page 58] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + + reply + + A reply is an acknowledgment (positive or negative) sent from + receiver to sender via the transmission channel in response to a + SMTP command. The general form of a reply is a completion code + (including error codes) followed by a text string. The codes are + for use by programs and the text is usually intended for human + users. + + sender-SMTP process + + A process which transfers mail in cooperation with a receiver-SMTP + process. A local language may be used in the user interface + command/reply dialogue. The sender-SMTP initiates the transport + service connection. It initiates SMTP commands, receives replies, + and governs the transfer of mail. + + session + + The set of exchanges that occur while the transmission channel is + open. + + transaction + + The set of exchanges required for one message to be transmitted + for one or more recipients. + + transmission channel + + A full-duplex communication path between a sender-SMTP and a + receiver-SMTP for the exchange of commands, replies, and mail + text. + + transport service + + Any reliable stream-oriented data communication services. For + example, NCP, TCP, NITS. + + user + + A human being (or a process on behalf of a human being) wishing to + obtain mail transfer service. In addition, a recipient of + computer mail. + + + + + + +Postel [Page 59] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + word + + A sequence of printing characters. + + <CRLF> + + The characters carriage return and line feed (in that order). + + <SP> + + The space character. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 60] Postel + + + +RFC 788 November 1981 + Simple Mail Transfer Protocol + + + +REFERENCES + + [1] ASCII + + ASCII, "USA Code for Information Interchange", United States of + America Standards Institute, X3.4, 1968. Also in: Feinler, E. + and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for + the Defense Communications Agency by SRI International, Menlo + Park, California, Revised January 1978. + + [2] RFC 733 + + Crocker, D., J. Vittal, K. Pogran, and D. Henderson, "Standard for + the Format of ARPA Network Text Messages," RFC 733, NIC 41952, + November 1977. Also in: Feinler, E. and J. Postel, eds., + "ARPANET Protocol Handbook", NIC 7104, for the Defense + Communications Agency by SRI International, Menlo Park, + California, Revised January 1978. + + [3] TCP + + Postel, J., ed., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", RFC 793, USC/Information Sciences + Institute, September 1981. + + [4] NCP + + McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, + January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [5] Initial Connection Protocol + + Postel, J., "Official Initial Connection Protocol", NIC 7101, + 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [6] NITS + + PSS/SG3, "A Network Independent Transport Service", Study Group 3, + The Post Office PSS Users Group, February 1980. Available from + the DCPU, National Physical Laboratory, Teddington, UK. + + + +Postel [Page 61] + + + +November 1981 RFC 788 +Simple Mail Transfer Protocol + + + + [7] X.25 + + CCITT, "Recommendation X.25 - Interface Between Data Terminal + Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for + Terminals Operating in the Packet Mode on Public Data Networks," + CCITT Orange Book, Vol. VIII.2, International Telephone and + Telegraph Consultative Committee, Geneva, 1976. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 62] Postel + diff --git a/Documentation/en/rfc/rfc882.txt b/Documentation/en/rfc/rfc882.txt new file mode 100644 index 00000000..9da22a9e --- /dev/null +++ b/Documentation/en/rfc/rfc882.txt @@ -0,0 +1,1798 @@ + +Network Working Group P. Mockapetris +Request for Comments: 882 ISI + November 1983 + + DOMAIN NAMES - CONCEPTS and FACILITIES + + +-----------------------------------------------------+ + | | + | This RFC introduces domain style names, their use | + | for ARPA Internet mail and host address support, | + | and the protocols and servers used to implement | + | domain name facilities. | + | | + | This memo describes the conceptual framework of the | + | domain system and some uses, but it omits many | + | uses, fields, and implementation details. A | + | complete specification of formats, timeouts, etc. | + | is presented in RFC 883, "Domain Names - | + | Implementation and Specification". That RFC | + | assumes that the reader is familiar with the | + | concepts discussed in this memo. | + | | + +-----------------------------------------------------+ + +INTRODUCTION + + The need for domain names + + As applications grow to span multiple hosts, then networks, and + finally internets, these applications must also span multiple + administrative boundaries and related methods of operation + (protocols, data formats, etc). The number of resources (for + example mailboxes), the number of locations for resources, and the + diversity of such an environment cause formidable problems when we + wish to create consistent methods for referencing particular + resources that are similar but scattered throughout the + environment. + + The ARPA Internet illustrates the size-related problems; it is a + large system and is likely to grow much larger. The need to have + a mapping between host names (e.g., USC-ISIF) and ARPA Internet + addresses (e.g., 10.2.0.52) is beginning to stress the existing + mechanisms. Currently hosts in the ARPA Internet are registered + with the Network Information Center (NIC) and listed in a global + table (available as the file <NETINFO>HOSTS.TXT on the SRI-NIC + host) [1]. The size of this table, and especially the frequency + of updates to the table are near the limit of manageability. What + is needed is a distributed database that performs the same + function, and hence avoids the problems caused by a centralized + database. + + The problem for computer mail is more severe. While mail system + implementers long ago recognized the impossibility of centralizing + + +Mockapetris [Page 1] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + mailbox names, they have also created an increasingly large and + irregular set of methods for identifying the location of a + mailbox. Some of these methods involve the use of routes and + forwarding hosts as part of the mail destination address, and + consequently force the mail user to know multiple address formats, + the capabilities of various forwarders, and ad hoc tricks for + passing address specifications through intermediaries. + + These problems have common characteristics that suggest the nature + of any solution: + + The basic need is for a consistent name space which will be + used for referring to resources. In order to avoid the + problems caused by ad hoc encodings, names should not contain + addresses, routes, or similar information as part of the name. + + The sheer size of the database and frequency of updates suggest + that it must be maintained in a distributed manner, with local + caching to improve performance. Approaches that attempt to + collect a consistent copy of the entire database will become + more and more expensive and difficult, and hence should be + avoided. The same principle holds for the structure of the + name space, and in particular mechanisms for creating and + deleting names; these should also be distributed. + + The costs of implementing such a facility dictate that it be + generally useful, and not restricted to a single application. + We should be able to use names to retrieve host addresses, + mailbox data, and other as yet undetermined information. + + Because we want the name space to be useful in dissimilar + networks, it is unlikely that all users of domain names will be + able to agree on the set of resources or resource information + that names will be used to retrieve. Hence names refer to a + set of resources, and queries contain resource identifiers. + The only standard types of information that we expect to see + throughout the name space is structuring information for the + name space itself, and resources that are described using + domain names and no nonstandard data. + + We also want the name server transactions to be independent of + the communications system that carries them. Some systems may + wish to use datagrams for simple queries and responses, and + only establish virtual circuits for transactions that need the + reliability (e.g. database updates, long transactions); other + systems will use virtual circuits exclusively. + + + + + +Mockapetris [Page 2] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + Elements of the solution + + The proposed solution has three major components: + + The DOMAIN NAME SPACE, which is a specification for a tree + structured name space. Conceptually, each node and leaf of the + domain name space tree names a set of information, and query + operations are attempts to extract specific types of + information from a particular set. A query names the domain + name of interest and describes the type of resource information + that is desired. For example, the ARPA Internet uses some of + its domain names to identify hosts; queries for address + resources return ARPA Internet host addresses. However, to + preserve the generality of the domain mechanism, domain names + are not required to have a one-to-one correspondence with host + names, host addresses, or any other type of information. + + NAME SERVERS are server programs which hold information about + the domain tree's structure and set information. A name server + may cache structure or set information about any part of the + domain tree, but in general a particular name server has + complete information about a subset of the domain space, and + pointers to other name servers that can be used to lead to + information from any part of the domain tree. Name servers + know the parts of the domain tree for which they have complete + information; these parts are called ZONEs; a name server is an + AUTHORITY for these parts of the name space. + + RESOLVERS are programs that extract information from name + servers in response to user requests. Resolvers must be able + to access at least one name server and use that name server's + information to answer a query directly, or pursue the query + using referrals to other name servers. A resolver will + typically be a system routine that is directly accessible to + user programs; hence no protocol is necessary between the + resolver and the user program. + + These three components roughly correspond to the three layers or + views of the domain system: + + From the user's point of view, the domain system is accessed + through simple procedure or OS calls to resolvers. The domain + space consists of a single tree and the user can request + information from any section of the tree. + + From the resolver's point of view, the domain system is + composed of an unknown number of name servers. Each name + server has one or more pieces of the whole domain tree's data, + + + +Mockapetris [Page 3] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + but the resolver views each of these databases as essentially + static. + + From a name server's point of view, the domain system consists + of separate sets of local information called zones. The name + server has local copies of some of the zones. The name server + must periodically refresh its zones from master copies in local + files or foreign name servers. The name server must + concurrently process queries that arrive from resolvers using + the local zones. + + In the interests of performance, these layers blur a bit. For + example, resolvers on the same machine as a name server may share + a database and may also introduce foreign information for use in + later queries. This cached information is treated differently + from the authoritative data in zones. + + Database model + + The organization of the domain system derives from some + assumptions about the needs and usage patterns of its user + community and is designed to avoid many of the the complicated + problems found in general purpose database systems. + + The assumptions are: + + The size of the total database will initially be proportional + to the number of hosts using the system, but will eventually + grow to be proportional to the number of users on those hosts + as mailboxes and other information are added to the domain + system. + + Most of the data in the system will change very slowly (e.g., + mailbox bindings, host addresses), but that the system should + be able to deal with subsets that change more rapidly (on the + order of minutes). + + The administrative boundaries used to distribute responsibility + for the database will usually correspond to organizations that + have one or more hosts. Each organization that has + responsibility for a particular set of domains will provide + redundant name servers, either on the organization's own hosts + or other hosts that the organization arranges to use. + + Clients of the domain system should be able to identify trusted + name servers they prefer to use before accepting referrals to + name servers outside of this "trusted" set. + + Access to information is more critical than instantaneous + + +Mockapetris [Page 4] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + updates or guarantees of consistency. Hence the update process + allows updates to percolate out though the users of the domain + system rather than guaranteeing that all copies are + simultaneously updated. When updates are unavailable due to + network or host failure, the usual course is to believe old + information while continuing efforts to update it. The general + model is that copies are distributed with timeouts for + refreshing. The distributor sets the timeout value and the + recipient of the distribution is responsible for performing the + refresh. In special situations, very short intervals can be + specified, or the owner can prohibit copies. + + Some users will wish to access the database via datagrams; + others will prefer virtual circuits. The domain system is + designed so that simple queries and responses can use either + style, although refreshing operations need the reliability of + virtual circuits. The same overall message format is used for + all communication. The domain system does not assume any + special properties of the communications system, and hence + could be used with any datagram or virtual circuit protocol. + + In any system that has a distributed database, a particular + name server may be presented with a query that can only be + answered by some other server. The two general approaches to + dealing with this problem are "recursive", in which the first + server pursues the query for the client at another server, and + "iterative", in which the server refers the client to another + server and lets the client pursue the query. Both approaches + have advantages and disadvantages, but the iterative approach + is preferred for the datagram style of access. The domain + system requires implementation of the iterative approach, but + allows the recursive approach as an option. The optional + recursive style is discussed in [14], and omitted from further + discussion in this memo. + + The domain system assumes that all data originates in master files + scattered through the hosts that use the domain system. These + master files are updated by local system administrators. Master + files are text files that are read by a local name server, and + hence become available to users of the domain system. A standard + format for these files is given in [14]. + + The standard format allows these files to be exchanged between + hosts (via FTP, mail, or some other mechanism); this facility is + useful when an organization wants a domain, but doesn't want to + support a name server. The organization can maintain the master + files locally using a text editor, transfer them to a foreign host + which runs a name server, and then arrange with the system + administrator of the name server to get the files loaded. + + +Mockapetris [Page 5] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + Each host's name servers and resolvers are configured by a local + system administrator. For a name server, this configuration data + includes the identity of local master files and instructions on + which non-local master files are to be loaded from foreign + servers. The name server uses the master files or copies to load + its zones. For resolvers, the configuration data identifies the + name servers which should be the primary sources of information. + + The domain system defines procedures for accessing the data and + for referrals to other name servers. The domain system also + defines procedures for caching retrieved data and for periodic + refreshing of data defined by the system administrator. + + The system administrators provide: + + The definition of zone boundaries + + Master files of data + + Updates to master files + + Statements of the refresh policies desired + + The domain system provides: + + Standard formats for resource data + + Standard methods for querying the database + + Standard methods for name servers to refresh local data from + foreign name servers + +DOMAIN NAME SPACE + + Name space specifications and terminology + + The domain name space is a tree structure. Each node and leaf on + the tree corresponds to a resource set (which may be empty). Each + node and leaf has an associated label. Labels are NOT guaranteed + to be unique, with the exception of the root node, which has a + null label. The domain name of a node or leaf is the path from + the root of the tree to the node or leaf. By convention, the + labels that compose a domain name are read left to right, from the + most specific (lowest) to the least specific (highest). + + Internally, programs that manipulate domain names represent them + as sequences of labels, where each label is a length octet + followed by an octet string. Because all domain names end at the + root, which has a null string for a label, these internal + + +Mockapetris [Page 6] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + representations can use a length byte of zero to terminate a + domain name. When domain names are printed, labels in a path are + separated by dots ("."). The root label and its associated dot + are omitted from printed domain names, but the root can be named + by a null domain name (" " in this memo). + + To simplify implementations, the total number of octets that + represent label octets and label lengths is limited to 255. Thus + a printed domain name can be up to 254 characters. + + A special label is defined that matches any other label. This + label is the asterisk or "*". An asterisk matches a single label. + Thus *.ARPA matches FOO.ARPA, but does not match FOO.BAR.ARPA. + The asterisk is mainly used to create default resource records at + the boundary between protocol families, and requires prudence in + its use. + + A domain is identified by a domain name, and consists of that part + of the domain name space that is at or below the domain name which + specifies the domain. A domain is a subdomain of another domain + if it is contained within that domain. This relationship can be + tested by seeing if the subdomain's name has the containing + domain's name as the right part of its name. For example, A.B.C.D + is a subdomain of B.C.D, C.D, D, and " ". + + This tree structure is intended to parallel the administrative + organization and delegation of authority. Potentially, each node + or leaf on the tree can create new subdomains ad infinitum. In + practice, this delegation can be limited by the administrator of + the name servers that manage the domain space and resource data. + + The following figure shows an example of a domain name space. + + | + +------------------+------------------+ + | | | + COLORS FLAVORS TRUTH + | | + +-----+-----+ | + | | | NATURAL + RED BLUE GREEN | + | + +---------------+---------------+ + | | | + CHOCOLATE VANILLA STRAWBERRY + + In this example, the root domain has three immediate subdomains: + COLORS, FLAVORS, and TRUTH. The FLAVORS domain has one immediate + subdomain named NATURAL.FLAVORS. All of the leaves are also + + +Mockapetris [Page 7] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + domains. This domain tree has the names " "(the root), COLORS, + RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVORS, NATURAL.FLAVORS, + CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS, + STRAWBERRY.NATURAL.FLAVORS, and TRUTH. If we wished to add a new + domain of ARTIFICIAL under FLAVORS, FLAVORS would typically be the + administrative entity that would decide; if we wished to create + CHIP and MOCHA names under CHOCOLATE, CHOCOLATE.NATURAL.FLAVORS + would typically be the appropriate administrative entity. + + Resource set information + + A domain name identifies a set of resource information. The set + of resource information associated with a particular name is + composed of separate resource records (RRs). + + Each resource record has the following major components: + + The domain name which identifies resource set that holds this + record, and hence the "owner" of the information. For example, + a RR that specifies a host address has a domain name the + specifies the host having that address. Thus F.ISI.ARPA might + be the owner of a RR which specified an address field of + 10.2.0.52. Since name servers typically store their resource + information in tree structures paralleling the organization of + the domain space, this information can usually be stored + implicitly in the database; however it is always included in + each resource record carried in a message. + + Other information used to manage the RR, such as length fields, + timeouts, etc. This information is omitted in much of this + memo, but is discussed in [14]. + + A resource type field that specifies the type of the resource + in this resource record. Types refer to abstract resources + such as host addresses or mail delivery agents. The type field + is two octets long and uses an encoding that is standard + throughout the domain name system. + + A class field identifies the format of the resource data, such + as the ARPA Internet format (IN) or the Computer Science + Network format (CSNET), for certain RR types (such as address + data). Note that while the class may separate different + protocol families, networks, etc. it does not do so in all + cases. For example, the IN class uses 32 bit IP addresses + exclusively, but the CSNET class uses 32 bit IP addresses, X.25 + addresses, and phone numbers. Thus the class field should be + used as a guide for interpreting the resource data. The class + field is two octets long and uses an encoding that is standard + throughout the domain name system. + + +Mockapetris [Page 8] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + Resource data that describes the resource. The format of this + data can be determined given the type and class fields, but + always starts with a two octet length field that allows a name + server or resolver to determine the boundaries of the resource + data in any transaction, even if it cannot "understand" the + resource data itself. Thus name servers and resolvers can hold + and pass on records which they cannot interpret. The format of + the internal data is restricted only by the maximum length of + 65535 octets; for example the host address record might specify + a fixed 32 bit number for one class, and a variable length list + of addresses in another class. + + While the class field in effect partitions the resource data in + the domain name system into separate parallel sections according + to class, services can span class boundaries if they use + compatible resource data formats. For example, the domain name + system uses compatible formats for structure information, and the + mail data decouples mail agent identification from details of how + to contact the agent (e.g. host addresses). + + This memo uses the following types in its examples: + + A - the host address associated with the domain name + + MF - identifies a mail forwarder for the domain + + MD - identifies a mail destination for the domain + + NS - the authoritative name server for the domain + + SOA - identifies the start of a zone of authority + + CNAME - identifies the canonical name of an alias + + This memo uses the following classes in its examples: + + IN - the ARPA Internet system + + CS - the CSNET system + + The first type of resource record holds a host name to host + address binding. Its fields are: + + +--------+--------+--------+--------------//----------------------+ + |<owner> | A | <class>| <class specific address>information | + +--------+--------+--------+--------------//----------------------+ + + + + + +Mockapetris [Page 9] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + The content of the class specific information varies according to + the value in the CLASS field; for the ARPA Internet, it is the 32 + bit ARPA Internet address of the host, for the CSNET it might be + the phone number of the host. For example, F.ISI.ARPA might have + two A records of the form: + + +----------+--------+--------+----------------------------+ + |F.ISI.ARPA| A | IN | 10.2.0.52 | + +----------+--------+--------+----------------------------+ + and + +----------+--------+--------+----------------------------+ + |F.ISI.ARPA| A | CS | 213-822-2112 | + +----------+--------+--------+----------------------------+ + + Note that the data formats for the A type are class dependent, and + the Internet address and phone number formats shown above are for + purposes of illustration only. The actual data formats are + specified in [14]. For example, CS class data for type A records + might actually be a list of Internet addresses, phone numbers and + TELENET addresses. + + The mail forwarder (MF) and mail delivery (MD) records have the + following format: + + +--------+--------+--------+----------------------------+ + |<owner> | MD/MF | <class>| <domain name> | + +--------+--------+--------+----------------------------+ + + The <domain name> field is a domain name of the host that will + handle mail; note that this domain name may be completely + different from the domain name which names the resource record. + For example, F.ISI.ARPA might have two records of the form: + + +----------+--------+--------+----------------------------+ + |F.ISI.ARPA| MD | IN | F.ISI.ARPA | + +----------+--------+--------+----------------------------+ + and + +----------+--------+--------+----------------------------+ + |F.ISI.ARPA| MF | IN | B.ISI.ARPA | + +----------+--------+--------+----------------------------+ + + These records mean that mail for F.ISI.ARPA can either be + delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which + will accept responsibility for its eventual delivery. In + principle, an additional name lookup is required to map the domain + name of the host to the appropriate address, in practice this + information is usually returned in the response to the mail query. + + The SOA and NS types of resource records are used to define limits + + +Mockapetris [Page 10] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + of authority. The domain name given by the owner field of a SOA + record is the start of a zone; the domain name given by the owner + field of a NS record identifies a point in the name space where + authority has been delegated, and hence marks the zone boundary. + Except in the case where a name server delegates authority to + itself, the SOA identifies the top limit of authority, and NS + records define the first name outside of a zone. These resource + records have a standard format for all of the name space: + + +----------+--------+--------+-----------------------------+ + | <owner> | SOA | <class>| <domain name, etc> | + +----------+--------+--------+-----------------------------+ + + +----------+--------+--------+-----------------------------+ + | <owner> | NS | <class>| <domain name> | + +----------+--------+--------+-----------------------------+ + + The SOA record marks the start of a zone when it is present in a + database; the NS record both marks the end of a zone started by an + SOA (if a higher SOA is present) and also points to a name server + that has a copy of the zone specified by the <owner. field of the + NS record. + + The <domain name, etc> in the SOA record specifies the original + source of the information in the zone and other information used + by name servers to organize their activities. SOA records are + never cached (otherwise they would create false zones); they can + only be created in special name server maintenance operations. + + The NS record says that a name server which is authoritative for + records of the given CLASS can be found at <domain name>. + + Queries + + Queries to a name server must include a domain name which + identifies the target resource set (QNAME), and the type and class + of desired resource records. The type and class fields in a query + can include any of the corresponding type and class fields that + are defined for resource records; in addition, the query type + (QTYPE) and query class (QCLASS) fields may contain special values + that match more than one of the corresponding fields in RRs. + + For example, the QTYPE field may contain: + + MAILA - matches all mail agent RRs (e.g. MD and MF). + + * - matches any RR type. + + + + +Mockapetris [Page 11] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + The QCLASS field may contain: + + * - matches any RR class. + + Using the query domain name, QTYPE, and QCLASS, the name server + looks for matching RRs. In addition to relevant records, the name + server may return RRs that point toward a name server that has the + desired information or RRs that are expected to be useful in + interpreting the relevant RRs. For example a name server that + doesn't have the requested information may know a name server that + does; a name server that returns a domain name in a relevant RR + may also return the RR that binds that domain name to an address. + + Note that the QCLASS=* construct requires special interpretation + regarding authority. Since a name server may not know all of the + classes available in the domain system, it can never know if it is + authoritative for all classes. Hence responses to QCLASS=* + queries can never be authoritative. + + Example space + + For purposes of exposition, the following name space is used for + the remainder of this memo: + + | + +------------------+------------------+ + | | | + DDN ARPA CSNET + | | | + +-----+-----+ | +-----+-----+ + | | | | | | + JCS ARMY NAVY | UDEL UCI + | + +--------+---------------+---------------+--------+ + | | | | | + DTI MIT ISI UDEL NBS + | | + +---+---+ +---+---+ + | | | | | + DMS AI A B F + + + + + + + + + + + +Mockapetris [Page 12] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + +NAME SERVERS + + Introduction + + Name servers store a distributed database consisting of the + structure of the domain name space, the resource sets associated + with domain names, and other information used to coordinate + actions between name servers. + + In general, a name server will be an authority for all or part of + a particular domain. The region covered by this authority is + called a zone. Name servers may be responsible for no + authoritative data, and hence have no zones, or may have several + zones. When a name server has multiple zones, the zones may have + no common borders or zones may be contiguous. + + While administrators should not construct overlapping zones, and + name servers must defend against overlapping zones, overlapping is + regarded as a non-fatal flaw in the database. Hence the measures + taken to protect against it are omitted for the remainder of this + memo. A detailed discussion can be found in [14]. + + When presented with a query for a domain name over which it has + authority, a name server returns the desired resource information + or an indication that the query refers to a domain name or + resource that does not exist. If a name server is presented with + a query for a domain name that is not within its authority, it may + have the desired information, but it will also return a response + that points toward an authoritative name server. If a name server + is not an authority for a query, it can never return a negative + response. + + There is no requirement that a name server for a domain reside in + a host which has a name in the same domain, although this will + usually be the case. There is also no restriction on the number + of name servers that can have authority over a particular domain; + most domains will have redundant authoritative name servers. The + assumption is that different authoritative copies are identical, + even though inconsistencies are possible as updates are made. + + Name server functions are designed to allow for very simple + implementations of name servers. The simplest name server has a + static set of information and uses datagrams to receive queries + and return responses. + + More sophisticated name server implementations can improve the + performance of their clients by caching information from other + domains. Although this information can be acquired in a number of + ways, the normal method is to store the information acquired by a + + +Mockapetris [Page 13] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + resolver when the resolver consults other name servers. In a + sophisticated host, the resolver and name server will coordinate + their actions and use a shared database. This cooperation + requires the incorporation of a time-to-live (TTL) field in all + cached resource records. Caching is discussed in the resolver + section of this memo; this section is devoted to the actions of a + name servers that don't cache. + + In order to free simple name servers of the requirement of + managing these timeouts, simple name servers should only contain + resource records that are expected to remain constant over very + long periods or resource records for which the name server is an + authority. In the following discussion, the TTL field is assumed + to be stored in the resource record but is omitted in descriptions + of databases and responses in the interest of clarity. + + Authority and administrative control of domains + + Although we want to have the potential of delegating the + privileges of name space management at every node, we don't want + such delegation to be required. + + Hence we introduce the concept of authority. Authority is vested + in name servers. A name server has authority over all of its + domain until it delegates authority for a subdomain to some other + name server. + + Any administrative entity that wishes to establish its own domain + must provide a name server, and have that server accepted by the + parent name server (i.e. the name server that has authority over + the place in the domain name space that will hold the new domain). + While the principles of authority allow acceptance to be at the + discretion of parent name servers, the following criteria are used + by the root, and are recommended to all name servers because they + are responsible for their children's actions: + + 1. It must register with the parent administrator of domains. + + 2. It must identify a responsible person. + + 3. In must provide redundant name servers. + + The domain name must be registered with the administrator to avoid + name conflicts and to make the domain related information + available to other domains. The central administrator may have + further requirements, and a domain is not registered until the + central administrator agrees that all requirements are met. + + There must be a responsible person associated with each domain to + + +Mockapetris [Page 14] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + be a contact point for questions about the domain, to verify and + update the domain related information, and to resolve any problems + (e.g., protocol violations) with hosts in the domain. + + The domain must provide redundant (i.e., two or more) name servers + to provide the name to address resolution service. These name + servers must be accessible from outside the domain (as well as + inside) and must resolve names for at least all the hosts in the + domain. + + Once the central administrator is satisfied, he will communicate + the existence to the appropriate administrators of other domains + so that they can incorporate NS records for the new name server + into their databases. + + Name server logic + + The processing steps that a name server performs in responding to + a query are conceptually simple, although implementations may have + internal databases that are quite complex. + + For purposes of explanation, we assume that the query consists of + a type QTYPE, a class QCLASS, and a domain name QNAME; we assume + that the name server stores its RRs in sets where each set has all + of the RRs for a particular domain. Note that this database + structure and the following algorithms are meant to illustrate one + possible implementation, rather than a specification of how all + servers must be implemented. + + The following notation is used: + + ord(DOMAIN-NAME) returns the number of labels in DOMAIN-NAME. + + findset(DOMAIN-NAME) returns a pointer to the set of stored RRs + for DOMAIN-NAME, or NULL if there is no such + information. + + set(POINTER) refers to a set located previously by + findset, where POINTER is the value returned + by findset. + + relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE is + relevant to the specified QTYPE. For + example, relevant(MAILA,MF) is true and + relevant(MAILA,NS) is false. + + right(NAME,NUMBER) returns a domain name that is the rightmost + NUMBER labels in the string NAME. + + + +Mockapetris [Page 15] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + copy(RR) copies the resource record specified by RR + into the response. + + The name server code could be represented as the following + sequence of steps: + + { find out whether the database makes this server + authoritative for the domain name specified by QNAME } + + for i:=0 to ord(QNAME) { sequence through all nodes in QNAME } + do begin + ptr:=findset(right(QNAME,i)); + if ptr<>NULL + then { there is domain data for this domain name } + begin + for all RRs in set(ptr) + do if type(RR)=NS and class(RR)=QCLASS + then begin + auth=false; + NSptr:=ptr + end; + for all RRs in set(ptr) + do if type(RR)=SOA and class(RR)=QCLASS + then auth:=true + end + end; + end; + + { copy out authority search results } + + if auth + then { if authority check for domain found } + if ptr=null + then return(Name error) + else + else { if not authority, copy NS RRs } + for all RRs in set(nsptr) + do if (type(RR)=NS and class(RR)=QCLASS) + or + (QCLASS=*) + then copy(RR); + + { Copy all RRs that answer the question } + + for all RRs in set(ptr) + do if class(RR)=QCLASS and relevant(QTYPE,type(RR)) + then copy(RR); + + The first section of the code (delimited by the for loop over all + + +Mockapetris [Page 16] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + of the subnodes of QNAME) discovers whether the name server is + authoritative for the domain specified by QNAME. It sequences + through all containing domains of QNAME, starting at the root. If + it encounters a SOA it knows that the name server is authoritative + unless it finds a lower NS RR which delegates authority. If the + name server is authoritative, it sets auth=true; if the name + server is not authoritative, it sets NSptr to point to the set + which contains the NS RR closest to the domain specified by QNAME. + + The second section of the code reflects the result of the + authority search into the response. If the name server is + authoritative, the code checks to see that the domain specified by + QNAME exists; if not, a name error is returned. If the name + server is not authoritative, the code copies the RRs for a closer + name server into the response. + + The last section of the code copies all relevant RRs into the + response. + + Note that this code is not meant as an actual implementation and + is incomplete in several aspects. For example, it doesn't deal + with providing additional information, wildcards, QCLASS=*, or + with overlapping zones. The first two of these issues are dealt + with in the following discussions, the remaining issues are + discussed in [14]. + + Additional information + + When a resolver returns information to a user program, the + returned information will often lead to a second query. For + example, if a mailer asks a resolver for the appropriate mail + agent for a particular domain name, the name server queried by the + resolver returns a domain name that identifies the agent. In + general, we would expect that the mailer would then request the + domain name to address binding for the mail agent, and a new name + server query would result. + + To avoid this duplication of effort, name servers return + additional information with a response which satisfies the + anticipated query. This information is kept in a separate section + of the response. Name servers are required to complete the + appropriate additional information if such information is + available, but the requestor should not depend on the presence of + the information since the name server may not have it. If the + resolver caches the additional information, it can respond to the + second query without an additional network transaction. + + The appropriate information is defined in [14], but generally + + + +Mockapetris [Page 17] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + consists of host to address bindings for domain names in returned + RRs. + + Aliases and canonical names + + In existing systems, hosts and other resources often have several + names that identify the same resource. For example, under current + ARPA Internet naming support, USC-ISIF and ISIF both identify the + same host. Similarly, in the case of mailboxes, many + organizations provide many names that actually go to the same + mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc., all + go to the same mailbox (although the mechanism behind this is + somewhat complicated). + + Most of these systems have a notion that one of the equivalent set + of names is the canonical name and all others are aliases. + + The domain system provides a similar feature using the canonical + name (CNAME) RR. When a name server fails to find a desired RR in + a set associated with some domain name, it checks to see if the + resource set contains a CNAME record with a matching class. If + so, the name server includes the CNAME record in the response, and + continues the query at the domain name specified in the data field + of the CNAME record. + + Suppose a name server was processing a query with QNAME=ISIF.ARPA, + QTYPE=A, and QCLASS=IN, and had the following resource records: + + ISIF.ARPA CNAME IN F.ISI.ARPA + F.ISI.ARPA A IN 10.2.0.52 + + Both of these RRs would be returned in the response. + + In the above example, because ISIF.ARPA has no RRs other than the + CNAME RR, the resources associated with ISIF.ARPA will appear to + be exactly those associated with F.ISI.ARPA for the IN CLASS. + Since the CNAME is effective only when the search fails, a CNAME + can also be used to construct defaults. For example, suppose the + name server had the following set of RRs: + + F.ISI.ARPA A IN 10.2.0.52 + F.ISI.ARPA MD IN F.ISI.ARPA + XXXX.ARPA CNAME IN F.ISI.ARPA + XXXX.ARPA MF IN A.ISI.ARPA + + Using this database, type A queries for XXXX.ARPA would return the + XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR, but MAILA or MF + queries to XXXX.ARPA would return the XXXX.ARPA MF RR without any + information from F.ISI.ARPA. This structure might be used to send + + +Mockapetris [Page 18] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + mail addressed to XXXX.ARPA to A.ISI.ARPA and to direct TELNET for + XXXX.ARPA to F.ISI.ARPA. + + Wildcards + + In certain cases, an administrator may wish to associate default + resource information for all or part of a domain. For example, + the CSNET domain administrator may wish to establish IN class mail + forwarding for all hosts in the CSNET domain without IN + capability. In such a case, the domain system provides a special + label "*" that matches any other label. Note that "*" matches + only a single label, and not zero or more than one label. Note + also that the "*" is distinct from the "*" values for QCLASS and + QTYPE. + + The semantics of "*" depend upon whether it appears in a query + domain name (QNAME) or in a RR in a database. + + When an "*" is used in a QNAME, it can only match a "*" in a + resource record. + + When "*" appears in a RR in a database, it can never override + an existing exact match. For example, if a name server + received a query for the domain UDEL.CSNET, and had appropriate + RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs would + be used and the *.CSNET RRs would be ignored. If a query to + the same database specified FOO.CSNET, the *.CSNET RR would be + used, but the corresponding labels from the QNAME would replace + the "*". Thus the FOO.CSNET query would match the *.CSNET RR + and return a RR for FOO.CSNET rather than *.CSNET. + + RRs containing "*" labels are copied exactly when zones are + transfered via name server maintenance operations. + + These semantics are easily implemented by having the name server + first search for an exact match for a query, and then replacing + the leftmost label with a "*" and trying again, repeating the + process until all labels became "*" or the search succeeded. + + TYPE=* in RRs is prohibited. If it were to be allowed, the + requestor would have no way of interpreting the data in the RR + because this data is type dependent. + + CLASS=* is also prohibited. Similar effects can be achieved using + QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to + complexities without apparent benefit. + + + + + +Mockapetris [Page 19] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + A scenario + + In our sample domain space, suppose we wanted separate + administrative control for the root, DDN, ARPA, CSNET, MIT and ISI + domains. We might allocate name servers as follows: + + |(B.ISI.ARPA) + |(UDEL.CSNET) + +------------------+------------------+ + | | | + DDN ARPA CSNET + |(JCS.DDN) |(F.ISI.ARPA) |(UDEL.ARPA) + +-----+-----+ |(A.ISI.ARPA)+-----+-----+ + | | | | | | + JCS ARMY NAVY | UDEL UCI + | + +--------+---------------+---------------+--------+ + | | | | | + DTI MIT ISI UDEL NBS + |(AI.MIT.ARPA) |(F.ISI.ARPA) + +---+---+ +---+---+ + | | | | | + DMS AI A B F + + In this example the authoritative name server is shown in + parentheses at the point in the domain tree at which is assumes + control. + + Thus the root name servers are on B.ISI.ARPA and UDEL.CSNET, the + DDN name server is on JCS.DDN, the CSNET domain server is on + UDEL.ARPA, etc. + + In an actual system, all domains should have redundant name + servers, but in this example only the ARPA domain has redundant + servers A.ISI.ARPA and F.ISI.ARPA. (The B.ISI.ARPA and UDEL.CSNET + name servers happen to be not redundant because they handle + different classes.) The F.ISI.ARPA name server has authority over + the ARPA domain, but delegates authority over the MIT.ARPA domain + to the name server on AI.MIT.ARPA. The A.ISI.ARPA name server + also has authority over the ARPA domain, but delegates both the + ISI.ARPA and MIT.ARPA domains to other name servers. + + + + + + + + + + +Mockapetris [Page 20] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + B.ISI.ARPA Name server for " " + + B.ISI.ARPA has the root name server for the IN class. Its + database might contain: + + Domain Resource Record + + " " SOA IN A.ISI.ARPA + DDN NS IN JCS.DDN + ARPA NS IN F.ISI.ARPA + CSNET NS IN UDEL.ARPA + " " NS IN B.ISI.ARPA + " " NS CS UDEL.CSNET + + JCS.DDN A IN 9.0.0.1 + F.ISI.ARPA A IN 10.2.0.52 + UDEL.CSNET A CS 302-555-0000 + UDEL.ARPA A IN 10.0.0.96 + + The SOA record for the root is necessary so that the name server + knows that it is authoritative for the root domain for class IN. + The contents of the SOA resource record point back to A.ISI.ARPA + and denote that the master data for the zone of authority is + originally from this host. The first three NS records denote + delegation of authority. The NS root entry for the B.ISI.ARPA + name server is necessary so that this name server knows about + itself, and can respond correctly to a query for NS information + about the root (for which it is an authority). The root entry for + class CS denotes that UDEL.CSNET is the authoritative name server + for the CS class root. UDEL.CSNET and UDEL.ARPA may or may not + refer to the same name server; from this information it is + impossible to tell. + + If this name server was sent a query specifying QTYPE=MAILA, + QCLASS=IN, QNAME=F.ISI.ARPA, it would begin processing (using the + previous algorithm) by determining that it was not an authority + for F.ISI.ARPA. The test would note that it had authority at " ", + but would also note that the authority was delegated at ARPA and + never reestablished via another SOA. Thus the response would + return the NS record for the domain ARPA. + + Any queries presented to this server with QCLASS=CS would result + in the UDEL.CSNET NS record being returned in the response. + + + + + + + + +Mockapetris [Page 21] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + F.ISI.ARPA Name server for ARPA and ISI.ARPA + + In the same domain space, the F.ISI.ARPA database for the domains + ARPA and ISI.ARPA might be: + + Domain Resource Record + + " " NS IN B.ISI.ARPA + " " NS CS CSNET.UDEL + ARPA SOA IN B.ISI.ARPA + ARPA NS IN A.ISI.ARPA + ARPA NS IN F.ISI.ARPA + MIT.ARPA NS IN AI.MIT.ARPA + ISI.ARPA SOA IN F.ISI.ARPA + ISI.ARPA NS IN F.ISI.ARPA + + A.ISI.ARPA MD IN A.ISI.ARPA + ISI.ARPA MD IN F.ISI.ARPA + A.ISI.ARPA MF IN F.ISI.ARPA + B.ISI.ARPA MD IN B.ISI.ARPA + B.ISI.ARPA MF IN F.ISI.ARPA + F.ISI.ARPA MD IN F.ISI.ARPA + F.ISI.ARPA MF IN A.ISI.ARPA + DTI.ARPA MD IN DTI.ARPA + NBS.ARPA MD IN NBS.ARPA + UDEL.ARPA MD IN UDEL.ARPA + + A.ISI.ARPA A IN 10.1.0.32 + F.ISI.ARPA A IN 10.2.0.52 + B.ISI.ARPA A IN 10.3.0.52 + DTI.ARPA A IN 10.0.0.12 + AI.MIT.ARPA A IN 10.2.0.6 + DMS.MIT.ARPA A IN 10.1.0.6 + NBS.ARPA A IN 10.0.0.19 + UDEL.ARPA A IN 10.0.0.96 + + For the IN class, the SOA RR for ARPA denotes that this name + server is authoritative for the domain ARPA, and that the master + file for this authority is stored on B.ISI.ARPA. This zone + extends to ISI.ARPA, where the database delegates authority back + to this name server in another zone, and doesn't include the + domain MIT.ARPA, which is served by a name server on AI.MIT.ARPA. + + This name server is not authoritative for any data in the CS + class. It has a pointer to the root server for CS data which + could be use to resolve CS class queries. + + Suppose this name server received a query of the form + QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN. The authority search + + +Mockapetris [Page 22] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + would notice the NS record for " ", its SOA at ARPA, a delegation + at ISI.ARPA, and the reassumption of authority at ISI.ARPA. Hence + it would know that it was an authority for this query. It would + then find the A record for A.ISI.ARPA, and return a datagram + containing this record. + + Another query might be QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=*. + In this case the name server would know that it cannot be + authoritative because of the "*" value of QCLASS, and would look + for records for domain B.ISI.ARPA that match. Assuming that the + name server performs the additional record inclusion mentioned in + the name server algorithm, the returned datagram would include: + + ISI.ARPA NS IN F.ISI.ARPA + " " NS CS UDEL.CSNET + B.ISI.ARPA MD IN B.ISI.ARPA + B.ISI.ARPA MF IN F.ISI.ARPA + B.ISI.ARPA A IN 10.3.0.52 + F.ISI.ARPA A IN 10.2.0.52 + + If the query were QNAME=DMS.MIT.ARPA, QTYPE=MAILA, QCLASS=IN, the + name server would discover that AI.MIT.ARPA was the authoritative + name server and return the following: + + MIT.ARPA NS IN AI.MIT.ARPA + AI.MIT.ARPA A IN 10.2.0.6 + + In this case, the requestor is directed to seek information from + the MIT.ARPA domain name server residing on AI.MIT.ARPA. + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 23] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + UDEL.ARPA and UDEL.CSNET name server + + In the previous discussion of the sample domain, we stated that + UDEL.CSNET and UDEL.ARPA might be the same name server. In this + example, we assume that this is the case. As such, the name + server is an authority for the root for class CS, and an authority + for the CSNET domain for class IN. + + This name server deals with mail forwarding between the ARPA + Internet and CSNET systems. Its RRs illustrate one approach to + solving this problem. The name server has the following resource + records: + + " " SOA CS UDEL.CSNET + " " NS CS UDEL.CSNET + " " NS IN B.ISI.ARPA + CSNET SOA IN UDEL.ARPA + CSNET NS IN UDEL.ARPA + ARPA NS IN A.ISI.ARPA + + *.CSNET MF IN UDEL.ARPA + UDEL.CSNET MD CS UDEL.CSNET + UCI.CSNET MD CS UCI.CSNET + UDEL.ARPA MD IN UDEL.ARPA + + B.ISI.ARPA A IN 10.3.0.52 + UDEL.ARPA A IN 10.0.0.96 + UDEL.CSNET A CS 302-555-0000 + UCI.CSNET A CS 714-555-0000 + + Suppose this name server received a query of the form + QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=IN. The name server + would discover it was authoritative for the CSNET domain under + class IN, but would find no explicit mail data for UCI.CSNET. + However, using the *.CSNET record, it would construct a reply: + + UCI.CSNET MF IN UDEL.ARPA + UDEL.ARPA A IN 10.0.0.96 + + If this name server received a query of the form QNAME=UCI.CSNET, + QTYPE=MAILA, and QCLASS=CS, the name server would return: + + UCI.CSNET MD CS UCI.CSNET + UCI.CSNET A CS 714-555-0000 + + Note that although this scheme allows for forwarding of all mail + addressed as <anything>.CSNET, it doesn't help with names that + have more than two components, e.g. A.B.CSNET. Although this + problem could be "fixed" by a series of MF entries for *.*.CSNET, + + +Mockapetris [Page 24] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + *.*.*.CSNET, etc, a more tasteful solution would be to introduce a + cleverer pattern matching algorithm in the CSNET name server. + + Summary of requirements for name servers + + The requirements for a name server are as follows: + + 1. It must be recognized by its parent. + + 2. It must have complete resource information for all domain + names for which it is the authority. + + 3. It must periodically refresh authoritative information from + a master file or name server which holds the master. + + 4. If it caches information it must also handle TTL management + for that information. + + 5. It must answer simple queries. + + Inverse queries + + Name servers may also support inverse queries that map a + particular resource to a domain name or domain names that have + that resource. For example, while a query might map a domain name + to a host address, the corresponding inverse query might map the + address back to the domain name. + + Implementation of this service is optional in a name server, but + all name servers must at least be able to understand an inverse + query message and return an error response. + + The domain system cannot guarantee the completeness or uniqueness + of inverse queries because the domain system is organized by + domain name rather than by host address or any other resource + type. In general, a resolver or other program that wishes to + guarantee that an inverse query will work must use a name server + that is known to have the appropriate data, or ask all name + servers in a domain of interest. + + For example, if a resolver wishes to perform an inverse query for + an arbitrary host on the ARPA Internet, it must consult a set of + name servers sufficient to know that all IN data was considered. + In practice, a single inverse query to a name server that has a + fairly comprehensive database should satisfy the vast majority of + inverse queries. + + A detailed discussion of inverse queries is contained in [14]. + + + +Mockapetris [Page 25] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + Completion services + + Some existing systems provide the ability to complete partial + specifications of arguments. The general principle is that the + user types the first few characters of the argument and then hits + an escape character to prompt the system to complete the rest. + Some completion systems require that the user type enough of the + argument to be unique; others do not. + + Other systems allow the user to specify one argument and ask the + system to fill in other arguments. For example, many mail systems + allow the user to specify a username without a host for local mail + delivery. + + The domain system defines name server completion transactions that + perform the analogous service for the domain system. + Implementation of this service is optional in a name server, but + all name servers must at least be able to understand a completion + request and return an error response. + + When a resolver wishes to request a completion, it sends a name + server a message that sets QNAME to the partial string, QTYPE to + the type of resource desired, and QCLASS to the desired class. + The completion request also includes a RR for the target domain. + The target domain RR identifies the preferred location of the + resource. In completion requests, QNAME must still have a null + label to terminate the name, but its presence is ignored. Note + that a completion request is not a query, but shares some of the + same field formats. + + For example, a completion request might contain QTYPE=A, QNAME=B, + QCLASS=IN and a RR for ISI.ARPA. This request asks for completion + for a resource whose name begins with "B" and is "close" to + ISI.ARPA. This might be a typical shorthand used in the ISI + community which uses "B" as a way of referring to B.ISI.ARPA. + + The first step in processing a completion request is to look for a + "whole label" match. When the name server receives the request + mentioned above, it looks at all records that are of type A, class + IN, and whose domain name starts (on the left) with the labels of + QNAME, in this case, "B". If multiple records match, the name + server selects those whose domain names match (from the right) the + most labels of the preferred domain name. If there are still + multiple candidates, the name server selects the records that have + the shortest (in terms of octets in the name) domain name. If + several records remain, then the name server returns them all. + + If no records are found in the previous algorithm, the name server + assumes that the rightmost label in QNAME is not complete, and + + +Mockapetris [Page 26] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + looks for records that match but require addition of characters to + the rightmost label of QNAME. For example, the previous search + would not match BB.ARPA to B, but this search would. If multiple + hits are found, the same discarding strategy is followed. + + A detailed discussion of completion can be found in [14]. + +RESOLVERS + + Introduction + + Resolvers are programs that interface user programs to domain name + servers. In the simplest case, a resolver receives a request from + a user program (e.g. mail programs, TELNET, FTP) in the form of a + subroutine call, system call etc., and returns the desired + information in a form compatible with the local host's data + formats. + + Because a resolver may need to consult several name servers, the + amount of time that a resolver will take to complete can vary. + This variance is part of the justification for the split between + name servers and resolvers; name servers may use datagrams and + have a response time that is essentially equal to network delay + plus a short service time, while resolvers may take an essentially + indeterminate amount of time. + + We expect to see two types of resolvers: simple resolvers that can + chain through multiple name servers when required, and more + complicated resolvers that cache resource records for use in + future queries. + + Simple resolvers + + A simple resolver needs the following capabilities: + + 1. It must know how to access a name server, and should know the + authoritative name server for the host that it services. + + 2. It must know the protocol capabilities for its clients so that + it can set the class fields of the queries it sends to return + information that is useful to its clients. If the resolver + serves a client that has multiple protocol capabilities, it + should be able to support the preferences of the client. + + The resolver for a multiple protocol client can either collect + information for all classes using the * class value, or iterate + on the classes supported by the client. Note that in either + case, the resolver must understand the preferences of the host. + For example, the host that supports both CSNET and ARPA + + +Mockapetris [Page 27] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + Internet protocols might prefer mail delivery (MD) to mail + forwarding (MF), regardless of protocol, or might prefer one + protocol regardless of whether MD or MF is required. Care is + required to prevent loops. + + 3. The resolver must be capable of chaining through multiple name + servers to get to an authoritative name server for any query. + The resolver should guard against loops in referrals; a simple + policy is to discard referrals that don't match more of the + query name than the referring name server, and also to avoid + querying the same name server twice (This test should be done + using addresses of name servers instead of domain names to + avoid problems when a name server has multiple domain names or + errors are present in aliases). + + 4. The resolver must be able to try alternate name servers when a + name server doesn't respond. + + 5. The resolver must be able to communicate different failure + conditions to its client. These failure conditions include + unknown domain name, unknown resource for a know domain name, + and inability to access any of the authoritative name servers + for a domain. + + 6. If the resolver uses datagrams for queries, it must recover + from lost and duplicate datagrams. + + Resolvers with cache management + + Caching provides a tool for improving the performance of name + service, but also is a potential source of incorrect results. For + example, a database might cache information that is later changed + in the authoritative name servers. While this problem can't be + eliminated without eliminating caching, it can be reduced to an + infrequent problem through the use of timeouts. + + When name servers return resource records, each record has an + associated time-to-live (TTL) field. This field is expressed in + seconds, and has 16 bits of significance. + + When a resolver caches a returned resource record it must also + remember the TTL field. The resolver must discard the record when + the equivalent amount of time has passed. If the resolver shares + a database with a name server, it must decrement the TTL field of + imported records periodically rather than simply deleting the + record. This strategy is necessary to avoid exporting a resource + record whose TTL field doesn't reflect the amount of time that the + resource record has been cached. Of course, the resolver should + + + +Mockapetris [Page 28] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + + not decrement the TTL fields of records for which the associated + name server is an authority. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 29] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + +Appendix 1 - Domain Name Syntax Specification + + The preferred syntax of domain names is given by the following BNF + rules. Adherence to this syntax will result in fewer problems with + many applications that use domain names (e.g., mail, TELNET). Note + that some applications described in [14] use domain names containing + binary information and hence do not follow this syntax. + + <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 + + 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. + + For example, the following strings identify hosts in the ARPA + Internet: + + F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA + + + + + + + + + + + + +Mockapetris [Page 30] + + +RFC 882 November 1983 + Domain Names - Concepts and Facilities + + +REFERENCES and BIBLIOGRAPHY + + [1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet + Host Table Specification", RFC 810, Network Information Center, + SRI International, March 1982. + + [2] J. Postel, "Computer Mail Meeting Notes", RFC 805, + USC/Information Sciences Institute, February 1982. + + [3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet + User Applications", RFC 819, Network Information Center, SRI + International, August 1982. + + [4] Z. Su, "A Distributed System for Internet Name Service", + RFC 830, Network Information Center, SRI International, + October 1982. + + [5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network + Information Center, SRI International, March 1982. + + [6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name + Server", Computer Networks, vol 6, nr 3, July 1982. + + [7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information + Center, SRI International, December 1977. + + [8] J. Postel, "Internet Name Server", IEN 116, USC/Information + Sciences Institute, August 1979. + + [9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", + RFC 811, Network Information Center, SRI International, + March 1982. + + [10] J. Postel, "Transmission Control Protocol", RFC 793, + USC/Information Sciences Institute, September 1981. + + [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information + Sciences Institute, August 1980. + + [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821, + USC/Information Sciences Institute, August 1980. + + [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870, + USC/Information Sciences Institute, October 1983. + + [14] P. Mockapetris, "Domain Names - Implementation and + Specification", RFC 883, USC/Information Sciences Institute, + November 1983. + + + +Mockapetris [Page 31] + diff --git a/Documentation/en/rfc/rfc883.txt b/Documentation/en/rfc/rfc883.txt new file mode 100644 index 00000000..bdffb524 --- /dev/null +++ b/Documentation/en/rfc/rfc883.txt @@ -0,0 +1,4349 @@ + +Network Working Group P. Mockapetris +Request for Comments: 883 ISI + November 1983 + + DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION + + +-----------------------------------------------------+ + | | + | This memo discusses the implementation of domain | + | name servers and resolvers, specifies the format of | + | transactions, and discusses the use of domain names | + | in the context of existing mail systems and other | + | network software. | + | | + | This memo assumes that the reader is familiar with | + | RFC 882, "Domain Names - Concepts and Facilities" | + | which discusses the basic principles of domain | + | names and their use. | + | | + | The algorithms and internal data structures used in | + | this memo are offered as suggestions rather than | + | requirements; implementers are free to design their | + | own structures so long as the same external | + | behavior is achieved. | + | | + +-----------------------------------------------------+ + + + + + +-----------------------------------------------+ + | | + | ***** WARNING ***** | + | | + | This RFC contains format specifications which | + | are preliminary and are included for purposes | + | of explanation only. Do not attempt to use | + | this information for actual implementations. | + | | + +-----------------------------------------------+ + + + + + + + + + + + + + + + +Mockapetris [Page i] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +TABLE OF CONTENTS + INTRODUCTION........................................................3 + Overview.........................................................3 + Implementation components........................................2 + Conventions......................................................6 + Design philosophy................................................8 + NAME SERVER TRANSACTIONS...........................................11 + Introduction....................................................11 + Query and response transport....................................11 + Overall message format..........................................13 + The contents of standard queries and responses..................15 + Standard query and response example.............................15 + The contents of inverse queries and responses...................17 + Inverse query and response example..............................18 + Completion queries and responses................................19 + Completion query and response example...........................22 + Recursive Name Service..........................................24 + Header section format...........................................26 + Question section format.........................................29 + Resource record format..........................................30 + Domain name representation and compression......................31 + Organization of the Shared database.............................33 + Query processing................................................36 + Inverse query processing........................................37 + Completion query processing.....................................38 + NAME SERVER MAINTENANCE............................................39 + Introduction....................................................39 + Conceptual model of maintenance operations......................39 + Name server data structures and top level logic.................41 + Name server file loading........................................43 + Name server file loading example................................45 + Name server remote zone transfer................................47 + RESOLVER ALGORITHMS................................................50 + Operations......................................................50 + DOMAIN SUPPORT FOR MAIL............................................52 + Introduction....................................................52 + Agent binding...................................................53 + Mailbox binding.................................................54 + Appendix 1 - Domain Name Syntax Specification......................56 + Appendix 2 - Field formats and encodings...........................57 + TYPE values.....................................................57 + QTYPE values....................................................57 + CLASS values....................................................58 + QCLASS values...................................................58 + Standard resource record formats................................59 + Appendix 3 - Internet specific field formats and operations........67 + REFERENCES and BIBLIOGRAPHY........................................72 + INDEX..............................................................73 + + + +Mockapetris [Page ii] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +INTRODUCTION + + Overview + + The goal of domain names is to provide a mechanism for naming + resources in such a way that the names are usable in different + hosts, networks, protocol families, internets, and administrative + organizations. + + From the user's point of view, domain names are useful as + arguments to a local agent, called a resolver, which retrieves + information associated with the domain name. Thus a user might + ask for the host address or mail information associated with a + particular domain name. To enable the user to request a + particular type of information, an appropriate query type is + passed to the resolver with the domain name. To the user, the + domain tree is a single information space. + + From the resolver's point of view, the database that makes up the + domain space is distributed among various name servers. Different + parts of the domain space are stored in different name servers, + although a particular data item will usually be stored redundantly + in two or more name servers. The resolver starts with knowledge + of at least one name server. When the resolver processes a user + query it asks a known name server for the information; in return, + the resolver either receives the desired information or a referral + to another name server. Using these referrals, resolvers learn + the identities and contents of other name servers. Resolvers are + responsible for dealing with the distribution of the domain space + and dealing with the effects of name server failure by consulting + redundant databases in other servers. + + Name servers manage two kinds of data. The first kind of data + held in sets called zones; each zone is the complete database for + a particular subtree of the domain space. This data is called + authoritative. A name server periodically checks to make sure + that its zones are up to date, and if not obtains a new copy of + updated zones from master files stored locally or in another name + server. The second kind of data is cached data which was acquired + by a local resolver. This data may be incomplete but improves the + performance of the retrieval process when non-local data is + repeatedly accessed. Cached data is eventually discarded by a + timeout mechanism. + + This functional structure isolates the problems of user interface, + failure recovery, and distribution in the resolvers and isolates + the database update and refresh problems in the name servers. + + + + +Mockapetris [Page 1] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Implementation components + + A host can participate in the domain name system in a number of + ways, depending on whether the host runs programs that retrieve + information from the domain system, name servers that answer + queries from other hosts, or various combinations of both + functions. The simplest, and perhaps most typical, configuration + is shown below: + + Local Host | Foreign + | + +---------+ +----------+ | +--------+ + | | user queries | |queries | | | + | User |-------------->| |---------|->|Foreign | + | Program | | Resolver | | | Name | + | |<--------------| |<--------|--| Server | + | | user responses| |responses| | | + +---------+ +----------+ | +--------+ + | A | + cache additions | | references | + V | | + +----------+ | + | database | | + +----------+ | + + User programs interact with the domain name space through + resolvers; the format of user queries and user responses is + specific to the host and its operating system. User queries will + typically be operating system calls, and the resolver and its + database will be part of the host operating system. Less capable + hosts may choose to implement the resolver as a subroutine to be + linked in with every program that needs its services. + + Resolvers answer user queries with information they acquire via + queries to foreign name servers, and may also cache or reference + domain information in the local database. + + Note that the resolver may have to make several queries to several + different foreign name servers to answer a particular user query, + and hence the resolution of a user query may involve several + network accesses and an arbitrary amount of time. The queries to + foreign name servers and the corresponding responses have a + standard format described in this memo, and may be datagrams. + + + + + + + + +Mockapetris [Page 2] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Depending on its capabilities, a name server could be a stand + alone program on a dedicated machine or a process or processes on + a large timeshared host. A simple configuration might be: + + Local Host | Foreign + | + +---------+ | + / /| | + +---------+ | +----------+ | +--------+ + | | | | |responses| | | + | | | | Name |---------|->|Foreign | + | Master |-------------->| Server | | |Resolver| + | files | | | |<--------|--| | + | |/ | | queries | +--------+ + +---------+ +----------+ | + + Here the name server acquires information about one or more zones + by reading master files from its local file system, and answers + queries about those zones that arrive from foreign resolvers. + + A more sophisticated name server might acquire zones from foreign + name servers as well as local master files. This configuration is + shown below: + + Local Host | Foreign + | + +---------+ | + / /| | + +---------+ | +----------+ | +--------+ + | | | | |responses| | | + | | | | Name |---------|->|Foreign | + | Master |-------------->| Server | | |Resolver| + | files | | | |<--------|--| | + | |/ | | queries | +--------+ + +---------+ +----------+ | + A |maintenance | +--------+ + | \------------|->| | + | queries | |Foreign | + | | | Name | + \------------------|--| Server | + maintenance responses | +--------+ + + In this configuration, the name server periodically establishes a + virtual circuit to a foreign name server to acquire a copy of a + zone or to check that an existing copy has not changed. The + messages sent for these maintenance activities follow the same + form as queries and responses, but the message sequences are + somewhat different. + + + +Mockapetris [Page 3] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + The information flow in a host that supports all aspects of the + domain name system is shown below: + + Local Host | Foreign + | + +---------+ +----------+ | +--------+ + | | user queries | |queries | | | + | User |-------------->| |---------|->|Foreign | + | Program | | Resolver | | | Name | + | |<--------------| |<--------|--| Server | + | | user responses| |responses| | | + +---------+ +----------+ | +--------+ + | A | + cache additions | | references | + V | | + +----------+ | + | Shared | | + | database | | + +----------+ | + A | | + +---------+ refreshes | | references | + / /| | V | + +---------+ | +----------+ | +--------+ + | | | | |responses| | | + | | | | Name |---------|->|Foreign | + | Master |-------------->| Server | | |Resolver| + | files | | | |<--------|--| | + | |/ | | queries | +--------+ + +---------+ +----------+ | + A |maintenance | +--------+ + | \------------|->| | + | queries | |Foreign | + | | | Name | + \------------------|--| Server | + maintenance responses | +--------+ + + The shared database holds domain space data for the local name + server and resolver. The contents of the shared database will + typically be a mixture of authoritative data maintained by the + periodic refresh operations of the name server and cached data + from previous resolver requests. The structure of the domain data + and the necessity for synchronization between name servers and + resolvers imply the general characteristics of this database, but + the actual format is up to the local implementer. This memo + suggests a multiple tree format. + + + + + + +Mockapetris [Page 4] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + This memo divides the implementation discussion into sections: + + NAME SERVER TRANSACTIONS, which discusses the formats for name + servers queries and the corresponding responses. + + NAME SERVER MAINTENANCE, which discusses strategies, + algorithms, and formats for maintaining the data residing in + name servers. These services periodically refresh the local + copies of zones that originate in other hosts. + + RESOLVER ALGORITHMS, which discusses the internal structure of + resolvers. This section also discusses data base sharing + between a name server and a resolver on the same host. + + DOMAIN SUPPORT FOR MAIL, which discusses the use of the domain + system to support mail transfer. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 5] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Conventions + + The domain system has several conventions dealing with low-level, + but fundamental, issues. While the implementer is free to violate + these conventions WITHIN HIS OWN SYSTEM, he must observe these + conventions in ALL behavior observed from other hosts. + + ********** Data Transmission Order ********** + + The order of transmission of the header and data described in this + document is resolved to the octet level. Whenever a diagram shows + a group of octets, the order of transmission of those octets is + the normal order in which they are read in English. For example, + in the following diagram the octets are transmitted in the order + they are numbered. + + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 3 | 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 5 | 6 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Transmission Order of Bytes + + Whenever an octet represents a numeric quantity the left most bit + in the diagram is the high order or most significant bit. That + is, the bit labeled 0 is the most significant bit. For example, + the following diagram represents the value 170 (decimal). + + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |1 0 1 0 1 0 1 0| + +-+-+-+-+-+-+-+-+ + + Significance of Bits + + Similarly, whenever a multi-octet field represents a numeric + quantity the left most bit of the whole field is the most + significant bit. When a multi-octet quantity is transmitted the + most significant octet is transmitted first. + + + + + +Mockapetris [Page 6] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + ********** Character Case ********** + + All comparisons between character strings (e.g. labels, domain + names, etc.) are done in a case-insensitive manner. + + When data enters the domain system, its original case should be + preserved whenever possible. In certain circumstances this cannot + be done. For example, if two domain names x.y and X.Y are entered + into the domain database, they are interpreted as the same name, + and hence may have a single representation. The basic rule is + that case can be discarded only when data is used to define + structure in a database, and two names are identical when compared + in a case insensitive manner. + + Loss of case sensitive data must be minimized. Thus while data + for x.y and X.Y may both be stored under x.y, data for a.x and B.X + can be stored as a.x and B.x, but not A.x, A.X, b.x, or b.X. In + general, this prevents the first component of a domain name from + loss of case information. + + Systems administrators who enter data into the domain database + should take care to represent the data they supply to the domain + system in a case-consistent manner if their system is + case-sensitive. The data distribution system in the domain system + will ensure that consistent representations are preserved. + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 7] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Design philosophy + + The design presented in this memo attempts to provide a base which + will be suitable for several existing networks. An equally + important goal is to provide these services within a framework + that is capable of adjustment to fit the evolution of services in + early clients as well as to accommodate new networks. + + Since it is impossible to predict the course of these + developments, the domain system attempts to provide for evolution + in the form of an extensible framework. This section describes + the areas in which we expect to see immediate evolution. + + DEFINING THE DATABASE + + This memo defines methods for partitioning the database and data + for host names, host addresses, gateway information, and mail + support. Experience with this system will provide guidance for + future additions. + + While the present system allows for many new RR types, classes, + etc., we feel that it is more important to get the basic services + in operation than to cover an exhaustive set of information. + Hence we have limited the data types to those we felt were + essential, and would caution designers to avoid implementations + which are based on the number of existing types and classes. + Extensibility in this area is very important. + + While the domain system provides techniques for partitioning the + database, policies for administrating the orderly connection of + separate domains and guidelines for constructing the data that + makes up a particular domain will be equally important to the + success of the system. Unfortunately, we feel that experience + with prototype systems will be necessary before this question can + be properly addressed. Thus while this memo has minimal + discussion of these issues, it is a critical area for development. + + TYING TOGETHER INTERNETS + + Although it is very difficult to characterize the types of + networks, protocols, and applications that will be clients of the + domain system, it is very obvious that some of these applications + will cross the boundaries of network and protocol. At the very + least, mail is such a service. + + Attempts to unify two such systems must deal with two major + problems: + + 1. Differing formats for environment sensitive data. For example, + + +Mockapetris [Page 8] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + network addresses vary in format, and it is unreasonable to + expect to enforce consistent conventions. + + 2. Connectivity may require intermediaries. For example, it is a + frequent occurence that mail is sent between hosts that share + no common protocol. + + The domain system acknowledges that these are very difficult + problems, and attempts to deal with both problems through its + CLASS mechanism: + + 1. The CLASS field in RRs allows data to be tagged so that all + programs in the domain system can identify the format in use. + + 2. The CLASS field allows the requestor to identify the format of + data which can be understood by the requestor. + + 3. The CLASS field guides the search for the requested data. + + The last point is central to our approach. When a query crosses + protocol boundaries, it must be guided though agents capable of + performing whatever translation is required. For example, when a + mailer wants to identify the location of a mailbox in a portion of + the domain system that doesn't have a compatible protocol, the + query must be guided to a name server that can cross the boundary + itself or form one link in a chain that can span the differences. + + If query and response transport were the only problem, then this + sort of problem could be dealt with in the name servers + themselves. However, the applications that will use domain + service have similar problems. For example, mail may need to be + directed through mail gateways, and the characteristics of one of + the environments may not permit frequent connectivity between name + servers in all environments. + + These problems suggest that connectivity will be achieved through + a variety of measures: + + Translation name servers that act as relays between different + protocols. + + Translation application servers that translate application + level transactions. + + Default database entries that route traffic through application + level forwarders in ways that depend on the class of the + requestor. + + While this approach seems best given our current understanding of + + +Mockapetris [Page 9] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + the problem, we realize that the approach of using resource data + that transcends class may be appropriate in future designs or + applications. By not defining class to be directly related to + protocol, network, etc., we feel that such services could be added + by defining a new "universal" class, while the present use of + class will provide immediate service. + + This problem requires more thought and experience before solutions + can be discovered. The concepts of CLASS, recursive servers and + other mechanisms are intended as tools for acquiring experience + and not as final solutions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 10] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +NAME SERVER TRANSACTIONS + + Introduction + + The primary purpose of name servers is to receive queries from + resolvers and return responses. The overall model of this service + is that a program (typically a resolver) asks the name server + questions (queries) and gets responses that either answer the + question or refer the questioner to another name server. Other + functions related to name server database maintenance use similar + procedures and formats and are discussed in a section later in + this memo. + + There are three kinds of queries presently defined: + + 1. Standard queries that ask for a specified resource attached + to a given domain name. + + 2. Inverse queries that specify a resource and ask for a domain + name that possesses that resource. + + 3. Completion queries that specify a partial domain name and a + target domain and ask that the partial domain name be + completed with a domain name close to the target domain. + + This memo uses an unqualified reference to queries to refer to + either all queries or standard queries when the context is clear. + + Query and response transport + + Name servers and resolvers use a single message format for all + communications. The message format consists of a variable-length + octet string which includes binary values. + + The messages used in the domain system are designed so that they + can be carried using either datagrams or virtual circuits. To + accommodate the datagram style, all responses carry the query as + part of the response. + + While the specification allows datagrams to be used in any + context, some activities are ill suited to datagram use. For + example, maintenance transactions and recursive queries typically + require the error control of virtual circuits. Thus datagram use + should be restricted to simple queries. + + The domain system assumes that a datagram service provides: + + 1. A non-reliable (i.e. best effort) method of transporting a + message of up to 512 octets. + + +Mockapetris [Page 11] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Hence datagram messages are limited to 512 octets. If a + datagram message would exceed 512 octets, it is truncated + and a truncation flag is set in its header. + + 2. A message size that gives the number of octets in the + datagram. + + The main implications for programs accessing name servers via + datagrams are: + + 1. Datagrams should not be used for maintenance transactions + and recursive queries. + + 2. Since datagrams may be lost, the originator of a query must + perform error recovery (such as retransmissions) as + appropriate. + + 3. Since network or host delay may cause retransmission when a + datagram has not been lost, the originator of a query must + be ready to deal with duplicate responses. + + The domain system assumes that a virtual circuit service provides: + + 1. A reliable method of transmitting a message of up to 65535 + octets. + + 2. A message size that gives the number of octets in the + message. + + If the virtual circuit service does not provide for message + boundary detection or limits transmission size to less than + 65535 octets, then messages are prefaced with an unsigned 16 + bit length field and broken up into separate transmissions + as required. The length field is only prefaced on the first + message. This technique is used for TCP virtual circuits. + + 3. Multiple messages may be sent over a virtual circuit. + + 4. A method for closing a virtual circuit. + + 5. A method for detecting that the other party has requested + that the virtual circuit be closed. + + The main implications for programs accessing name servers via + virtual circuits are: + + 1. Either end of a virtual circuit may initiate a close when + there is no activity in progress. The other end should + comply. + + +Mockapetris [Page 12] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + The decision to initiate a close is a matter of individual + site policy; some name servers may leave a virtual circuit + open for an indeterminate period following a query to allow + for subsequent queries; other name servers may choose to + initiate a close following the completion of the first query + on a virtual circuit. Of course, name servers should not + close the virtual circuit in the midst of a multiple message + stream used for zone transfer. + + 2. Since network delay may cause one end to erroneously believe + that no activity is in progress, a program which receives a + virtual circuit close while a query is in progress should + close the virtual circuit and resubmit the query on a new + virtual circuit. + + All messages may use a compression scheme to reduce the space + consumed by repetitive domain names. The use of the compression + scheme is optional for the sender of a message, but all receivers + must be capable of decoding compressed domain names. + + Overall message format + + All messages sent by the domain system are divided into 5 sections + (some of which are empty in certain cases) shown below: + + +---------------------+ + | Header | + +---------------------+ + | Question | the question for the name server + +---------------------+ + | Answer | answering resource records (RRs) + +---------------------+ + | Authority | RRs pointing toward an authority + +---------------------+ + | Additional | RRs holding pertinent information + +---------------------+ + + The header section is always present. The header includes fields + that specify which of the remaining sections are present, and also + specify whether the message is a query, inverse query, completion + query, or response. + + The question section contains fields that describe a question to a + name server. These fields are a query type (QTYPE), a query class + (QCLASS), and a query domain name (QNAME). + + The last three sections have the same format: a possibly empty + list of concatenated resource records (RRs). The answer section + contains RRs that answer the question; the authority section + + +Mockapetris [Page 13] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + contains RRs that point toward an authoritative name server; the + additional records section contains RRs which relate to the query, + but are not strictly answers for the question. + + The next two sections of this memo illustrate the use of these + message sections through examples; a detailed discussion of data + formats follows the examples. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 14] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + The contents of standard queries and responses + + When a name server processes a standard query, it first determines + whether it is an authority for the domain name specified in the + query. + + If the name server is an authority, it returns either: + + 1. the specified resource information + + 2. an indication that the specified name does not exist + + 3. an indication that the requested resource information does + not exist + + If the name server is not an authority for the specified name, it + returns whatever relevant resource information it has along with + resource records that the requesting resolver can use to locate an + authoritative name server. + + Standard query and response example + + The overall structure of a query for retrieving information for + Internet mail for domain F.ISI.ARPA is shown below: + + +-----------------------------------------+ + Header | OPCODE=QUERY, ID=2304 | + +-----------------------------------------+ + Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | + +-----------------------------------------+ + Answer | <empty> | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | <empty> | + +-----------------------------------------+ + + The header includes an opcode field that specifies that this + datagram is a query, and an ID field that will be used to + associate replies with the original query. (Some additional + header fields have been omitted for clarity.) The question + section specifies that the type of the query is for mail agent + information, that only ARPA Internet information is to be + considered, and that the domain name of interest is F.ISI.ARPA. + The remaining sections are empty, and would not use any octets in + a real query. + + + + + +Mockapetris [Page 15] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + One possible response to this query might be: + + +-----------------------------------------+ + Header | OPCODE=RESPONSE, ID=2304 | + +-----------------------------------------+ + Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | + +-----------------------------------------+ + Answer | <empty> | + +-----------------------------------------+ + Authority | ARPA NS IN A.ISI.ARPA | + | ------- | + | ARPA NS IN F.ISI.ARPA | + +-----------------------------------------+ + Additional | F.ISI.ARPA A IN 10.2.0.52 | + | ------- | + | A.ISI.ARPA A IN 10.1.0.22 | + +-----------------------------------------+ + + This type of response would be returned by a name server that was + not an authority for the domain name F.ISI.ARPA. The header field + specifies that the datagram is a response to a query with an ID of + 2304. The question section is copied from the question section in + the query datagram. + + The answer section is empty because the name server did not have + any information that would answer the query. (Name servers may + happen to have cached information even if they are not + authoritative for the query.) + + The best that this name server could do was to pass back + information for the domain ARPA. The authority section specifies + two name servers for the domain ARPA using the Internet family: + A.ISI.ARPA and F.ISI.ARPA. Note that it is merely a coincidence + that F.ISI.ARPA is a name server for ARPA as well as the subject + of the query. + + In this case, the name server included in the additional records + section the Internet addresses for the two hosts specified in the + authority section. Such additional data is almost always + available. + + Given this response, the process that originally sent the query + might resend the query to the name server on A.ISI.ARPA, with a + new ID of 2305. + + + + + + + +Mockapetris [Page 16] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + The name server on A.ISI.ARPA might return a response: + + +-----------------------------------------+ + Header | OPCODE=RESPONSE, ID=2305 | + +-----------------------------------------+ + Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | + +-----------------------------------------+ + Answer | F.ISI.ARPA MD IN F.ISI.ARPA | + | ------- | + | F.ISI.ARPA MF IN A.ISI.ARPA | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | F.ISI.ARPA A IN 10.2.0.52 | + | ------- | + | A.ISI.ARPA A IN 10.1.0.22 | + +-----------------------------------------+ + + This query was directed to an authoritative name server, and hence + the response includes an answer but no authority records. In this + case, the answer section specifies that mail for F.ISI.ARPA can + either be delivered to F.ISI.ARPA or forwarded to A.ISI.ARPA. The + additional records section specifies the Internet addresses of + these hosts. + + The contents of inverse queries and responses + + Inverse queries reverse the mappings performed by standard query + operations; while a standard query maps a domain name to a + resource, an inverse query maps a resource to a domain name. For + example, a standard query might bind a domain name to a host + address; the corresponding inverse query binds the host address to + a domain name. + + Inverse query mappings are not guaranteed to be unique or complete + because the domain system does not have any internal mechanism for + determining authority from resource records that parallels the + capability for determining authority as a function of domain name. + In general, resolvers will be configured to direct inverse queries + to a name server which is known to have the desired information. + + Name servers are not required to support any form of inverse + queries; it is anticipated that most name servers will support + address to domain name conversions, but no other inverse mappings. + If a name server receives an inverse query that it does not + support, it returns an error response with the "Not Implemented" + error set in the header. While inverse query support is optional, + all name servers must be at least able to return the error + response. + + +Mockapetris [Page 17] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + When a name server processes an inverse query, it either returns: + + 1. zero, one, or multiple domain names for the specified + resource + + 2. an error code indicating that the name server doesn't + support inverse mapping of the specified resource type. + + Inverse query and response example + + The overall structure of an inverse query for retrieving the + domain name that corresponds to Internet address 10.2.0.52 is + shown below: + + +-----------------------------------------+ + Header | OPCODE=IQUERY, ID=997 | + +-----------------------------------------+ + Question | <empty> | + +-----------------------------------------+ + Answer | <anyname> A IN 10.2.0.52 | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | <empty> | + +-----------------------------------------+ + + This query asks for a question whose answer is the Internet style + address 10.2.0.52. Since the owner name is not known, any domain + name can be used as a placeholder (and is ignored). The response + to this query might be: + + +-----------------------------------------+ + Header | OPCODE=RESPONSE, ID=997 | + +-----------------------------------------+ + Question | QTYPE=A, QCLASS=IN, QNAME=F.ISI.ARPA | + +-----------------------------------------+ + Answer | F.ISI.ARPA A IN 10.2.0.52 | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | <empty> | + +-----------------------------------------+ + + Note that the QTYPE in a response to an inverse query is the same + as the TYPE field in the answer section of the inverse query. + Responses to inverse queries may contain multiple questions when + the inverse is not unique. + + + + +Mockapetris [Page 18] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Completion queries and responses + + Completion queries ask a name server to complete a partial domain + name and return a set of RRs whose domain names meet a specified + set of criteria for "closeness" to the partial input. This type + of query can provide a local shorthand for domain names or command + completion similar to that in TOPS-20. + + Implementation of completion query processing is optional in a + name server. However, a name server must return a "Not + Implemented" (NI) error response if it does not support + completion. + + The arguments in a completion query specify: + + 1. A type in QTYPE that specifies the type of the desired name. + The type is used to restrict the type of RRs which will match + the partial input so that completion queries can be used for + mailbox names, host names, or any other type of RR in the + domain system without concern for matches to the wrong type of + resource. + + 2. A class in QCLASS which specifies the desired class of the RR. + + 3. A partial domain name that gives the input to be completed. + All returned RRs will begin with the partial string. The + search process first looks for names which qualify under the + assumption that the partial string ends with a full label + ("whole label match"); if this search fails, the search + continues under the assumption that the last label in the + partial sting may be an incomplete label ("partial label + match"). For example, if the partial string "Smith" was used + in a mailbox completion, it would match Smith@ISI.ARPA in + preference to Smithsonian@ISI.ARPA. + + The partial name is supplied by the user through the user + program that is using domain services. For example, if the + user program is a mail handler, the string might be "Mockap" + which the user intends as a shorthand for the mailbox + Mockapetris@ISI.ARPA; if the user program is TELNET, the user + might specify "F" for F.ISI.ARPA. + + In order to make parsing of messages consistent, the partial + name is supplied in domain name format (i.e. a sequence of + labels terminated with a zero length octet). However, the + trailing root label is ignored during matching. + + 4. A target domain name which specifies the domain which is to be + examined for matches. This name is specified in the additional + + +Mockapetris [Page 19] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + section using a NULL RR. All returned names will end with the + target name. + + The user program which constructs the query uses the target + name to restrict the search. For example, user programs + running at ISI might restrict completion to names that end in + ISI.ARPA; user programs running at MIT might restrict + completion to the domain MIT.ARPA. + + The target domain name is also used by the resolver to + determine the name server which should be used to process the + query. In general, queries should be directed to a name server + that is authoritative for the target domain name. User + programs which wish to provide completion for a more than one + target can issue multiple completion queries, each directed at + a different target. Selection of the target name and the + number of searches will depend on the goals of the user + program. + + 5. An opcode for the query. The two types of completion queries + are "Completion Query - Multiple", or CQUERYM, which asks for + all RRs which could complete the specified input, and + "Completion Query - Unique", or CQUERYU, which asks for the + "best" completion. + + CQUERYM is used by user programs which want to know if + ambiguities exist or wants to do its own determinations as to + the best choice of the available candidates. + + CQUERYU is used by user programs which either do not wish to + deal with multiple choices or are willing to use the closeness + criteria used by CQUERYU to select the best match. + + When a name server receives either completion query, it first + looks for RRs that begin (on the left) with the same labels as are + found in QNAME (with the root deleted), and which match the QTYPE + and QCLASS. This search is called "whole label" matching. If one + or more hits are found the name server either returns all of the + hits (CQUERYM) or uses the closeness criteria described below to + eliminate all but one of the matches (CQUERYU). + + If the whole label match fails to find any candidates, then the + name server assumes that the rightmost label of QNAME (after root + deletion) is not a complete label, and looks for candidates that + would match if characters were added (on the right) to the + rightmost label of QNAME. If one or more hits are found the name + server either returns all of the hits (CQUERYM) or uses the + closeness criteria described below to eliminate all but one of the + matches (CQUERYU). + + +Mockapetris [Page 20] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + If a CQUERYU query encounters multiple hits, it uses the following + sequence of rules to discard multiple hits: + + 1. Discard candidates that have more labels than others. Since + all candidates start with the partial name and end with the + target name, this means that we select those entries that + require the fewest number of added labels. For example, a host + search with a target of "ISI.ARPA" and a partial name of "A" + will select A.ISI.ARPA in preference to A.IBM-PCS.ISI.ARPA. + + 2. If partial label matching was used, discard those labels which + required more characters to be added. For example, a mailbox + search for partial "X" and target "ISI.ARPA" would prefer + XX@ISI.ARPA to XYZZY@ISI.ARPA. + + If multiple hits are still present, return all hits. + + Completion query mappings are not guaranteed to be unique or + complete because the domain system does not have any internal + mechanism for determining authority from a partial domain name + that parallels the capability for determining authority as a + function of a complete domain name. In general, resolvers will be + configured to direct completion queries to a name server which is + known to have the desired information. + + When a name server processes a completion query, it either + returns: + + 1. An answer giving zero, one, or more possible completions. + + 2. an error response with Not Implemented (NI) set. + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 21] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Completion query and response example + + Suppose that the completion service was used by a TELNET program + to allow a user to specify a partial domain name for the desired + host. Thus a user might ask to be connected to "B". Assuming + that the query originated from an ISI machine, the query might + look like: + + +-----------------------------------------+ + Header | OPCODE=CQUERYU, ID=409 | + +-----------------------------------------+ + Question | QTYPE=A, QCLASS=IN, QNAME=B | + +-----------------------------------------+ + Answer | <empty> | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | ISI.ARPA NULL IN | + +-----------------------------------------+ + + The partial name in the query is "B", the mappings of interest are + ARPA Internet address records, and the target domain is ISI.ARPA. + Note that NULL is a special type of NULL resource record that is + used as a placeholder and has no significance; NULL RRs obey the + standard format but have no other function. + + The response to this completion query might be: + + +-----------------------------------------+ + Header | OPCODE=RESPONSE, ID=409 | + +-----------------------------------------+ + Question | QTYPE=A, QCLASS=IN, QNAME=B | + +-----------------------------------------+ + Answer | B.ISI.ARPA A IN 10.3.0.52 | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | ISI.ARPA NULL IN | + +-----------------------------------------+ + + This response has completed B to mean B.ISI.ARPA. + + + + + + + + + + +Mockapetris [Page 22] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Another query might be: + + +-----------------------------------------+ + Header | OPCODE=CQUERYM, ID=410 | + +-----------------------------------------+ + Question | QTYPE=A, QCLASS=IN, QNAME=B | + +-----------------------------------------+ + Answer | <empty> | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | ARPA NULL IN | + +-----------------------------------------+ + + This query is similar to the previous one, but specifies a target + of ARPA rather than ISI.ARPA. It also allows multiple matches. + In this case the same name server might return: + + +-----------------------------------------+ + Header | OPCODE=RESPONSE, ID=410 | + +-----------------------------------------+ + Question | QTYPE=A, QCLASS=IN, QNAME=B | + +-----------------------------------------+ + Answer | B.ISI.ARPA A IN 10.3.0.52 | + | - | + | B.BBN.ARPA A IN 10.0.0.49 | + | - | + | B.BBNCC.ARPA A IN 8.1.0.2 | + +-----------------------------------------+ + Authority | <empty> | + +-----------------------------------------+ + Additional | ARPA NULL IN | + +-----------------------------------------+ + + This response contains three answers, B.ISI.ARPA, B.BBN.ARPA, and + B.BBNCC.ARPA. + + + + + + + + + + + + + + + +Mockapetris [Page 23] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Recursive Name Service + + Recursive service is an optional feature of name servers. + + When a name server receives a query regarding a part of the name + space which is not in one of the name server's zones, the standard + response is a message that refers the requestor to another name + server. By iterating on these referrals, the requestor eventually + is directed to a name server that has the required information. + + Name servers may also implement recursive service. In this type + of service, a name server either answers immediately based on + local zone information, or pursues the query for the requestor and + returns the eventual result back to the original requestor. + + A name server that supports recursive service sets the Recursion + Available (RA) bit in all responses it generates. A requestor + asks for recursive service by setting the Recursion Desired (RD) + bit in queries. In some situations where recursive service is the + only path to the desired information (see below), the name server + may go recursive even if RD is zero. + + If a query requests recursion (RD set), but the name server does + not support recursion, and the query needs recursive service for + an answer, the name server returns a "Not Implemented" (NI) error + code. If the query can be answered without recursion since the + name server is authoritative for the query, it ignores the RD bit. + + Because of the difficulty in selecting appropriate timeouts and + error handling, recursive service is best suited to virtual + circuits, although it is allowed for datagrams. + + Recursive service is valuable in several special situations: + + In a system of small personal computers clustered around one or + more large hosts supporting name servers, the recursive + approach minimizes the amount of code in the resolvers in the + personal computers. Such a design moves complexity out of the + resolver into the name server, and may be appropriate for such + systems. + + Name servers on the boundaries of different networks may wish + to offer recursive service to create connectivity between + different networks. Such name servers may wish to provide + recursive service regardless of the setting of RD. + + Name servers that translate between domain name service and + some other name service may wish to adopt the recursive style. + Implicit recursion may be valuable here as well. + + +Mockapetris [Page 24] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + These concepts are still under development. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 25] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Header section format + + +-----------------------------------------------+ + | | + | ***** WARNING ***** | + | | + | The following format is preliminary and is | + | included for purposes of explanation only. In | + | particular, the size and position of the | + | OPCODE, RCODE fields and the number and | + | meaning of the single bit fields are subject | + | to change. | + | | + +-----------------------------------------------+ + + The header contains the following fields: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| | RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + ID - A 16 bit identifier assigned by the program that + generates any kind of query. This identifier is copied + into all replies and can be used by the requestor to + relate replies to outstanding questions. + + QR - A one bit field that specifies whether this message is a + query (0), or a response (1). + + OPCODE - A four bit field that specifies kind of query in this + message. This value is set by the originator of a query + and copied into the response. The values are: + + 0 a standard query (QUERY) + + + +Mockapetris [Page 26] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + 1 an inverse query (IQUERY) + + 2 an completion query allowing multiple + answers (CQUERYM) + + 2 an completion query requesting a single + answer (CQUERYU) + + 4-15 reserved for future use + + AA - Authoritative Answer - this bit is valid in responses, + and specifies that the responding name server + is an authority for the domain name in the + corresponding query. + + TC - TrunCation - specifies that this message was truncated + due to length greater than 512 characters. + This bit is valid in datagram messages but not + in messages sent over virtual circuits. + + RD - Recursion Desired - this bit may be set in a query and + is copied into the response. If RD is set, it + directs the name server to pursue the query + recursively. Recursive query support is + optional. + + RA - Recursion Available - this be is set or cleared in a + response, and denotes whether recursive query + support is available in the name server. + + RCODE - Response code - this 4 bit field is set as part of + responses. The values have the following + interpretation: + + 0 No error condition + + 1 Format error - The name server was unable + to interpret the query. + + 2 Server failure - The name server was unable + to process this query due to a problem with + the name server. + + 3 Name Error - Meaningful only for responses + from an authoritative name server, this + code signifies that the domain name + referenced in the query does not exist. + + + + +Mockapetris [Page 27] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + 4 Not Implemented - The name server does not + support the requested kind of query. + + 5 Refused - The name server refuses to + perform the specified operation for policy + reasons. For example, a name server may + not wish to provide the information to the + particular requestor, or a name server may + not wish to perform a particular operation + (e.g. zone transfer) for particular data. + + 6-15 Reserved for future use. + + QDCOUNT - an unsigned 16 bit integer specifying the number of + entries in the question section. + + ANCOUNT - an unsigned 16 bit integer specifying the number of + resource records in the answer section. + + NSCOUNT - an unsigned 16 bit integer specifying the number of name + server resource records in the authority records + section. + + ARCOUNT - an unsigned 16 bit integer specifying the number of + resource records in the additional records section. + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 28] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Question section format + + The question section is used in all kinds of queries other than + inverse queries. In responses to inverse queries, this section + may contain multiple entries; for all other responses it contains + a single entry. Each entry has the following format: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / QNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QTYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QCLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + QNAME - a variable number of octets that specify a domain name. + This field uses the compressed domain name format + described in the next section of this memo. This field + can be used to derive a text string for the domain name. + Note that this field may be an odd number of octets; no + padding is used. + + QTYPE - a two octet code which specifies the type of the query. + The values for this field include all codes valid for a + TYPE field, together with some more general codes which + can match more than one type of RR. For example, QTYPE + might be A and only match type A RRs, or might be MAILA, + which matches MF and MD type RRs. The values for this + field are listed in Appendix 2. + + QCLASS - a two octet code that specifies the class of the query. + For example, the QCLASS field is IN for the ARPA + Internet, CS for the CSNET, etc. The numerical values + are defined in Appendix 2. + + + + + + + + + + + +Mockapetris [Page 29] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Resource record format + + The answer, authority, and additional sections all share the same + format: a variable number of resource records, where the number of + records is specified in the corresponding count field in the + header. Each resource record has the following format: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + NAME - a compressed domain name to which this resource record + pertains. + + TYPE - two octets containing one of the RR type codes defined + in Appendix 2. This field specifies the meaning of the + data in the RDATA field. + + CLASS - two octets which specify the class of the data in the + RDATA field. + + TTL - a 16 bit unsigned integer that specifies the time + interval (in seconds) that the resource record may be + cached before it should be discarded. Zero values are + interpreted to mean that the RR can only be used for the + transaction in progress, and should not be cached. For + example, SOA records are always distributed with a zero + TTL to prohibit caching. Zero values can also be used + for extremely volatile data. + + + + +Mockapetris [Page 30] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + RDLENGTH- an unsigned 16 bit integer that specifies the length in + octets of the RDATA field. + + RDATA - a variable length string of octets that describes the + resource. The format of this information varies + according to the TYPE and CLASS of the resource record. + For example, the if the TYPE is A and the CLASS is IN, + the RDATA field is a 4 octet ARPA Internet address. + + Formats for particular resource records are shown in Appendicies 2 + and 3. + + Domain name representation and compression + + Domain names messages are expressed in terms of a sequence of + labels. Each label is represented as a one octet length field + followed by that number of octets. Since every domain name ends + with the null label of the root, a compressed domain name is + terminated by a length byte of zero. The high order two bits of + the length field must be zero, and the remaining six bits of the + length field limit the label to 63 octets or less. + + To simplify implementations, the total length of label octets and + label length octets that make up a domain name is restricted to + 255 octets or less. Since the trailing root label and its dot are + not printed, printed domain names are 254 octets or less. + + Although labels can contain any 8 bit values in octets that make + up a label, it is strongly recommended that labels follow the + syntax described in Appendix 1 of this memo, which is compatible + with existing host naming conventions. Name servers and resolvers + must compare labels in a case-insensitive manner, i.e. A=a, and + hence all character strings must be ASCII with zero parity. + Non-alphabetic codes must match exactly. + + Whenever possible, name servers and resolvers must preserve all 8 + bits of domain names they process. When a name server is given + data for the same name under two different case usages, this + preservation is not always possible. For example, if a name + server is given data for ISI.ARPA and isi.arpa, it should create a + single node, not two, and hence will preserve a single casing of + the label. Systems with case sensitivity should take special + precautions to insure that the domain data for the system is + created with consistent case. + + In order to reduce the amount of space used by repetitive domain + names, the sequence of octets that defines a domain name may be + terminated by a pointer to the length octet of a previously + specified label string. The label string that the pointer + + +Mockapetris [Page 31] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + specifies is appended to the already specified label string. + Exact duplication of a previous label string can be done with a + single pointer. Multiple levels are allowed. + + Pointers can only be used in positions in the message where the + format is not class specific. If this were not the case, a name + server that was handling a RR for another class could make + erroneous copies of RRs. As yet, there are no such cases, but + they may occur in future RDATA formats. + + If a domain name is contained in a part of the message subject to + a length field (such as the RDATA section of an RR), and + compression is used, the length of the compressed name is used in + the length calculation, rather than the length of the expanded + name. + + Pointers are represented as a two octet field in which the high + order 2 bits are ones, and the low order 14 bits specify an offset + from the start of the message. The 01 and 10 values of the high + order bits are reserved for future use and should not be used. + + Programs are free to avoid using pointers in datagrams they + generate, although this will reduce datagram capacity. However + all programs are required to understand arriving messages that + contain pointers. + + For example, a datagram might need to use the domain names + F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the + other fields of the message, these domain names might be + represented as: + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 32] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 20 | 1 | F | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 22 | 3 | I | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 24 | S | I | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 26 | 4 | A | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 28 | R | P | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 30 | A | 0 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 40 | 3 | F | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 42 | O | O | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 44 | 1 1| 20 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 64 | 1 1| 26 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 92 | 0 | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The domain name for F.ISI.ARPA is shown at offset 20. The domain + name FOO.F.ISI.ARPA is shown at offset 40; this definition uses a + pointer to concatenate a label for FOO to the previously defined + F.ISI.ARPA. The domain name ARPA is defined at offset 64 using a + pointer to the ARPA component of the name F.ISI.ARPA at 20; note + that this reference relies on ARPA being the last label in the + string at 20. The root domain name is defined by a single octet + of zeros at 92; the root domain name has no labels. + + Organization of the Shared database + + While name server implementations are free to use any internal + data structures they choose, the suggested structure consists of + several separate trees. Each tree has structure corresponding to + the domain name space, with RRs attached to nodes and leaves. + Each zone of authoritative data has a separate tree, and one tree + holds all non-authoritative data. All of the trees corresponding + to zones are managed identically, but the non-authoritative or + cache tree has different management procedures. + + +Mockapetris [Page 33] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Data stored in the database can be kept in whatever form is + convenient for the name server, so long as it can be transformed + back into the format needed for messages. In particular, the + database will probably use structure in place of expanded domain + names, and will also convert many of the time intervals used in + the domain systems to absolute local times. + + Each tree corresponding to a zone has complete information for a + "pruned" subtree of the domain space. The top node of a zone has + a SOA record that marks the start of the zone. The bottom edge of + the zone is delimited by nodes containing NS records signifying + delegation of authority to other zones, or by leaves of the domain + tree. When a name server contains abutting zones, one tree will + have a bottom node containing a NS record, and the other tree will + begin with a tree location containing a SOA record. + + Note that there is one special case that requires consideration + when a name server is implemented. A node that contains a SOA RR + denoting a start of zone will also have NS records that identify + the name servers that are expected to have a copy of the zone. + Thus a name server will usually find itself (and possibly other + redundant name servers) referred to in NS records occupying the + same position in the tree as SOA records. The solution to this + problem is to never interpret a NS record as delimiting a zone + started by a SOA at the same point in the tree. (The sample + programs in this memo deal with this problem by processing SOA + records only after NS records have been processed.) + + Zones may also overlap a particular part of the name space when + they are of different classes. + + Other than the abutting and separate class cases, trees are always + expected to be disjoint. Overlapping zones are regarded as a + non-fatal error. The scheme described in this memo avoids the + overlap issue by maintaining separate trees; other designs must + take the appropriate measures to defend against possible overlap. + + Non-authoritative data is maintained in a separate tree. This + tree is unlike the zone trees in that it may have "holes". Each + RR in the cache tree has its own TTL that is separately managed. + The data in this tree is never used if authoritative data is + available from a zone tree; this avoids potential problems due to + cached data that conflicts with authoritative data. + + The shared database will also contain data structures to support + the processing of inverse queries and completion queries if the + local system supports these optional features. Although many + schemes are possible, this memo describes a scheme that is based + on tables of pointers that invert the database according to key. + + +Mockapetris [Page 34] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Each kind of retrieval has a separate set of tables, with one + table per zone. When a zone is updated, these tables must also be + updated. The contents of these tables are discussed in the + "Inverse query processing" and "Completion query processing" + sections of this memo. + + The database implementation described here includes two locks that + are used to control concurrent access and modification of the + database by name server query processing, name server maintenance + operations, and resolver access: + + The first lock ("main lock") controls access to all of the + trees. Multiple concurrent reads are allowed, but write access + can only be acquired by a single process. Read and write + access are mutually exclusive. Resolvers and name server + processes that answer queries acquire this lock in read mode, + and unlock upon completion of the current message. This lock + is acquired in write mode by a name server maintenance process + when it is about to change data in the shared database. The + actual update procedures are described under "NAME SERVER + MAINTENANCE" but are designed to be brief. + + The second lock ("cache queue lock") controls access to the + cache queue. This queue is used by a resolver that wishes to + add information to the cache tree. The resolver acquires this + lock, then places the RRs to be cached into the queue. The + name server maintenance procedure periodically acquires this + lock and adds the queue information to the cache. The + rationale for this procedure is that it allows the resolver to + operate with read-only access to the shared database, and + allows the update process to batch cache additions and the + associated costs for inversion calculations. The name server + maintenance procedure must take appropriate precautions to + avoid problems with data already in the cache, inversions, etc. + + This organization solves several difficulties: + + When searching the domain space for the answer to a query, a + name server can restrict its search for authoritative data to + that tree that matches the most labels on the right side of the + domain name of interest. + + Since updates to a zone must be atomic with respect to + searches, maintenance operations can simply acquire the main + lock, insert a new copy of a particular zone without disturbing + other zones, and then release the storage used by the old copy. + Assuming a central table pointing to valid zone trees, this + operation can be a simple pointer swap. + + + +Mockapetris [Page 35] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + TTL management of zones can be performed using the SOA record + for the zone. This avoids potential difficulties if individual + RRs in a zone could be timed out separately. This issue is + discussed further in the maintenance section. + + Query processing + + The following algorithm outlines processing that takes place at a + name server when a query arrives: + + 1. Search the list of zones to find zones which have the same + class as the QCLASS field in the query and have a top domain + name that matches the right end of the QNAME field. If there + are none, go to step 2. If there are more than one, pick the + zone that has the longest match and go to step 3. + + 2. Since the zone search failed, the only possible RRs are + contained in the non-authoritative tree. Search the cache tree + for the NS record that has the same class as the QCLASS field + and the largest right end match for domain name. Add the NS + record or records to the authority section of the response. If + the cache tree has RRs that are pertinent to the question + (domain names match, classes agree, not timed-out, and the type + field is relevant to the QTYPE), copy these RRs into the answer + section of the response. The name server may also search the + cache queue. Go to step 4. + + 3. Since this zone is the best match, the zone in which QNAME + resides is either this zone or a zone to which this zone will + directly or indirectly delegate authority. Search down the + tree looking for a NS RR or the node specified by QNAME. + + If the node exists and has no NS record, copy the relevant + RRs to the answer section of the response and go to step 4. + + If a NS RR is found, either matching a part or all of QNAME, + then QNAME is in a delegated zone outside of this zone. If + so, copy the NS record or records into the authority section + of the response, and search the remainder of the zone for an + A type record corresponding to the NS reference. If the A + record is found, add it to the additional section. Go to + step 2. + + If the node is not found and a NS is not found, there is no + such name; set the Name error bit in the response and exit. + + 4. When this step is reached, the answer and authority sections + are complete. What remains is to complete the additional + section. This procedure is only possible if the name server + + +Mockapetris [Page 36] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + knows the data formats implied by the class of records in the + answer and authority sections. Hence this procedure is class + dependent. Appendix 3 discusses this procedure for Internet + class data. + + While this algorithm deals with typical queries and databases, + several additions are required that will depend on the database + supported by the name server: + + QCLASS=* + + Special procedures are required when the QCLASS of the query is + "*". If the database contains several classes of data, the + query processing steps above are performed separately for each + CLASS, and the results are merged into a single response. The + name error condition is not meaningful for a QCLASS=* query. + If the requestor wants this information, it must test each + class independently. + + If the database is limited to data of a particular class, this + operation can be performed by simply reseting the authoritative + bit in the response, and performing the query as if QCLASS was + the class used in the database. + + * labels in database RRs + + Some zones will contain default RRs that use * to match in + cases where the search fails for a particular domain name. If + the database contains these records then a failure must be + retried using * in place of one or more labels of the search + key. The procedure is to replace labels from the left with + "*"s looking for a match until either all labels have been + replaced, or a match is found. Note that these records can + never be the result of caching, so a name server can omit this + processing for zones that don't contain RRs with * in labels, + or can omit this processing entirely if * never appears in + local authoritative data. + + Inverse query processing + + Name servers that support inverse queries can support these + operations through exhaustive searches of their databases, but + this becomes impractical as the size of the database increases. + An alternative approach is to invert the database according to the + search key. + + For name servers that support multiple zones and a large amount of + data, the recommended approach is separate inversions for each + + + +Mockapetris [Page 37] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + zone. When a particular zone is changed during a refresh, only + its inversions need to be redone. + + Support for transfer of this type of inversion may be included in + future versions of the domain system, but is not supported in this + version. + + Completion query processing + + Completion query processing shares many of the same problems in + data structure design as are found in inverse queries, but is + different due to the expected high rate of use of top level labels + (ie., ARPA, CSNET). A name server that wishes to be efficient in + its use of memory may well choose to invert only occurrences of + ARPA, etc. that are below the top level, and use a search for the + rare case that top level labels are used to constrain a + completion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 38] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +NAME SERVER MAINTENANCE + + Introduction + + Name servers perform maintenance operations on their databases to + insure that the data they distribute is accurate and timely. The + amount and complexity of the maintenance operations that a name + server must perform are related to the size, change rate, and + complexity of the database that the name server manages. + + Maintenance operations are fundamentally different for + authoritative and non-authoritative data. A name server actively + attempts to insure the accuracy and timeliness of authoritative + data by refreshing the data from master copies. Non-authoritative + data is merely purged when its time-to-live expires; the name + server does not attempt to refresh it. + + Although the refreshing scheme is fairly simple to implement, it + is somewhat less powerful than schemes used in other distributed + database systems. In particular, an update to the master does not + immediately update copies, and should be viewed as gradually + percolating though the distributed database. This is adequate for + the vast majority of applications. In situations where timliness + is critical, the master name server can prohibit caching of copies + or assign short timeouts to copies. + + Conceptual model of maintenance operations + + The vast majority of information in the domain system is derived + from master files scattered among hosts that implement name + servers; some name servers will have no master files, other name + servers will have one or more master files. Each master file + contains the master data for a single zone of authority rather + than data for the whole domain name space. The administrator of a + particular zone controls that zone by updating its master file. + + Master files and zone copies from remote servers may include RRs + that are outside of the zone of authority when a NS record + delegates authority to a domain name that is a descendant of the + domain name at which authority is delegated. These forward + references are a problem because there is no reasonable method to + guarantee that the A type records for the delegatee are available + unless they can somehow be attached to the NS records. + + For example, suppose the ARPA zone delegates authority at + MIT.ARPA, and states that the name server is on AI.MIT.ARPA. If a + resolver gets the NS record but not the A type record for + AI.MIT.ARPA, it might try to ask the MIT name server for the + address of AI.MIT.ARPA. + + +Mockapetris [Page 39] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + The solution is to allow type A records that are outside of the + zone of authority to be copied with the zone. While these records + won't be found in a search for the A type record itself, they can + be protected by the zone refreshing system, and will be passed + back whenever the name server passes back a referral to the + corresponding NS record. If a query is received for the A record, + the name server will pass back a referral to the name server with + the A record in the additional section, rather than answer + section. + + The only exception to the use of master files is a small amount of + data stored in boot files. Boot file data is used by name servers + to provide enough resource records to allow zones to be imported + from foreign servers (e.g. the address of the server), and to + establish the name and address of root servers. Boot file records + establish the initial contents of the cache tree, and hence can be + overridden by later loads of authoritative data. + + The data in a master file first becomes available to users of the + domain name system when it is loaded by the corresponding name + server. By definition, data from a master file is authoritative. + + Other name servers which wish to be authoritative for a particular + zone do so by transferring a copy of the zone from the name server + which holds the master copy using a virtual circuit. These copies + include parameters which specify the conditions under which the + data in the copy is authoritative. In the most common case, the + conditions specify a refresh interval and policies to be followed + when the refresh operation cannot be performed. + + A name server may acquire multiple zones from different name + servers and master files, but the name server must maintain each + zone separately from others and from non-authoritative data. + + When the refresh interval for a particular zone copy expires, the + name server holding the copy must consult the name server that + holds the master copy. If the data in the zone has not changed, + the master name server instructs the copy name server to reset the + refresh interval. If the data has changed, the master passes a + new copy of the zone and its associated conditions to the copy + name server. Following either of these transactions, the copy + name server begins a new refresh interval. + + Copy name servers must also deal with error conditions under which + they are unable to communicate with the name server that holds the + master copy of a particular zone. The policies that a copy name + server uses are determined by other parameters in the conditions + distributed with every copy. The conditions include a retry + interval and a maximum holding time. When a copy name server is + + +Mockapetris [Page 40] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + unable to establish communications with a master or is unable to + complete the refresh transaction, it must retry the refresh + operation at the rate specified by the retry interval. This retry + interval will usually be substantially shorter than the refresh + interval. Retries continue until the maximum holding time is + reached. At that time the copy name server must assume that its + copy of the data for the zone in question is no longer + authoritative. + + Queries must be processed while maintenance operations are in + progress because a zone transfer can take a long time. However, + to avoid problems caused by access to partial databases, the + maintenance operations create new copies of data rather than + directly modifying the old copies. When the new copy is complete, + the maintenance process locks out queries for a short time using + the main lock, and switches pointers to replace the old data with + the new. After the pointers are swapped, the maintenance process + unlocks the main lock and reclaims the storage used by the old + copy. + + Name server data structures and top level logic + + The name server must multiplex its attention between multiple + activities. For example, a name server should be able to answer + queries while it is also performing refresh activities for a + particular zone. While it is possible to design a name server + that devotes a separate process to each query and refresh activity + in progress, the model described in this memo is based on the + assumption that there is a single process performing all + maintenance operations, and one or more processes devoted to + handling queries. The model also assumes the existence of shared + memory for several control structures, the domain database, locks, + etc. + + The model name server uses the following files and shared data + structures: + + 1. A configuration file that describes the master and boot + files which the name server should load and the zones that + the name server should attempt to load from foreign name + servers. This file establishes the initial contents of the + status table. + + 2. Domain data files that contain master and boot data to be + loaded. + + 3. A status table that is derived from the configuration file. + Each entry in this table describes a source of data. Each + entry has a zone number. The zone number is zero for + + +Mockapetris [Page 41] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + non-authoritative sources; authoritative sources are + assigned separate non-zero numbers. + + 4. The shared database that holds the domain data. This + database is assumed to be organized in some sort of tree + structure paralleling the domain name space, with a list of + resource records attached to each node and leaf in the tree. + The elements of the resource record list need not contain + the exact data present in the corresponding output format, + but must contain data sufficient to create the output + format; for example, these records need not contain the + domain name that is associated with the resource because + that name can be derived from the tree structure. Each + resource record also internal data that the name server uses + to organize its data. + + 5. Inversion data structures that allow the name server to + process inverse queries and completion queries. Although + many structures could be used, the implementation described + in this memo supposes that there is one array for every + inversion that the name server can handle. Each array + contains a list of pointers to resource records such that + the order of the inverted quantities is sorted. + + 6. The main and cache queue locks + + 7. The cache queue + + The maintenance process begins by loading the status table from + the configuration file. It then periodically checks each entry, + to see if its refresh interval has elapsed. If not, it goes on to + the next entry. If so, it performs different operations depending + on the entry: + + If the entry is for zone 0, or the cache tree, the maintenance + process checks to see if additions or deletions are required. + Additions are acquired from the cache queue using the cache + queue lock. Deletions are detected using TTL checks. If any + changes are required, the maintenance process recalculates + inversion data structures and then alters the cache tree under + the protection of the main lock. Whenever the maintenance + process modifies the cache tree, it resets the refresh interval + to the minimum of the contained TTLs and the desired time + interval for cache additions. + + If the entry is not zone 0, and the entry refers to a local + file, the maintenance process checks to see if the file has + been modified since its last load. If so the file is reloaded + using the procedures specified under "Name server file + + +Mockapetris [Page 42] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + loading". The refresh interval is reset to that specified in + the SOA record if the file is a master file. + + If the entry is for a remote master file, the maintenance + process checks for a new version using the procedure described + in "Names server remote zone transfer". + + Name server file loading + + Master files are kept in text form for ease of editing by system + maintainers. These files are not exchanged by name servers; name + servers use the standard message format when transferring zones. + + Organizations that want to have a domain, but do not want to run a + name server, can use these files to supply a domain definition to + another organization that will run a name server for them. For + example, if organization X wants a domain but not a name server, + it can find another organization, Y, that has a name server and is + willing to provide service for X. Organization X defines domain X + via the master file format and ships a copy of the master file to + organization Y via mail, FTP, or some other method. A system + administrator at Y configures Y's name server to read in X's file + and hence support the X domain. X can maintain the master file + using a text editor and send new versions to Y for installation. + + These files have a simple line-oriented format, with one RR per + line. Fields are separated by any combination of blanks and tab + characters. Tabs are treated the same as spaces; in the following + discussion the term "blank" means either a tab or a blank. A line + can be either blank (and ignored), a RR, or a $INCLUDE line. + + If a RR line starts with a domain name, that domain name is used + to specify the location in the domain space for the record, i.e. + the owner. If a RR line starts with a blank, it is loaded into + the location specified by the most recent location specifier. + + The location specifiers are assumed to be relative to some origin + that is provided by the user of a file unless the location + specifier contains the root label. This provides a convenient + shorthand notation, and can also be used to prevent errors in + master files from propagating into other zones. This feature is + particularly useful for master files imported from other sites. + + An include line begins with $INCLUDE, starting at the first line + position, and is followed by a local file name and an optional + offset modifier. The filename follows the appropriate local + conventions. The offset is one or more labels that are added to + the offset in use for the file that contained the $INCLUDE. If + the offset is omitted, the included file is loaded using the + + +Mockapetris [Page 43] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + offset of the file that contained the $INCLUDE command. For + example, a file being loaded at offset ARPA might contain the + following lines: + + $INCLUDE <subsys>isi.data ISI + $INCLUDE <subsys>addresses.data + + The first line would be interpreted to direct loading of the file + <subsys>isi.data at offset ISI.ARPA. The second line would be + interpreted as a request to load data at offset ARPA. + + Note that $INCLUDE commands do not cause data to be loaded into a + different zone or tree; they are simply ways to allow data for a + given zone to be organized in separate files. For example, + mailbox data might be kept separately from host data using this + mechanism. + + Resource records are entered as a sequence of fields corresponding + to the owner name, TTL, CLASS, TYPE and RDATA components. (Note + that this order is different from the order used in examples and + the order used in the actual RRs; the given order allows easier + parsing and defaulting.) + + The owner name is derived from the location specifier. + + The TTL field is optional, and is expressed as a decimal + number. If omitted TTL defaults to zero. + + The CLASS field is also optional; if omitted the CLASS defaults + to the most recent value of the CLASS field in a previous RR. + + The RDATA fields depend on the CLASS and TYPE of the RR. In + general, the fields that make up RDATA are expressed as decimal + numbers or as domain names. Some exceptions exist, and are + documented in the RDATA definitions in Appendicies 2 and 3 of + this memo. + + Because CLASS and TYPE fields don't contain any common + identifiers, and because CLASS and TYPE fields are never decimal + numbers, the parse is always unique. + + Because these files are text files several special encodings are + necessary to allow arbitrary data to be loaded. In particular: + + . A free standing dot is used to refer to the current domain + name. + + @ A free standing @ is used to denote the current origin. + + + +Mockapetris [Page 44] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + .. Two free standing dots represent the null domain name of + the root. + + \X where X is any character other than a digit (0-9), is used + to quote that character so that its special meaning does + not apply. For example, "\." can be used to place a dot + character in a label. + + \DDD where each D is a digit is the octet corresponding to the + decimal number described by DDD. The resulting octet is + assumed to be text and is not checked for special meaning. + + ( ) Parentheses are used to group data that crosses a line + boundary. In effect, line terminations are not recognized + within parentheses. + + ; Semicolon is used to start a comment; the remainder of the + line is ignored. + + Name server file loading example + + A name server for F.ISI.ARPA , serving as an authority for the + ARPA and ISI.ARPA domains, might use a boot file and two master + files. The boot file initializes some non-authoritative data, and + would be loaded without an origin: + + .. 9999999 IN NS B.ISI.ARPA + 9999999 CS NS UDEL.CSNET + B.ISI.ARPA 9999999 IN A 10.3.0.52 + UDEL.CSNET 9999999 CS A 302-555-0000 + + This file loads non-authoritative data which provides the + identities and addresses of root name servers. The first line + contains a NS RR which is loaded at the root; the second line + starts with a blank, and is loaded at the most recent location + specifier, in this case the root; the third and fourth lines load + RRs at B.ISI.ARPA and UDEL.CSNET, respectively. The timeouts are + set to high values (9999999) to prevent this data from being + discarded due to timeout. + + The first master file loads authoritative data for the ARPA + domain. This file is designed to be loaded with an origin of + ARPA, which allows the location specifiers to omit the trailing + .ARPA labels. + + + + + + + +Mockapetris [Page 45] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + @ IN SOA F.ISI.ARPA Action.E.ISI.ARPA ( + 20 ; SERIAL + 3600 ; REFRESH + 600 ; RETRY + 3600000; EXPIRE + 60) ; MINIMUM + NS F.ISI.ARPA ; F.ISI.ARPA is a name server for ARPA + NS A.ISI.ARPA ; A.ISI.ARPA is a name server for ARPA + MIT NS AI.MIT.ARPA; delegation to MIT name server + ISI NS F.ISI.ARPA ; delegation to ISI name server + + UDEL MD UDEL.ARPA + A 10.0.0.96 + NBS MD NBS.ARPA + A 10.0.0.19 + DTI MD DTI.ARPA + A 10.0.0.12 + + AI.MIT A 10.2.0.6 + F.ISI A 10.2.0.52 + + The first group of lines contains the SOA record and its + parameters, and identifies name servers for this zone and for + delegated zones. The Action.E.ISI.ARPA field is a mailbox + specification for the responsible person for the zone, and is the + domain name encoding of the mail destination Action@E.ISI.ARPA. + The second group specifies data for domain names within this zone. + The last group has forward references for name server address + resolution for AI.MIT.ARPA and F.ISI.ARPA. This data is not + technically within the zone, and will only be used for additional + record resolution for NS records used in referrals. However, this + data is protected by the zone timeouts in the SOA, so it will + persist as long as the NS references persist. + + The second master file defines the ISI.ARPA environment, and is + loaded with an origin of ISI.ARPA: + + @ IN SOA F.ISI.ARPA Action\.ISI.E.ISI.ARPA ( + 20 ; SERIAL + 7200 ; REFRESH + 600 ; RETRY + 3600000; EXPIRE + 60) ; MINIMUM + NS F.ISI.ARPA ; F.ISI.ARPA is a name server + A A 10.1.0.32 + MD A.ISI.ARPA + MF F.ISI.ARPA + B A 10.3.0.52 + MD B.ISI.ARPA + + +Mockapetris [Page 46] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + MF F.ISI.ARPA + F A 10.2.0.52 + MD F.ISI.ARPA + MF A.ISI.ARPA + $INCLUDE <SUBSYS>ISI-MAILBOXES.TXT + + Where the file <SUBSYS>ISI-MAILBOXES.TXT is: + + MOE MB F.ISI.ARPA + LARRY MB A.ISI.ARPA + CURLEY MB B.ISI.ARPA + STOOGES MB B.ISI.ARPA + MG MOE.ISI.ARPA + MG LARRY.ISI.ARPA + MG CURLEY.ISI.ARPA + + Note the use of the \ character in the SOA RR to specify the + responsible person mailbox "Action.ISI@E.ISI.ARPA". + + Name server remote zone transfer + + When a name server needs to make an initial copy of a zone or test + to see if a existing zone copy should be refreshed, it begins by + attempting to open a virtual circuit to the foreign name server. + + If this open attempt fails, and this was an initial load attempt, + it schedules a retry and exits. If this was a refresh operation, + the name server tests the status table to see if the maximum + holding time derived from the SOA EXPIRE field has elapsed. If + not, the name server schedules a retry. If the maximum holding + time has expired, the name server invalidates the zone in the + status table, and scans all resource records tagged with this zone + number. For each record it decrements TTL fields by the length of + time since the data was last refreshed. If the new TTL value is + negative, the record is deleted. If the TTL value is still + positive, it moves the RR to the cache tree and schedules a retry. + + If the open attempt succeeds, the name server sends a query to the + foreign name server in which QTYPE=SOA, QCLASS is set according to + the status table information from the configuration file, and + QNAME is set to the domain name of the zone of interest. + + The foreign name server will return either a SOA record indicating + that it has the zone or an error. If an error is detected, the + virtual circuit is closed, and the failure is treated in the same + way as if the open attempt failed. + + If the SOA record is returned and this was a refresh, rather than + an initial load of the zone, the name server compares the SERIAL + + +Mockapetris [Page 47] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + field in the new SOA record with the SERIAL field in the SOA + record of the existing zone copy. If these values match, the zone + has not been updated since the last copy and hence there is no + reason to recopy the zone. In this case the name server resets + the times in the existing SOA record and closes the virtual + circuit to complete the operation. + + If this is initial load, or the SERIAL fields were different, the + name server requests a copy of the zone by sending the foreign + name server an AXFR query which specifies the zone by its QCLASS + and QNAME fields. + + When the foreign name server receives the AXFR request, it sends + each node from the zone to the requestor in a separate message. + It begins with the node that contains the SOA record, walks the + tree in breadth-first order, and completes the transfer by + resending the node containing the SOA record. + + Several error conditions are possible: + + If the AXFR request cannot be matched to a SOA, the foreign + name server will return a single message in response that does + not contain the AXFR request. (The normal SOA query preceding + the AXFR is designed to avoid this condition, but it is still + possible.) + + The foreign name server can detect an internal error or detect + some other condition (e.g. system going down, out of resources, + etc.) that forces the transfer to be aborted. If so, it sends + a message with the "Server failure" condition set. If the AXFR + can be immediately retried with some chance of success, it + leaves the virtual open; otherwise it initiates a close. + + If the foreign name server doesn't wish to perform the + operation for policy reasons (i.e. the system administrator + wishes to forbid zone copies), the foreign server returns a + "Refused" condition. + + The requestor receives these records and builds a new tree. This + tree is not yet in the status table, so its data are not used to + process queries. The old copy of the zone, if any, may be used to + satisfy request while the transfer is in progress. + + When the requestor receives the second copy of the SOA node, it + compares the SERIAL field in the first copy of the SOA against the + SERIAL field in the last copy of the SOA record. If these don't + match, the foreign server updated its zone while the transfer was + in progress. In this case the requestor repeats the AXFR request + to acquire the newer version. + + +Mockapetris [Page 48] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + If the AXFR transfer eventually succeeds, the name server closes + the virtual circuit and and creates new versions of inversion data + structures for this zone. When this operation is complete, the + name server acquires the main lock in write mode and then replaces + any old copy of the zone and inversion data structures with new + ones. The name server then releases the main lock, and can + reclaim the storage used by the old copy. + + If an error occurs during the AXFR transfer, the name server can + copy any partial information into its cache tree if it wishes, + although it will not normally do so if the zone transfer was a + refresh rather than an initial load. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 49] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +RESOLVER ALGORITHMS + + Operations + + Resolvers have a great deal of latitude in the semantics they + allow in user calls. For example, a resolver might support + different user calls that specify whether the returned information + must be from and authoritative name server or not. Resolvers are + also responsible for enforcement of any local restrictions on + access, etc. + + In any case, the resolver will transform the user query into a + number of shared database accesses and queries to remote name + servers. When a user requests a resource associated with a + particular domain name, the resolver will execute the following + steps: + + 1. The resolver first checks the local shared database, if any, + for the desired information. If found, it checks the + applicable timeout. If the timeout check succeeds, the + information is used to satisfy the user request. If not, the + resolver goes to step 2. + + 2. In this step, the resolver consults the shared database for the + name server that most closely matches the domain name in the + user query. Multiple redundant name servers may be found. The + resolver goes to step 3. + + 3. In this step the resolver chooses one of the available name + servers and sends off a query. If the query fails, it tries + another name server. If all fail, an error indication is + returned to the user. If a reply is received the resolver adds + the returned RRs to its database and goes to step 4. + + 4. In this step, the resolver interprets the reply. If the reply + contains the desired information, the resolver returns the + information to the user. The the reply indicates that the + domain name in the user query doesn't exist, then the resolver + returns an error to the user. If the reply contains a + transient name server failure, the resolver can either wait and + retry the query or go back to step 3 and try a different name + server. If the reply doesn't contain the desired information, + but does contain a pointer to a closer name server, the + resolver returns to step 2, where the closer name servers will + be queried. + + Several modifications to this algorithm are possible. A resolver + may not support a local cache and instead only cache information + during the course of a single user request, discarding it upon + + +Mockapetris [Page 50] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + completion. The resolver may also find that a datagram reply was + truncated, and open a virtual circuit so that the complete reply + can be recovered. + + Inverse and completion queries must be treated in an + environment-sensitive manner, because the domain system doesn't + provide a method for guaranteeing that it can locate the correct + information. The typical choice will be to configure a resolver + to use a particular set of known name servers for inverse queries. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 51] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +DOMAIN SUPPORT FOR MAIL + + Introduction + + Mail service is a particularly sensitive issue for users of the + domain system because of the lack of a consistent system for + naming mailboxes and even hosts, and the need to support continued + operation of existing services. This section discusses an + evolutionary approach for adding consistent domain name support + for mail. + + The crucial issue is deciding on the types of binding to be + supported. Most mail systems specify a mail destination with a + two part construct such as X@Y. The left hand side, X, is an + string, often a user or account, and Y is a string, often a host. + This section refers to the part on the left, i.e. X, as the local + part, and refers to the part on the right, i.e. Y, as the global + part. + + Most existing mail systems route mail based on the global part; a + mailer with mail to deliver to X@Y will decide on the host to be + contacted using only Y. We refer to this type of binding as + "agent binding". + + For example, mail addressed to Mockapetris@ISIF is delivered to + host USC-ISIF (USC-ISIF is the official name for the host + specified by nickname ISIF). + + More sophisticated mail systems use both the local and global + parts, i.e. both X and Y to determine which host should receive + the mail. These more sophisticated systems usually separate the + binding of the destination to the host from the actual delivery. + This allows the global part to be a generic name rather than + constraining it to a single host. We refer to this type of + binding as "mailbox binding". + + For example, mail addressed to Mockapetris@ISI might be bound + to host F.ISI.ARPA, and subsequently delivered to that host, + while mail for Cohen@ISI might be bound to host B.ISI.ARPA. + + The domain support for mail consists of two levels of support, + corresponding to these two binding models. + + The first level, agent binding, is compatible with existing + ARPA Internet mail procedures and uses maps a global part onto + one or more hosts that will accept the mail. This type of + binding uses the MAILA QTYPE. + + The second level, mailbox binding, offers extended services + + +Mockapetris [Page 52] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + that map a local part and a global part onto one or more sets + of data via the MAILB QTYPE. The sets of data include hosts + that will accept the mail, mailing list members (mail groups), + and mailboxes for reporting errors or requests to change a mail + group. + + The domain system encodes the global part of a mail destination as + a domain name and uses dots in the global part to separate labels + in the encoded domain name. The domain system encodes the local + part of a mail destination as a single label, and any dots in this + part are simply copied into the label. The domain system forms a + complete mail destination as the local label concatenated to the + domain string for the global part. We call this a mailbox. + + For example, the mailbox Mockapetris@F.ISI.ARPA has a global + domain name of three labels, F.ISI.ARPA. The domain name + encoding for the whole mailbox is Mockapetris.F.ISI.ARPA. The + mailbox Mockapetris.cad@F.ISI.ARPA has the same domain name for + the global part and a 4 label domain name for the mailbox of + Mockapetris\.cad.F.ISI.ARPA (the \ is not stored in the label, + its merely used to denote the "quoted" dot). + + It is anticipated that the Internet system will adopt agent + binding as part of the initial implementation of the domain + system, and that mailbox binding will eventually become the + preferred style as organizations convert their mail systems to the + new style. To facilitate this approach, the domain information + for these two binding styles is organized to allow a requestor to + determine which types of support are available, and the + information is kept in two disjoint classes. + + Agent binding + + In agent binding, a mail system uses the global part of the mail + destination as a domain name, with dots denoting structure. The + domain name is resolved using a MAILA query which return MF and MD + RRs to specify the domain name of the appropriate host to receive + the mail. MD (Mail delivery) RRs specify hosts that are expected + to have the mailbox in question; MF (Mail forwarding) RRs specify + hosts that are expected to be intermediaries willing to accept the + mail for eventual forwarding. The hosts are hints, rather than + definite answers, since the query is made without the full mail + destination specification. + + For example, mail for MOCKAPETRIS@F.ISI.ARPA would result in a + query with QTYPE=MAILA and QNAME=F.ISI.ARPA, which might return + two RRs: + + + + +Mockapetris [Page 53] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + F.ISI.ARPA MD IN F.ISI.ARPA + F.ISI.ARPA MF IN A.ISI.ARPA + + The mailer would interpret these to mean that the mail agent on + F.ISI.ARPA should be able to deliver the mail directly, but that + A.ISI.ARPA is willing to accept the mail for probable forwarding. + + Using this system, an organization could implement a system that + uses organization names for global parts, rather than the usual + host names, but all mail for the organization would be routed the + same, regardless of its local part. Hence and organization with + many hosts would expect to see many forwarding operations. + + Mailbox binding + + In mailbox binding, the mailer uses the entire mail destination + specification to construct a domain name. The encoded domain name + for the mailbox is used as the QNAME field in a QTYPE=MAILB query. + + Several outcomes are possible for this query: + + 1. The query can return a name error indicating that the mailbox + does not exist as a domain name. + + In the long term this would indicate that the specified mailbox + doesn't exist. However, until the use of mailbox binding is + universal, this error condition should be interpreted to mean + that the organization identified by the global part does not + support mailbox binding. The appropriate procedure is to + revert to agent binding at this point. + + 2. The query can return a Mail Rename (MR) RR. + + The MR RR carries new mailbox specification in its RDATA field. + The mailer should replace the old mailbox with the new one and + retry the operation. + + 3. The query can return a MB RR. + + The MB RR carries a domain name for a host in its RDATA field. + The mailer should deliver the message to that host via whatever + protocol is applicable, e.g. SMTP. + + 4. The query can return one or more Mail Group (MG) RRs. + + This condition means that the mailbox was actually a mailing + list or mail group, rather than a single mailbox. Each MG RR + has a RDATA field that identifies a mailbox that is a member of + + + +Mockapetris [Page 54] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + the group. The mailer should deliver a copy of the message to + each member. + + 5. The query can return a MB RR as well as one or more MG RRs. + + This condition means the the mailbox was actually a mailing + list. The mailer can either deliver the message to the host + specified by the MB RR, which will in turn do the delivery to + all members, or the mailer can use the MG RRs to do the + expansion itself. + + In any of these cases, the response may include a Mail Information + (MINFO) RR. This RR is usually associated with a mail group, but + is legal with a MB. The MINFO RR identifies two mailboxes. One + of these identifies a responsible person for the original mailbox + name. This mailbox should be used for requests to be added to a + mail group, etc. The second mailbox name in the MINFO RR + identifies a mailbox that should receive error messages for mail + failures. This is particularly appropriate for mailing lists when + errors in member names should be reported to a person other than + the one who sends a message to the list. New fields may be added + to this RR in the future. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 55] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +Appendix 1 - Domain Name Syntax Specification + + The preferred syntax of domain names is given by the following BNF + rules. Adherence to this syntax will result in fewer problems with + many applications that use domain names (e.g., mail, TELNET). Note + that some applications use domain names containing binary information + and hence do not follow this syntax. + + <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 + + 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. + + For example, the following strings identify hosts in the ARPA + Internet: + + F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA + + + + + + + + + + + + +Mockapetris [Page 56] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +Appendix 2 - Field formats and encodings + + +-----------------------------------------------+ + | | + | ***** WARNING ***** | + | | + | The following formats are preliminary and | + | are included for purposes of explanation only.| + | In particular, new RR types will be added, | + | and the size, position, and encoding of | + | fields are subject to change. | + | | + +-----------------------------------------------+ + + TYPE values + + TYPE fields are used in resource records. Note that these types + are not the same as the QTYPE fields used in queries, although the + functions are often similar. + + TYPE value meaning + + A 1 a host address + + NS 2 an authoritative name server + + MD 3 a mail destination + + MF 4 a mail forwarder + + CNAME 5 the canonical name for an alias + + SOA 6 marks the start of a zone of authority + + MB 7 a mailbox domain name + + MG 8 a mail group member + + MR 9 a mail rename domain name + + NULL 10 a null RR + + WKS 11 a well known service description + + PTR 12 a domain name pointer + + HINFO 13 host information + + MINFO 14 mailbox or mail list information + + +Mockapetris [Page 57] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + QTYPE values + + QTYPE fields appear in the question part of a query. They include + the values of TYPE with the following additions: + + AXFR 252 A request for a transfer of an entire zone of authority + + MAILB 253 A request for mailbox-related records (MB, MG or MR) + + MAILA 254 A request for mail agent RRs (MD and MF) + + * 255 A request for all records + + CLASS values + + CLASS fields appear in resource records + + CLASS value meaning + + IN 1 the ARPA Internet + + CS 2 the computer science network (CSNET) + + QCLASS values + + QCLASS fields appear in the question section of a query. They + include the values of CLASS with the following additions: + + * 255 any class + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 58] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + Standard resource record formats + + All RRs have the same top level format shown below: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + NAME - a compressed domain name to which this resource + record pertains. + + TYPE - two octets containing one of the RR type codes + defined in Appendix 2. This field specifies the + meaning of the data in the RDATA field. + + CLASS - two octets which specifies the class of the data in + the RDATA field. + + TTL - a 16 bit signed integer that specifies the time + interval that the resource record may be cached + before the source of the information should again be + consulted. Zero values are interpreted to mean that + the RR can only be used for the transaction in + progress, and should not be cached. For example, SOA + records are always distributed with a zero TTL to + prohibit caching. Zero values can also be used for + extremely volatile data. + + RDLENGTH- an unsigned 16 bit integer that specifies the length + in octets of the RDATA field. + + + +Mockapetris [Page 59] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + RDATA - a variable length string of octets that describes the + resource. The format of this information varies + according to the TYPE and CLASS of the resource + record. + + The format of the RDATA field is standard for all classes for the + RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO and + NULL. These formats are shown below together with the appropriate + additional section RR processing. + + CNAME RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / CNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + CNAME - A compressed domain name which specifies that the + domain name of the RR is an alias for a canonical + name specified by CNAME. + + CNAME records cause no additional section processing. The + RDATA section of a CNAME line in a master file is a standard + printed domain name. + + HINFO RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / CPU / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / OS / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + CPU - A character string which specifies the CPU type. The + character string is represented as a single octet + length followed by that number of characters. The + following standard strings are defined:. + + PDP-11/70 C/30 C/70 VAX-11/780 + H-316 H-516 DEC-2060 DEC-1090T + ALTO IBM-PC IBM-PC/XT PERQ + IBM-360/67 IBM-370/145 + + OS - A character string which specifies the operating system + type. The character string is represented as a single octet + + +Mockapetris [Page 60] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + length followed by that number of characters. The following + standard types are defined:. + + ASP AUGUST BKY CCP + DOS/360 ELF EPOS EXEC-8 + GCOS GPOS ITS INTERCOM + KRONOS MCP MOS MPX-RT + MULTICS MVT NOS NOS/BE + OS/MVS OS/MVT RIG RSX11 + RSX11M RT11 SCOPE SIGNAL + SINTRAN TENEX TOPS10 TOPS20 + TSS UNIX VM/370 VM/CMS + VMS WAITS + + HINFO records cause no additional section processing. + + HINFO records are used to acquire general information about a + host. The main use is for protocols such as FTP that can use + special procedures when talking between machines or operating + systems of the same type. + + MB RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MADNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + MADNAME - A compressed domain name which specifies a host which + has the specified mailbox. + + MB records cause additional section processing which looks up + an A type record corresponding to MADNAME. The RDATA section + of a MB line in a master file is a standard printed domain + name. + + MD RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MADNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + MADNAME - A compressed domain name which specifies a host which + + + +Mockapetris [Page 61] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + has a mail agent for the domain which should be able + to deliver mail for the domain. + + MD records cause additional section processing which looks up + an A type record corresponding to MADNAME. The RDATA section + of a MD line in a master file is a standard printed domain + name. + + MF RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MADNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + MADNAME - A compressed domain name which specifies a host which + has a mail agent for the domain which will accept + mail for forwarding to the domain. + + MF records cause additional section processing which looks up + an A type record corresponding to MADNAME. The RDATA section + of a MF line in a master file is a standard printed domain + name. + + MG RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MGMNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + MGMNAME - A compressed domain name which specifies a mailbox + which is a member of the mail group specified by the + domain name. + + MF records cause no additional section processing. The RDATA + section of a MF line in a master file is a standard printed + domain name. + + + + + + + + + +Mockapetris [Page 62] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + MINFO RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / RMAILBX / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / EMAILBX / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + RMAILBX - A compressed domain name which specifies a mailbox + which is responsible for the mailing list or mailbox. + If this domain name names the root, the owner of the + MINFO RR is responsible for itself. Note that many + existing mailing lists use a mailbox X-request for + the RMAILBX field of mailing list X, e.g. + Msgroup-request for Msgroup. This field provides a + more general mechanism. + + EMAILBX - A compressed domain name which specifies a mailbox + which is to receive error messages related to the + mailing list or mailbox specified by the owner of the + MINFO RR (similar to the ERRORS-TO: field which has + been proposed). If this domain name names the root, + errors should be returned to the sender of the + message. + + MINFO records cause no additional section processing. Although + these records can be associated with a simple mailbox, they are + usually used with a mailing list. The MINFO section of a MF + line in a master file is a standard printed domain name. + + MR RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / NEWNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + NEWNAME - A compressed domain name which specifies a mailbox + which is the proper rename of the specified mailbox. + + MR records cause no additional section processing. The RDATA + section of a MR line in a master file is a standard printed + domain name. + + + + +Mockapetris [Page 63] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + NULL RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / <anything> / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + Anything at all may be in the RDATA field so long as it is + 65535 octets or less. + + NULL records cause no additional section processing. NULL RRs + are not allowed in master files. + + NS RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / NSDNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + NSDNAME - A compressed domain name which specifies a host which + has a name server for the domain. + + NS records cause both the usual additional section processing + to locate a type A record, and a special search of the zone in + which they reside. The RDATA section of a NS line in a master + file is a standard printed domain name. + + PTR RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / PTRDNAME / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + PTRDNAME - A compressed domain name which points to some + location in the domain name space. + + PTR records cause no additional section processing. These RRs + are used in special domains to point to some other location in + the domain space. These records are simple data, and don't + imply any special processing similar to that performed by + CNAME, which identifies aliases. Appendix 3 discusses the use + of these records in the ARPA Internet address domain. + + + + +Mockapetris [Page 64] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + SOA RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / RNAME / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | SERIAL | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | REFRESH | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RETRY | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | EXPIRE | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | MINIMUM | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + MNAME - The domain name of the name server that was the + original source of data for this zone. + + RNAME - A domain name which specifies the mailbox of the + person responsible for this zone. + + SERIAL - The unsigned 16 bit version number of the of the + original copy of the zone. This value wraps and + should be compared using sequence space arithmetic. + + REFRESH - The unsigned 32 bit time interval before the zone + should be refreshed. + + RETRY - The unsigned 32 bit time interval that should elapse + before a failed refresh should be retried. + + EXPIRE - A 32 bit time value that specifies the upper limit on + the time interval that can elapse before the zone is + no longer authoritative. + + MINIMUM - The unsigned 16 bit minimum TTL field that should be + exported with any RR from this zone (other than the + SOA itself). + + SOA records cause no additional section processing. The RDATA + + +Mockapetris [Page 65] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + section of a SOA line in a master file is a standard printed + domain name for MNAME, a standard X@Y mailbox specification for + RNAME, and decimal numbers for the remaining parameters. + + All times are in units of seconds. + + Most of these fields are pertinent only for name server + maintenance operations. However, MINIMUM is used in all query + operations that retrieve RRs from a zone. Whenever a RR is + sent in a response to a query, the TTL field is set to the + maximum of the TTL field from the RR and the MINIMUM field in + the appropriate SOA. Thus MINIMUM is a lower bound on the TTL + field for all RRs in a zone. RRs in a zone are never discarded + due to timeout unless the whole zone is deleted. This prevents + partial copies of zones. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 66] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +Appendix 3 - Internet specific field formats and operations + + Message transport + + The Internet supports name server access using TCP [10] on server + port 53 (decimal) as well as datagram access using UDP [11] on UDP + port 53 (decimal). Messages sent over TCP virtual circuits are + preceded by an unsigned 16 bit length field which describes the + length of the message, excluding the length field itself. + + +-----------------------------------------------+ + | | + | ***** WARNING ***** | + | | + | The following formats are preliminary and | + | are included for purposes of explanation only.| + | In particular, new RR types will be added, | + | and the size, position, and encoding of | + | fields are subject to change. | + | | + +-----------------------------------------------+ + + A RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ADDRESS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + ADDRESS - A 32 bit ARPA internet address + + Hosts that have multiple ARPA Internet addresses will have + multiple A records. + + A records cause no additional section processing. The RDATA + section of an A line in a master file is an Internet address + expressed as four decimal numbers separated by dots without any + imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6"). + + + + + + + + + + + + +Mockapetris [Page 67] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + WKS RDATA format + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ADDRESS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | PROTOCOL | | + +--+--+--+--+--+--+--+--+ | + | | + / <BIT MAP> / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + ADDRESS - An 32 bit ARPA Internet address + + PROTOCOL - An 8 bit IP protocol number + + <BIT MAP> - A variable length bit map. The bit map must be a + multiple of 8 bits long. + + The WKS record is used to describe the well known services + supported by a particular protocol on a particular internet + address. The PROTOCOL field specifies an IP protocol number, and + the bit map has one bit per port of the specified protocol. The + first bit corresponds to port 0, the second to port 1, etc. If + less than 256 bits are present, the remainder are assumed to be + zero. The appropriate values for ports and protocols are + specified in [13]. + + For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP + port 25 (SMTP). If this bit is set, a SMTP server should be + listening on TCP port 25; if zero, SMTP service is not supported + on the specified address. + + The anticipated use of WKS RRs is to provide availability + information for servers for TCP and UDP. If a server supports + both TCP and UDP, or has multiple Internet addresses, then + multiple WKS RRs are used. + + WKS RRs cause no additional section processing. The RDATA section + of a WKS record consists of a decimal protocol number followed by + mnemonic identifiers which specify bits to be set to 1. + + IN-ADDR special domain + + The ARPA internet uses a special domain to support gateway + location and ARPA Internet address to host mapping. The intent of + this domain is to allow queries to locate all gateways on a + + +Mockapetris [Page 68] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + particular network in the ARPA Internet, and also to provide a + guaranteed method to perform host address to host name mapping. + + Note that both of these services are similar to functions that + could be performed by inverse queries; the difference is that this + part of the domain name space is structured according to address, + and hence can guarantee that the appropriate data can be located + without an exhaustive search of the domain space. It is + anticipated that the special tree will be used by ARPA Internet + resolvers for all gateway location services, but that address to + name resolution will be performed by first trying the inverse + query on the local name server database followed by a query in the + special space if the inverse query fails. + + The domain is a top level domain called IN-ADDR whose substructure + follows the ARPA Internet addressing structure. + + Domain names in the IN-ADDR domain are defined to have up to four + labels in addition to the IN-ADDR label. Each label is a + character string which expresses a decimal value in the range + 0-255 (with leading zeros omitted except in the case of a zero + octet which is represented by a single zero). These labels + correspond to the 4 octets of an ARPA Internet address. + + Host addresses are represented by domain names that have all four + labels specified. Thus data for ARPA Internet address 10.2.0.52 + is located at domain name 52.0.2.10.IN-ADDR. The reversal, though + awkward to read, allows zones to follow the natural grouping of + hosts within networks. For example, 10.IN-ADDR can be a zone + containing data for the ARPANET, while 26.IN-ADDR can be a + separate zone for MILNET. Address nodes are used to hold pointers + to primary host names in the normal domain space. + + Network addresses correspond to some of the non-terminal nodes in + the IN-ADDR tree, since ARPA Internet network numbers are either + 1, 2, or 3 octets. Network nodes are used to hold pointers to + primary host names (which happen to be gateways) in the normal + domain space. Since a gateway is, by definition, on more than one + network, it will typically have two or more network nodes that + point at the gateway. Gateways will also have host level pointers + at their fully qualified addresses. + + Both the gateway pointers at network nodes and the normal host + pointers at full address nodes use the PTR RR to point back to the + primary domain names of the corresponding hosts. + + For example, part of the IN-ADDR domain will contain information + about the ISI to MILNET and MIT gateways, and hosts F.ISI.ARPA and + MULTICS.MIT.ARPA. Assuming that ISI gateway has addresses + + +Mockapetris [Page 69] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + 10.2.0.22 and 26.0.0.103, and a name MILNET-GW.ISI.ARPA, and the + MIT gateway has addresses 10.0.0.77 and 18.10.0.4 and a name + GW.MIT.ARPA, the domain database would contain: + + 10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA + 10.IN-ADDR PTR IN GW.MIT.ARPA + 18.IN-ADDR PTR IN GW.MIT.ARPA + 26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA + 22.0.2.10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA + 103.0.0.26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA + 77.0.0.10.IN-ADDR PTR IN GW.MIT.ARPA + 4.0.10.18.IN-ADDR PTR IN GW.MIT.ARPA + 52.0.2.10.IN-ADDR PTR IN F.ISI.ARPA + 6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA + + Thus a program which wanted to locate gateways on net 10 would + originate a query of the form QTYPE=PTR, QCLASS=IN, + QNAME=10.IN-ADDR. It would receive two RRs in response: + + 10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA + 10.IN-ADDR PTR IN GW.MIT.ARPA + + The program could then originate QTYPE=A, QCLASS=IN queries for + MILNET-GW.ISI.ARPA and GW.MIT.ARPA to discover the ARPA Internet + addresses of these gateways. + + A resolver which wanted to find the host name corresponding to + ARPA Internet host address 10.0.0.6 might first try an inverse + query on the local name server, but find that this information + wasn't available. It could then try a query of the form + QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR, and would receive: + + 6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA + + Several cautions apply to the use of these services: + + Since the IN-ADDR special domain and the normal domain for a + particular host or gateway will be in different zones, the + possibility exists that that the data may be inconsistent. + + Gateways will often have two names in separate domains, only + one of which can be primary. + + Systems that use the domain database to initialize their + routing tables must start with enough gateway information to + guarantee that they can access the appropriate name server. + + The gateway data only reflects the existence of a gateway in a + + + +Mockapetris [Page 70] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + + manner equivalent to the current HOSTS.TXT file. It doesn't + replace the dynamic availability information from GGP or EGP. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mockapetris [Page 71] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +REFERENCES and BIBLIOGRAPHY + + [1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet + Host Table Specification", RFC 810, Network Information Center, + SRI International, March 1982. + + [2] J. Postel, "Computer Mail Meeting Notes", RFC 805, + USC/Information Sciences Institute, February 1982. + + [3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet + User Applications", RFC 819, Network Information Center, SRI + International, August 1982. + + [4] Z. Su, "A Distributed System for Internet Name Service", + RFC 830, Network Information Center, SRI International, + October 1982. + + [5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network + Information Center, SRI International, March 1982. + + [6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name + Server", Computer Networks, vol 6, nr 3, July 1982. + + [7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information + Center, SRI International, December 1977. + + [8] J. Postel, "Internet Name Server", IEN 116, USC/Information + Sciences Institute, August 1979. + + [9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", + RFC 811, Network Information Center, SRI International, + March 1982. + + [10] J. Postel, "Transmission Control Protocol", RFC 793, + USC/Information Sciences Institute, September 1981. + + [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information + Sciences Institute, August 1980. + + [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821, + USC/Information Sciences Institute, August 1980. + + [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870, + USC/Information Sciences Institute, October 1983. + + [14] P. Mockapetris, "Domain names - Concepts and Facilities," + RFC 882, USC/Information Sciences Institute, November 1983. + + + + +Mockapetris [Page 72] + + +RFC 883 November 1983 + Domain Names - Implementation and Specification + + +INDEX + + * usage........................................................37, 57 + + A RDATA format.....................................................67 + + byte order..........................................................6 + + cache queue....................................................35, 42 + character case..................................................7, 31 + CLASS...........................................................9, 58 + completion.........................................................19 + compression........................................................31 + CNAME RR...........................................................60 + + header format......................................................26 + HINFO RR...........................................................60 + + include files......................................................43 + inverse queries....................................................17 + + mailbox names......................................................53 + master files.......................................................43 + MB RR..............................................................61 + MD RR..............................................................61 + message format.....................................................13 + MF RR..............................................................62 + MG RR..............................................................62 + MINFO RR...........................................................63 + MR RR..............................................................63 + + NULL RR............................................................64 + NS RR..............................................................64 + + PTR RR.........................................................64, 69 + + QCLASS.............................................................58 + QTYPE..............................................................57 + queries (standard).................................................15 + + recursive service..................................................24 + RR format..........................................................59 + + SOA RR.............................................................65 + Special domains....................................................68 + + TYPE...............................................................57 + + WKS type RR........................................................68 + + +Mockapetris [Page 73] diff --git a/Documentation/en/rfc/rfc912.txt b/Documentation/en/rfc/rfc912.txt new file mode 100644 index 00000000..3f148095 --- /dev/null +++ b/Documentation/en/rfc/rfc912.txt @@ -0,0 +1,171 @@ + + +Network Working Group Mike StJohns +Request for Comments: 912 TPSC + September 1984 + + Authentication Service + + +STATUS OF THIS MEMO + + This RFC suggests a proposed protocol for the ARPA-Internet + community, and requests discussion and suggestions for improvements. + Distribution of this memo is unlimited. + +INTRODUCTION + + The Authentication Server provides a means to determine the identity + of a user of a particular TCP connection. Given a TCP port number + pair, it returns a character string which identifies the owner of + that connection on the server's system. Suggested uses include + automatic identification and verification of a user during an FTP + session, additional verification of a TAC dial up user, and access + verification for a generalized network file server. + +OVERVIEW + + This is a connection based application on TCP. A server listens for + TCP connections on TCP port 113 (decimal). Once a connection is + established, the server reads one line of data which specifies the + connection of interest. If it exists, the system dependent user + identifier of the connection of interest is sent out the connection. + The service closes the connection after sending the user identifier. + +RESTRICTIONS + + Queries are permitted only for fully specified connections. The + local/foreign host pair used to fully specify the connection are + taken from the query connection. This means a user on Host A may + only query the server on Host B about connections between A and B. + +QUERY/RESPONSE FORMAT + + The server accepts simple text query requests of the form + + <local-port>, <foreign-port> + + where <local-port>, is the TCP port (decimal) on the target (server) + system, and <foreign-port> is the TCP port (decimal) on the source + (user) system. + + For example: + + + +StJohns [Page 1] + + + +RFC 912 September 1984 +Authentication Service + + + 23, 6191 + + The response is of the form + + <local-port>, <foreign-port> : <response-type> : <additional-info> + + where <local-port>, <foreign-port> are the same pair as the query, + <response-type> is a keyword identifying the type of response, and + <additional info> is context dependent. + + For example: + + 23, 6191 : USERID : StJohns + +RESPONSE TYPES + + A response can be one of two types: + + USERID + + In this case, <additional-info> is the printable representation of + the user identifier of the owner of the connection. The format of + the returned user identifier is completely system dependent. + + ERROR + + For some reason the owner of the TCP port could not be determined, + <additional-info> tells why. The following are suggested values + of <additional-info> and their meanings. + + INVALID PORT + + Either the local or foreign port was improperly specified. + + NO USER + + The connection specified by the port pair is not currently + in use. + + UNKNOWN ERROR + + Can't determine connection owner; reason unknown. + Other values may be specified as necessary. + + + + + + +StJohns [Page 2] + + + +RFC 912 September 1984 +Authentication Service + + +CAVEATS + + Unfortunately, the trustworthiness of the various host systems that + might implement an authentication server will vary quite a bit. It + is up to the various applications that will use the server to + determine the amount of trust they will place in the returned + information. It may be appropriate in some cases restrict the use of + the server to within a locally controlled subnet. + +APPLICATIONS + + 1) Automatic user authentication for FTP. + + 2) Verification for privileged network operations. For example, + having the server start or stop special purpose servers. + +DISCLAIMER + + I designed this protocol to allow me to eliminate the bother of + having to identify myself before continuing an FTP session. + + Since I started work on it, other applications appeared. I have + tried to consider all of our applications while still making this as + general as possible. + + + + + + + + + + + + + + + + + + + + + + + + + +StJohns [Page 3] + diff --git a/Documentation/en/rfc/rfc931.txt b/Documentation/en/rfc/rfc931.txt new file mode 100644 index 00000000..190adc88 --- /dev/null +++ b/Documentation/en/rfc/rfc931.txt @@ -0,0 +1,278 @@ +Network Working Group Mike StJohns +Request for Comments: 931 TPSC +Supersedes: RFC 912 January 1985 + + Authentication Server + + +STATUS OF THIS MEMO + + This RFC suggests a proposed protocol for the ARPA-Internet + community, and requests discussion and suggestions for improvements. + This is the second draft of this proposal (superseding RFC 912) and + incorporates a more formal description of the syntax for the request + and response dialog, as well as a change to specify the type of user + identification returned. Distribution of this memo is unlimited. + +INTRODUCTION + + The Authentication Server Protocol provides a means to determine the + identity of a user of a particular TCP connection. Given a TCP port + number pair, it returns a character string which identifies the owner + of that connection on the server's system. Suggested uses include + automatic identification and verification of a user during an FTP + session, additional verification of a TAC dial up user, and access + verification for a generalized network file server. + +OVERVIEW + + This is a connection based application on TCP. A server listens for + TCP connections on TCP port 113 (decimal). Once a connection is + established, the server reads one line of data which specifies the + connection of interest. If it exists, the system dependent user + identifier of the connection of interest is sent out the connection. + The service closes the connection after sending the user identifier. + +RESTRICTIONS + + Queries are permitted only for fully specified connections. The + local/foreign host pair used to fully specify the connection are + taken from the query connection. This means a user on Host A may + only query the server on Host B about connections between A and B. + + + + + + + + + + + + +StJohns [Page 1] + + +RFC 931 January 1985 +Authentication Server + + +QUERY/RESPONSE FORMAT + + The server accepts simple text query requests of the form + + <local-port>, <foreign-port> + + where <local-port> is the TCP port (decimal) on the target (server) + system, and <foreign-port> is the TCP port (decimal) on the source + (user) system. + + For example: + + 23, 6191 + + The response is of the form + + <local-port>, <foreign-port> : <response-type> : <additional-info> + + where <local-port>,<foreign-port> are the same pair as the query, + <response-type> is a keyword identifying the type of response, and + <additional info> is context dependent. + + For example: + + 23, 6191 : USERID : MULTICS : StJohns.DODCSC.a + 23, 6193 : USERID : TAC : MCSJ-MITMUL + 23, 6195 : ERROR : NO-USER + +RESPONSE TYPES + + A response can be one of two types: + + USERID + + In this case, <additional-info> is a string consisting of an + operating system name, followed by a ":", followed by user + identification string in a format peculiar to the operating system + indicated. Permitted operating system names are specified in + RFC-923, "Assigned Numbers" or its successors. The only other + names permitted are "TAC" to specify a BBN Terminal Access + Controller, and "OTHER" to specify any other operating system not + yet registered with the NIC. + + + + + + + +StJohns [Page 2] + + +RFC 931 January 1985 +Authentication Server + + + ERROR + + For some reason the owner of <TCP-port> could not be determined, + <additional-info> tells why. The following are suggested values + of <additional-info> and their meanings. + + INVALID-PORT + + Either the local or foreign port was improperly specified. + + NO-USER + + The connection specified by the port pair is not currently in + use. + + UNKNOWN-ERROR + + Can't determine connection owner; reason unknown. Other values + may be specified as necessary. + +CAVEATS + + Unfortunately, the trustworthiness of the various host systems that + might implement an authentication server will vary quite a bit. It + is up to the various applications that will use the server to + determine the amount of trust they will place in the returned + information. It may be appropriate in some cases restrict the use of + the server to within a locally controlled subnet. + +APPLICATIONS + + 1) Automatic user authentication for FTP + + A user-FTP may send a USER command with no argument to the + server-FTP to request automatic authentication. The server-FTP + will reply with a 230 (user logged in) if it can use the + authentication. It will reply with a 530 (not logged in) if it + cannot authenticate the user. It will reply with a 500 or 501 + (syntax or parameter problem) if it does not implement automatic + authentication. Please note that no change is needed to currently + implemented servers to handle the request for authentication; they + will reject it normally as a parameter problem. This is a + suggested implementation for experimental use only. + + 2) Verification for privileged network operations. For example, + having the server start or stop special purpose servers. + + + +StJohns [Page 3] + + +RFC 931 January 1985 +Authentication Server + + + 3) Elimination of "double login" for TAC and other TELNET users. + + This will be implemented as a TELNET option. + +FORMAL SYNTAX + + <request> ::= <port-pair> <CR> <LF> + + <port-pair> ::= <integer-number> "," <integer-number> + + <reply> ::= <reply-text> <CR> <LF> + + <reply-text> ::= <error-reply> | <auth-reply> + + <error-reply> ::= <port-pair> ":" ERROR ":" <error-type> + + <auth-reply> ::= <port-pair> ":" USERID ":" <opsys> ":" <user-id> + + <error-type> ::= INVALID-PORT | NO-USER | UNKNOWN-ERROR + + <opsys> ::= TAC | OTHER | MULTICS | UNIX ...etc. + (See "Assigned Numbers") + + Notes on Syntax: + + 1) White space (blanks and tab characters) between tokens is not + important and may be ignored. + + 2) White space, the token separator character (":"), and the port + pair separator character (",") must be quoted if used within a + token. The quote character is a back-slash, ASCII 92 (decimal) + ("\"). For example, a quoted colon is "\:". The back-slash must + also be quoted if its needed to represent itself ("\\"). + +Notes on User Identification Format: + + The user identifier returned by the server should be the standard one + for the system. For example, the standard Multics identifier + consists of a PERSONID followed by a ".", followed by a PROJECTID, + followed by a ".", followed by an INSTANCE TAG of one character. An + instance tag of "a" identifies an interactive user, and instance tag + of "m" identifies an absentee job (batch job) user, and an instance + tag of "z" identifies a daemon (background) user. + + Each set of operating system users must come to a consensus as to + + + + +StJohns [Page 4] + + +RFC 931 January 1985 +Authentication Server + + + what the OFFICIAL user identification for their systems will be. + Until they register this information, they must use the "OTHER" tag + to specify their user identification. + +Notes on User Identification Translation: + + Once you have a user identifier from a remote system, you must then + have a way of translating it into an identifier that meaningful on + the local system. The following is a sketchy outline of table driven + scheme for doing this. + + The table consists of four columns, the first three are used to match + against, the fourth is the result. + + USERID Opsys Address Result + MCSJ-MITMUL TAC 26.*.*.* StJohns + * MULTICS 192.5.42.* = + * OTHER 10.0.0.42 anonymous + MSJ ITS 10.3.0.44 StJohns + + The above table is a sample one for a Multics system on MILNET at the + Pentagon. When an authentication is returned, the particular + application using the userid simply looks for the first match in the + table. Notice the second line. It says that any authentication + coming from a Multics system on Net 192.5.42 is accepted in the same + format. + + Obviously, various users will have to be registered to use this + facility, but the registration can be done at the same time the use + receives his login identity from the system. + + + + + + + + + + + + + + + + + + + +StJohns [Page 5]
\ No newline at end of file diff --git a/Documentation/en/rfc/rfc973.txt b/Documentation/en/rfc/rfc973.txt new file mode 100644 index 00000000..17776f31 --- /dev/null +++ b/Documentation/en/rfc/rfc973.txt @@ -0,0 +1,570 @@ + + +Network Working Group Paul Mockapetris +Request for Comments: 973 ISI + January 1986 + + Domain System Changes and Observations + + +STATUS OF THIS MEMO + + This RFC documents updates to Domain Name System specifications + RFC-882 [1] and RFC-883 [2], suggests some operational guidelines, + and discusses some experiences and problem areas in the present + system. Distribution of this memo is unlimited. + + This document includes all changes to the Domain System through + January, 1986. Change notices and additional discussion are + available online in file [USC-ISIB.ARPA]<DOMAIN>DOMAIN.CHANGES. + +OVERVIEW + + This memo is divided into four major sections: + + "UPDATES" which discusses changes to the domain specification + which are in widespread use and should be regarded as being part + of the specification. + + "OPERATION GUIDELINES" which suggests rules-of-thumb for using the + domain system and configuring your database which are appropriate + in most cases, but which may have rare exceptions. + + "EXPERIENCES" which discusses some unusual situations and common + bugs which are encountered in the present system, and should be + helpful in problem determination and tuning. + + "PROBLEM AREAS" which discusses some shortcomings in the present + system which may be addressed in future versions. + +UPDATES + + This section discusses changes to the specification which are final, + and should be incorporated in all domain system software. + + TTL timeouts too small + + The 16 bit TTL field in RRs could not represent a large enough + time interval. The 16 bit field, using seconds for units, has a + maximum period of approximately 18 hours. + + All time values, including all TTLs and the MINIMUM field of the + SOA RR, are expanded to 32 bits. + + + +Mockapetris [Page 1] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + CLASS changes + + Class 2, originally reserved for CSNET, is obsolete. Class 3 has + been assigned for use by CHAOS. + + CNAME usage + + The specification allows CNAME RRs to exist with other RRs at the + same node. This creates difficulties since the other RRs stored + with the CNAME at the alias might not agree with the RRs stored at + the primary name. + + If a node has a CNAME RR, it should have no other RRs. + + * semantics + + The use of * to represent a single label wildcard, along with the + possibility of multiple * labels, led to difficult server + implementations and complicated search algorithms. There were + also questions regarding whether a * based specification could + refer to names that were not contained in the zone which had the * + specification. + + While we might want the "inheritability" for some cases, it leads + to implementation difficulties. The first of these is that + whenever we can't find a RR in a particular zone, we have to + search all parent zones to look for a suitable * result. + (Alternatively we could develop some automatic method for insuring + consistency or insist on careful duplication of inherited data.) + We also must deal with conflicts, i.e. what if a subdomain doesn't + want to inherit defaults. + + Given these difficulties, the solution is to insist that + delegation of authority cancels the * defaults. This is quite + simple to implement; all you need to do is to check for delegation + before looking for * RRs. + + A second difficulty is the restriction that * match a single + label. Thus if a name server is looking for RRs for the name + A.B.C.D.E.F, it must check for *.B.C.D.E.F, *.*.C.D.E.F, + *.*.*.D.E.F, etc. This check must also be careful of zone + boundaries and multiplies the effort to handle a query. + + The solution adopted is to allow a single * label in the leftmost + part of a name stored in a zone, and to allow this label to match + + + + +Mockapetris [Page 2] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + any number of unknown labels or a single known label in the query + name. However, the * match is only taken for parts of the tree + which are neither delegated or explicitly represented. + + The algorithm for performing the search in a tree structured + database has the following steps: + + 1) Descend in the tree matching labels from right to left. If a + delegation is found return that; if the specified node is found + go to step 2, if the tree ends go to step 3. + + 2) Look for RRs that answer the query. If any are found, return + them as the answer. If none are found, look for answers in a * + node which has the same name as the query name except for the + rightmost label. (e.g. if you can't find an answer at F.ISI.ARPA, + look for a RR at *.ISI.ARPA) + + 3) The search for a desired name has failed; look for a node whose + name is * plus however much matched. Look for answers there. + (e.g. If you are looking for X.Y.ISI.ARPA and the tree ends at + ISI.ARPA, look at *.ISI.ARPA. The same thing holds for + Y.ISI.ARPA, or any name of the form <anything>.Z.ISI.ARPA, where Z + is a label that doesn't exist under ISI.ARPA) + + Note that this interpretation means that * matches names that are + not in the tree, no matter how much of the tree is missing, and + also matches one level's worth of known tree. + + AA semantics + + When a name server is responding to a query for a particular name + and finds a CNAME, it may optionally restart the search at the + canonical name. If the server uses the restart feature, the + answer section of the returned query contains one (or more) + CNAMEs, possibly followed by answers for the primary name. The + canonical name will usually be in the same zone as the alias, but + this need not be the case. If the server is authoritative for one + of the names but not both, it is not clear whether the AA bit + should be set. + + The solution adopted is to make the AA refer to the original query + name. + + + + + + + +Mockapetris [Page 3] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + Master file format + + The present specification uses a somewhat awkward method for + representing domain names in master files. + + The change adopted is that all domain names in this file will be + represented as either absolute or relative. An absolute domain + name ends with a ".". A free standing "." is assumed to refer to + the root. A relative domain name doesn't end with a dot, and is + assumed to be relative to the current origin. + + SERIAL number size + + If the master file changes rapidly, an infrequently updated copy + may miss the wrapping of the sequence number in the SERIAL field + of the SOA, or misinterpret the number of updates that have taken + place. + + The SERIAL field is increased to 32 bits. + + MD and MF replaced by MX + + The original specification uses MD and MF RRs for mail agent + binding. The problem is that a mailer making a MAILA query, which + asks for both types, can't use the cache since the cache might + have the results for a MD or MF query. That is, the presence of + one of these types of information in the cache doesn't imply + anything about the other type. The result was that either mailers + would have to always consult authoritative servers or try to use + partial information; neither of these is really acceptable. + + The change is to replace MD and MF with a new type of RR called MX + which conveys similar information in a single RR type. MX has + been assigned a type code of 15 decimal. The format of the MX RR + is a 16 bit preference value followed by a domain name. A node + may have multiple MX RRs, and multiple MX RRs with the same + preference value are allowed at a given node. + + + + + + + + + + + + +Mockapetris [Page 4] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + The preference values denote the relative preference that the mail + destination places on the mail agents, with lower values being + "better". A mailer is expected to at least try the mail agent(s) + with the lowest preference value. The significance of particular + preference values, the units of preference, and the linearity of + preference values are not defined but left open; preference values + should only be used to establish relative rankings. + + For example, the current RRs: + + MAIL-ORG MD HOST1 + MD HOST2 + MF HOST3 + + might be replaced by: + + MAIL-ORG MX 10 HOST1 + MX 10 HOST2 + MX 20 HOST3 + + The values 10 and 20 have no significance other than 10<20. A + detailed discussion of the use of MX is the subject of [3]. + + Zone transfer + + The original specification states that zone transfers take place + in breadth first order. The intent was to make the transfer + easier for the accepting name server to handle. This now doesn't + work out to be very helpful, and is a severe pain for implementers + using various hashing algorithms. The new rule is that you can + transmit the records in any order you choose, so long as the SOA + node of the zone is transmitted first and last, and no other + duplication occurs. + + IN-ADDR domain renamed + + The name of the IN-ADDR domain is now IN-ADDR.ARPA. This change + was made because many felt that the use of a top-level name was + inappropriate to network-specific information. + + + + + + + + + + +Mockapetris [Page 5] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + +OPERATIONAL GUIDELINES + + This section suggests rules-of-thumb for using the domain system and + configuring your database which are appropriate in most cases, but + which may have rare exceptions. + + Zone delegation + + When a domain wishes to become independent from its parent, the + RRs which mark the delegation in the parent and child zones should + be carefully synchronized to minimize the possibility that + resolvers become confused. + + For example, suppose that we wish to create a new zone called + ISI.EDU under an existing EDU zone, and that the servers for the + child zone are X.ISI.EDU and Y.GOV. + + We might add the following to the parent zone: + + ISI.EDU. 10000 NS X.ISI.EDU. + 10000 NS Y.GOV. + X.ISI.EDU. 10000 A <address of X.ISI.EDU.> + Y.GOV. 10000 A <address of Y.GOV.> + + and the following to the child zone: + + ISI.EDU. 10000 NS X.ISI.EDU. + 10000 NS Y.GOV. + 50000 SOA <SOA information> + X.ISI.EDU. 10000 A <address of X.ISI.EDU.> + Y.GOV. 10000 A <address of Y.GOV.> + + Note the following: + + In both cases, the A RR for Y.GOV is included, even though + Y.GOV isn't in the EDU or ISI.EDU domains. This RR isn't + authoritative, but is included to guarantee that the address of + Y.GOV is passed with delegations to it. Strictly speaking this + RR need not be in either zone, but its presence is recommended. + The X.ISI.EDU A RR is absolutely essential. The only time that + a server should use the glue RRs is when it is returning the NS + RRs and doesn't otherwise have the address of the server. For + example, if the parent server also was authoritative for GOV, + the glue RR would typically not be consulted. However, it is + still a good idea for it to be present, so that the zone is + self-sufficient. + + + +Mockapetris [Page 6] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + The child zone and the parent zone have identical NS RRs for + the ISI.EDU domain. This guarantees that no matter which + server is asked about the ISI.EDU domain, the same set of name + servers is returned. + + The child zone and the parent zone have A RRs for the name + servers in the NS RRs that delegate the ISI.EDU domain. This + guarantees that in addition to knowing the name servers for the + ISI.EDU domain, the addresses of the servers are known as well. + + The TTLs for the NS RRs that delegate the ISI.EDU domain and + the A RRs that represent the addresses of the name servers are + all the same. This guarantees that all of these RRs will + timeout simultaneously. In this example, the value 10000 has + no special significance, but the coincidence of the TTLs is + significant. + + These guidelines haven't changed any of the flexibility of the + system; the name of a name server and the domains it serves are + still independent. + + It might also be the case that the organization called ISI wanted + to take over management of the IN-ADDR domain for an internal + network, say 128.99.0.0. In this case, we would have additions to + the parent zone, say IN-ADDR.ARPA. + + We might add the following to the parent zone: + + 99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU. + 2000 NS XX.MIT.EDU. + Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.> + XX.MIT.EDU. 2000 A <address of XX.MIT.EDU.> + + and the following to the child zone: + + 99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU. + 2000 NS XX.MIT.EDU. + 5000 SOA <SOA information> + Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.> + XX.MIT.EDU. 2000 A <address of XX.MIT.EDU.> + + SOA serials + + The serial field of the SOA RR for a domain is supposed to be a + continuously increasing (mod 2**32) value which denotes the + + + + +Mockapetris [Page 7] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + version of the database. The idea is that you can tell that a + zone has changed by comparing serial numbers. When you change a + zone, you should increment the serial field of the SOA. + + All RRs with the same name, class, and type should have the same TTL. + + The logic here is that all of them will timeout simultaneously if + cached and hence the cache can be reliably used. + + Case consistency + + The domain system is supposed to preserve case, but be case + insensitive. However, it does nobody any good to put both RRs for + domain name xxx and XXX in the data base - It merely makes caching + ambiguous and decreases the efficiency of compression. This + consistency should also exist in the duplicate RRs that mark + delegation in the delegator and delegatee. For example, if you + ask the NIC to delegate UZOO.EDU to you, your database shouldn't + say uzoo.edu. + + Inappropriate use of aliases + + Canonical names are preferred to aliases in all RRs. One reason + is that the canonical names are closer to the information + associated with a name. A second is that canonical names are + unique, and aliases are not, and hence comparisons will work. + + In particular, the use of aliases in PTR RRs of the IN-ADDR domain + or in NS RRs that mark delegation is discouraged. + +EXPERIENCES + + This section discusses some unusual situations and common bugs which + are encountered in the present system, and should be helpful in + problem determination and tuning. Put differently, you should try to + make your code defend against these attacks, and you should expect to + be the object of complaint if you make these attacks. + + UDP addresses + + When you send a query to a host with multiple addresses, you might + expect the response to be from the address to which you sent the + query. This isn't the case with almost all UNIX implementations. + + + + + + +Mockapetris [Page 8] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + UDP checksums + + Many versions of UNIX generate incorrect UDP checksums, and most + ignore the checksum of incoming UDP datagrams. The typical + symptom is that your UNIX domain code works fine with other + UNIXes, but won't communicate with TOPS-20 or other systems. + (JEEVES, the TOPS-20 server used for 3 of the 4 root servers, + ignores datagrams with bad UDP checksums.) + + Making up data + + There are lots of name servers which return RRs for the root + servers with 99999999 or similar large values in the TTL. For + example, some return RRs that suggest that ISIF is a root server. + (It was months ago, but is no longer.) + + One of the main ideas of the domain system is that everybody can + get a chunk of the name space to manage as they choose. However, + you aren't supposed to lie about other parts of the name space. + Its OK to remember about other parts of the name space for caching + or other purposes, but you are supposed to follow the TTL rules. + + Now it may be that you put such records in your server or whatever + to ensure a server of last resort. That's fine. But if you + export these in answers to queries, you should be shot. These + entries get put in caches and never die. + + Suggested domain meta-rule: + + If you must lie, lie only to yourself. + +PROBLEM AREAS + + This section discusses some shortcomings in the present system which + may be addressed in future versions. + + Compression and types + + The present specification attempts to allow name servers and + resolvers to cache RRs for classes they don't "understand" as well + as to allow compression of domain names to minimize the size of + UDP datagrams. These two goals conflict in the present scheme + since the only way to expand a compressed name is to know that a + name is expected in that position. + + One technique for addressing this problem would be to preface + binary data (i.e. anything but a domain name) with a length octet. + + +Mockapetris [Page 9] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + The high order two bits of the length octet could contain either + 01 or 10, which are illegal for domain names. To compensate for + the additional bytes of data, we could omit the RDATA length field + and terminate each RR with a binary length field of zero. + + Caching non-existent names + + In the present system, a resolver has no standard method for + caching the result that a name does not exist, which seems to make + up a larger than expected percentage of queries. Some resolvers + create "does not exist" RRs with TTLs to guarantee against + repetitive queries for a non-existent name. + + A standard technique might be to return the SOA RR for the zone + (note that only authoritative servers can say name does not exist) + in the reply, and define the semantics to be that the requester is + free to assume that the name does not exist for a period equal to + the MINIMUM field of the SOA. + + Cache conflicts + + When a resolver is processing a reply, it may well decide to cache + all RRs found in sections of the reply. The problem is that the + resolver's cache may already contain a subset of these RRs, + probably with different TTLs. + + If the RRs are from authoritative data in the answer section, then + the cache RRs should be replaced. In other cases, the correct + strategy isn't completely clear. Note that if the authoritative + data's TTL has changed, then the resolver doesn't have enough + information to make the correct decision in all cases. + + This issue is tricky, and deserves thought. + +REFERENCES + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", + RFC-882, USC Information Sciences Institute, November 1983. + + [2] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC-883, USC Information Sciences Institute, + November 1983. + + [3] Partridge, C., "Mail Routing and the Domain System", RFC-974, + CSNET-CIC, BBN Laboratories, January 1986. + + + + +Mockapetris [Page 10] + |