From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4735.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc4735.txt (limited to 'doc/rfc/rfc4735.txt') diff --git a/doc/rfc/rfc4735.txt b/doc/rfc/rfc4735.txt new file mode 100644 index 0000000..c1808be --- /dev/null +++ b/doc/rfc/rfc4735.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group T. Taylor +Request for Comments: 4735 Nortel +Category: Standards Track October 2006 + + + Example Media Types for Use in Documentation + +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 (2006). + +Abstract + + This document is registration for the 'example' media type and + 'example' subtypes within the standards tree. The 'example/*' and + '*/example' media types are defined for documentation purposes only. + +1. Introduction + + From time to time, documents created by the IETF or by other + standards bodies show examples involving the use of media types, + where the actual media type is not relevant. It would be useful in + such cases to be able to show a media type whose illustrative role in + the example is clear. In the worst case, this can be useful to debug + implementations where the designer mistook the example for a + requirement of the protocol concerned. + + To meet this need, this document registers the following media types: + + o the 'example' media type; + + o the 'application/example', 'audio/example', 'image/example', + 'message/example', 'model/example', 'multipart/example', + 'text/example', and 'video/example' media subtypes. + + It is suggested that compilers of illustrative examples involving + media types in trees other than the standards tree might also + incorporate the string "example" into their hypothetical media types. + + + + + +Taylor Standards Track [Page 1] + +RFC 4735 Example Media Types October 2006 + + +2. 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]. + +3. Registration of the 'example' Media Type + + This section registers the 'example' media type in accordance with + the requirements of RFC 4288. + + Type name: example. + + Subtype name: any subtype may be used with the 'example' type. + However, IANA MUST NOT register any subtypes for the 'example' media + type. + + + Required parameters: as invented by the user. + + Optional parameters: as invented by the user. + + Encoding considerations: as invented by the user. + + Security considerations: The 'example' media type is defined for use + in documentation only. It MUST NOT be implemented. Its appearance + in real code could lead to unpredictable results and therefore open + up security holes. + + Interoperability considerations: Any attempt to negotiate or send the + 'example' media type is bound to lead to interoperability problems. + + Published specification: this document. + + Applications that use this media type: as invented by the user. + + Additional information: + Magic number(s): not applicable. + File extension(s): not applicable. + Macintosh file type code(s): not applicable. + + Person & email address to contact for further information: + ietf-types@iana.org. + + Intended usage: LIMITED USE. + + + + + + +Taylor Standards Track [Page 2] + +RFC 4735 Example Media Types October 2006 + + + Restrictions on usage: This type is intended only for use in + documents providing examples involving specification of some media + type, where the actual media type used is irrelevant. + + Author: Internet Engineering Task Force + + Change controller: Internet Engineering Task Force + +4. Registration of the 'application/example', 'audio/example', + 'image/example', 'message/example', 'model/example', + 'multipart/example', 'text/example', and 'video/example' Subtypes + + This section registers 'example' media subtypes in accordance with + the requirements of RFC 4288. + + Type name: 'application', 'audio', 'image', 'message', 'model', + 'multipart', 'text', and 'video'. + + Subtype name: 'example'. + + Required parameters: those required by the type and any others as + invented by the user. + + Optional parameters: those offered by the type and any others as + invented by the user. + + Encoding considerations: as invented by the user. + + Security considerations: The 'example' media subtypes are defined + for use in documentation only. They MUST NOT be implemented. Their + appearance in real code could lead to unpredictable results and + therefore open up security holes. + + Interoperability considerations: Any attempt to negotiate or send + one of these 'example' media subtypes is bound to lead to + interoperability problems. + + Published specification: this document. + + Applications that use this media type: as invented by the user. + + Additional information: + Magic number(s): not applicable. + File extension(s): not applicable. + Macintosh file type code(s): not applicable. + + Person & email address to contact for further information: + ietf-types@iana.org. + + + +Taylor Standards Track [Page 3] + +RFC 4735 Example Media Types October 2006 + + + Intended usage: LIMITED USE. + + Restrictions on usage: These subtypes are intended only for use in + documents providing examples involving specification of some subtype + of the given media type, where the actual subtype used is irrelevant. + + Author: Internet Engineering Task Force + + Change controller: Internet Engineering Task Force + +5. Security Considerations + + The 'example' media type and subtypes are defined for use in + documentation only. They MUST NOT be implemented. Any attempt to + implement them in real code could lead to unpredictable results and + thus potentially open up security holes. + +6. IANA Considerations + + This document specifies and registers the 'example' media type and + the 'application/example', 'audio/example', 'image/example', + 'message/example', 'model/example', 'multipart/example', + 'text/example', and 'video/example' subtypes. + +7. Acknowledgements + + This document sprang from Magnus Westerland's expression of need and + Rod Walsh's support and suggestions for generalization. Warnings + against implementation in the Security Considerations and + Interoperability Considerations sections and the 'multipart/example' + subtype were added at John Klensin's suggestion. Some editing + touchups and strengthening of the language in the Security + Considerations section were done in response to the Gen-ART reviewer, + Sharon Chisholm. + +8. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and + Registration Procedures", BCP 13, RFC 4288, December 2005. + + + + + + + + + +Taylor Standards Track [Page 4] + +RFC 4735 Example Media Types October 2006 + + +Author's Address + + Tom Taylor + Nortel + 1852 Lorraine Ave + Ottawa, Ontario K1H 6Z8 + Canada + + EMail: taylor@nortel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Taylor Standards Track [Page 5] + +RFC 4735 Example Media Types October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Taylor Standards Track [Page 6] + -- cgit v1.2.3