#[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
impl<'r> BinDecodable<'r> for Mandatory
source§fn read(decoder: &mut BinDecoder<'r>) -> ProtoResult<Self>
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>
fn from_bytes(bytes: &'r [u8]) -> ProtoResult<Self>
source§impl BinEncodable for Mandatory
impl BinEncodable for Mandatory
source§fn emit(&self, encoder: &mut BinEncoder<'_>) -> ProtoResult<()>
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§impl Display for Mandatory
impl Display for Mandatory
source§fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>
fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>
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