doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc4027.txt b/doc/rfc/rfc4027.txt
new file mode 100644
index 0000000..84d3f65
--- /dev/null
+++ b/doc/rfc/rfc4027.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                       S. Josefsson
+Request for Comments: 4027                                    April 2005
+Category: Informational
+
+
+                     Domain Name System 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 (2005).
+
+Abstract
+
+   This document registers the media types application/dns and text/dns
+   in accordance with RFC 2048.  The application/dns media type is used
+   to identify data on the detached Domain Name System (DNS) format
+   described in RFC 2540.  The text/dns media type is used to identify
+   master files as described in RFC 1035.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  1
+   2.  MIME Type Registration of application/dns  . . . . . . . . . .  2
+   3.  MIME Type Registration of text/dns . . . . . . . . . . . . . .  3
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  4
+   A.  Disclaimer and License . . . . . . . . . . . . . . . . . . . .  5
+       Normative References . . . . . . . . . . . . . . . . . . . . .  5
+       Informative References . . . . . . . . . . . . . . . . . . . .  5
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  5
+       Full Copyright Statements. . . . . . . . . . . . . . . . . . .  6
+
+1.  Introduction
+
+   Domain Name System (DNS) [1] information is traditionally stored in
+   text files, so-called master files or zone files.  The format is
+   described in section 5 of RFC 1035 [2].
+
+   DNS data can also be stored in a "detached" format, intended for
+   archiving purposes, described in RFC 2540 [4].
+
+
+
+
+Josefsson                    Informational                      [Page 1]
+
+RFC 4027             Domain Name System Media Types           April 2005
+
+
+   This document registers MIME media types for the two data formats,
+   with the registration procedures described in RFC 2048 [3].
+
+2.  MIME Type Registration of application/dns
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type application/dns
+
+   MIME media type name: application
+
+   MIME subtype name: dns
+
+   Required parameters: None.
+
+   Optional parameters: None.
+
+   Encoding considerations: The data format is binary, and data must be
+   transfered unmodified.  Using encodings intended for textual parts is
+   not recommended.
+
+   Security considerations: This media type identifies content as being
+   detached DNS information, as documented in RFC 2540 [4].  This data
+   may be security relevant as per RFC 2538 [7] or may be secured
+   information as per RFC 2535 [6].  Securing the content further may be
+   done with standard techniques, such as OpenPGP [5] or CMS [9], but
+   this is outside of the scope here.  Further security assessments are
+   not available at this point.
+
+   Interoperability considerations: The encoding of detached DNS
+   information is, unlike textual master files, well defined.  No
+   further interoperability considerations are known.
+
+   Published specification: The format of data that could be tagged with
+   this media type is documented in RFC 2540 [4].
+
+   Applications that use this media type: DNS-related software,
+   including software storing and using certificates stored in DNS.
+
+   Additional information:
+     Magic number(s): None.
+     File extension(s): Unknown.
+     Macintosh File Type Code(s): Unknown.
+
+   Person & email address to contact for further information:
+
+   Simon Josefsson simon@josefsson.org
+
+   Intended usage: LIMITED USE
+
+
+
+Josefsson                    Informational                      [Page 2]
+
+RFC 4027             Domain Name System Media Types           April 2005
+
+
+   Author/change controller: simon@josefsson.org
+
+3.  MIME Type Registration of text/dns
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type text/dns
+
+   MIME media type name: text
+
+   MIME subtype name: dns
+
+   Required parameters: None.
+
+   Optional parameters: None.
+
+   Encoding considerations: The data is textual and should be transfered
+   in a line-oriented mode.  Text literals may contain CRLF within the
+   text.  Binary transport is possible between systems that use the same
+   end-of-line conventions.  Master files are in general ASCII, but
+   non-ASCII octet values may occur and are treated as opaque values by
+   DNS software (compare RFC 1035, section 5).  The master file format
+   permits encoding arbitrary octet values by using the "\DDD" encoding.
+   The use of "\DDD" encoding can be more reliable than transporting
+   non-ASCII through MIME transports, if data passes through a gateway
+   that re-encodes the character data.
+
+   Security considerations: This media type identifies content as being
+   DNS information in "master file" format, as documented in RFC 1035
+   [2].  The DNS data may be security relevant as per to RFC 2538 [7],
+   or may be secured information as per to RFC 2535 [6].  Securing the
+   content further may be done with standard techniques, such as OpenPGP
+   [5] or CMS [9], but this is outside of the scope here.  Further
+   security assessments are not available at this point.
+
+   Interoperability considerations: There are interoperability concerns
+   with master files, due to the widespread use of vendor-specific
+   extensions.  Non-ASCII comments within master files may have been
+   encoded in locally chosen character sets, which may be difficult to
+   transport interoperably.  Non-ASCII data in general can become
+   corrupted by re-encoding gateways.  To achieve interoperability, one
+   can use the master file format described in the specification and the
+   "\DDD" encoding for non-ASCII octets.  Further interoperability
+   issues with unrecognized RR types exist, which may be handled as
+   discussed in section 5 of RFC 3597 [8].
+
+   Published specification: The format of data that could be tagged with
+   this MIME type is documented in RFC 1035 [2].
+
+
+
+
+Josefsson                    Informational                      [Page 3]
+
+RFC 4027             Domain Name System Media Types           April 2005
+
+
+   Applications that use this media type: DNS-related software,
+   including software storing and using certificates stored in DNS.
+
+   Additional information:
+     Magic number(s): None.
+     File extension(s): 'soa' and 'zone' are known to be used.
+     Macintosh file type code(s): Unknown.
+
+   Person & email address to contact for further information:
+
+   Simon Josefsson simon@josefsson.org
+
+   Intended usage: LIMITED USE
+
+   Author/change controller: simon@josefsson.org
+
+4.  Security Considerations
+
+   Security considerations are discussed in the security considerations
+   clauses of the MIME registrations in sections 2 and 3.
+
+5.  IANA Considerations
+
+   The IANA has registered the MIME media types application/dns and
+   text/dns by using the registration templates in sections 2 and 3, as
+   per the procedure described in RFC 2048 [3].
+
+6.  Acknowledgements
+
+   Thanks to D. Eastlake for suggesting text/dns.  Thanks to Keith Moore
+   and Alfred Hoenes for reviewing this document.  The author
+   acknowledges the RSA Laboratories for supporting the work that led to
+   this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                    Informational                      [Page 4]
+
+RFC 4027             Domain Name System Media Types           April 2005
+
+
+A.  Disclaimer and License
+
+   Regarding this entire document or any portion of it, the author makes
+   no guarantees and is not responsible for any damage resulting from
+   its use.  The author grants irrevocable permission to anyone to use,
+   modify, and distribute it in any way that does not diminish the
+   rights of anyone else to use, modify, and distribute it, provided
+   that redistributed derivative works do not contain misleading author
+   or version information.  Derivative works need not be licensed under
+   similar terms.
+
+Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
+        Mail Extensions (MIME) Part Four: Registration Procedures", BCP
+        13, RFC 2048, November 1996.
+
+   [4]  Eastlake 3rd, D., "Detached Domain Name System (DNS)
+        Information", RFC 2540, March 1999.
+
+Informative References
+
+   [5]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
+        Message Format", RFC 2440, November 1998.
+
+   [6]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [7]  Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates in
+        the Domain Name System (DNS)", RFC 2538, March 1999.
+
+   [8]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+        Types", RFC 3597, September 2003.
+
+   [9]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
+        July 2004.
+
+Author's Address
+
+   Simon Josefsson
+
+   EMail: simon@josefsson.org
+
+
+
+Josefsson                    Informational                      [Page 5]
+
+RFC 4027             Domain Name System Media Types           April 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Josefsson                    Informational                      [Page 6]
+