1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
//! Draft-19 object status values.
//!
//! - 0x0 = Normal, may carry a payload
//! - 0x3 = End of Group, may not
//! - 0x4 = End of Track, may not
//!
//! The code points and their wire encoding are the ones draft-18 used. What
//! draft-19 changed is where the payload rule comes from: draft-18 stated flatly
//! that an Object with a status other than Normal has an empty payload, so the
//! payload rule could be read off the status number. Draft-19 Section 15.9 gives
//! the Object Status registry a "Payload" column instead and requires every
//! future registration to fill it in, so the rule is registry data. It is
//! carried here as a `PayloadPermission` on the status itself.
/// Whether an Object carrying a given status is permitted a non-empty payload:
/// the "Payload" column of the Object Status registry, MoQ Transport draft-19
/// Section 15.9, Table 16.
///
/// Draft-19 Section 11.2.1.1 phrases the rule as "An Object MUST have an empty
/// payload unless its Object Status value is registered as permitting a
/// payload", and Section 15.9 adds that each new registration "MUST indicate
/// whether the status permits a payload". Modelling the column as a value keeps
/// that obligation visible: a status cannot be added to [`ObjectStatus`]
/// without [`ObjectStatus::payload_permission`] refusing to compile until its
/// column is filled in.
///
/// Earlier drafts had no such column — draft-18 and its predecessors derived
/// the same answer arithmetically, from the status being non-zero — so this
/// type is deliberately draft-19-only rather than shared.
/// Object status values, from MoQ Transport draft-19 Section 11.2.1.1
/// "Object Status", with the same three code points listed in the IANA Object
/// Status registry the draft establishes in Section 15.9.
///
/// The draft assigns 0x0, 0x3 and 0x4. Of every other value the section says:
/// "Any other value SHOULD be treated as a protocol error and the session
/// SHOULD be closed with a PROTOCOL_VIOLATION". [`ObjectStatus::from_u64`]
/// answers `None` for everything the draft leaves unassigned, 0x1 and 0x2
/// included. The section also states plainly that there is no status meaning
/// end of Subgroup: a subgroup ends when its stream is closed with a FIN.
///
/// Each status carries the registry's payload rule with it, as
/// [`ObjectStatus::payload_permission`].