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
144
145
146
//! Draft-20 object status values.
//!
//! - 0x0 = Normal, may carry a payload
//! - 0x3 = End of Group, may not
//! - 0x4 = End of Track, may not
//!
//! Unchanged from draft-19 in both the code points and the rule behind them.
//! Draft-18 and earlier 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 gave the Object Status registry a "Payload" column
//! and made the rule registry data, and draft-20 Section 15.9 keeps it that
//! way. It is carried here as a `PayloadPermission` on the status itself.
//!
//! Object Status is present only on subscription-delivered Objects. Draft-20
//! Section 11.2.1.1 is unchanged on this: a fetch stream's objects carry no
//! status field at all.
/// Whether an Object carrying a given status is permitted a non-empty payload:
/// the "Payload" column of the Object Status registry, MoQ Transport draft-20
/// Section 15.9, Table 16.
///
/// Draft-20 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.
///
/// Drafts up to 18 had no such column — they derived the same answer
/// arithmetically, from the status being non-zero — so this type belongs to
/// draft-19 and later rather than being shared across the range.
/// Object status values, from MoQ Transport draft-20 Section 11.2.1.1
/// "Object Status", with the same three code points listed in the IANA Object
/// Status registry at Section 15.9, Table 16.
///
/// 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`].