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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
|
FROM RFC XXXX
This section describes how IPP can be extended to allow the
following registered and private extensions to IPP:
1. keyword attribute values
2. enum attribute values
3. attributes
4. attribute syntaxes
5. operations
6. attribute groups
7. status codes
Extensions registered for use with IPP/1.0 are OPTIONAL for client
and IPP object conformance to the IPP/1.0 Model specification.
These extension procedures are aligned with the guidelines as set
forth by the IESG [RFC2434]. Section 11 describes how to propose
new registrations for consideration. IANA will reject registration
proposals that leave out required information or do not follow the
appropriate format described in Section 11. IPP/1.0 may also be
extended by an appropriate RFC that specifies any of the above
extensions.
6.1 Typed 'keyword' and 'enum' Extensions
IPP allows for 'keyword' and 'enum' extensions (see sections
4.1.2.3 and 4.1.4). This document uses prefixes to the 'keyword' and
'enum' basic attribute syntax type in order to communicate extra
information to the reader through its name. This extra information is not
represented in the protocol because it is unimportant to a client
or Printer object. The list below describes the prefixes and their
meaning.
"type1": The IPP specification must be revised to add a new
keyword or a new enum. No private keywords or enums are
allowed.
"type2": Implementers can, at any time, add new keyword or enum
values by proposing the complete specification to IANA:
iana@iana.org
IANA will forward the registration proposal to the IPP
Designated Expert who will review the proposal with a mailing
list that the Designated Expert keeps for this purpose.
Initially, that list will be the mailing list used by the IPP
WG:
ipp@pwg.org
even after the IPP WG is disbanded as permitted by [RFC2434].
The IPP Designated Expert is appointed by the IESG Area
Director responsible for IPP, according to [RFC2434].
When a type2 keyword or enum is approved, the IPP Designated
Expert becomes the point of contact for any future maintenance
that might be required for that registration.
"type3": Implementers can, at any time, add new keyword and enum
values by submitting the complete specification to IANA as for
type2 who will forward the proposal to the IPP Designated
Expert. While no additional technical review is required, the
IPP Designated Expert may, at his/her discretion, forward the
proposal to the same mailing list as for type2 registrations
for advice and comment.
When a type3 keyword or enum is approved by the IPP Designated
Expert, the original proposer becomes the point of contact for
any future maintenance that might be required for that
registration.
For type2 and type3 keywords, the proposer includes the name of the
keyword in the registration proposal and the name is part of the
technical review.
After type2 and type3 enums specifications are approved, the IPP
Designated Expert in consultation with IANA assigns the next
available enum number for each enum value.
IANA will publish approved type2 and type3 keyword and enum
attributes value registration specifications in:
ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt
where xxx is the attribute name that specifies the initial values
and yyy.txt is a descriptive file name that contains one or more enums
or keywords approved at the same time. For example, if several
additional enums for stapling are approved for use with the
"finishings" attribute (and "finishings-default" and "finishings-
supported" attributes), IANA will publish the additional values in
the file:
ftp.isi.edu/iana/assignments/ipp/attribute-
values/finishings/stapling.txt.
Note: Some attributes are defined to be: 'type3 keywords' | 'name'
which allows for attribute values to be extended by a site
administrator with administrator defined names. Such names are not
registered with IANA.
By definition, each of the three types above assert some sort of
registry or review process in order for extensions to be considered
valid. Each higher numbered level (1, 2, 3) tends to be
decreasingly less stringent than the previous level. Therefore,
any typeN value MAY be registered using a process for some typeM where
M is less than N, however such registration is NOT REQUIRED. For
example, a type3 value MAY be registered in a type 1 manner (by being
included in a future version of an IPP specification), however, it is NOT
REQUIRED.
This specification defines keyword and enum values for all of the
above types, including type3 keywords.
For private (unregistered) keyword extensions, implementers SHOULD
use keywords with a suitable distinguishing prefix, such as "xxx-"
where xxx is the (lowercase) fully qualified company name
registered with IANA for use in domain names [RFC1035]. For
example, if the company XYZ Corp. had obtained the domain name
"XYZ.com", then a private keyword 'abc' would be: 'xyz.com-abc'.
Note: RFC 1035 [RFC1035] indicates that while upper and lower case
letters are allowed in domain names, no significance is attached to
the case. That is, two names with the same spelling but different
case are to be treated as if identical. Also, the labels in a
domain name must follow the rules for ARPANET host names: They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. Labels must be 63
characters or less. Labels are separated by the "." character.
For private (unregistered) enum extension, implementers MUST use
values in the reserved integer range which is 2**30 to 2**31-1.
6.2 Attribute Extensibility
Attribute names are type2 keywords. Therefore, new attributes may
be registered and have the same status as attributes in this document
by following the type2 extension rules. For private (unregistered)
attribute extensions, implementers SHOULD use keywords with a
suitable distinguishing prefix as described in Section 6.1.
IANA will publish approved attribute registration specifications as
separate files:
ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt
where "xxx-yyy" is the new attribute name.
If a new Printer object attribute is defined and its values can be
affected by a specific document format, its specification needs to
contain the following sentence:
"The value of this attribute returned in a Get-Printer-Attributes
response MAY depend on the "document-format" attribute supplied
(see Section 3.2.5.1)."
If the specification does not, then its value in the Get-Printer-
Attributes response MUST NOT depend on the "document-format"
supplied in the request. When a new Job Template attribute is registered,
the value of the Printer attributes MAY vary with "document-format"
supplied in the request without the specification having to
indicate so.
6.3 Attribute Syntax Extensibility
Attribute syntaxes are like type2 enums. Therefore, new attribute
syntaxes may be registered and have the same status as attribute
syntaxes in this document by following the type2 extension rules
described in Section 6.1. The value codes that identify each of
the attribute syntaxes are assigned in the Encoding and Transport
specification [RFC2565], including a designated range for private,
experimental use.
For attribute syntaxes, the IPP Designated Expert in consultation
with IANA assigns the next attribute syntax code in the appropriate
range as specified in [RFC2565]. IANA will publish approved
attribute syntax registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt
where 'xxx-yyy' is the new attribute syntax name.
6.4 Operation Extensibility
Operations may also be registered following the type2 procedures
described in Section 6.1, though major new operations will usually
be done by a new standards track RFC that augments this document.
For private (unregistered) operation extensions, implementers MUST
use the range for the "operation-id" in requests specified in
Section 4.4.13 "operations-supported" Printer attribute.
For operations, the IPP Designated Expert in consultation with IANA
assigns the next operation-id code as specified in Section 4.4.13.
IANA will publish approved operation registration specifications as
separate files:
ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt
where "Xxx-Yyy" is the new operation name.
6.5 Attribute Groups
Attribute groups passed in requests and responses may be registered
following the type2 procedures described in Section 6.1. The tags
that identify each of the attribute groups are assigned in
[RFC2565].
For attribute groups, the IPP Designated Expert in consultation
with IANA assigns the next attribute group tag code in the
appropriate range as specified in [RFC2565]. IANA will publish
approved attribute group registration specifications as separate
files:
ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
tag.txt
where 'xxx-yyy-tag' is the new attribute group tag name.
6.6 Status Code Extensibility
Operation status codes may also be registered following the type2
procedures described in Section 6.1. The values for status codes
are allocated in ranges as specified in Section 13 for each status
code class:
"informational" - Request received, continuing process
"successful" - The action was successfully received, understood,
and accepted
"redirection" - Further action must be taken in order to complete
the request
"client-error" - The request contains bad syntax or cannot be
fulfilled
"server-error" - The IPP object failed to fulfill an apparently
valid request
For private (unregistered) operation status code extensions,
implementers MUST use the top of each range as specified in Section
13.
For operation status codes, the IPP Designated Expert in
consultation with IANA assigns the next status code in the
appropriate class range as specified in Section 13. IANA will
publish approved status code registration specifications as
separate files:
ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt
where "xxx-yyy" is the new operation status code keyword.
|
