IPP IANA Registry Policy - March 2, 2015 Status: Stable Editor: msweet@apple.com Abstract RFC 2911 defines a formal process for registering IPP attributes, operation,s nad values in the IANA IPP registry, but it does not define a formal process for obsoleting or deprecating them. This policy document amends the process defined in RFC 2911 to allow previously registered attributes, operations, and values to be deprecated or obsoleted by the PWG Internet Printing Protocol workgroup. It also clarifies that IANA does not allow so-called "type3" registrations. This version is available in the following locations: http://ftp.pwg.org/pub/pwg/general/process/ipp-registry-policy-20150302.txt -------------------------------------------------------------------------------- IPP IANA Registry Policy (Normative) OVERVIEW The Internet Assigned Numbers Authority (IANA) maintains XML and plain test registries for the Internet Printing Protocol (IPP) at: http://www.iana.org/assignments/ipp-registrations/ipp-registrations.xml http://www.iana.org/assignments/ipp-registrations/ipp-registrations.txt These registries were established by the IPP/1.1: Model and Semantics [RFC2911] and are maintained jointly by IANA and the PWG through its current IETF designated experts. The PWG IPP workgroup is responsible for reviewing all registrations and approving or rejecting changes to the registry. GENERAL REGISTRATION PROCESS Registrations are submitted either as part of a standards-track document or as a separate request submitted by an organization or individual. Standards-track registrations MUST BE approved as part of the document going through PWG Formal Approval. Non-standards track registrations MUST be reviewed by the PWG IPP workgroup, which can: 1. Approve the request as submitted; 2. Approve the request with modifications; or 3. Reject the request for a stated technical reason. When approved by the PWG IPP workgroup, the PWG IPP workgroup secretary then posts a PWG Call for Objections or, at the discretion of the PWG Steering Committee, a PWG Formal Vote for the requested changes. Once the changes have successfully completed the PWG Call for Objections or Formal Vote, the requested deprecations and/or obsoletions will be published to the IANA IPP registry using the archive page containing the PWG IPP workgroup secretary's message as the durable reference. REGISTRATION OF NEW ITEMS New IPP attributes, values, operations, and status codes can be added to the IANA IPP Registry using the process defined in section 11 of RFC 2911. However, Type 3 keyword and enum value registrations are not accepted (per a prior IESG decision) and are instead treated as Type 2 registrations that MUST be a) part of an approved PWG specification or b) approved by the PWG IPP WG. DEPRECATION AND OBSOLETION OF EXISTING ITEMS The PWG IPP workgroup MAY, at its discretion, decide that specific IPP attributes, operations, and/or values should be deprecated or obsoleted in order to a) replace an existing attribute, operation, and/or value with an equivalent that better serves the long term goals of the PWG for the IPP Model and Semantics, or b) remove an existing attribute, operation, and/or value when it has demonstrated interoperability issues or side-effects that make its use problematic. Deprecations are equivalent to a SHOULD NOT conformance requirement for Clients and Printers, while obsoletions are equivalent to a MUST NOT conformance requirement. Deprecated attributes or values can be reported at run-time by the Printer by returning the deprecated attribute or value in the unsupported attributes group of the response and returning the 'successful-ok-ignored-or-substituted' status code. Obsoleted attributes or values can be reported at run-time by the Printer by returning the obsoleted attribute or value in the unsupported attributes group of the response and returning the 'client-error-attributes-or-values-not- supported' status code. Printers also do not return obsoleted attributes or values in their responses to the various Get operations. Deprecations and obsoletions of type1 attributes and type1 values (which include status codes, group tags, and value tags) MUST be registered in approved PWG specifications. Deprecations and obsoletions for type2 and type3 attributes and values, as well as operations, can be registered in approved PWG specifications or submitted to the PWG IPP workgroup mailing list and approved or rejected depending on workgroup consensus. DEPRECATIONS AND OBSOLETIONS IN THE IANA IPP REGISTRY Deprecated and obsoleted IPP attributes, operations, and values are shown in the registry using second record below the item with deprecated or obsolete in parenthesis after the name. For example, a Job Template attribute named "my- attribute" that has been deprecated would appear in the registry as: Job Template my-attribute type2 keyword [RFCnnnn] Job Template my-attribute(deprecated) type2 keyword [LABEL] The LABEL reference provides a durable link to the specification or a message in the mailing list archive in which the deprecation occurred. DEPRECATING AND OBSOLETING IN SPECIFICATIONS To deprecate or obsolete an IPP attribute, operation, or value in a specification, the editor simply includes it in the IANA Considerations section, using the "(deprecated)" or "(obsolete)" text after the attribute, operation, or value. For example, the "my-attribute" deprecation would use the following registration text: Job Template attributes: Reference -------------------------------------------------------- -------------- my-attribute(deprecated) (type2 keyword) [PWG5100.NAME] Deprecations and obsoletions in a specification are published in the IANA IPP registry when the corresponding specification has been approved by the PWG members. DEPRECATING AND OBSOLETING THROUGH IPP WORKGROUP DISCUSSION To deprecate or obsolete an IPP attribute, operation, or value outside a specification, an individual sends an email to the PWG IPP WG mailing list (ipp@pwg.org) with the subject line: Subject: IPP Deprecation Request for The body of the message then includes a justification for the deprecation or obsoletion followed by the IANA registration template for the attributes, operations, and values being deprecated or obsoleted. After discussion in an PWG IPP workgroup conference call or face-to-face meeting, the PWG IPP workgroup secretary will then post a response to the original request indicating the final disposition of the request as well as the final IANA registration template that will be used.