#[repr(u64)]pub enum StreamType {
Show 13 variants
Fetch = 5,
SubgroupZero = 16,
SubgroupZeroExt = 17,
SubgroupFirstObj = 18,
SubgroupFirstObjExt = 19,
SubgroupExplicit = 20,
SubgroupExplicitExt = 21,
SubgroupZeroEog = 24,
SubgroupZeroEogExt = 25,
SubgroupFirstObjEog = 26,
SubgroupFirstObjEogExt = 27,
SubgroupExplicitEog = 28,
SubgroupExplicitEogExt = 29,
}Expand description
Stream type IDs for draft-13 data streams.
§Draft-13 contradicts itself about where the subgroup types sit
Draft-13 repeats draft-12’s disagreement word for word, in the same three places. Two carry draft-11’s answer:
- Section 9, Table 10, the table of unidirectional stream types, whose SUBGROUP_HEADER row reads 0x08-0x0D.
- Section 9.4.2, Figure 33, the header’s own layout:
Type (i) = 0x8..0xD.
The third does not. Section 9.4.2 says “There are 12 defined Type values for SUBGROUP_HEADER” and Table 13, immediately under that figure, lists them: 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x18, 0x19, 0x1A, 0x1B, 0x1C and 0x1D.
This enum implements Table 13, so a stream opening with 0x08 through
0x0D is CodecError::UnknownStreamType and closes the session.
Table 13 is the surviving half, for the same reason and by the same
mechanism as the datagram-status contradiction documented on
DatagramType — a code-point update that missed a spot:
- The range 0x08-0x0D holds six values, and this draft defines twelve
types. Draft-11 Section 9.4.2 Table 11 lists exactly six, at 0x08
through 0x0D, and the twelve here are those six crossed with the End Of
Group bit draft-12 added. So 0x08-0x0D and
0x8..0xDare draft-11’s range left behind, and they cannot hold what this draft defines. - Table 13 is the only one of the three that says what each value means. The other two give a range and nothing else, so following either would leave every framing decision — whether a Subgroup ID field is on the wire, whether objects carry extensions, whether the stream ends the group — with nothing to read it from.
- Draft-14 keeps Table 13 unchanged and corrects the other two to match:
its Table 10 reads “0x10-0x1D” and its Figure reads
Type (i) = 0x10..0x1D. That is the disagreement being resolved in favour of Table 13 by the working group, one draft later.
The cost of being wrong is asymmetric and points the same way. Accepting 0x08-0x0D as well would mean parsing a stream under framing no table assigns it, which is the failure this codebase refuses elsewhere — an out-of-range Type aliased onto a valid one produces objects with plausible, wrong contents. Refusing them closes a session with a peer that followed the stale half of its own draft, which is visible, reportable, and what draft-14 says the peer should not have done.
Variants§
Fetch = 5
SubgroupZero = 16
SubgroupZeroExt = 17
SubgroupFirstObj = 18
SubgroupFirstObjExt = 19
SubgroupExplicit = 20
SubgroupExplicitExt = 21
SubgroupZeroEog = 24
SubgroupZeroEogExt = 25
SubgroupFirstObjEog = 26
SubgroupFirstObjEogExt = 27
SubgroupExplicitEog = 28
SubgroupExplicitEogExt = 29
Implementations§
Source§impl StreamType
impl StreamType
pub fn from_id(id: u64) -> Option<Self>
pub fn is_subgroup(&self) -> bool
pub fn has_extensions(&self) -> bool
pub fn contains_end_of_group(&self) -> bool
Sourcepub fn writes_subgroup_id(&self) -> bool
pub fn writes_subgroup_id(&self) -> bool
True if this subgroup stream type puts an explicit Subgroup ID on the wire.
The Subgroup ID Field Present column of the SUBGROUP_HEADER type table in Section 9.4.2. The other two columns of that row say what the Subgroup ID is where the field is absent — zero, or the first Object’s ID — so this is only about the field, never about the value.