Struct trust_dns_proto::rr::rdata::svcb::Mandatory

source · [−]

#[repr(transparent)]
pub struct Mandatory(pub Vec<SvcParamKey>);

Expand description

7.  ServiceMode RR compatibility and mandatory keys

   In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the
   RR will not function correctly for clients that ignore this
   SvcParamKey.  Each SVCB protocol mapping SHOULD specify a set of keys
   that are "automatically mandatory", i.e. mandatory if they are
   present in an RR.  The SvcParamKey "mandatory" is used to indicate
   any mandatory keys for this RR, in addition to any automatically
   mandatory keys that are present.

   A ServiceMode RR is considered "compatible" with a client if the
   client recognizes all the mandatory keys, and their values indicate
   that successful connection establishment is possible.  If the SVCB
   RRSet contains no compatible RRs, the client will generally act as if
   the RRSet is empty.

   The presentation "value" SHALL be a comma-separated list
   (Appendix A.1) of one or more valid SvcParamKeys, either by their
   registered name or in the unknown-key format (Section 2.1).  Keys MAY
   appear in any order, but MUST NOT appear more than once.  For self-
   consistency (Section 2.4.3), listed keys MUST also appear in the
   SvcParams.

   To enable simpler parsing, this SvcParamValue MUST NOT contain escape
   sequences.

   For example, the following is a valid list of SvcParams:

   echconfig=... key65333=ex1 key65444=ex2 mandatory=key65444,echconfig

   In wire format, the keys are represented by their numeric values in
   network byte order, concatenated in ascending order.

   This SvcParamKey is always automatically mandatory, and MUST NOT
   appear in its own value-list.  Other automatically mandatory keys
   SHOULD NOT appear in the list either.  (Including them wastes space
   and otherwise has no effect.)

Tuple Fields

0: Vec<SvcParamKey>

Trait Implementations

source

impl<'r> BinDecodable<'r> for Mandatory

source

fn read(decoder: &mut BinDecoder<'r>) -> ProtoResult<Self>

This expects the decoder to be limited to only this field, i.e. the end of input for the decoder is the end of input for the fields

   In wire format, the keys are represented by their numeric values in
   network byte order, concatenated in ascending order.

source

fn from_bytes(bytes: &'r [u8 ]) -> ProtoResult<Self>

Returns the object in binary form

source

impl BinEncodable for Mandatory

source

fn emit(&self, encoder: &mut BinEncoder<'_>) -> ProtoResult<()>

This expects the decoder to be limited to only this field, i.e. the end of input for the decoder is the end of input for the fields

   In wire format, the keys are represented by their numeric values in
   network byte order, concatenated in ascending order.

source

fn to_bytes(&self) -> ProtoResult<Vec<u8>>

Returns the object in binary form

source

impl Clone for Mandatory

source

fn clone(&self) -> Mandatory

Returns a copy of the value. Read more

1.0.0 · source

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source. Read more

source

impl Debug for Mandatory

source

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter. Read more

source

The presentation “value” SHALL be a comma-separated list (Appendix A.1) of one or more valid SvcParamKeys, either by their registered name or in the unknown-key format (Section 2.1). Keys MAY appear in any order, but MUST NOT appear more than once. For self- consistency (Section 2.4.3), listed keys MUST also appear in the SvcParams.

To enable simpler parsing, this SvcParamValue MUST NOT contain escape sequences.

For example, the following is a valid list of SvcParams:

echconfig=… key65333=ex1 key65444=ex2 mandatory=key65444,echconfig

source