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.