[HTPP] Barnett, J., Carter, K., and R. deBry, "Internet Print Protocol Proposal: HTPP -- Hypertext Print Protocol (HTPP/1.0 Initial Draft)", October 1996,
<ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/
overview.ps.gz>.
[IANA-CS] IANA, "Registry of Coded Character Sets",
<http://www.iana.org/assignments/character-sets/>.
[IANA-MT] IANA, "Media Types",
<http://www.iana.org/assignments/media-types/>.
[IANA-PEN]
IANA, "Private Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers/>.
[ISO32000] "Document management Portable document format Part 1: PDF 1.7", July 2008, <http://www.adobe.com/
devnet/acrobat/pdfs/PDF32000_2008.pdf>.
[LDPA] Isaacson, S., Taylor, D., MacKay, M., Zehler, P.,
Hastings, T., and C. Manros, "LDPA - Lightweight Document Printing Application", Proposed Internet-Draft,
October 1996, <ftp://ftp.pwg.org/pub/pwg/ipp/
historic/ldpa/ldpa8.pdf.gz>.
[P1387.4] Kirk, M., "POSIX Systems Administration - Part 4: Printing Interfaces, POSIX 1387.4 D8", 1998.
[PSIS] Herriot, R., Ed., "X/Open: A Printing System
Interoperability Specification (PSIS)", August 1995.
[PWG-IPP-WG]
IEEE-ISTO Printer Working Group, "Internet Printing Protocol Workgroup", <http://www.pwg.org/ipp>.
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <http://www.rfc-editor.org/info/rfc959>.
[RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, DOI 10.17487/RFC1179, August 1990,
<http://www.rfc-editor.org/info/rfc1179>.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, December 1994, <http://www.rfc-editor.org/info/rfc1738>.
[RFC2565] Herriot, R., Ed., Butler, S., Moore, P., and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, DOI 10.17487/RFC2565, April 1999,
<http://www.rfc-editor.org/info/rfc2565>.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P.
Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, DOI 10.17487/RFC2566, April 1999, <http://www.rfc-editor.org/info/rfc2566>.
[RFC2567] Wright, F., "Design Goals for an Internet Printing Protocol", RFC 2567, DOI 10.17487/RFC2567, April 1999, <http://www.rfc-editor.org/info/rfc2567>.
[RFC2568] Zilles, S., "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol", RFC 2568, DOI 10.17487/RFC2568, April 1999,
<http://www.rfc-editor.org/info/rfc2568>.
[RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569,
DOI 10.17487/RFC2569, April 1999,
<http://www.rfc-editor.org/info/rfc2569>.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, <http://www.rfc-editor.org/info/rfc2579>.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <http://www.rfc-editor.org/info/rfc2978>.
[RFC3239] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations", RFC 3239,
DOI 10.17487/RFC3239, February 2002, <http://www.rfc-editor.org/info/rfc3239>.
[RFC3997] Hastings, T., Ed., deBry, R., and H. Lewis, "Internet Printing Protocol (IPP): Requirements for IPP
Notifications", RFC 3997, DOI 10.17487/RFC3997,
March 2005, <http://www.rfc-editor.org/info/rfc3997>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The ’mailto’
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, <http://www.rfc-editor.org/info/rfc6068>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[SWP] Moore, P. and S. Butler, "Simple Web Printing (SWP/1.0)", May 1997, <ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/
swp9705.pdf>.
Appendix A. Formats for IPP Registration Proposals
In order to propose an IPP extension for registration, the proposer must submit an application to IANA by email to "iana@iana.org" or by filling out the appropriate form on the IANA web pages
(http://www.iana.org). This section specifies the required
information and the formats for proposing registrations of extensions to IPP as provided in Section 7 for:
1. attributes
2. type2 ’keyword’ attribute values 3. type2 ’enum’ attribute values 4. operations
5. status-code values A.1. Attribute Registration
Type of registration: attribute
Proposed keyword name of this attribute:
Types of attributes (Document Description, Document Status, Document Template, Event Notifications, Job Description, Job Status, Job Template, Operation, Printer Description, Printer Status,
Subscription Description, Subscription Status, Subscription Template):
Operations to be used if the attribute is an operation attribute:
Object (Document, Job, Printer, Subscription, etc. if bound to an object):
Attribute syntax(es) (include ’1setOf’ and range; see Section 5.2):
If attribute syntax is ’keyword’ or ’enum’, is it type1 or type2?
If this is a Printer attribute, MAY the value returned depend on "document-format"? (See Section 7.2.)
If this is a Job Template attribute, how does its specification depend on the value of the "multiple-document-handling" attribute?
Specification of this attribute (follow the style of Section 5.2):
Name of proposer:
Email address of proposer:
Note: For attributes, the IPP Designated Expert will be the point of contact and change controller for the approved registration
specification, if any maintenance of the registration specification is needed.
A.2. type2 ’keyword’ Attribute Value Registration Type of registration: type2 keyword attribute value
Name of attribute to which this keyword specification is to be added:
Proposed keyword name of this ’keyword’ value:
Specification of this ’keyword’ value (follow the style of Section 5.1.4):
Name of proposer:
Email address of proposer:
Note: For type2 keywords, the Designated Expert will be the point of contact and change controller for the approved registration
specification, if any maintenance of the registration specification is needed.
A.3. type2 ’enum’ Attribute Value Registration Type of registration: type2 enum attribute value
Name of attribute to which this enum specification is to be added:
Keyword symbolic name of this enum value:
Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA):
Specification of this enum value (follow the style of Section 5.1.5):
Name of proposer:
Email address of proposer:
Note: For type2 enums, the Designated Expert will be the point of contact and change controller for the approved registration
specification, if any maintenance of the registration specification is needed.
A.4. Operation Registration
Type of registration: operation Proposed name of this operation:
Numeric "operation-id" value according to Section 5.4.15 (to be assigned by the IPP Designated Expert in consultation with IANA):
Object Target (Document, Job, Printer, Subscription, etc. that operation is upon):
Specification of this operation (follow the style of Section 4):
Name of proposer:
Email address of proposer:
Note: For operations, the IPP Designated Expert will be the point of contact and change controller for the approved registration
specification, if any maintenance of the registration specification is needed.
A.5. Status-Code Registration
Type of registration: status-code
Keyword symbolic name of this status-code value:
Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA):
Operations that this status-code can be used with:
Specification of this status-code (follow the style of Appendix B):
Name of proposer:
Email address of proposer:
Note: For status-code values, the Designated Expert will be the point of contact and change controller for the approved registration
specification, if any maintenance of the registration specification is needed.
Appendix B. Status-Code Values and Suggested Status-Code Messages This section defines status-code enum keywords and values that are used to provide semantic information on the results of an operation request. Each operation response MUST include a status-code. The response MAY also contain a status message that provides a short textual description of the status. The status-code is intended for use by automata, and the status message is intended for the human End User.
The prefix of the status keyword defines the class of response as follows:
"informational" - Request received, continuing process
"successful" - The action was successfully received, understood, and accepted
"redirection" - Further action is 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
As with type2 enums, IPP status-code values are extensible.
Regardless of whether all status-code values are recognized, IPP Clients MUST understand the class of any status-code, as indicated by the prefix, and treat any unrecognized response as being equivalent to the first status-code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an
unrecognized status-code of ’client-error-xxx-yyy’ is received by the Client, it can safely assume that there was something wrong with its request and treat the response as if it had received a
’client-error-bad-request’ status-code. The name of the enum is the suggested status message for US English.
See [PWG5100.19] for guidelines on presenting status messages to End Users.