As per Relevance of the word crawford, we have this rfc below:
Network Working Group M.
Request for Comments: 2673
Category: Standards Track August 1999
Binary Labels in the Domain Name
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
1. Introduction and
This document defines a "Bit-String Label" which may appear
domain names. This new label type compactly represents a sequence
"One-Bit Labels" and enables resource records to be stored at
bit-boundary in a binary-named section of the domain name tree
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [KWORD].
2.
Binary labels are intended to efficiently solve the problem
storing data and delegating authority on arbitrary boundaries
the structure of underlying name space is most naturally
in binary
3. Label
Up to 256 One-Bit Labels can be grouped into a single Bit-
Label. Within a Bit-String Label the most significant or "
level" bit appears first. This is unlike the ordering of DNS
themselves, which has the least significant or "lowest level"
first. Nonetheless, this ordering seems to be the most natural
efficient for representing binary labels
Crawford Standards Track [Page 1]
RFC 2673 Binary Labels in the Domain Name System August 1999
Among consecutive Bit-String Labels, the bits in the first-
label are less significant or "at a lower level" than the bits
subsequent Bit-String Labels, just as ASCII labels are ordered
3.1.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
|0 1| ELT | Count | Label ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
(Each tic mark represents one bit.)
ELT 000001 binary, the six-bit extended label type [EDNS0]
assigned to the Bit-String Label
Count The number of significant bits in the Label field. A
value of zero indicates that 256 bits are significant
(Thus the null label representing the DNS root cannot
represented as a Bit String Label.)
Label The bit string representing a sequence of One-Bit Labels
with the most significant bit first. That is, the One-
Label in position 17 in the diagram above represents
subdomain of the domain represented by the One-Bit Label
position 16, and so on
The Label field is padded on the right with zero to
pad bits to make the entire field occupy an integral
of octets. These pad bits MUST be zero on transmission
ignored on reception
A sequence of bits may be split into two or more Bit-String Labels
but the division points have no significance and need not
preserved. An excessively clever server implementation might
Bit-String Labels so as to maximize the effectiveness of
compression [DNSIS]. A simpler server might divide Bit-String
at zone boundaries, if any zone boundaries happen to fall
One-Bit Labels
3.2. Textual
A Bit-String Label is represented in text -- in a zone file,
example -- as a surrounded by the delimiters "\[" and "]".
The is either a dotted quad or a base indicator and
sequence of digits appropriate to that base, optionally followed by
Crawford Standards Track [Page 2]
RFC 2673 Binary Labels in the Domain Name System August 1999
slash and a length. The base indicators are "b", "o" and "x",
denoting base 2, 8 and 16 respectively. The length counts
significant bits and MUST be between 1 and 32, inclusive, after
dotted quad, or between 1 and 256, inclusive, after one of the
forms. If the length is omitted, the implicit length is 32 for
dotted quad or 1, 3 or 4 times the number of binary, octal
hexadecimal digits supplied, respectively, for the other forms
In augmented Backus-Naur form [ABNF],
bit-string-label = "\[" bit-spec "]"
bit-spec = bit-data [ "/" length ]
/ dotted-quad [ "/" slength ]
bit-data = "x" 1*64
/ "o" 1*86
/ "b" 1*256
dotted-quad = decbyte "." decbyte "." decbyte "."
decbyte = 1*3
length = NZDIGIT *2
slength = NZDIGIT [ DIGIT ]
OCTDIG = %x30-37
NZDIGIT = %x31-39
If a is present, the number of digits in the
be just sufficient to contain the number of bits specified by
. If there are insignificant bits in a final hexadecimal
octal digit, they MUST be zero. A always has all
parts even if the associated is less than 24, but, like
other forms, insignificant bits MUST be zero
Each number represented by a must be between 0 and 255,
inclusive
The number represented by must be between 1 and 256
inclusive
The number represented by must be between 1 and 32
inclusive
Crawford Standards Track [Page 3]
RFC 2673 Binary Labels in the Domain Name System August 1999
When the textual form of a Bit-String Label is generated by machine
the length SHOULD be explicit, not implicit
3.2.1.
The following four textual forms represent the same Bit-String Label
\[b11010000011101]
\[o64072/14]
\[xd074/14]
\[208.116.0.0/14]
The following represents two consecutive Bit-String Labels
denote the same relative point in the DNS tree as any of the
single Bit-String Labels
\[b11101].\[o640]
3.3. Canonical Representation and Sort
Both the wire form and the text form of binary labels have a
of flexibility in their grouping into multiple consecutive Bit-
Labels. For generating and checking DNS signature records [DNSSEC
binary labels must be in a predictable form. This canonical form
defined as the form which has the fewest possible Bit-String
and in which all except possibly the first (least significant)
in any sequence of consecutive Bit-String Labels is of
length
For example, the canonical form of any sequence of up to 256 One-
Labels has a single Bit-String Label, and the canonical form of
sequence of 513 to 768 One-Bit Labels has three Bit-String Labels
which the second and third contain 256 label bits
The canonical sort order of domain names [DNSSEC] is extended
encompass binary labels as follows. Sorting is still label-by-label
from most to least significant, where a label may now be a One-
Label or a standard (code 00) label. Any One-Bit Label sorts
any standard label, and a 0 bit sorts before a 1 bit. The absence
a label sorts before any label, as specified in [DNSSEC].
Crawford Standards Track [Page 4]
RFC 2673 Binary Labels in the Domain Name System August 1999
For example, the following domain names are correctly sorted
foo.
\[b1].foo.
\[b100].foo.
\[b101].foo.
bravo.\[b10].foo.
alpha.foo.
4. Processing
A One-Bit Label never matches any other kind of label.
particular, the DNS labels represented by the single ASCII
"0" and "1" do not match One-Bit Labels represented by the bit
0 and 1.
5.
A Count of zero in the wire-form represents a 256-bit sequence,
to optimize that particular case, but to make it
impossible to have a zero-bit label
6. IANA
This document defines one Extended Label Type, termed the Bit-
Label, and requests registration of the code point 000001 binary
the space defined by [EDNS0].
7. Security
All security considerations which apply to traditional ASCII
labels apply equally to binary labels. he canonicalization
sorting rules of section 3.3 allow these to be addressed by
Security [DNSSEC].
Crawford Standards Track [Page 5]
RFC 2673 Binary Labels in the Domain Name System August 1999
8.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[DNSIS] Mockapetris, P., "Domain names - implementation
specification", STD 13, RFC 1035, November 1987.
[DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System
Extensions", RFC 2065, January 1997
[EDNS0] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
[KWORD] Bradner, S., "Key words for use in RFCs to
Requirement Levels," BCP 14, RFC 2119, March 1997.
9. Author's
Matt
Fermilab MS 368
PO Box 500
Batavia, IL 60510
Phone: +1 630 840-3461
EMail: crawdad@fnal.
Crawford Standards Track [Page 6]
RFC 2673 Binary Labels in the Domain Name System August 1999
10. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Crawford Standards Track [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
