IPP IANA Registry Policy - January 11, 2018 Status: Stable Editor: Michael Sweet (msweet@apple.com), Smith Kennedy (smith.kennedy@hp.com) Abstract RFC 8011 defines a formal process for registering IPP attributes, operations, and values in the IANA IPP registry, but it does not define a formal process for obsoleting or deprecating them, nor does it define the minimum requirements for submissions to the PWG IPP WG for evaluation. This policy document amends the process defined in RFC 8011 to allow previously registered attributes, operations, and values to be deprecated or obsoleted by the PWG Internet Printing Protocol workgroup. It also clarifies the documentation requirements for registrations. This version is available in the following locations: http://ftp.pwg.org/pub/pwg/general/wd/ipp-registry-policy-20180111.docx -------------------------------------------------------------------------------- IPP IANA Registry Policy (Normative) OVERVIEW The Internet Assigned Numbers Authority (IANA) maintains XML and plain text 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 "IPP/1.1: Model and Semantics" [RFC8011] and are maintained jointly by IANA and the PWG through its current IETF designated experts. The PWG IPP WG is responsible for reviewing all registrations and approving or rejecting changes to the registry. DEFINITIONS A standards-track document is a numbered PWG Candidate Standard or PWG Standard document as defined in PWG Process/3.0. An IPP Registration document is a white paper that is formally reviewed by the PWG IPP WG. At the successful conclusion of an IPP WG last call, the PWG IPP WG secretary "publishes" the approved draft with status "IPP WG Approved". Published registration documents have the prefix "reg-" and are uploaded to the "/pub/pwg/ipp/registrations" directory on the PWG FTP server. A deprecation is a statement that an IPP operation, attribute, value, group, or attribute syntax should no longer be used or implemented. An obsoletion is a statement that an IPP operation, attribute, value, group, or attribute syntax must no longer be used or implemented.   GENERAL REGISTRATION PROCESS Registrations are submitted either as part of a standards-track document, an IPP Registration document, or as a separate request submitted by an organization or individual. The request is made either via email directly sent to the IPP mailing list (ipp@pwg.org) or through IANA's registration portal. Standards-track registrations in PWG documents are approved as part of the document going through PWG Formal Approval as defined in PWG Process/3.0. Non-standards-track registrations and standards-track registrations in non-PWG documents are reviewed by the PWG IPP WG, which can: 1. Approve the request as submitted; 2. Approve the request with modifications; or 3. Reject the request for a stated technical reason. Approved deprecations or obsoletions additionally go through a PWG Call for Objections or, at the discretion of the PWG Steering Committee, a PWG Formal Approval for the requested changes. Approved registrations are published to the IANA IPP registry using the archive page containing the PWG IPP WG secretary's message as the durable reference. REGISTRATION OF NEW ITEMS New IPP attributes, values, operations, and status codes are added to the IANA IPP Registry using the process defined in appendix A of RFC 8011. New attributes and new values for existing type2 enum or keywords can be registered using the RFC 8011 templates and a short description of the attributes and/or values being registered. New operations, attribute syntaxes, group tags, and status codes typically require a full definition of their semantics in a standards-track document, although operations and status codes with simple semantics may defined in an IPP Registration document, at the discretion of the PWG IPP WG and/or PWG Steering Committee. DEPRECATION AND OBSOLETION OF EXISTING ITEMS The PWG IPP WG 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, with the understanding that they will eventually become obsoletions. 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 attribute syntaxes) MUST be registered in standards-track documents. Deprecations and obsoletions for type2 attributes and values, as well as operations, can be registered in approved PWG specifications or submitted to the PWG IPP WG 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 WG conference call or face-to-face meeting, the PWG IPP WG 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.