Difference between revisions of "RFC1311"
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
Network Working Group Internet Activities Board | Network Working Group Internet Activities Board | ||
Request for Comments: 1311 J. Postel, Editor | Request for Comments: 1311 J. Postel, Editor | ||
Line 9: | Line 4: | ||
Introduction to the STD Notes | Introduction to the STD Notes | ||
− | Status of this Memo | + | |
+ | '''Status of this Memo''' | ||
+ | |||
This RFC describes a new sub-series of RFCs, called STDs (Standards). | This RFC describes a new sub-series of RFCs, called STDs (Standards). | ||
Distribution of this memo is unlimited. | Distribution of this memo is unlimited. | ||
− | == | + | |
+ | == Introduction == | ||
+ | |||
The STDs are a subseries of notes within the RFC series that are the | The STDs are a subseries of notes within the RFC series that are the | ||
Internet standards. The intent is to identify clearly for the | Internet standards. The intent is to identify clearly for the | ||
Internet community those RFCs which document Internet standards. | Internet community those RFCs which document Internet standards. | ||
− | == | + | |
+ | == The Assignment of STD Numbers == | ||
+ | |||
There is a need to be very clear about which specifications have | There is a need to be very clear about which specifications have | ||
completed the full process of standardization in the Internet. To do | completed the full process of standardization in the Internet. To do | ||
Line 23: | Line 24: | ||
either Technical Specifications (TS) or Applicability Statements | either Technical Specifications (TS) or Applicability Statements | ||
(AS). | (AS). | ||
+ | |||
When a specification reaches the final stage of the standardization | When a specification reaches the final stage of the standardization | ||
process and the IAB has designated it a standard for the Internet, an | process and the IAB has designated it a standard for the Internet, an | ||
STD number will be assigned to that specification. | STD number will be assigned to that specification. | ||
+ | |||
The existing standards have been assigned STD numbers (see Appendix). | The existing standards have been assigned STD numbers (see Appendix). | ||
+ | |||
The standard for a particular protocol will always have the same STD | The standard for a particular protocol will always have the same STD | ||
number. | number. | ||
+ | |||
If at some future time a protocol is reworked and a new document | If at some future time a protocol is reworked and a new document | ||
is produced as the specification of that standard and the new | is produced as the specification of that standard and the new | ||
Line 34: | Line 39: | ||
Internet, then the new document will be labeled with the same STD | Internet, then the new document will be labeled with the same STD | ||
number (of course, that new document will have a new RFC number). | number (of course, that new document will have a new RFC number). | ||
+ | |||
Multiple Documents for One Standard: | Multiple Documents for One Standard: | ||
+ | |||
A STD number identifies a standard not a document. A document is | A STD number identifies a standard not a document. A document is | ||
identified by its RFC number. If the specification of a standard | identified by its RFC number. If the specification of a standard | ||
is spread over several documents they will each carry the same STD | is spread over several documents they will each carry the same STD | ||
number. | number. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
For example, the Domain Name System (DNS) is currently | For example, the Domain Name System (DNS) is currently | ||
specified by the combination of RFCs 1034 and 1035. Both of | specified by the combination of RFCs 1034 and 1035. Both of | ||
these documents are now labeled STD-13. | these documents are now labeled STD-13. | ||
+ | |||
To be completely clear the DNS "Concepts and Facilities" | To be completely clear the DNS "Concepts and Facilities" | ||
document can be referenced as "STD-13/RFC-1034". | document can be referenced as "STD-13/RFC-1034". | ||
+ | |||
In such cases, whenever possible, the set of documents defining a | In such cases, whenever possible, the set of documents defining a | ||
particular standard will cross reference each other. | particular standard will cross reference each other. | ||
+ | |||
One Standard or Multiple Standards: | One Standard or Multiple Standards: | ||
+ | |||
One difficult decision is deciding whether a set of documents | One difficult decision is deciding whether a set of documents | ||
describe one standard or multiple standards. In the Appendix, one | describe one standard or multiple standards. In the Appendix, one | ||
Line 60: | Line 65: | ||
which a family of specifications has multiple STD numbers; that is | which a family of specifications has multiple STD numbers; that is | ||
the Telnet Options. | the Telnet Options. | ||
+ | |||
The general rule is that a separate STD number is used when the | The general rule is that a separate STD number is used when the | ||
specification is logically separable. That is, logically | specification is logically separable. That is, logically | ||
Line 65: | Line 71: | ||
amendments and non-optional extensions use the same STD number as | amendments and non-optional extensions use the same STD number as | ||
the base specification. | the base specification. | ||
+ | |||
Multiple Versions or Editions of a Standard: | Multiple Versions or Editions of a Standard: | ||
+ | |||
It may occur that the documentation of a standard is updated or | It may occur that the documentation of a standard is updated or | ||
replaced with a new document. In such cases, the same STD number | replaced with a new document. In such cases, the same STD number | ||
Line 73: | Line 81: | ||
document will have a distinct RFC number (and of course a | document will have a distinct RFC number (and of course a | ||
different date). | different date). | ||
+ | |||
The complete identification of a specification and its document is | The complete identification of a specification and its document is | ||
the combination of the STD and the RFC. For example, "STD-13/RFC- | the combination of the STD and the RFC. For example, "STD-13/RFC- | ||
1035" completely identifies the current version of the second part of | 1035" completely identifies the current version of the second part of | ||
the Domain Name System specification. | the Domain Name System specification. | ||
+ | |||
To completely identify all of the DNS standard the citation would | To completely identify all of the DNS standard the citation would | ||
be "STD-13/RFC-1034/RFC-1035". | be "STD-13/RFC-1034/RFC-1035". | ||
+ | |||
One way to think of this is that an acronym (like TCP) refers to a | One way to think of this is that an acronym (like TCP) refers to a | ||
concept, which is called a protocol. An RFC number (like RFC-793) | concept, which is called a protocol. An RFC number (like RFC-793) | ||
Line 84: | Line 95: | ||
number (like STD-7) designates the status of the protocol. | number (like STD-7) designates the status of the protocol. | ||
+ | == Why an RFC Subseries ? == | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
There are several reasons why the STDs are part of the larger RFC | There are several reasons why the STDs are part of the larger RFC | ||
series of notes. | series of notes. | ||
+ | |||
The foremost reason is that the distribution mechanisms for RFCs are | The foremost reason is that the distribution mechanisms for RFCs are | ||
tried and true. Anyone who can get an RFC, can automatically get a | tried and true. Anyone who can get an RFC, can automatically get a | ||
STD. More important, anyone who knows of the RFC series can easily | STD. More important, anyone who knows of the RFC series can easily | ||
find the STDs. | find the STDs. | ||
+ | |||
Another reason for making STDs part of the RFC series is that the | Another reason for making STDs part of the RFC series is that the | ||
maintenance mechanisms for RFCs are already in place. It makes sense | maintenance mechanisms for RFCs are already in place. It makes sense | ||
to maintain similar documents is a similar way. | to maintain similar documents is a similar way. | ||
− | == | + | |
+ | == Format Rules == | ||
+ | |||
Since the STDs are a part of the RFC series, they must conform to | Since the STDs are a part of the RFC series, they must conform to | ||
"Request for Comments on Request for Comments: Instructions to RFC | "Request for Comments on Request for Comments: Instructions to RFC | ||
Authors" (RFC-1111) with respect to format. | Authors" (RFC-1111) with respect to format. | ||
− | === | + | |
+ | === Status Statement === | ||
+ | |||
Each STD RFC must include on its first page the "Status of this Memo" | Each STD RFC must include on its first page the "Status of this Memo" | ||
section which contains a paragraph describing the intention of the | section which contains a paragraph describing the intention of the | ||
RFC. This section is meant to convey the status approved by the | RFC. This section is meant to convey the status approved by the | ||
Internet Activities Board (IAB). | Internet Activities Board (IAB). | ||
− | === | + | |
+ | === Distribution Statement === | ||
+ | |||
Each STD RFC will also include a "distribution statement". As the | Each STD RFC will also include a "distribution statement". As the | ||
purpose of the STD series is to disseminate information, there is no | purpose of the STD series is to disseminate information, there is no | ||
reason for the distribution to be anything other than "unlimited". | reason for the distribution to be anything other than "unlimited". | ||
+ | |||
Typically, the distribution statement will simply be the sentence | Typically, the distribution statement will simply be the sentence | ||
"Distribution of this memo is unlimited." appended to the "Status of | "Distribution of this memo is unlimited." appended to the "Status of | ||
this Memo" section. | this Memo" section. | ||
+ | |||
=== Security Considerations === | === Security Considerations === | ||
+ | |||
All STD RFCs must contain a section that discusses the security | All STD RFCs must contain a section that discusses the security | ||
considerations of the procedures that are the main topic of the RFC. | considerations of the procedures that are the main topic of the RFC. | ||
− | === | + | |
+ | === Author's Address === | ||
+ | |||
Each STD RFC must have at the very end a section giving the author's | Each STD RFC must have at the very end a section giving the author's | ||
address, including the name and postal address, the telephone number, | address, including the name and postal address, the telephone number, | ||
and the Internet email address. | and the Internet email address. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
In the case of multiple authors, each of the authors will be listed. | In the case of multiple authors, each of the authors will be listed. | ||
Line 136: | Line 147: | ||
document will be listed and optionally the chair of the group may be | document will be listed and optionally the chair of the group may be | ||
listed. | listed. | ||
+ | |||
== The STD Publication == | == The STD Publication == | ||
+ | |||
New documents can only become STD RFCs through an action of the IAB. | New documents can only become STD RFCs through an action of the IAB. | ||
The publication of STDs will be performed by the RFC Editor. | The publication of STDs will be performed by the RFC Editor. | ||
− | == | + | |
+ | == STD Announcements == | ||
+ | |||
New STD RFCs are announced to the RFC distribution list maintained by | New STD RFCs are announced to the RFC distribution list maintained by | ||
the Network Information Center (NIC). Contact the NIC to be added or | the Network Information Center (NIC). Contact the NIC to be added or | ||
deleted from this mailing list by sending an email message to RFC- | deleted from this mailing list by sending an email message to RFC- | ||
− | == | + | |
+ | == Obtaining STDs == | ||
+ | |||
STD RFCs may be obtained in the same way as any RFC. | STD RFCs may be obtained in the same way as any RFC. | ||
+ | |||
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending | Details on obtaining RFCs via FTP or EMAIL may be obtained by sending | ||
an EMAIL message to "[email protected]" with the message body "help: | an EMAIL message to "[email protected]" with the message body "help: | ||
ways_to_get_rfcs". For example: | ways_to_get_rfcs". For example: | ||
+ | |||
Subject: getting rfcs | Subject: getting rfcs | ||
+ | |||
help: ways_to_get_rfcs | help: ways_to_get_rfcs | ||
+ | |||
The current standards are listed in the "IAB Official Protocol | The current standards are listed in the "IAB Official Protocol | ||
Standards" (which is STD-1), whose current edition is RFC-1280. | Standards" (which is STD-1), whose current edition is RFC-1280. | ||
+ | |||
Security Considerations | Security Considerations | ||
+ | |||
Security issues are not discussed in this memo. | Security issues are not discussed in this memo. | ||
+ | |||
Author's Address | Author's Address | ||
+ | |||
Jon Postel | Jon Postel | ||
USC/Information Sciences Institute | USC/Information Sciences Institute | ||
4676 Admiralty Way | 4676 Admiralty Way | ||
Marina del Rey, CA 90292 | Marina del Rey, CA 90292 | ||
+ | |||
Phone: 310-822-1511 | Phone: 310-822-1511 | ||
Fax: 310-823-6714 | Fax: 310-823-6714 | ||
+ | |||
Email: [email protected] | Email: [email protected] | ||
+ | APPENDIX -- The Grandfathered STDs | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Protocol Name Status RFC STD | Protocol Name Status RFC STD | ||
======== ===================================== ======= ===== ==== | ======== ===================================== ======= ===== ==== | ||
Line 207: | Line 229: | ||
DAYTIME Daytime Protocol Ele 867 25 | DAYTIME Daytime Protocol Ele 867 25 | ||
TIME Time Server Protocol Ele 868 26 | TIME Time Server Protocol Ele 868 26 | ||
+ | |||
Telnet Options Option Status RFC STD | Telnet Options Option Status RFC STD | ||
======== ================================= ====== ======= ===== ==== | ======== ================================= ====== ======= ===== ==== |
Latest revision as of 21:37, 29 September 2020
Network Working Group Internet Activities Board Request for Comments: 1311 J. Postel, Editor
March 1992
Introduction to the STD Notes
Status of this Memo
This RFC describes a new sub-series of RFCs, called STDs (Standards). Distribution of this memo is unlimited.
Contents
Introduction
The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards.
The Assignment of STD Numbers
There is a need to be very clear about which specifications have completed the full process of standardization in the Internet. To do this an STD number will be assigned to a specification when it reaches the Standard maturity level. Note that specifications may be either Technical Specifications (TS) or Applicability Statements (AS).
When a specification reaches the final stage of the standardization process and the IAB has designated it a standard for the Internet, an STD number will be assigned to that specification.
The existing standards have been assigned STD numbers (see Appendix).
The standard for a particular protocol will always have the same STD number.
If at some future time a protocol is reworked and a new document is produced as the specification of that standard and the new specification is designated by the IAB as a standard for the Internet, then the new document will be labeled with the same STD number (of course, that new document will have a new RFC number).
Multiple Documents for One Standard:
A STD number identifies a standard not a document. A document is identified by its RFC number. If the specification of a standard is spread over several documents they will each carry the same STD number.
For example, the Domain Name System (DNS) is currently specified by the combination of RFCs 1034 and 1035. Both of these documents are now labeled STD-13.
To be completely clear the DNS "Concepts and Facilities" document can be referenced as "STD-13/RFC-1034".
In such cases, whenever possible, the set of documents defining a particular standard will cross reference each other.
One Standard or Multiple Standards:
One difficult decision is deciding whether a set of documents describe one standard or multiple standards. In the Appendix, one can see that there are several cases in which one STD applies to multiple RFCs (see STDs 5, 13, and 20). There is one case in which a family of specifications has multiple STD numbers; that is the Telnet Options.
The general rule is that a separate STD number is used when the specification is logically separable. That is, logically separable options are assigned distinct STD numbers while amendments and non-optional extensions use the same STD number as the base specification.
Multiple Versions or Editions of a Standard:
It may occur that the documentation of a standard is updated or replaced with a new document. In such cases, the same STD number will be used to label the standard. No version numbers will be attached to STD numbers. There need be no confusion about having the up-to-date document about STD-9 since each version of the document will have a distinct RFC number (and of course a different date).
The complete identification of a specification and its document is the combination of the STD and the RFC. For example, "STD-13/RFC- 1035" completely identifies the current version of the second part of the Domain Name System specification.
To completely identify all of the DNS standard the citation would be "STD-13/RFC-1034/RFC-1035".
One way to think of this is that an acronym (like TCP) refers to a concept, which is called a protocol. An RFC number (like RFC-793) indicates the specific version of the protocol specification. An STD number (like STD-7) designates the status of the protocol.
Why an RFC Subseries ?
There are several reasons why the STDs are part of the larger RFC series of notes.
The foremost reason is that the distribution mechanisms for RFCs are tried and true. Anyone who can get an RFC, can automatically get a STD. More important, anyone who knows of the RFC series can easily find the STDs.
Another reason for making STDs part of the RFC series is that the maintenance mechanisms for RFCs are already in place. It makes sense to maintain similar documents is a similar way.
Format Rules
Since the STDs are a part of the RFC series, they must conform to "Request for Comments on Request for Comments: Instructions to RFC Authors" (RFC-1111) with respect to format.
Status Statement
Each STD RFC must include on its first page the "Status of this Memo" section which contains a paragraph describing the intention of the RFC. This section is meant to convey the status approved by the Internet Activities Board (IAB).
Distribution Statement
Each STD RFC will also include a "distribution statement". As the purpose of the STD series is to disseminate information, there is no reason for the distribution to be anything other than "unlimited".
Typically, the distribution statement will simply be the sentence "Distribution of this memo is unlimited." appended to the "Status of this Memo" section.
Security Considerations
All STD RFCs must contain a section that discusses the security considerations of the procedures that are the main topic of the RFC.
Author's Address
Each STD RFC must have at the very end a section giving the author's address, including the name and postal address, the telephone number, and the Internet email address.
In the case of multiple authors, each of the authors will be listed. In the case of a document produced by a group, the editor of the document will be listed and optionally the chair of the group may be listed.
The STD Publication
New documents can only become STD RFCs through an action of the IAB. The publication of STDs will be performed by the RFC Editor.
STD Announcements
New STD RFCs are announced to the RFC distribution list maintained by the Network Information Center (NIC). Contact the NIC to be added or deleted from this mailing list by sending an email message to RFC- [email protected].
Obtaining STDs
STD RFCs may be obtained in the same way as any RFC.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "[email protected]" with the message body "help: ways_to_get_rfcs". For example:
To: [email protected] Subject: getting rfcs
help: ways_to_get_rfcs
The current standards are listed in the "IAB Official Protocol Standards" (which is STD-1), whose current edition is RFC-1280.
Security Considerations
Security issues are not discussed in this memo.
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: [email protected]
APPENDIX -- The Grandfathered STDs
Protocol Name Status RFC STD
==== ===================================== ======= =====
IAB Official Protocol Standards Req 1280 1
Assigned Numbers Req 1060 2
Host Requirements Req 1122,1123 3
Gateway Requirements Req 1009 4
IP Internet Protocol Req 791 5
as amended by:
IP Subnet Extension Req 950 5
IP Broadcast Datagrams Req 919 5
IP Broadcast Datagrams with Subnets Req 922 5
ICMP Internet Control Message Protocol Req 792 5 IGMP Internet Group Multicast Protocol Rec 1112 5 UDP User Datagram Protocol Rec 768 6 TCP Transmission Control Protocol Rec 793 7 TELNET Telnet Protocol Rec 854,855 8 FTP File Transfer Protocol Rec 959 9 SMTP Simple Mail Transfer Protocol Rec 821 10 MAIL Format of Electronic Mail Messages Rec 822 11 CONTENT Content Type Header Field Rec 1049 11 NTP Network Time Protocol Rec 1119 12 DOMAIN Domain Name System Rec 1034,1035 13 DNS-MX Mail Routing and the Domain System Rec 974 14 SNMP Simple Network Management Protocol Rec 1157 15 SMI Structure of Management Information Rec 1155 16 MIB-II Management Information Base-II Rec 1213 17 EGP Exterior Gateway Protocol Rec 904 18 NETBIOS NetBIOS Service Protocols Ele 1001,1002 19 ECHO Echo Protocol Rec 862 20 DISCARD Discard Protocol Ele 863 21 CHARGEN Character Generator Protocol Ele 864 22 QUOTE Quote of the Day Protocol Ele 865 23 USERS Active Users Protocol Ele 866 24 DAYTIME Daytime Protocol Ele 867 25 TIME Time Server Protocol Ele 868 26
Telnet Options Option Status RFC STD
==== ================================= ====== ======= =====
TOPT-BIN Binary Transmission 0 Rec 856 27 TOPT-ECHO Echo 1 Rec 857 28 TOPT-SUPP Suppress Go Ahead 3 Rec 858 29 TOPT-STAT Status 5 Rec 859 30 TOPT-TIM Timing Mark 6 Rec 860 31 TOPT-EXTOP Extended-Options-List 255 Rec 861 32