Enum domain::bits::name::LabelContent [−][src]
The contents of a label.
There are two types of labels with content currently in use: termed normal labels and binary labels herein. The type of a label is determined by the first octet of the label’s wire representation.
Originally, RFC 1035 decreed that the label type shall encoded in this
octet’s two most-significant bits. 0b00
was to mean a normal label
and 0b11
was to indicate the pointer of a compressed domain name.
Since that left only two more types, RFC 2671 declared 0b01
to
signal an extended label type with the rest of the first octet
stating which label type exactly. RFC 2673 used this mechanism to
define binary labels as type 0x41
.
However, because domain names are such a fundamental part of the DNS, it turned out that adding a new label type resulted in all sorts of compatibility issues. It was thus decided with RFC 6891 to abandon this experiment and deprecate binary labels.
The LabelContent
type still has two variants for normal and binary
labels. Because it is an enum, creation of values cannot be regulated
which means that any value of this type not directly acquired through
a call to Label::content()
may contain invalid data. Despite that,
the implementations of the various std::fmt
traits provided by this
type happily assume correctly encoded data and will panic.
Variants
Normal(&'a [u8])
A normal label.
Normal labels consist of up to 63 octets of data. While RFC 1034 proposes to limit the octets to ASCII letters, digits, and hyphens, no hard restriction exists and all values are allowed.
When encoded, normal labels start with a one-octet value containing
the number of octets in the label’s content followed by that
content. Because the label type in the most-significant bits of that
first octet is 0b00
, the value of the octet really is length and
no masking is required.
Binary(u8, &'a [u8])
A binary label, also called a bit-string label.
Binary labels contains a sequence of one-bit labels. The bits in the label are treated each as a label of its own. The intention was to provide a way to express arbitrary binary data in DNS allowing zone cuts at any point in the data. This was supposed to make the zone delgation for reverse pointers in IPv6 easier and more flexible.
The content of a binary label consists of one octet giving the number of bits in the label. The value of zero indicates 256 bits in order to make empty labels impossible. This octet is followed by the smallest number of octets necessary to contain that many bits with excess bits set to zero.
Confusingly, the bits are arranged in reverse order. The most-significant bit (bit 7 of the first octet) contains the right-most label in customary label order. However, two consecutive binary labels are arranged as normal.
This variant contains the number of bits in its first element and
a bytes slice of the bits in its second element. The bit count is
kept as is, ie., 0
still means 256 bits.
Trait Implementations
impl<'a> Display for LabelContent<'a>
[src]
impl<'a> Display for LabelContent<'a>
fn fmt(&self, f: &mut Formatter) -> Result
[src]
fn fmt(&self, f: &mut Formatter) -> Result
Formats the value using the given formatter. Read more
impl<'a> Octal for LabelContent<'a>
[src]
impl<'a> Octal for LabelContent<'a>
impl<'a> LowerHex for LabelContent<'a>
[src]
impl<'a> LowerHex for LabelContent<'a>
impl<'a> UpperHex for LabelContent<'a>
[src]
impl<'a> UpperHex for LabelContent<'a>
impl<'a> Binary for LabelContent<'a>
[src]
impl<'a> Binary for LabelContent<'a>
impl<'a> Debug for LabelContent<'a>
[src]
impl<'a> Debug for LabelContent<'a>
Auto Trait Implementations
impl<'a> Send for LabelContent<'a>
impl<'a> Send for LabelContent<'a>
impl<'a> Sync for LabelContent<'a>
impl<'a> Sync for LabelContent<'a>