draft-ietf-dnsext-rfc3597-bis-01.txt   draft-ietf-dnsext-rfc3597-bis-02.txt 
INTERNET-DRAFT A. Gustafsson INTERNET-DRAFT A. Gustafsson
Araneus Information Systems Oy Araneus Information Systems Oy
January 26, 2010 February 24, 2010
Intended status: Draft Standard Intended status: Draft Standard
Obsoletes: RFC3597 Obsoletes: RFC3597
Handling of Unknown DNS Resource Record (RR) Types Handling of Unknown DNS Resource Record (RR) Types
draft-ietf-dnsext-rfc3597-bis-01.txt draft-ietf-dnsext-rfc3597-bis-02.txt
Abstract Abstract
Extending the Domain Name System (DNS) with new Resource Record (RR) Extending the Domain Name System (DNS) with new Resource Record (RR)
types should not requires changes to name server software. This types should not requires changes to name server software. This
document specifies how new RR types are transparently handled by DNS document specifies how new RR types are transparently handled by DNS
software. software.
Status of this Memo Status of this Memo
skipping to change at page 4, line 13 skipping to change at page 4, line 13
type number, with no intervening whitespace. In the "class" field, type number, with no intervening whitespace. In the "class" field,
an unknown class is similarly represented as the word "CLASS" an unknown class is similarly represented as the word "CLASS"
immediately followed by the decimal class number. immediately followed by the decimal class number.
This convention allows types and classes to be distinguished from This convention allows types and classes to be distinguished from
each other and from TTL values, allowing the "[<TTL>] [<class>] each other and from TTL values, allowing the "[<TTL>] [<class>]
<type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
[RFC1035] section 5.1 to both be unambiguously parsed. [RFC1035] section 5.1 to both be unambiguously parsed.
The RDATA section of an RR of unknown type is represented as a The RDATA section of an RR of unknown type is represented as a
sequence of white space separated words as follows: sequence of items separated by any combination of tabs and spaces, as
follows:
The special token \# (a backslash immediately followed by a hash - The special token \# (a backslash immediately followed by a hash
sign), which identifies the RDATA as having the generic encoding sign), which identifies the RDATA as having the generic encoding
defined herein rather than a traditional type-specific encoding. defined herein rather than a traditional type-specific encoding.
An unsigned decimal integer specifying the RDATA length in octets. - An unsigned decimal integer specifying the RDATA length in
octets.
Zero or more words of hexadecimal data encoding the actual RDATA - Zero or more items of hexadecimal data encoding the actual RDATA
field, each containing an even number of hexadecimal digits. field, each item containing an even number of hexadecimal digits.
If the RDATA is of zero length, the text representation contains only If the RDATA is of zero length, the text representation contains only
the \# token and the single zero representing the length. the \# token and the single zero representing the length.
An implementation MAY also choose to represent some RRs of known type An implementation MAY also choose to represent some RRs of known type
using the above generic representations for the type, class and/or using the above generic representations for the type, class and/or
RDATA, which carries the benefit of making the resulting master file RDATA, which carries the benefit of making the resulting master file
portable to servers where these types are unknown. Using the generic portable to servers where these types are unknown. Using the generic
representation for the RDATA of an RR of known type can also be representation for the RDATA of an RR of known type can also be
useful in the case of an RR type where the text format varies useful in the case of an RR type where the text format varies
skipping to change at page 6, line 48 skipping to change at page 6, line 50
Andreas Gustafsson Andreas Gustafsson
Araneus Information Systems Oy Araneus Information Systems Oy
PL 110 PL 110
02321 Espoo 02321 Espoo
Finland Finland
Phone: +358 40 547 2099 Phone: +358 40 547 2099
EMail: gson@araneus.fi EMail: gson@araneus.fi
Appendix A. Change History Appendix A. Summary of Changes Since RFC3597
This section summarizes the major changes between RFC3597 and this
document. In addition to the changes listed below, there has also
been a number of editorial changes, such as updates to the text in
the Abstract and Introduction to better reflect the current state of
implementation, updates to boilerplate text, and minor
clarifications.
The reference to the DNS IANA Considerations BCP (BCP42) has been
changed from RFC2929 to the current version, RFC5395.
Downward references have been eliminated; specifically, the document
no longer refers to RFC2163 or RFC2535.
IP addresses in examples have been changed to use the 192.0.2.0/24
range per RFC3330.
The document no longer specifies changes to the DNSSEC canonical form
and ordering, as those changes have now been incorporated into the
base DNSSEC specification.
Appendix B. Detailed Change Log
[NOTE TO RFC EDITOR: PLEASE REMOVE THIS APPENDIX ON PUBLICATION.] [NOTE TO RFC EDITOR: PLEASE REMOVE THIS APPENDIX ON PUBLICATION.]
A.1. Changes between RFC3597 and -00 B.1. Changes between RFC3597 and -00
The reference to the DNS IANA Considerations BCP (BCP42) has been The reference to the DNS IANA Considerations BCP (BCP42) has been
changed from RFC2929 to the current version, RFC5395 changed from RFC2929 to the current version, RFC5395.
Downward references have been eliminated; specifically, the document Downward references have been eliminated; specifically, the document
no longer refers to RFC2163 or RFC2535. no longer refers to RFC2163 or RFC2535.
IP addresses in examples have been changed to the 192.0.2.0/24 range IP addresses in examples have been changed to use the 192.0.2.0/24
per RFC3330 range per RFC3330.
The draft no longer specifies changes to the DNSSEC canonical form The document no longer specifies changes to the DNSSEC canonical form
and ordering, as those changes have now been incorporated into the and ordering, as those changes have now been incorporated into the
base DNSSEC specification. base DNSSEC specification.
There has also been a number of editorial changes, such as updates to There has also been a number of editorial changes, such as updates to
the text in the Abstract and Introduction to better reflect the the text in the Abstract and Introduction to better reflect the
current state of implementation. current state of implementation.
A.2. Changes between -00 and -01 B.2. Changes between -00 and -01
Moved the Abstract to immediately following the document title. Moved the Abstract to immediately following the document title.
Updated boilerplate to the current version. Updated boilerplate to the current version.
In the Introduction, the text "Another development that has In the Introduction, the text "Another development that has
simplified the introduction of new DNS RR types is the adoption of a simplified the introduction of new DNS RR types is the adoption of a
simpler IANA allocation procedure for RR types" and a reference to simpler IANA allocation procedure for RR types" and a reference to
[RFC5395] were added. [RFC5395] were added.
skipping to change at line 338 skipping to change at page 8, line 30
sentence was rephrased. sentence was rephrased.
In section 4, the entries for SRV and NAPTR in the list of RR types In section 4, the entries for SRV and NAPTR in the list of RR types
to decompress were swapped to make the list consistently ordered by to decompress were swapped to make the list consistently ordered by
ascending numerical RR type. ascending numerical RR type.
References to RFC 1035 and RFC 1123 now include the specific section References to RFC 1035 and RFC 1123 now include the specific section
numbers being referenced. numbers being referenced.
A Change History was added as Appendix A. A Change History was added as Appendix A.
B.3. Changes between -01 and -02
In section 5, the term "white space" was replaced by "any combination
of tabs and spaces", and the term "word" was replaced by "item", for
consistency with RFC1035 terminology.
In section 5, hyphens were added to mark the beginning of each item
in the the list of items comprising the RDATA text representation.
The Change History was split into a Summary of Changes Since RFC3597
(Appendix A) intended to remain in the document when published as an
RFC, and a Detailed Change Log (Appendix B) to be deleted on
publication.
 End of changes. 13 change blocks. 
16 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/