Internet Engineering Task Force (IETF) M. Sweet
Request for Comments: 8010 Apple Inc.
Obsoletes: 2910, 3382 I. McDonald
Category: Standards Track High North, Inc.
ISSN: 2070-1721 January 2017
Internet Engineering Task Force (IETF) M. Sweet
Request for Comments: 8010 Apple Inc.
Obsoletes: 2910, 3382 I. McDonald
Category: Standards Track High North, Inc.
ISSN: 2070-1721 January 2017
Internet Printing Protocol/1.1: Encoding and Transport
Internet打印协议/1.1：编码和传输
Abstract
摘要
The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called "application/ipp". It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/or HTTPS. The IPP data model and operation semantics are described in "Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011).
Internet打印协议（IPP）是一种应用程序级协议，用于使用Internet工具和技术进行分布式打印。本文档定义了将IPP操作、属性和值编码到称为“应用程序/IPP”的Internet MIME媒体类型中的规则。它还定义了通过HTTP和/或HTTPS传输内容类型为“应用程序/ipp”的消息体的规则。IPP数据模型和操作语义在“Internet打印协议/1.1：模型和语义”（RFC 8011）中进行了描述。
This document obsoletes RFCs 2910 and 3382.
本文件淘汰了RFC 2910和3382。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8010.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8010.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Printing Terminology . . . . . . . . . . . . . . . . . . 5
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Encoding of the Operation Layer . . . . . . . . . . . . . . . 6
3.1. Picture of the Encoding . . . . . . . . . . . . . . . . . 8
3.1.1. Request and Response . . . . . . . . . . . . . . . . 8
3.1.2. Attribute Group . . . . . . . . . . . . . . . . . . . 9
3.1.3. Attribute . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. Attribute-with-one-value . . . . . . . . . . . . . . 10
3.1.5. Additional-value . . . . . . . . . . . . . . . . . . 11
3.1.6. Collection Attribute . . . . . . . . . . . . . . . . 12
3.1.7. Member Attributes . . . . . . . . . . . . . . . . . . 13
3.1.8. Alternative Picture of the Encoding of a Request or a
Response . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Syntax of Encoding . . . . . . . . . . . . . . . . . . . 15
3.3. Attribute-group . . . . . . . . . . . . . . . . . . . . . 16
3.4. Required Parameters . . . . . . . . . . . . . . . . . . . 18
3.4.1. "version-number" . . . . . . . . . . . . . . . . . . 18
3.4.2. "operation-id" . . . . . . . . . . . . . . . . . . . 18
3.4.3. "status-code" . . . . . . . . . . . . . . . . . . . . 19
3.4.4. "request-id" . . . . . . . . . . . . . . . . . . . . 19
3.5. Tags . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1. "delimiter-tag" Values . . . . . . . . . . . . . . . 19
3.5.2. "value-tag" Values . . . . . . . . . . . . . . . . . 20
3.6. "name-length" . . . . . . . . . . . . . . . . . . . . . . 23
3.7. (Attribute) "name" . . . . . . . . . . . . . . . . . . . 23
3.8. "value-length" . . . . . . . . . . . . . . . . . . . . . 23
3.9. (Attribute) "value" . . . . . . . . . . . . . . . . . . . 24
3.10. Data . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Printing Terminology . . . . . . . . . . . . . . . . . . 5
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Encoding of the Operation Layer . . . . . . . . . . . . . . . 6
3.1. Picture of the Encoding . . . . . . . . . . . . . . . . . 8
3.1.1. Request and Response . . . . . . . . . . . . . . . . 8
3.1.2. Attribute Group . . . . . . . . . . . . . . . . . . . 9
3.1.3. Attribute . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. Attribute-with-one-value . . . . . . . . . . . . . . 10
3.1.5. Additional-value . . . . . . . . . . . . . . . . . . 11
3.1.6. Collection Attribute . . . . . . . . . . . . . . . . 12
3.1.7. Member Attributes . . . . . . . . . . . . . . . . . . 13
3.1.8. Alternative Picture of the Encoding of a Request or a
Response . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Syntax of Encoding . . . . . . . . . . . . . . . . . . . 15
3.3. Attribute-group . . . . . . . . . . . . . . . . . . . . . 16
3.4. Required Parameters . . . . . . . . . . . . . . . . . . . 18
3.4.1. "version-number" . . . . . . . . . . . . . . . . . . 18
3.4.2. "operation-id" . . . . . . . . . . . . . . . . . . . 18
3.4.3. "status-code" . . . . . . . . . . . . . . . . . . . . 19
3.4.4. "request-id" . . . . . . . . . . . . . . . . . . . . 19
3.5. Tags . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1. "delimiter-tag" Values . . . . . . . . . . . . . . . 19
3.5.2. "value-tag" Values . . . . . . . . . . . . . . . . . 20
3.6. "name-length" . . . . . . . . . . . . . . . . . . . . . . 23
3.7. (Attribute) "name" . . . . . . . . . . . . . . . . . . . 23
3.8. "value-length" . . . . . . . . . . . . . . . . . . . . . 23
3.9. (Attribute) "value" . . . . . . . . . . . . . . . . . . . 24
3.10. Data . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. Encoding of Transport Layer . . . . . . . . . . . . . . . . . 26
4.1. Printer URI, Job URI, and Job ID . . . . . . . . . . . . 26
5. IPP URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Internationalization Considerations . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. Security Conformance Requirements . . . . . . . . . . . . 31
8.1.1. Digest Authentication . . . . . . . . . . . . . . . . 32
8.1.2. Transport Layer Security (TLS) . . . . . . . . . . . 32
8.2. Using IPP with TLS . . . . . . . . . . . . . . . . . . . 33
9. Interoperability with Other IPP Versions . . . . . . . . . . 33
9.1. The "version-number" Parameter . . . . . . . . . . . . . 34
9.2. Security and URI Schemes . . . . . . . . . . . . . . . . 34
10. Changes since RFC 2910 . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Protocol Examples . . . . . . . . . . . . . . . . . 40
A.1. Print-Job Request . . . . . . . . . . . . . . . . . . . . 40
A.2. Print-Job Response (Successful) . . . . . . . . . . . . . 41
A.3. Print-Job Response (Failure) . . . . . . . . . . . . . . 42
A.4. Print-Job Response (Success with Attributes Ignored) . . 43
A.5. Print-URI Request . . . . . . . . . . . . . . . . . . . . 45
A.6. Create-Job Request . . . . . . . . . . . . . . . . . . . 46
A.7. Create-Job Request with Collection Attributes . . . . . . 46
A.8. Get-Jobs Request . . . . . . . . . . . . . . . . . . . . 48
A.9. Get-Jobs Response . . . . . . . . . . . . . . . . . . . . 49
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
4. Encoding of Transport Layer . . . . . . . . . . . . . . . . . 26
4.1. Printer URI, Job URI, and Job ID . . . . . . . . . . . . 26
5. IPP URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Internationalization Considerations . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. Security Conformance Requirements . . . . . . . . . . . . 31
8.1.1. Digest Authentication . . . . . . . . . . . . . . . . 32
8.1.2. Transport Layer Security (TLS) . . . . . . . . . . . 32
8.2. Using IPP with TLS . . . . . . . . . . . . . . . . . . . 33
9. Interoperability with Other IPP Versions . . . . . . . . . . 33
9.1. The "version-number" Parameter . . . . . . . . . . . . . 34
9.2. Security and URI Schemes . . . . . . . . . . . . . . . . 34
10. Changes since RFC 2910 . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Protocol Examples . . . . . . . . . . . . . . . . . 40
A.1. Print-Job Request . . . . . . . . . . . . . . . . . . . . 40
A.2. Print-Job Response (Successful) . . . . . . . . . . . . . 41
A.3. Print-Job Response (Failure) . . . . . . . . . . . . . . 42
A.4. Print-Job Response (Success with Attributes Ignored) . . 43
A.5. Print-URI Request . . . . . . . . . . . . . . . . . . . . 45
A.6. Create-Job Request . . . . . . . . . . . . . . . . . . . 46
A.7. Create-Job Request with Collection Attributes . . . . . . 46
A.8. Get-Jobs Request . . . . . . . . . . . . . . . . . . . . 48
A.9. Get-Jobs Response . . . . . . . . . . . . . . . . . . . . 49
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
This document contains the rules for encoding IPP operations and describes two layers: the transport layer and the operation layer.
本文档包含IPP操作编码规则，并描述了两层：传输层和操作层。
The transport layer consists of an HTTP request and response. All IPP implementations support HTTP/1.1, the relevant parts of which are described in the following RFCs:
传输层由HTTP请求和响应组成。所有IPP实现都支持HTTP/1.1，其相关部分在以下RFC中描述：
o Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing [RFC7230]
o 超文本传输协议（HTTP/1.1）：消息语法和路由[RFC7230]
o Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content [RFC7231]
o 超文本传输协议（HTTP/1.1）：语义和内容[RFC7231]
o Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests [RFC7232]
o 超文本传输协议（HTTP/1.1）：条件请求[RFC7232]
o Hypertext Transfer Protocol (HTTP/1.1): Caching [RFC7234]
o 超文本传输协议（HTTP/1.1）：缓存[RFC7234]
o Hypertext Transfer Protocol (HTTP/1.1): Authentication [RFC7235]
o 超文本传输协议（HTTP/1.1）：身份验证[RFC7235]
o The 'Basic' HTTP Authentication Scheme [RFC7617]
o “基本”HTTP身份验证方案[RFC7617]
o HTTP Digest Access Authentication [RFC7616]
o HTTP摘要访问身份验证[RFC7616]
IPP implementations can support HTTP/2, which is described in the following RFCs:
IPP实现可以支持HTTP/2，这在以下RFC中进行了描述：
o Hypertext Transfer Protocol Version 2 (HTTP/2) [RFC7540]
o 超文本传输协议版本2（HTTP/2）[RFC7540]
o HPACK - Header Compression for HTTP/2 [RFC7541]
o HPACK-HTTP/2的头压缩[RFC7541]
This document specifies the HTTP headers that an IPP implementation supports.
本文档指定IPP实现支持的HTTP头。
The operation layer consists of a message body in an HTTP request or response. The "Internet Printing Protocol/1.1: Model and Semantics" document [RFC8011] and subsequent extensions (collectively known as the IPP Model) define the semantics of such a message body and the supported values. This document specifies the encoding of an IPP request and response message.
操作层由HTTP请求或响应中的消息体组成。“Internet打印协议/1.1：模型和语义”文档[RFC8011]和后续扩展（统称为IPP模型）定义了此类消息体的语义和支持的值。本文档指定IPP请求和响应消息的编码。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Client: Initiator of outgoing IPP session requests and sender of outgoing IPP operation requests (Hypertext Transfer Protocol -- HTTP/1.1 [RFC7230] User Agent).
客户端：传出IPP会话请求的发起方和传出IPP操作请求的发送方（超文本传输协议——HTTP/1.1[RFC7230]用户代理）。
Document: An object created and managed by a Printer that contains description, processing, and status information. A Document object may have attached data and is bound to a single Job.
文档：由打印机创建和管理的对象，包含描述、处理和状态信息。文档对象可能具有附加数据，并绑定到单个作业。
'ipp' URI: An IPP URI as defined in [RFC3510].
“ipp”URI:[RFC3510]中定义的ipp URI。
'ipps' URI: An IPPS URI as defined in [RFC7472].
“ipps”URI:[RFC7472]中定义的ipps URI。
Job: An object created and managed by a Printer that contains description, processing, and status information. The Job also contains zero or more Document objects.
作业：由打印机创建和管理的对象，包含描述、处理和状态信息。作业还包含零个或多个文档对象。
Logical Device: A print server, software service, or gateway that processes Jobs and either forwards or stores the processed Job or uses one or more Physical Devices to render output.
逻辑设备：打印服务器、软件服务或网关，用于处理作业并转发或存储处理后的作业，或使用一个或多个物理设备呈现输出。
Model: The semantics of operations, attributes, values, and status-codes used in the Internet Printing Protocol as defined in the Internet Printing Protocol/1.1: Model and Semantics document [RFC8011] and subsequent extensions.
模型：互联网打印协议中使用的操作、属性、值和状态代码的语义，如互联网打印协议/1.1：模型和语义文档[RFC8011]及后续扩展中所定义。
Output Device: A single Logical or Physical Device.
输出设备：单个逻辑或物理设备。
Physical Device: A hardware implementation of an endpoint device, e.g., a marking engine, a fax modem, etc.
物理设备：终端设备的硬件实现，例如标记引擎、传真调制解调器等。
Printer: Listener for incoming IPP session requests and receiver of incoming IPP operation requests (Hypertext Transfer Protocol -- HTTP/1.1 [RFC7230] Server) that represents one or more Physical Devices or a Logical Device.
打印机：传入IPP会话请求的侦听器和传入IPP操作请求的接收器（超文本传输协议——HTTP/1.1[RFC7230]服务器），表示一个或多个物理设备或逻辑设备。
ABNF: Augmented Backus-Naur Form [RFC5234]
ABNF：扩充的巴科斯诺尔表[RFC5234]
ASCII: American Standard Code for Information Interchange [RFC20]
ASCII：美国信息交换标准代码[RFC20]
HTTP: Hypertext Transfer Protocol [RFC7230]
HTTP：超文本传输协议[RFC7230]
HTTPS: HTTP over TLS [RFC2818]
HTTPS:HTTP over TLS[RFC2818]
IANA: Internet Assigned Numbers Authority
IANA：互联网分配号码管理局
IEEE: Institute of Electrical and Electronics Engineers
IEEE：电气和电子工程师学会
IESG: Internet Engineering Steering Group
IESG：互联网工程指导小组
IPP: Internet Printing Protocol (this document and [PWG5100.12])
IPP：互联网打印协议（本文件和[PWG5100.12]）
ISTO: IEEE Industry Standards and Technology Organization
ISTO:IEEE行业标准和技术组织
LPD: Line Printer Daemon Protocol [RFC1179]
LPD：行打印机守护程序协议[RFC1179]
PWG: IEEE-ISTO Printer Working Group
PWG:IEEE-ISTO打印机工作组
RFC: Request for Comments
RFC：征求意见
TCP: Transmission Control Protocol [RFC793]
TCP：传输控制协议[RFC793]
TLS: Transport Layer Security [RFC5246]
TLS：传输层安全性[RFC5246]
URI: Uniform Resource Identifier [RFC3986]
URI:统一资源标识符[RFC3986]
URL: Uniform Resource Locator [RFC3986]
URL:统一资源定位器[RFC3986]
UTF-8: Unicode Transformation Format - 8-bit [RFC3629]
UTF-8:Unicode转换格式-8位[RFC3629]
The operation layer is the message body part of the HTTP request or response and it MUST contain a single IPP operation request or IPP operation response. Each request or response consists of a sequence of values and attribute groups. Attribute groups consist of a sequence of attributes each of which is a name and value. Names and values are ultimately sequences of octets.
操作层是HTTP请求或响应的消息体部分，它必须包含单个IPP操作请求或IPP操作响应。每个请求或响应由一系列值和属性组组成。属性组由一系列属性组成，每个属性都是名称和值。名称和值最终是八位字节序列。
The encoding consists of octets as the most primitive type. There are several types built from octets, but three important types are integers, character strings, and octet strings, on which most other
编码由最原始的八位字节组成。有几种类型是由八位字节构建的，但有三种重要类型是整数、字符串和八位字节字符串，而大多数其他类型都基于这些类型
data types are built. Every character string in this encoding MUST be a sequence of characters where the characters are associated with some charset [RFC2978] and some natural language. A character string MUST be in "reading order" with the first character in the value (according to reading order) being the first character in the encoding. A character string whose associated charset is US-ASCII and whose associated natural language is US English is henceforth called a US-ASCII-STRING. A character string whose associated charset and natural language are specified in a request or response as described in the Model is henceforth called a LOCALIZED-STRING. An octet string MUST be in "Model order" with the first octet in the value (according to the Model order) being the first octet in the encoding. Every integer in this encoding MUST be encoded as a signed integer using two's-complement binary encoding with big-endian format (also known as "network order" and "most significant byte first"). The number of octets for an integer MUST be 1, 2, or 4, depending on usage in the protocol. A one-octet integer, henceforth called a SIGNED-BYTE, is used for the version-number and tag fields. A two-byte integer, henceforth called a SIGNED-SHORT, is used for the operation-id, status-code, and length fields. A four-byte integer, henceforth called a SIGNED-INTEGER, is used for value fields and the request-id.
构建数据类型。此编码中的每个字符串必须是一个字符序列，其中的字符与某些字符集[RFC2978]和某些自然语言相关联。字符串必须是“读取顺序”，值中的第一个字符（根据读取顺序）是编码中的第一个字符。与其关联的字符集为US-ASCII且其关联的自然语言为US-English的字符串从此被称为US-ASCII-string。如模型中所述，其相关字符集和自然语言在请求或响应中指定的字符串从此被称为本地化字符串。八位字节字符串必须是“模型顺序”，值中的第一个八位字节（根据模型顺序）是编码中的第一个八位字节。此编码中的每个整数都必须使用big-endian格式的双补二进制编码（也称为“网络顺序”和“最高有效字节优先”）编码为有符号整数。整数的八位字节数必须为1、2或4，具体取决于协议中的用法。版本号和标记字段使用一个八位整数，此后称为有符号字节。两字节整数（此后称为有符号短整数）用于操作id、状态代码和长度字段。四字节整数（此后称为有符号整数）用于值字段和请求id。
The following two sections present the encoding of the operation layer in two ways:
以下两部分以两种方式介绍操作层的编码：
o informally through pictures and description
o 非正式地通过图片和描述
o formally through Augmented Backus-Naur Form (ABNF), as specified by RFC 5234 [RFC5234]
o 按照RFC 5234[RFC5234]的规定，正式通过扩充的巴科斯诺尔表格（ABNF）
An operation request or response MUST use the encoding described in these two sections.
操作请求或响应必须使用这两部分中描述的编码。
An operation request or response is encoded as follows:
操作请求或响应编码如下：
-----------------------------------------------
| version-number | 2 bytes - required
-----------------------------------------------
| operation-id (request) |
| or | 2 bytes - required
| status-code (response) |
-----------------------------------------------
| request-id | 4 bytes - required
-----------------------------------------------
| attribute-group | n bytes - 0 or more
-----------------------------------------------
| end-of-attributes-tag | 1 byte - required
-----------------------------------------------
| data | q bytes - optional
-----------------------------------------------
-----------------------------------------------
| version-number | 2 bytes - required
-----------------------------------------------
| operation-id (request) |
| or | 2 bytes - required
| status-code (response) |
-----------------------------------------------
| request-id | 4 bytes - required
-----------------------------------------------
| attribute-group | n bytes - 0 or more
-----------------------------------------------
| end-of-attributes-tag | 1 byte - required
-----------------------------------------------
| data | q bytes - optional
-----------------------------------------------
Figure 1: IPP Message Format
图1:IPP消息格式
The first three fields in the above diagram contain the value of attributes described in Section 4.1.1 of the Model and Semantics document [RFC8011].
上图中的前三个字段包含模型和语义文档[RFC8011]第4.1.1节中描述的属性值。
The fourth field is the "attribute-group" field, and it occurs 0 or more times. Each "attribute-group" field represents a single group of attributes, such as an Operation Attributes group or a Job Attributes group (see the Model). The Model specifies the required attribute groups and their order for each operation request and response.
第四个字段是“属性组”字段，它出现0次或更多次。每个“属性组”字段表示一组属性，例如操作属性组或作业属性组（请参见模型）。该模型为每个操作请求和响应指定所需的属性组及其顺序。
The "end-of-attributes-tag" field is always present, even when the "data" is not present. The Model specifies whether the "data" field is present for each operation request and response.
“属性结束标记”字段始终存在，即使“数据”不存在。模型指定每个操作请求和响应是否存在“数据”字段。
Each "attribute-group" field is encoded as follows:
每个“属性组”字段的编码如下：
-----------------------------------------------
| begin-attribute-group-tag | 1 byte
----------------------------------------------------------
| attribute | p bytes |- 0 or more
----------------------------------------------------------
-----------------------------------------------
| begin-attribute-group-tag | 1 byte
----------------------------------------------------------
| attribute | p bytes |- 0 or more
----------------------------------------------------------
Figure 2: Attribute Group Encoding
图2：属性组编码
An "attribute-group" field contains zero or more "attribute" fields.
“属性组”字段包含零个或多个“属性”字段。
Note that the values of the "begin-attribute-group-tag" field and the "end-of-attributes-tag" field are called "delimiter-tags".
请注意，“开始属性组标记”字段和“结束属性标记”字段的值称为“分隔符标记”。
An "attribute" field is encoded as follows:
“属性”字段编码如下：
-----------------------------------------------
| attribute-with-one-value | q bytes
----------------------------------------------------------
| additional-value | r bytes |- 0 or more
----------------------------------------------------------
-----------------------------------------------
| attribute-with-one-value | q bytes
----------------------------------------------------------
| additional-value | r bytes |- 0 or more
----------------------------------------------------------
Figure 3: Attribute Encoding
图3：属性编码
When an attribute is single valued (e.g., "copies" with a value of 10) or multi-valued with one value (e.g., "sides-supported" with just the value 'one-sided'), it is encoded with just an "attribute-with-one-value" field. When an attribute is multi-valued with n values (e.g., "sides-supported" with the values 'one-sided' and 'two-sided-long-edge'), it is encoded with an "attribute-with-one-value" field followed by n-1 "additional-value" fields.
当一个属性是单值属性（例如，值为10的“副本”）或一个值的多值属性（例如，值为“单侧”的“支持的边”是多值属性）时，它只使用一个“值为一的属性”字段进行编码。当一个属性是具有n个值的多值属性时（例如，“支持的边”的值为“单边”和“双面长边”），它将使用“具有一个值的属性”字段和n-1个“附加值”字段进行编码。
Each "attribute-with-one-value" field is encoded as follows:
每个“具有一个值的属性”字段的编码如下：
-----------------------------------------------
| value-tag | 1 byte
-----------------------------------------------
| name-length (value is u) | 2 bytes
-----------------------------------------------
| name | u bytes
-----------------------------------------------
| value-length (value is v) | 2 bytes
-----------------------------------------------
| value | v bytes
-----------------------------------------------
-----------------------------------------------
| value-tag | 1 byte
-----------------------------------------------
| name-length (value is u) | 2 bytes
-----------------------------------------------
| name | u bytes
-----------------------------------------------
| value-length (value is v) | 2 bytes
-----------------------------------------------
| value | v bytes
-----------------------------------------------
Figure 4: Single Value Attribute Encoding
图4：单值属性编码
An "attribute-with-one-value" field is encoded with five subfields:
“具有一个值的属性”字段由五个子字段编码：
o The "value-tag" field specifies the attribute syntax, e.g., 0x44 for the attribute syntax 'keyword'.
o “值标记”字段指定属性语法，例如属性语法“关键字”的0x44。
o The "name-length" field specifies the length of the "name" field in bytes, e.g., u in the above diagram or 15 for the name "sides-supported".
o “名称长度”字段以字节为单位指定“名称”字段的长度，例如上图中的u或15表示名称“受支持的边”。
o The "name" field contains the textual name of the attribute, e.g., "sides-supported".
o “名称”字段包含属性的文本名称，例如“支持的边”。
o The "value-length" field specifies the length of the "value" field in bytes, e.g., v in the above diagram or 9 for the (keyword) value 'one-sided'.
o “值长度”字段以字节为单位指定“值”字段的长度，如上图中的v或（关键字）值“单边”的9。
o The "value" field contains the value of the attribute, e.g., the textual value 'one-sided'.
o “值”字段包含属性值，例如文本值“单边”。
Each "additional-value" field is encoded as follows:
每个“附加值”字段编码如下：
-----------------------------------------------
| value-tag | 1 byte
-----------------------------------------------
| name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| value-length (value is w) | 2 bytes
-----------------------------------------------
| value | w bytes
-----------------------------------------------
-----------------------------------------------
| value-tag | 1 byte
-----------------------------------------------
| name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| value-length (value is w) | 2 bytes
-----------------------------------------------
| value | w bytes
-----------------------------------------------
Figure 5: Additional Attribute Value Encoding
图5：附加属性值编码
An "additional-value" is encoded with four subfields:
“附加值”由四个子字段编码：
o The "value-tag" field specifies the attribute syntax, e.g., 0x44 for the attribute syntax 'keyword'.
o “值标记”字段指定属性语法，例如属性语法“关键字”的0x44。
o The "name-length" field has the value of 0 in order to signify that it is an "additional-value". The value of the "name-length" field distinguishes an "additional-value" field ("name-length" is 0) from an "attribute-with-one-value" field ("name-length" is not 0).
o “名称长度”字段的值为0，表示它是一个“附加值”。“名称长度”字段的值将“附加值”字段（“名称长度”为0）与“具有一个值的属性”字段（“名称长度”不是0）区分开来。
o The "value-length" field specifies the length of the "value" field in bytes, e.g., w in the above diagram or 19 for the (keyword) value 'two-sided-long-edge'.
o “值长度”字段以字节为单位指定“值”字段的长度，例如上图中的w或（关键字）值“双面长边”的19。
o The "value" field contains the value of the attribute, e.g., the textual value 'two-sided-long-edge'.
o “值”字段包含属性值，例如文本值“双面长边”。
Collection attributes create a named group containing related "member" attributes. The "attribute-with-one-value" field for a collection attribute is encoded as follows:
集合属性创建包含相关“成员”属性的命名组。集合属性的“具有一个值的属性”字段编码如下：
-----------------------------------------------
| value-tag (value is 0x34) | 1 byte
-----------------------------------------------
| name-length (value is u) | 2 bytes
-----------------------------------------------
| name | u bytes
-----------------------------------------------
| value-length (value is 0x0000) | 2 bytes
-----------------------------------------------------------
| member-attribute | q bytes |-0 or more
-----------------------------------------------------------
| end-value-tag (value is 0x37) | 1 byte
-----------------------------------------------
| end-name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| end-value-length (value is 0x0000) | 2 bytes
-----------------------------------------------
-----------------------------------------------
| value-tag (value is 0x34) | 1 byte
-----------------------------------------------
| name-length (value is u) | 2 bytes
-----------------------------------------------
| name | u bytes
-----------------------------------------------
| value-length (value is 0x0000) | 2 bytes
-----------------------------------------------------------
| member-attribute | q bytes |-0 or more
-----------------------------------------------------------
| end-value-tag (value is 0x37) | 1 byte
-----------------------------------------------
| end-name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| end-value-length (value is 0x0000) | 2 bytes
-----------------------------------------------
Figure 6: Collection Attribute Encoding
图6：集合属性编码
Collection attribute is encoded with eight subfields:
集合属性由八个子字段编码：
o The "value-tag" field specifies the start attribute syntax: 0x34 for the attribute syntax 'begCollection'.
o “值标记”字段指定属性语法“begCollection”的开始属性语法：0x34。
o The "name-length" field specifies the length of the "name" field in bytes, e.g., u in the above diagram or 9 for the name "media-col". Additional collection attribute values use a name length of 0x0000.
o “名称长度”字段以字节为单位指定“名称”字段的长度，例如上图中的u或9表示名称“媒体列”。其他集合属性值使用的名称长度为0x0000。
o The "name" field contains the textual name of the attribute, e.g., "media-col".
o “名称”字段包含属性的文本名称，例如“媒体列”。
o The "value-length" field specifies a length of 0x0000.
o “值长度”字段指定长度为0x0000。
o The "member-attribute" field contains member attributes encoded as defined in Section 3.1.7.
o “成员属性”字段包含按照第3.1.7节定义编码的成员属性。
o The "end-value-tag" field specifies the end attribute syntax: 0x37 for the attribute syntax 'endCollection'.
o “end value tag”字段为属性语法“endCollection”指定end属性语法：0x37。
o The "end-name-length" field specifies a length of 0x0000.
o “结束名称长度”字段指定长度0x0000。
o The "end-value-length" field specifies a length of 0x0000.
o “结束值长度”字段指定长度0x0000。
Each "member-attribute" field is encoded as follows:
每个“成员属性”字段的编码如下：
-----------------------------------------------
| value-tag (value is 0x4a) | 1 byte
-----------------------------------------------
| name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| value-length (value is w) | 2 bytes
-----------------------------------------------
| value (member-name) | w bytes
-----------------------------------------------
| member-value-tag | 1 byte
-----------------------------------------------
| name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| member-value-length (value is x) | 2 bytes
-----------------------------------------------
| member-value | x bytes
-----------------------------------------------
-----------------------------------------------
| value-tag (value is 0x4a) | 1 byte
-----------------------------------------------
| name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| value-length (value is w) | 2 bytes
-----------------------------------------------
| value (member-name) | w bytes
-----------------------------------------------
| member-value-tag | 1 byte
-----------------------------------------------
| name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| member-value-length (value is x) | 2 bytes
-----------------------------------------------
| member-value | x bytes
-----------------------------------------------
Figure 7: Member Attribute Encoding
图7：成员属性编码
A "member-attribute" is encoded with eight subfields:
“成员属性”由八个子字段编码：
o The "value-tag" field specifies 0x4a for the attribute syntax 'memberAttrName'.
o “值标记”字段为属性语法“memberAttrName”指定0x4a。
o The "name-length" field has the value of 0 in order to signify that it is a "member-attribute" contained in the collection.
o “名称长度”字段的值为0，表示它是集合中包含的“成员属性”。
o The "value-length" field specifies the length of the "value" field in bytes, e.g., w in the above diagram or 10 for the member attribute name 'media-type'. Additional member attribute values are specified using a value length of 0.
o “值长度”字段以字节为单位指定“值”字段的长度，例如，上图中的w或成员属性名称“媒体类型”的10。使用值长度0指定其他成员属性值。
o The "value" field contains the name of the member attribute, e.g., the textual value 'media-type'.
o “值”字段包含成员属性的名称，例如文本值“媒体类型”。
o The "member-value-tag" field specifies the attribute syntax for the member attribute, e.g., 0x44 for the attribute syntax 'keyword'.
o “成员值标记”字段指定成员属性的属性语法，例如属性语法“关键字”的0x44。
o The second "name-length" field has the value of 0 in order to signify that it is a "member-attribute" contained in the collection.
o 第二个“名称长度”字段的值为0，表示它是集合中包含的“成员属性”。
o The "member-value-length" field specifies the length of the member attribute value, e.g., x in the above diagram or 10 for the value 'stationery'.
o “成员值长度”字段指定成员属性值的长度，如上图中的x或“信纸”值的10。
o The "member-value" field contains the value of the attribute, e.g., the textual value 'stationery'.
o “成员值”字段包含属性值，例如文本值“信纸”。
From the standpoint of a parser that performs an action based on a "tag" value, the encoding consists of:
从基于“标记”值执行操作的解析器的角度来看，编码包括：
-----------------------------------------------
| version-number | 2 bytes - required
-----------------------------------------------
| operation-id (request) |
| or | 2 bytes - required
| status-code (response) |
-----------------------------------------------
| request-id | 4 bytes - required
-----------------------------------------------------------
| tag (delimiter-tag or value-tag) | 1 byte |
----------------------------------------------- |-0 or more
| empty or rest of attribute | x bytes |
-----------------------------------------------------------
| end-of-attributes-tag | 1 byte - required
-----------------------------------------------
| data | y bytes - optional
-----------------------------------------------
-----------------------------------------------
| version-number | 2 bytes - required
-----------------------------------------------
| operation-id (request) |
| or | 2 bytes - required
| status-code (response) |
-----------------------------------------------
| request-id | 4 bytes - required
-----------------------------------------------------------
| tag (delimiter-tag or value-tag) | 1 byte |
----------------------------------------------- |-0 or more
| empty or rest of attribute | x bytes |
-----------------------------------------------------------
| end-of-attributes-tag | 1 byte - required
-----------------------------------------------
| data | y bytes - optional
-----------------------------------------------
Figure 8: Encoding Based on Value Tags
图8：基于值标记的编码
The following shows what fields the parser would expect after each type of "tag":
下面显示了解析器在每种类型的“标记”之后需要哪些字段：
o "begin-attribute-group-tag": expect zero or more "attribute" fields
o “开始属性组标记”：预期零个或多个“属性”字段
o "value-tag": expect the remainder of an "attribute-with-one-value" or an "additional-value"
o “值标记”：预期“具有一个值的属性”或“附加值”的剩余部分
o "end-of-attributes-tag": expect that "attribute" fields are complete and there is optional "data"
o “属性结束标记”：期望“属性”字段完整，并且有可选的“数据”
The ABNF [RFC5234] syntax for an IPP message is shown in Figure 9.
IPP消息的ABNF[RFC5234]语法如图9所示。
ipp-message = ipp-request / ipp-response ipp-request = version-number operation-id request-id *attribute-group end-of-attributes-tag data ipp-response = version-number status-code request-id *attribute-group end-of-attributes-tag data
ipp消息=ipp请求/ipp响应ipp请求=版本号操作id请求id*属性组属性标记数据结尾ipp响应=版本号状态代码请求id*属性组属性标记数据结尾
version-number = major-version-number minor-version-number major-version-number = SIGNED-BYTE minor-version-number = SIGNED-BYTE
版本号=主要版本号次要版本号主要版本号=有符号字节次要版本号=有符号字节
operation-id = SIGNED-SHORT ; mapping from model
status-code = SIGNED-SHORT ; mapping from model
request-id = SIGNED-INTEGER ; whose value is > 0
operation-id = SIGNED-SHORT ; mapping from model
status-code = SIGNED-SHORT ; mapping from model
request-id = SIGNED-INTEGER ; whose value is > 0
attribute-group = begin-attribute-group-tag *attribute attribute = attribute-with-one-value *additional-value attribute-with-one-value = value-tag name-length name value-length value additional-value = value-tag zero-name-length value-length value
属性组=开始属性组标记*属性属性=具有一个值的属性*具有一个值的附加值属性=值标记名称长度名称值长度值附加值=值标记零名称长度值长度值
name-length = SIGNED-SHORT ; number of octets of 'name'
name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )
value-length = SIGNED-SHORT ; number of octets of 'value'
value = OCTET-STRING
data = OCTET-STRING
name-length = SIGNED-SHORT ; number of octets of 'name'
name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )
value-length = SIGNED-SHORT ; number of octets of 'value'
value = OCTET-STRING
data = OCTET-STRING
zero-name-length = %x00.00 ; name-length of 0
value-tag = %x10-ff ; see Section 3.5.2
begin-attribute-group-tag = %x00-02 / %x04-0f ; see Section 3.5.1
end-of-attributes-tag = %x03 ; tag of 3
; see Section 3.5.1
zero-name-length = %x00.00 ; name-length of 0
value-tag = %x10-ff ; see Section 3.5.2
begin-attribute-group-tag = %x00-02 / %x04-0f ; see Section 3.5.1
end-of-attributes-tag = %x03 ; tag of 3
; see Section 3.5.1
SIGNED-BYTE = BYTE
SIGNED-SHORT = 2BYTE
SIGNED-INTEGER = 4BYTE
DIGIT = %x30-39 ; "0" to "9"
LALPHA = %x61-7A ; "a" to "z"
BYTE = %x00-ff
OCTET-STRING = *BYTE
SIGNED-BYTE = BYTE
SIGNED-SHORT = 2BYTE
SIGNED-INTEGER = 4BYTE
DIGIT = %x30-39 ; "0" to "9"
LALPHA = %x61-7A ; "a" to "z"
BYTE = %x00-ff
OCTET-STRING = *BYTE
Figure 9: ABNF of IPP Message Format
图9:IPP报文格式的ABNF
Figure 10 defines additional terms that are referenced in this document and provides an alternate grouping of the delimiter tags.
图10定义了本文档中引用的其他术语，并提供了分隔符标记的备选分组。
delimiter-tag = begin-attribute-group-tag / ; see Section 3.5.1
end-of-attributes-tag
begin-attribute-group-tag = %x00 / operation-attributes-tag /
job-attributes-tag / printer-attributes-tag /
unsupported-attributes-tag / future-group-tags
operation-attributes-tag = %x01 ; tag of 1
job-attributes-tag = %x02 ; tag of 2
end-of-attributes-tag = %x03 ; tag of 3
printer-attributes-tag = %x04 ; tag of 4
unsupported-attributes-tag = %x05 ; tag of 5
future-group-tags = %x06-0f ; future extensions
delimiter-tag = begin-attribute-group-tag / ; see Section 3.5.1
end-of-attributes-tag
begin-attribute-group-tag = %x00 / operation-attributes-tag /
job-attributes-tag / printer-attributes-tag /
unsupported-attributes-tag / future-group-tags
operation-attributes-tag = %x01 ; tag of 1
job-attributes-tag = %x02 ; tag of 2
end-of-attributes-tag = %x03 ; tag of 3
printer-attributes-tag = %x04 ; tag of 4
unsupported-attributes-tag = %x05 ; tag of 5
future-group-tags = %x06-0f ; future extensions
Figure 10: ABNF for Attribute Group Tags
图10：属性组标记的ABNF
Each "attribute-group" field MUST be encoded with the "begin-attribute-group-tag" field followed by zero or more "attribute" sub-fields.
每个“属性组”字段必须编码为“开始属性组标记”字段，后跟零个或多个“属性”子字段。
Table 1 maps the Model group name to value of the "begin-attribute-group-tag" field:
表1将模型组名称映射到“开始属性组标记”字段的值：
+----------------+--------------------------------------------------+
| Model Document | "begin-attribute-group-tag" field values |
| Group | |
+----------------+--------------------------------------------------+
| Operation | "operations-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Job Template | "job-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Job Object | "job-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Unsupported | "unsupported-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Requested | (Get-Job-Attributes) "job-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Requested | (Get-Printer-Attributes)"printer-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Document | in a special position at the end of the message |
| Content | as described in Section 3.1.1. |
+----------------+--------------------------------------------------+
+----------------+--------------------------------------------------+
| Model Document | "begin-attribute-group-tag" field values |
| Group | |
+----------------+--------------------------------------------------+
| Operation | "operations-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Job Template | "job-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Job Object | "job-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Unsupported | "unsupported-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Requested | (Get-Job-Attributes) "job-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Requested | (Get-Printer-Attributes)"printer-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Document | in a special position at the end of the message |
| Content | as described in Section 3.1.1. |
+----------------+--------------------------------------------------+
Table 1: Group Values
表1：组值
For each operation request and response, the Model prescribes the required and optional attribute groups, along with their order. Within each attribute group, the Model prescribes the required and optional attributes, along with their order.
对于每个操作请求和响应，模型规定了必需的和可选的属性组及其顺序。在每个属性组中，模型规定了必需和可选属性及其顺序。
When the Model requires an attribute group in a request or response and the attribute group contains zero attributes, a request or response SHOULD encode the attribute group with the "begin-attribute-group-tag" field followed by zero "attribute" fields. For example, if the Client requests a single unsupported attribute with the Get-Printer-Attributes operation, the Printer MUST return no "attribute" fields, and it SHOULD return a "begin-attribute-group-tag" field for the Printer Attributes group. The Unsupported Attributes group is not such an example. According to the Model, the Unsupported Attributes group SHOULD be present only if the Unsupported Attributes group contains at least one attribute.
当模型需要请求或响应中的属性组，且属性组包含零个属性时，请求或响应应使用“开始属性组标记”字段和零个“属性”字段对属性组进行编码。例如，如果客户端使用“获取打印机属性”操作请求单个不受支持的属性，则打印机必须不返回“属性”字段，并且应为打印机属性组返回“开始属性组标记”字段。不支持的属性组不是这样的示例。根据模型，仅当不支持的属性组至少包含一个属性时，不支持的属性组才应存在。
A receiver of a request MUST be able to process the following as equivalent empty attribute groups:
请求的接收者必须能够将以下内容作为等效的空属性组进行处理：
a. A "begin-attribute-group-tag" field with zero following "attribute" fields.
a. “开始属性组标记”字段，其后的“属性”字段为零。
b. A missing, but expected, "begin-attribute-group-tag" field.
b. 缺少但应为“开始属性组标记”字段。
When the Model requires a sequence of an unknown number of attribute groups, each of the same type, the encoding MUST contain one "begin-attribute-group-tag" field for each attribute group, even when an "attribute-group" field contains zero "attribute" sub-fields. For example, the Get-Jobs operation may return zero attributes for some Jobs and not others. The "begin-attribute-group-tag" field followed by zero "attribute" fields tells the recipient that there is a Job in queue for which no information is available except that it is in the queue.
当模型需要未知数量的属性组序列时，每个属性组的类型相同，编码必须为每个属性组包含一个“开始属性组标记”字段，即使“属性组”字段包含零个“属性”子字段。例如，“获取作业”操作可能会为某些作业返回零属性，而不是其他作业。“begin attribute group tag”字段后跟零个“attribute”字段，告诉收件人队列中有一个作业，除了该作业在队列中之外，没有其他可用信息。
Some operation elements are called parameters in the Model. They MUST be encoded in a special position and they MUST NOT appear as operation attributes. These parameters are described in the subsections below.
一些操作元素在模型中称为参数。它们必须在特殊位置进行编码，并且不能作为操作属性出现。这些参数在下面的小节中描述。
The "version-number" field consists of a major and minor version-number, each of which is represented by a SIGNED-BYTE. The major version-number is the first byte of the encoding and the minor version-number is the second byte of the encoding. The protocol described in [RFC8011] has a major version-number of 1 (0x01) and a minor version-number of 1 (0x01). The ABNF for these two bytes is %x01.01.
“版本号”字段由主版本号和次版本号组成，每个版本号都由带符号字节表示。主版本号是编码的第一个字节，次版本号是编码的第二个字节。[RFC8011]中描述的协议主要版本号为1（0x01），次要版本号为1（0x01）。这两个字节的ABNF为%x01.01。
Note: See Section 9 for more information on the "version-number" field and IPP version numbers.
注：有关“版本号”字段和IPP版本号的更多信息，请参见第9节。
The "operation-id" field contains an operation-id value as defined in the Model. The value is encoded as a SIGNED-SHORT and is located in the third and fourth bytes of the encoding of an operation request.
“操作id”字段包含模型中定义的操作id值。该值被编码为有符号短字符，位于操作请求编码的第三和第四字节中。
The "status-code" field contains a status-code value as defined in the Model. The value is encoded as a SIGNED-SHORT and is located in the third and fourth bytes of the encoding of an operation response.
“状态代码”字段包含模型中定义的状态代码值。该值被编码为有符号短字符，并位于操作响应编码的第三和第四字节中。
If an IPP status-code is returned, then the HTTP status-code MUST be 200 (OK). With any other HTTP status-code value, the HTTP response MUST NOT contain an IPP message body, and thus no IPP status-code is returned.
如果返回IPP状态代码，则HTTP状态代码必须为200（正常）。对于任何其他HTTP状态代码值，HTTP响应不得包含IPP消息正文，因此不会返回IPP状态代码。
The "request-id" field contains the request-id value as defined in the Model. The value is encoded as a SIGNED-INTEGER and is located in the fifth through eighth bytes of the encoding.
“请求id”字段包含模型中定义的请求id值。该值被编码为有符号整数，位于编码的第五到第八个字节中。
There are two kinds of tags:
有两种类型的标记：
o delimiter tags: delimit major sections of the protocol, namely attribute groups and data
o 分隔符标记：分隔协议的主要部分，即属性组和数据
o value tags: specify the type of each attribute value
o 值标记：指定每个属性值的类型
Tags are part of the IANA IPP registry [IANA-IPP]
标签是IANA IPP注册表[IANA-IPP]的一部分
Table 2 specifies the values for the delimiter tags defined in this document. These tags are registered, along with tags defined in other documents, in the "Attribute Group Tags" registry.
表2指定了本文档中定义的分隔符标记的值。这些标记与其他文档中定义的标记一起注册到“属性组标记”注册表中。
+-----------------+------------------------------+
| Tag Value (Hex) | Meaning |
+-----------------+------------------------------+
| 0x00 | Reserved |
| 0x01 | "operation-attributes-tag" |
| 0x02 | "job-attributes-tag" |
| 0x03 | "end-of-attributes-tag" |
| 0x04 | "printer-attributes-tag" |
| 0x05 | "unsupported-attributes-tag" |
+-----------------+------------------------------+
+-----------------+------------------------------+
| Tag Value (Hex) | Meaning |
+-----------------+------------------------------+
| 0x00 | Reserved |
| 0x01 | "operation-attributes-tag" |
| 0x02 | "job-attributes-tag" |
| 0x03 | "end-of-attributes-tag" |
| 0x04 | "printer-attributes-tag" |
| 0x05 | "unsupported-attributes-tag" |
+-----------------+------------------------------+
Table 2: "delimiter-tag" Values
表2：“分隔符标记”值
When a "begin-attribute-group-tag" field occurs in the protocol, it means that zero or more following attributes up to the next group tag are attributes belonging to the attribute group specified by the value of the "begin-attribute-group-tag". For example, if the value of "begin-attribute-group-tag" is 0x01, the following attributes are members of the Operations Attributes group.
当协议中出现“开始属性组标记”字段时，意味着下一个组标记之前的零个或多个后续属性属于“开始属性组标记”值指定的属性组。例如，如果“开始属性组标记”的值为0x01，则以下属性是操作属性组的成员。
The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in an operation and MUST be the last "delimiter-tag". If the operation has a document-data group, the Document data in that group follows the "end-of-attributes-tag".
“属性结束标记”（值0x03）必须在操作中恰好出现一次，并且必须是最后一个“分隔符标记”。如果操作具有文档数据组，则该组中的文档数据将跟随“属性结束标记”。
The order and presence of "attribute-group" fields (whose beginning is marked by the "begin-attribute-group-tag" subfield) for each operation request and each operation response MUST be that defined in the Model.
每个操作请求和每个操作响应的“属性组”字段（其开头由“开始属性组标记”子字段标记）的顺序和存在性必须是模型中定义的顺序和存在性。
A Printer MUST treat a "delimiter-tag" (values from 0x00 through 0x0f) differently from a "value-tag" (values from 0x10 through 0xff) so that the Printer knows there is an entire attribute group as opposed to a single value.
打印机必须将“分隔符标记”（0x00到0x0f的值）与“值标记”（0x10到0xff的值）区别对待，以便打印机知道存在一个完整的属性组，而不是单个值。
The remaining tables show values for the "value-tag" field, which is the first octet of an attribute. The "value-tag" field specifies the type of the value of the attribute.
其余的表显示“值标记”字段的值，该字段是属性的第一个八位字节。“值标记”字段指定属性值的类型。
Table 3 specifies the "out-of-band" values for the "value-tag" field defined in this document. These tags are registered, along with tags defined in other documents, in the "Out-of-Band Attribute Value Tags" registry.
表3规定了本文件中定义的“值标签”字段的“带外”值。这些标记与其他文档中定义的标记一起注册到“带外属性值标记”注册表中。
+-----------------+-------------+
| Tag Value (Hex) | Meaning |
+-----------------+-------------+
| 0x10 | unsupported |
| 0x12 | unknown |
| 0x13 | no-value |
+-----------------+-------------+
+-----------------+-------------+
| Tag Value (Hex) | Meaning |
+-----------------+-------------+
| 0x10 | unsupported |
| 0x12 | unknown |
| 0x13 | no-value |
+-----------------+-------------+
Table 3: Out-of-Band Values
表3：带外值
Table 4 specifies the integer values defined in this document for the "value-tag" field; they are registered in the "Attribute Syntaxes" registry.
表4规定了本文件中为“值标签”字段定义的整数值；它们在“属性语法”注册表中注册。
+----------------+--------------------------------------------------+
| Tag Value | Meaning |
| (Hex) | |
+----------------+--------------------------------------------------+
| 0x20 | Unassigned integer data type (see IANA IPP |
| | registry) |
| 0x21 | integer |
| 0x22 | boolean |
| 0x23 | enum |
| 0x24-0x2f | Unassigned integer data types (see IANA IPP |
| | registry) |
+----------------+--------------------------------------------------+
+----------------+--------------------------------------------------+
| Tag Value | Meaning |
| (Hex) | |
+----------------+--------------------------------------------------+
| 0x20 | Unassigned integer data type (see IANA IPP |
| | registry) |
| 0x21 | integer |
| 0x22 | boolean |
| 0x23 | enum |
| 0x24-0x2f | Unassigned integer data types (see IANA IPP |
| | registry) |
+----------------+--------------------------------------------------+
Table 4: Integer Tags
表4：整数标记
Table 5 specifies the octetString values defined in this document for the "value-tag" field; they are registered in the "Attribute Syntaxes" registry.
表5规定了本文件中为“值标签”字段定义的八进制字符串值；它们在“属性语法”注册表中注册。
+---------------+---------------------------------------------------+
| Tag Value | Meaning |
| (Hex) | |
+---------------+---------------------------------------------------+
| 0x30 | octetString with an unspecified format |
| 0x31 | dateTime |
| 0x32 | resolution |
| 0x33 | rangeOfInteger |
| 0x34 | begCollection |
| 0x35 | textWithLanguage |
| 0x36 | nameWithLanguage |
| 0x37 | endCollection |
| 0x38-0x3f | Unassigned octetString data types (see IANA IPP |
| | registry) |
+---------------+---------------------------------------------------+
+---------------+---------------------------------------------------+
| Tag Value | Meaning |
| (Hex) | |
+---------------+---------------------------------------------------+
| 0x30 | octetString with an unspecified format |
| 0x31 | dateTime |
| 0x32 | resolution |
| 0x33 | rangeOfInteger |
| 0x34 | begCollection |
| 0x35 | textWithLanguage |
| 0x36 | nameWithLanguage |
| 0x37 | endCollection |
| 0x38-0x3f | Unassigned octetString data types (see IANA IPP |
| | registry) |
+---------------+---------------------------------------------------+
Table 5: octetString Tags
表5：八进制字符串标记
Table 6 specifies the character-string values defined in this document for the "value-tag" field; they are registered in the "Attribute Syntaxes" registry.
表6规定了本文件中为“值标签”字段定义的字符串值；它们在“属性语法”注册表中注册。
+---------------+---------------------------------------------------+
| Tag Value | Meaning |
| (Hex) | |
+---------------+---------------------------------------------------+
| 0x40 | Unassigned character-string data type (see IANA |
| | IPP registry) |
| 0x41 | textWithoutLanguage |
| 0x42 | nameWithoutLanguage |
| 0x43 | Unassigned character-string data type (see IANA |
| | IPP registry) |
| 0x44 | keyword |
| 0x45 | uri |
| 0x46 | uriScheme |
| 0x47 | charset |
| 0x48 | naturalLanguage |
| 0x49 | mimeMediaType |
| 0x4a | memberAttrName |
| 0x4b-0x5f | Unassigned character-string data types (see IANA |
| | IPP registry) |
+---------------+---------------------------------------------------+
+---------------+---------------------------------------------------+
| Tag Value | Meaning |
| (Hex) | |
+---------------+---------------------------------------------------+
| 0x40 | Unassigned character-string data type (see IANA |
| | IPP registry) |
| 0x41 | textWithoutLanguage |
| 0x42 | nameWithoutLanguage |
| 0x43 | Unassigned character-string data type (see IANA |
| | IPP registry) |
| 0x44 | keyword |
| 0x45 | uri |
| 0x46 | uriScheme |
| 0x47 | charset |
| 0x48 | naturalLanguage |
| 0x49 | mimeMediaType |
| 0x4a | memberAttrName |
| 0x4b-0x5f | Unassigned character-string data types (see IANA |
| | IPP registry) |
+---------------+---------------------------------------------------+
Table 6: String Tags
表6：字符串标记
Note: An attribute value always has a type, which is explicitly specified by its tag; one such tag value is "nameWithoutLanguage". An attribute's name has an implicit type, which is keyword.
注意：属性值总是有一个类型，该类型由其标记显式指定；一个这样的标记值是“nameWithoutLanguage”。属性的名称有一个隐式类型，即关键字。
The values 0x60-0xff are reserved for future type definitions in Standards Track documents.
值0x60-0xff保留用于标准跟踪文档中未来的类型定义。
The tag 0x7f is reserved for extending types beyond the 255 values available with a single byte. A tag value of 0x7f MUST signify that the first four bytes of the value field are interpreted as the tag value. Note this future extension doesn't affect parsers that are unaware of this special tag. The tag is like any other unknown tag, and the value length specifies the length of a value, which contains a value that the parser treats atomically. Values from 0x00000000 to 0x3fffffff are reserved for definition in future Standards Track documents. The values 0x40000000 to 0x7fffffff are reserved for vendor extensions.
标记0x7f保留用于将类型扩展到单个字节可用的255个值之外。标记值0x7f必须表示值字段的前四个字节被解释为标记值。注意，这个未来的扩展不会影响不知道这个特殊标记的解析器。该标记类似于任何其他未知标记，值长度指定值的长度，该值包含解析器原子处理的值。0x00000000到0x3fffffff之间的值保留用于将来的标准跟踪文档中的定义。0x40000000到0x7fffffff的值保留给供应商扩展。
The "name-length" field consists of a SIGNED-SHORT and specifies the number of octets in the immediately following "name" field. The value of this field excludes the two bytes of the "name-length" field. For example, if the "name" field contains 'sides', the value of this field is 5.
“名称长度”字段由带符号的短字符组成，并在紧跟其后的“名称”字段中指定八位字节数。此字段的值不包括“名称长度”字段的两个字节。例如，如果“名称”字段包含“边”，则该字段的值为5。
If a "name-length" field has a value of zero, the following "name" field is empty and the following value is treated as an additional value for the attribute encoded in the nearest preceding "attribute-with-one-value" field. Within an attribute group, if two or more attributes have the same name, the attribute group is malformed (see [RFC8011]). The zero-length name is the only mechanism for multi-valued attributes.
如果“名称长度”字段的值为零，则以下“名称”字段为空，并且以下值将被视为前一个最近的“具有一个值的属性”字段中编码的属性的附加值。在属性组中，如果两个或多个属性具有相同的名称，则属性组的格式不正确（请参见[RFC8011]）。零长度名称是多值属性的唯一机制。
The "name" field contains the name of an attribute. The Model specifies such names.
“名称”字段包含属性的名称。模型指定了这样的名称。
The "value-length" field consists of a SIGNED-SHORT, which specifies the number of octets in the immediately following "value" field. The value of this field excludes the two bytes of the "value-length" field. For example, if the "value" field contains the keyword (string) value 'one-sided', the value of this field is 9.
“值长度”字段由带符号的短字符组成，它指定紧跟其后的“值”字段中的八位字节数。此字段的值不包括“值长度”字段的两个字节。例如，如果“值”字段包含关键字（字符串）值“单面”，则此字段的值为9。
For any of the types represented by binary signed integers, the sender MUST encode the value in exactly four octets.
对于由二进制有符号整数表示的任何类型，发送方必须将值精确地编码为四个八位字节。
For any of the types represented by binary signed bytes, e.g., the boolean type, the sender MUST encode the value in exactly one octet.
对于二进制有符号字节表示的任何类型，例如布尔类型，发送方必须将值精确编码为一个八位字节。
For any of the types represented by character strings, the sender MUST encode the value with all the characters of the string and without any padding characters.
对于由字符串表示的任何类型，发送方必须使用字符串的所有字符对值进行编码，并且不使用任何填充字符。
For "out-of-band" values for the "value-tag" field defined in this document, such as 'unsupported', the "value-length" MUST be 0 and the "value" empty; the "value" has no meaning when the "value-tag" has one of these "out-of-band" values. For future "out-of-band" "value-tag" fields, the same rule holds unless the definition explicitly states that the "value-length" MAY be non-zero and the "value" non-empty
对于本文档中定义的“值标签”字段的“带外”值，如“不支持”，则“值长度”必须为0，“值”为空；当“值标签”具有其中一个“带外”值时，“值”没有任何意义。对于未来的“带外”值标记字段，相同的规则适用，除非定义明确说明“值长度”可能为非零，“值”可能为非空
The syntax types (specified by the "value-tag" field) and most of the details of the representation of attribute values are defined in the Model. Table 7 augments the information in the Model and defines the syntax types from the Model in terms of the five basic types defined in Section 3. The five types are US-ASCII-STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING.
语法类型（由“value tag”字段指定）和属性值表示的大部分细节都在模型中定义。表7扩充了模型中的信息，并根据第3节中定义的五种基本类型定义了模型中的语法类型。这五种类型是US-ASCII-STRING、本地化-STRING、有符号整数、有符号短、有符号字节和八位字节字符串。
+----------------------+--------------------------------------------+
| Syntax of Attribute | Encoding |
| Value | |
+----------------------+--------------------------------------------+
| textWithoutLanguage, | LOCALIZED-STRING |
| nameWithoutLanguage | |
+----------------------+--------------------------------------------+
| textWithLanguage | OCTET-STRING consisting of four fields: a |
| | SIGNED-SHORT, which is the number of |
| | octets in the following field; a value of |
| | type natural-language; a SIGNED-SHORT, |
| | which is the number of octets in the |
| | following field; and a value of type |
| | textWithoutLanguage. The length of a |
| | textWithLanguage value MUST be 4 + the |
| | value of field a + the value of field c. |
+----------------------+--------------------------------------------+
| nameWithLanguage | OCTET-STRING consisting of four fields: a |
| | SIGNED-SHORT, which is the number of |
| | octets in the following field; a value of |
| | type natural-language; a SIGNED-SHORT, |
| | which is the number of octets in the |
| | following field; and a value of type |
| | nameWithoutLanguage. The length of a |
| | nameWithLanguage value MUST be 4 + the |
| | value of field a + the value of field c. |
+----------------------+--------------------------------------------+
| charset, | US-ASCII-STRING |
| naturalLanguage, | |
| mimeMediaType, | |
| keyword, uri, and | |
| uriScheme | |
+----------------------+--------------------------------------------+
| boolean | SIGNED-BYTE where 0x00 is 'false' and 0x01 |
| | is 'true' |
+----------------------+--------------------------------------------+
| integer and enum | a SIGNED-INTEGER |
+----------------------+--------------------------------------------+
| Syntax of Attribute | Encoding |
| Value | |
+----------------------+--------------------------------------------+
| textWithoutLanguage, | LOCALIZED-STRING |
| nameWithoutLanguage | |
+----------------------+--------------------------------------------+
| textWithLanguage | OCTET-STRING consisting of four fields: a |
| | SIGNED-SHORT, which is the number of |
| | octets in the following field; a value of |
| | type natural-language; a SIGNED-SHORT, |
| | which is the number of octets in the |
| | following field; and a value of type |
| | textWithoutLanguage. The length of a |
| | textWithLanguage value MUST be 4 + the |
| | value of field a + the value of field c. |
+----------------------+--------------------------------------------+
| nameWithLanguage | OCTET-STRING consisting of four fields: a |
| | SIGNED-SHORT, which is the number of |
| | octets in the following field; a value of |
| | type natural-language; a SIGNED-SHORT, |
| | which is the number of octets in the |
| | following field; and a value of type |
| | nameWithoutLanguage. The length of a |
| | nameWithLanguage value MUST be 4 + the |
| | value of field a + the value of field c. |
+----------------------+--------------------------------------------+
| charset, | US-ASCII-STRING |
| naturalLanguage, | |
| mimeMediaType, | |
| keyword, uri, and | |
| uriScheme | |
+----------------------+--------------------------------------------+
| boolean | SIGNED-BYTE where 0x00 is 'false' and 0x01 |
| | is 'true' |
+----------------------+--------------------------------------------+
| integer and enum | a SIGNED-INTEGER |
+----------------------+--------------------------------------------+
| dateTime | OCTET-STRING consisting of eleven octets |
| | whose contents are defined by |
| | "DateAndTime" in RFC 2579 [RFC2579] |
+----------------------+--------------------------------------------+
| resolution | OCTET-STRING consisting of nine octets of |
| | two SIGNED-INTEGERs followed by a SIGNED- |
| | BYTE. The first SIGNED-INTEGER contains |
| | the value of cross-feed direction |
| | resolution. The second SIGNED-INTEGER |
| | contains the value of feed direction |
| | resolution. The SIGNED-BYTE contains the |
| | units value. |
+----------------------+--------------------------------------------+
| rangeOfInteger | Eight octets consisting of two SIGNED- |
| | INTEGERs. The first SIGNED-INTEGER |
| | contains the lower bound and the second |
| | SIGNED-INTEGER contains the upper bound. |
+----------------------+--------------------------------------------+
| 1setOf X | Encoding according to the rules for an |
| | attribute with more than one value. Each |
| | value X is encoded according to the rules |
| | for encoding its type. |
+----------------------+--------------------------------------------+
| octetString | OCTET-STRING |
+----------------------+--------------------------------------------+
| collection | Encoding as defined in Section 3.1.6. |
+----------------------+--------------------------------------------+
+----------------------+--------------------------------------------+
| dateTime | OCTET-STRING consisting of eleven octets |
| | whose contents are defined by |
| | "DateAndTime" in RFC 2579 [RFC2579] |
+----------------------+--------------------------------------------+
| resolution | OCTET-STRING consisting of nine octets of |
| | two SIGNED-INTEGERs followed by a SIGNED- |
| | BYTE. The first SIGNED-INTEGER contains |
| | the value of cross-feed direction |
| | resolution. The second SIGNED-INTEGER |
| | contains the value of feed direction |
| | resolution. The SIGNED-BYTE contains the |
| | units value. |
+----------------------+--------------------------------------------+
| rangeOfInteger | Eight octets consisting of two SIGNED- |
| | INTEGERs. The first SIGNED-INTEGER |
| | contains the lower bound and the second |
| | SIGNED-INTEGER contains the upper bound. |
+----------------------+--------------------------------------------+
| 1setOf X | Encoding according to the rules for an |
| | attribute with more than one value. Each |
| | value X is encoded according to the rules |
| | for encoding its type. |
+----------------------+--------------------------------------------+
| octetString | OCTET-STRING |
+----------------------+--------------------------------------------+
| collection | Encoding as defined in Section 3.1.6. |
+----------------------+--------------------------------------------+
Table 7: Attribute Value Encoding
表7：属性值编码
The attribute syntax type of the value determines its encoding and the value of its "value-tag".
值的属性语法类型决定其编码及其“值标记”的值。
The "data" field MUST include any data required by the operation.
“数据”字段必须包括操作所需的任何数据。
HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol. HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol.
HTTP/1.1[RFC7230]是此协议所需的传输层。HTTP/2[RFC7540]是此协议的可选传输层。
The operation layer has been designed with the assumption that the transport layer contains the following information:
操作层的设计假设传输层包含以下信息：
o the target URI for the operation; and
o 操作的目标URI；和
o the total length of the data in the operation layer, either as a single length or as a sequence of chunks each with a length.
o 操作层中数据的总长度，可以是单个长度，也可以是每个具有一个长度的块序列。
Printer implementations MUST support HTTP over the IANA-assigned well-known port 631 (the IPP default port), although a Printer implementation can support HTTP over some other port as well.
打印机实现必须支持IANA指定的已知端口631（IPP默认端口）上的HTTP，尽管打印机实现也可以支持其他端口上的HTTP。
Each HTTP operation MUST use the POST method where the request-target is the object target of the operation and where the "Content-Type" of the message body in each request and response MUST be "application/ ipp". The message body MUST contain the operation layer and MUST have the syntax described in Section 3.2, "Syntax of Encoding". A Client implementation MUST adhere to the rules for a Client described for HTTP [RFC7230]. A Printer (server) implementation MUST adhere to the rules for an origin server described for HTTP [RFC7230].
每个HTTP操作必须使用POST方法，其中请求目标是操作的对象目标，并且每个请求和响应中消息体的“内容类型”必须是“应用程序/ipp”。消息正文必须包含操作层，并且必须具有第3.2节“编码语法”中描述的语法。客户端实现必须遵守HTTP[RFC7230]中描述的客户端规则。打印机（服务器）实现必须遵守HTTP[RFC7230]中描述的源服务器规则。
An IPP server sends a response for each request that it receives. If an IPP server detects an error, it MAY send a response before it has read the entire request. If the HTTP layer of the IPP server completes processing the HTTP headers successfully, it MAY send an intermediate response, such as "100 Continue", with no IPP data before sending the IPP response. A Client MUST expect such a variety of responses from an IPP server. For further information on HTTP, consult the HTTP documents [RFC7230].
IPP服务器为其收到的每个请求发送响应。如果IPP服务器检测到错误，它可能会在读取整个请求之前发送响应。如果IPP服务器的HTTP层成功完成对HTTP头的处理，它可能会发送一个中间响应，例如“100 Continue”，在发送IPP响应之前没有IPP数据。客户机必须期望IPP服务器做出各种响应。有关HTTP的更多信息，请参阅HTTP文档[RFC7230]。
An HTTP/1.1 server MUST support chunking for IPP requests, and an IPP Client MUST support chunking for IPP responses according to HTTP/1.1 [RFC7230].
根据HTTP/1.1[RFC7230]，HTTP/1.1服务器必须支持IPP请求的分块，IPP客户端必须支持IPP响应的分块。
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC3986] so that they can be persistently and unambiguously referenced. Jobs can also be identified by a combination of Printer URI and Job ID.
所有打印机和作业对象都由统一资源标识符（URI）[RFC3986]标识，以便可以持久和明确地引用它们。作业还可以通过打印机URI和作业ID的组合来标识。
Some operation elements are encoded twice, once as the request-target on the HTTP request-line and a second time as a REQUIRED operation attribute in the application/ipp entity. These attributes are the target for the operation and are called "printer-uri" and "job-uri".
一些操作元素被编码两次，一次作为HTTP请求行上的请求目标，另一次作为应用程序/ipp实体中的必需操作属性。这些属性是操作的目标，称为“打印机uri”和“作业uri”。
Note: The target URI is included twice in an operation referencing the same IPP object, but the two URIs can be different. For example, the HTTP request-target can be relative while the IPP request URI is absolute.
注意：目标URI在引用同一IPP对象的操作中包含两次，但两个URI可能不同。例如，HTTP请求目标可以是相对的，而IPP请求URI是绝对的。
HTTP allows Clients to generate and send a relative URI rather than an absolute URI. A relative URI identifies a resource with the scope of the HTTP server but does not include scheme, host, or port. The following statements characterize how URIs are used in the mapping of IPP onto HTTP:
HTTP允许客户端生成和发送相对URI，而不是绝对URI。相对URI标识HTTP服务器范围内的资源，但不包括方案、主机或端口。以下语句描述了在将IPP映射到HTTP时如何使用URI：
1. Although potentially redundant, a Client MUST supply the target of the operation both as an operation attribute and as a URI at the HTTP layer. The rationale for this decision is to maintain a consistent set of rules for mapping "application/ipp" to possibly many communication layers, even where URIs are not used as the addressing mechanism in the transport layer.
1. 尽管可能是冗余的，但客户机必须在HTTP层提供操作目标作为操作属性和URI。此决定的基本原理是维护一组一致的规则，以便将“应用程序/ipp”映射到可能的多个通信层，即使URI未用作传输层中的寻址机制。
2. Even though these two URIs might not be literally identical (one being relative and the other being absolute), they MUST both reference the same IPP object.
2. 尽管这两个URI可能并不完全相同（一个是相对的，另一个是绝对的），但它们都必须引用相同的IPP对象。
3. The URI in the HTTP layer is either relative or absolute and is used by the HTTP server to route the HTTP request to the correct resource relative to that HTTP server.
3. HTTP层中的URI是相对的或绝对的，HTTP服务器使用它将HTTP请求路由到相对于该HTTP服务器的正确资源。
4. Once the HTTP server resource begins to process the HTTP request, it can get the reference to the appropriate IPP Printer object from either the HTTP URI (using to the context of the HTTP server for relative URIs) or from the URI within the operation request; the choice is up to the implementation.
4. 一旦HTTP服务器资源开始处理HTTP请求，它就可以从HTTP URI（使用HTTP服务器上下文中的相对URI）或操作请求中的URI获取对适当IPP打印机对象的引用；选择取决于实现。
5. HTTP URIs can be relative or absolute, but the target URI in the IPP operation attribute MUST be an absolute URI.
5. HTTP URI可以是相对的，也可以是绝对的，但IPP操作属性中的目标URI必须是绝对URI。
The IPP URI schemes are 'ipp' [RFC3510] and 'ipps' [RFC7472]. Clients and Printers MUST support the ipp-URI value in the following IPP attributes:
IPP URI方案是“IPP”[RFC3510]和“IPP”[RFC7472]。客户端和打印机必须支持以下ipp属性中的ipp URI值：
o Job attributes:
o 作业属性：
* job-uri
* 作业uri
* job-printer-uri
* 作业打印机uri
o Printer attributes:
o 打印机属性：
* printer-uri-supported
* 支持的打印机uri
o Operation attributes:
o 操作属性：
* job-uri
* 作业uri
* printer-uri
* 打印机uri
Each of the above attributes identifies a Printer or Job. The ipp-URI and ipps-URI are intended as the value of the attributes in this list. All of these attributes have a syntax type of 'uri', but there are attributes with a syntax type of 'uri' that do not use the 'ipp' scheme, e.g., "job-more-info".
上述每个属性都标识打印机或作业。ipp URI和ipps URI将用作此列表中属性的值。所有这些属性的语法类型均为“uri”，但也有语法类型为“uri”的属性不使用“ipp”方案，例如“job more info”。
If a Printer registers its URI with a directory service, the Printer MUST register an ipp-URI or ipps-URI.
如果打印机向目录服务注册其URI，则打印机必须注册ipp URI或ipps URI。
When a Client sends a request, it MUST convert a target ipp-URI to a target http-URL (or ipps-URI to a target https-URI) for the HTTP layer according to the following steps:
客户端发送请求时，必须按照以下步骤将http层的目标ipp URI转换为目标http URL（或将ipp URI转换为目标https URI）：
1. change the 'ipp' scheme to 'http' or 'ipps' scheme to 'https'; and
1. 将“ipp”方案更改为“http”，或将“ipp”方案更改为“https”；和
2. add an explicit port 631 if the ipp-URL or ipps-URL does not contain an explicit port. Note that port 631 is the IANA-assigned well-known port for the 'ipp' and 'ipps' schemes.
2. 如果ipp URL或ipps URL不包含显式端口，请添加显式端口631。请注意，631端口是IANA为“ipp”和“ipps”方案指定的知名端口。
The Client MUST use the target http-URL or https-URL in both the HTTP request-line and HTTP headers, as specified by HTTP [RFC7230]. However, the Client MUST use the target ipp-URI or ipps-URI for the value of the "printer-uri" or "job-uri" operation attribute within the application/ipp body of the request. The server MUST use the
客户端必须在http请求行和http头中使用目标http URL或https URL，如http[RFC7230]所指定。但是，客户端必须使用目标ipp URI或ipps URI作为请求的应用程序/ipp正文中的“打印机URI”或“作业URI”操作属性的值。服务器必须使用
ipp-URI or ipps-URI for the value of the "printer-uri", "job-uri", or "printer-uri-supported" attributes within the application/ipp body of the response.
响应的应用程序/ipp正文中“打印机URI”、“作业URI”或“支持的打印机URI”属性的值的ipp URI或ipps URI。
For example, when an IPP Client sends a request directly, i.e., no proxy, to an ipp-URI "ipp://printer.example.com/ipp/print/myqueue", it opens a TCP connection to port 631 (the IPP implicit port) on the host "printer.example.com" and sends the following data:
例如，当IPP客户端直接向IPP URI发送请求（即无代理）时“ipp://printer.example.com/ipp/print/myqueue，它将打开到主机“printer.example.com”上的端口631（IPP隐式端口）的TCP连接，并发送以下数据：
POST /ipp/print/myqueue HTTP/1.1 Host: printer.example.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" 'ipp://printer.example.com/ipp/print/myqueue' (encoded in application/ipp message body) ...
POST/ipp/print/myqueue HTTP/1.1主机：printer.example.com:631内容类型：应用程序/ipp传输编码：分块。。。“打印机uri”ipp://printer.example.com/ipp/print/myqueue“（在应用程序/ipp消息正文中编码）。。。
Figure 11: Direct IPP Request
图11：直接IPP请求
As another example, when an IPP Client sends the same request as above via a proxy "myproxy.example.com", it opens a TCP connection to the proxy port 8080 on the proxy host "myproxy.example.com" and sends the following data:
作为另一个示例，当IPP客户端通过代理“myproxy.example.com”发送与上述相同的请求时，它将打开到代理主机“myproxy.example.com”上的代理端口8080的TCP连接，并发送以下数据：
POST http://printer.example.com:631/ipp/print/myqueue HTTP/1.1 Host: printer.example.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" 'ipp://printer.example.com/ipp/print/myqueue' (encoded in application/ipp message body) ...
邮递http://printer.example.com:631/ipp/print/myqueue HTTP/1.1主机：printer.example.com:631内容类型：应用程序/ipp传输编码：分块。。。“打印机uri”ipp://printer.example.com/ipp/print/myqueue“（在应用程序/ipp消息正文中编码）。。。
Figure 12: Proxied IPP Request
图12：代理IPP请求
The proxy then connects to the IPP origin server with headers that are the same as the "no-proxy" example above.
然后，代理使用与上述“无代理”示例相同的头连接到IPP源服务器。
The IANA-PRINTER-MIB [RFC3805] has been updated to reference this document; the current version is available from <http://www.iana.org>.
IANA-PRINTER-MIB[RFC3805]已更新，以参考本文件；当前版本可从以下站点获得：<http://www.iana.org>.
See the IANA Considerations in the document "Internet Printing Protocol/1.1: Model and Semantics" [RFC8011] for information on IANA considerations for IPP extensions. IANA has updated the existing
有关IPP扩展的IANA注意事项的信息，请参阅文档“Internet打印协议/1.1：模型和语义”[RFC8011]中的IANA注意事项。IANA已经更新了现有的
'application/ipp' media type registration (whose contents are defined in Section 3 "Encoding of the Operation Layer") with the following information.
“应用程序/ipp”媒体类型注册（其内容在第3节“操作层编码”中定义），包含以下信息。
Type name: application
类型名称：应用程序
Subtype name: ipp
子类型名称：ipp
Required parameters: N/A
所需参数：不适用
Optional parameters: N/A
可选参数：不适用
Encoding considerations: IPP requests/responses MAY contain long lines and ALWAYS contain binary data (for example, attribute value lengths).
编码注意事项：IPP请求/响应可能包含长行，并且始终包含二进制数据（例如，属性值长度）。
Security considerations: IPP requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. Protocol mixed-version interworking rules in [RFC8011] as well as protocol-encoding rules in this document are complete and unambiguous. See also the security considerations in this document and [RFC8011].
安全注意事项：IPP请求/响应不会带来基础传输协议中尚未固有的任何安全风险。[RFC8011]中的协议混合版本互通规则以及本文档中的协议编码规则是完整且明确的。另请参见本文档和[RFC8011]中的安全注意事项。
Interoperability considerations: IPP requests (generated by Clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [RFC8011] and this document. Protocol-encoding rules specified in RFC 8010 are comprehensive so that interoperability between conforming implementations is guaranteed (although support for specific optional features is not ensured). Both the "charset" and "natural-language" of all IPP attribute values that are a LOCALIZED-STRING are explicit within IPP requests/responses (without recourse to any external information in HTTP, SMTP, or other message transport headers).
互操作性注意事项：IPP请求（由客户端生成）和响应（由服务器生成）必须符合规范性规范[RFC8011]和本文件规定的所有一致性要求。RFC 8010中规定的协议编码规则是全面的，因此可以保证一致性实现之间的互操作性（尽管无法确保对特定可选功能的支持）。作为本地化字符串的所有IPP属性值的“字符集”和“自然语言”在IPP请求/响应中都是显式的（不依赖HTTP、SMTP或其他邮件传输头中的任何外部信息）。
Published specifications: RFCs 8010 and 8011
已发布规范：RFCs 8010和8011
Applications that use this media type: Internet Printing Protocol (IPP) print clients and print servers that communicate using HTTP/ HTTPS or other transport protocols. Messages of type "application/ ipp" are self-contained and transport independent, including "charset" and "natural-language" context for any LOCALIZED-STRING value.
使用此媒体类型的应用程序：使用HTTP/HTTPS或其他传输协议进行通信的Internet打印协议（IPP）打印客户端和打印服务器。“application/ipp”类型的消息是自包含且独立于传输的，包括任何本地化字符串值的“charset”和“natural language”上下文。
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional information:
其他信息：
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
ISTO PWG IPP Workgroup <ipp@pwg.org>
ISTO PWG IPP Workgroup <ipp@pwg.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: ISTO PWG IPP Workgroup <ipp@pwg.org>
Author: ISTO PWG IPP Workgroup <ipp@pwg.org>
Change controller: ISTO PWG IPP Workgroup <ipp@pwg.org>
Change controller: ISTO PWG IPP Workgroup <ipp@pwg.org>
Provisional registration? (standards tree only): No
临时登记？（仅限标准树）：否
See the section on "Internationalization Considerations" in the document "Internet Printing Protocol/1.1: Model and Semantics" [RFC8011] for information on internationalization. This document adds no additional issues.
有关国际化的信息，请参阅文档“Internet打印协议/1.1：模型和语义”[RFC8011]中的“国际化注意事项”部分。本文件不增加其他问题。
The IPP Model and Semantics document [RFC8011] discusses high-level security requirements (Client Authentication, Server Authentication, and Operation Privacy). Client Authentication is the mechanism by which the Client proves its identity to the server in a secure manner. Server Authentication is the mechanism by which the server proves its identity to the Client in a secure manner. Operation Privacy is defined as a mechanism for protecting operations from eavesdropping.
IPP模型和语义文档[RFC8011]讨论了高级安全需求（客户端身份验证、服务器身份验证和操作隐私）。客户端身份验证是客户端以安全的方式向服务器证明其身份的机制。服务器身份验证是服务器以安全的方式向客户端证明其身份的机制。操作隐私被定义为防止操作被窃听的机制。
Message Integrity is addressed in the document "Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme" [RFC7472].
“HTTPS传输绑定上的互联网打印协议（IPP）和“ipps”URI方案”文档[RFC7472]中阐述了消息完整性。
This section defines the security requirements for IPP Clients and IPP objects.
本节定义了IPP客户端和IPP对象的安全要求。
IPP Clients and Printers SHOULD support Digest Authentication [RFC7616]. Use of the Message Integrity feature (qop="auth-int") is OPTIONAL.
IPP客户端和打印机应支持摘要身份验证[RFC7616]。使用消息完整性功能（qop=“auth int”）是可选的。
Note: Previous versions of this specification required support for the MD5 algorithms; however, [RFC7616] makes SHA2-256 mandatory to implement and deprecates MD5, only allowing its use for backwards compatibility reasons. IPP implementations that support Digest Authentication MUST support SHA2-256 and SHOULD support MD5 for backwards compatibility.
注：本规范的早期版本要求支持MD5算法；但是，[RFC7616]强制SHA2-256实现，并反对MD5，仅允许出于向后兼容性原因使用它。支持摘要身份验证的IPP实现必须支持SHA2-256，并应支持MD5以实现向后兼容性。
Note: The reason that IPP Clients and Printers SHOULD (rather than MUST) support Digest Authentication is that there is a certain class of Output Devices where it does not make sense. Specifically, a low-end device with limited ROM space and low paper throughput may not need Client Authentication. This class of device typically requires firmware designers to make trade-offs between protocols and functionality to arrive at the lowest-cost solution possible. Factored into the designer's decisions is not just the size of the code, but also the testing, maintenance, usefulness, and time-to-market impact for each feature delivered to the customer. Forcing such low-end devices to provide security in order to claim IPP/1.1 conformance would not make business sense. Print devices that have high-volume throughput and have available ROM space will typically provide support for Client Authentication that safeguards the device from unauthorized access because these devices are prone to a high loss of consumables and paper if unauthorized access occurs.
注意：IPP客户端和打印机应该（而不是必须）支持摘要身份验证的原因是，某些类型的输出设备不支持摘要身份验证。具体而言，具有有限ROM空间和较低纸张吞吐量的低端设备可能不需要客户端身份验证。这类设备通常需要固件设计者在协议和功能之间进行权衡，以获得尽可能低的成本解决方案。设计师的决策不仅考虑到代码的大小，还考虑到交付给客户的每个特性的测试、维护、有用性和上市时间影响。强制这些低端设备提供安全性以声明IPP/1.1合规性在商业上是没有意义的。具有高容量吞吐量和可用ROM空间的打印设备通常会支持客户端身份验证，以保护设备免受未经授权的访问，因为如果发生未经授权的访问，这些设备很容易出现耗材和纸张的高损失。
IPP Clients and Printers SHOULD support Transport Layer Security (TLS) [RFC5246] [RFC7525] for Server Authentication and Operation Privacy. IPP Printers MAY also support TLS for Client Authentication. IPP Clients and Printers MAY support Basic Authentication [RFC7617] for User Authentication if the channel is secure, e.g., IPP over HTTPS [RFC7472]. IPP Clients and Printers SHOULD NOT support Basic Authentication over insecure channels.
IPP客户端和打印机应支持传输层安全（TLS）[RFC5246][RFC7525]以实现服务器身份验证和操作隐私。IPP打印机还可以支持TLS进行客户端身份验证。如果通道是安全的，IPP客户端和打印机可能支持用户身份验证的基本身份验证[RFC7617]，例如HTTPS上的IPP[RFC7472]。IPP客户端和打印机不应支持通过不安全通道进行基本身份验证。
The IPP Model and Semantics document [RFC8011] defines two Printer attributes ("uri-authentication-supported" and "uri-security-supported") that the Client can use to discover the security policy of a Printer. That document also outlines IPP-specific security considerations and is the primary reference for security implications with regard to the IPP itself.
IPP模型和语义文档[RFC8011]定义了两个打印机属性（“支持uri身份验证”和“支持uri安全”），客户机可以使用它们来发现打印机的安全策略。该文件还概述了IPP特定的安全注意事项，是IPP自身安全影响的主要参考。
Note: Because previous versions of this specification did not require TLS support, this version cannot require it for IPP/1.1. However, since printing often involves a great deal of sensitive or private information (medical reports, performance reviews, banking information, etc.) and network monitoring is pervasive ([RFC7258]), implementors are strongly encouraged to include TLS support.
注：由于本规范的早期版本不需要TLS支持，因此本版本无法要求IPP/1.1支持TLS。但是，由于打印通常涉及大量敏感或私人信息（医疗报告、性能评估、银行信息等），并且网络监控非常普遍（[RFC7258]），因此强烈鼓励实施者提供TLS支持。
Note: Because IPP Printers typically use self-signed X.509 certificates, IPP Clients SHOULD support Trust On First Use (defined in [RFC7435]) in addition to traditional X.509 certificate validation.
注意：由于IPP打印机通常使用自签名的X.509证书，因此除了传统的X.509证书验证外，IPP客户端还应支持首次使用时的信任（在[RFC7435]中定义）。
IPP uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817] for 'ipp' URIs. The Client requests a secure TLS connection by using the HTTP "Upgrade" header while the server agrees in the HTTP response. The switch to TLS occurs either because the server grants the Client's request to upgrade to TLS or a server asks to switch to TLS in its response. Secure communication begins with a server's response to switch to TLS.
IPP对“IPP”URI使用“升级到HTTP/1.1中的TLS”机制[RFC2817]。客户端使用HTTP“升级”头请求安全TLS连接，而服务器在HTTP响应中表示同意。切换到TLS是因为服务器授予客户端升级到TLS的请求，或者服务器在其响应中请求切换到TLS。安全通信从服务器对切换到TLS的响应开始。
IPP uses the "HTTPS: HTTP over TLS" mechanism [RFC2818] for 'ipps' URIs. The Client and server negotiate a secure TLS connection immediately and unconditionally.
IPP对“IPP”URI使用“HTTPS:HTTP over TLS”机制[RFC2818]。客户端和服务器立即无条件协商安全TLS连接。
It is beyond the scope of this specification to mandate conformance with versions of IPP other than 1.1. IPP was deliberately designed, however, to make supporting other versions easy. IPP objects (Printers, Jobs, etc.) SHOULD:
强制要求符合IPP 1.1以外版本的要求超出了本规范的范围。然而，IPP的设计初衷是为了使支持其他版本变得容易。IPP对象（打印机、作业等）应：
o understand any valid request whose major "version-number" is greater than 0; and
o 理解主要“版本号”大于0的任何有效请求；和
o respond appropriately with a response containing the same "version-number" parameter value used by the Client in the request (if the Client-supplied "version-number" is supported) or the highest "version-number" supported by the Printer (if the Client-supplied "version-number" is not supported).
o 使用包含客户端在请求中使用的相同“版本号”参数值（如果支持客户端提供的“版本号”）或打印机支持的最高“版本号”（如果不支持客户端提供的“版本号”）的响应进行适当响应。
IPP Clients SHOULD:
IPP客户应：
o understand any valid response whose major "version-number" is greater than 0.
o 理解主“版本号”大于0的任何有效响应。
The following are rules regarding the "version-number" parameter (see Section 3.3):
以下是关于“版本号”参数的规则（见第3.3节）：
1. Clients MUST send requests containing a "version-number" parameter with the highest supported value, e.g., '1.1', '2.0', etc., and SHOULD try supplying alternate version numbers if they receive a 'server-error-version-not-supported' error return in a response. For example, if a Client sends an IPP/2.0 request that is rejected with the 'server-error-version-not-supported' error and an IPP/1.1 "version-number", it SHOULD retry by sending an IPP/1.1 request.
1. 客户端必须发送包含具有最高支持值的“版本号”参数的请求，例如“1.1”、“2.0”等，如果在响应中收到“服务器错误版本不受支持”错误返回，则应尝试提供备用版本号。例如，如果客户端发送的IPP/2.0请求因“服务器错误版本不受支持”错误和IPP/1.1“版本号”而被拒绝，则应通过发送IPP/1.1请求重试。
2. IPP objects (Printers, Jobs, etc.) MUST accept requests containing a "version-number" parameter with a '1.1' value (or reject the request for reasons other than 'server-error-version-not-supported').
2. IPP对象（打印机、作业等）必须接受包含具有“1.1”值的“版本号”参数的请求（或因“不支持服务器错误版本”以外的原因拒绝请求）。
3. IPP objects SHOULD either accept requests whose major version is greater than 0 or reject such requests with the 'server-error-version-not-supported' status-code. See Section 4.1.8 of [RFC8011].
3. IPP对象应接受主版本大于0的请求，或以“服务器错误版本不受支持”状态代码拒绝此类请求。见[RFC8011]第4.1.8节。
4. In any case, security MUST NOT be compromised when a Client supplies a lower "version-number" parameter in a request. For example, if an IPP/2.0 conforming Printer accepts version '1.1' requests and is configured to enforce Digest Authentication, it MUST do the same for a version '1.1' request.
4. 在任何情况下，当客户端在请求中提供较低的“版本号”参数时，安全性都不得受到损害。例如，如果符合IPP/2.0的打印机接受版本“1.1”请求并配置为强制摘要身份验证，则必须对版本“1.1”请求执行相同的操作。
The following are rules regarding security, the "version-number" parameter, and the URI scheme supplied in target attributes and responses:
以下是有关安全性、“版本号”参数以及目标属性和响应中提供的URI方案的规则：
1. When a Client supplies a request, the "printer-uri" or "job-uri" target operation attribute MUST have the same scheme as that indicated in one of the values of the "printer-uri-supported" Printer attribute.
1. 当客户端提供请求时，“打印机uri”或“作业uri”目标操作属性必须具有与“支持的打印机uri”打印机属性的一个值中指示的方案相同的方案。
2. When the Printer returns the "job-printer-uri" or "job-uri" Job Description attributes, it SHOULD return the same scheme ('ipp', 'ipps', etc.) that the Client supplied in the "printer-uri" or "job-uri" target operation attributes in the Get-Job-Attributes or Get-Jobs request, rather than the scheme used when the Job was created. However, when a Client requests Job attributes using the Get-Job-Attributes or Get-Jobs operations, the Jobs and Job
2. 当打印机返回“作业打印机uri”或“作业uri”作业描述属性时，它应返回客户端在Get job attributes或Get Jobs请求的“打印机uri”或“作业uri”目标操作属性中提供的相同方案（“ipp”、“ipp”等），而不是创建作业时使用的方案。但是，当客户端使用“获取作业属性”或“获取作业”操作请求作业属性时，作业和作业
attributes that the Printer returns depends on: (1) the security in effect when the Job was created, (2) the security in effect in the query request, and (3) the security policy in force.
打印机返回的属性取决于：（1）创建作业时有效的安全性，（2）查询请求中有效的安全性，以及（3）有效的安全策略。
3. The Printer MUST enforce its security and privacy policies based on the owner of the IPP object and the URI scheme and/or credentials supplied by the Client in the current request.
3. 打印机必须根据IPP对象的所有者以及客户端在当前请求中提供的URI方案和/或凭据强制执行其安全和隐私策略。
The following changes have been made since the publication of RFC 2910:
自RFC 2910发布以来，进行了以下更改：
o Added references to current IPP extension specifications.
o 增加了对当前IPP扩展规范的参考。
o Added optional support for HTTP/2.
o 添加了对HTTP/2的可选支持。
o Added collection attribute syntax from RFC 3382.
o 从RFC3382中添加了集合属性语法。
o Fixed typographical errors.
o 修正了印刷错误。
o Now reference TLS/1.2 and no longer mandate the TLS/1.0 MTI ciphersuites.
o 现在参考TLS/1.2，不再强制使用TLS/1.0 MTI密码套件。
o Updated all references.
o 更新了所有参考资料。
o Updated document organization to follow current style.
o 已更新文档组织以遵循当前样式。
o Updated example ipp: URIs to follow guidelines in RFC 7472.
o 更新示例ipp:URI以遵循RFC 7472中的指南。
o Updated version compatibility for all versions of IPP.
o 更新了IPP所有版本的版本兼容性。
o Updated HTTP Digest Authentication to optional for Clients.
o 已将HTTP摘要身份验证更新为客户端的可选身份验证。
o Removed references to (Experimental) IPP/1.0 and usage of http:/https: URLs.
o 删除了对（实验性）IPP/1.0的引用和http:/https:URL的使用。
[PWG5100.12] Sweet, M. and I. McDonald, "IPP Version 2.0, 2.1, and 2.2", October 2015, <http://ftp.pwg.org/pub/pwg/standards/ std-ipp20-20151030-5100.12.pdf>.
[PWG5100.12]Sweet，M.和I.McDonald，“IPP版本2.0、2.1和2.2”，2015年10月<http://ftp.pwg.org/pub/pwg/standards/ std-ipp20-20151030-5100.12.pdf>。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC2579]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“SMIv2的文本约定”，STD 58，RFC 2579，DOI 10.17487/RFC2579，1999年4月<http://www.rfc-editor.org/info/rfc2579>.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, <http://www.rfc-editor.org/info/rfc2817>.
[RFC2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 2817，DOI 10.17487/RFC2817，2000年5月<http://www.rfc-editor.org/info/rfc2817>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[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>.
[RFC2978]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，DOI 10.17487/RFC2978，2000年10月<http://www.rfc-editor.org/info/rfc2978>.
[RFC3510] Herriot, R. and I. McDonald, "Internet Printing Protocol/1.1: IPP URL Scheme", RFC 3510, DOI 10.17487/RFC3510, April 2003, <http://www.rfc-editor.org/info/rfc3510>.
[RFC3510]Herriot，R.和I.McDonald，“互联网打印协议/1.1:IPP URL方案”，RFC 3510，DOI 10.17487/RFC3510，2003年4月<http://www.rfc-editor.org/info/rfc3510>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：有条件请求”，RFC 7232，DOI 10.17487/RFC72322014年6月<http://www.rfc-editor.org/info/rfc7232>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<http://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC7472] McDonald, I. and M. Sweet, "Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme", RFC 7472, DOI 10.17487/RFC7472, March 2015, <http://www.rfc-editor.org/info/rfc7472>.
[RFC7472]McDonald，I.和M.Sweet，“HTTPS传输绑定上的互联网打印协议（IPP）和“IPP”URI方案”，RFC 7472，DOI 10.17487/RFC7472，2015年3月<http://www.rfc-editor.org/info/rfc7472>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<http://www.rfc-editor.org/info/rfc7540>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <http://www.rfc-editor.org/info/rfc7541>.
[RFC7541]Paun，R.和H.Ruellan，“HPACK：HTTP/2的报头压缩”，RFC 7541，DOI 10.17487/RFC7541，2015年5月<http://www.rfc-editor.org/info/rfc7541>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<http://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <http://www.rfc-editor.org/info/rfc7617>.
[RFC7617]Reschke，J.“基本”HTTP认证方案”，RFC 7617，DOI 10.17487/RFC76172015年9月<http://www.rfc-editor.org/info/rfc7617>.
[RFC8011] Sweet, M. and I. McDonald, "Internet Printing Protocol/1.1: Model and Semantics", RFC 8011, DOI 10.17487/RFC8011, January 2017, <http://www.rfc-editor.org/info/rfc8011>.
[RFC8011]Sweet，M.和I.McDonald，“互联网打印协议/1.1：模型和语义”，RFC 8011，DOI 10.17487/RFC8011，2017年1月<http://www.rfc-editor.org/info/rfc8011>.
[IANA-IPP] IANA, "Internet Printing Protocol (IPP) Registry", <http://www.iana.org/assignments/ipp-registrations/>.
[IANA-IPP]IANA，“互联网打印协议（IPP）注册表”<http://www.iana.org/assignments/ipp-registrations/>.
[PWG5100.3] Ocke, K. and T. Hastings, "Internet Printing Protocol (IPP): Production Printing Attributes - Set1", Candidate Standard 5100.3-2001, February 2001, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippprodprint10-20010212-5100.3.pdf>.
[PWG5100.3]Ocke，K.和T.Hastings，“互联网打印协议（IPP）：生产打印属性-Set1”，候选标准5100.3-2001，2001年2月<http://ftp.pwg.org/pub/pwg/candidates/ cs-ippprodprint10-20010212-5100.3.pdf>。
[RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, DOI 10.17487/RFC1179, August 1990, <http://www.rfc-editor.org/info/rfc1179>.
[RFC1179]McLaughlin，L.，“线路打印机守护程序协议”，RFC 1179，DOI 10.17487/RFC1179，1990年8月<http://www.rfc-editor.org/info/rfc1179>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[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>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
The following is an example of a Print-Job request with "job-name", "copies", and "sides" specified. The "ipp-attribute-fidelity" attribute is set to 'true' so that the print request will fail if the "copies" or the "sides" attribute is not supported or their values are not supported.
以下是指定了“作业名称”、“副本”和“侧面”的打印作业请求的示例。“ipp属性保真度”属性设置为“真”，这样，如果不支持“副本”或“侧面”属性，或不支持其值，打印请求将失败。
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x0002 Print-Job operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/pinetree 0x42 nameWithoutLanguage value-tag type 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x22 boolean type value-tag 0x0016 name-length ipp-attribute-fidelity ipp-attribute- name fidelity 0x0001 value-length 0x01 true value 0x02 start job-attributes job-attributes-
0x0101 1.1版本号0x0002打印作业操作id 0x00000001 1请求id 0x01开始操作-操作属性属性标记0x47字符集类型值标记0x0012名称长度属性字符集属性字符集名称0x0005值长度utf-8 utf-8值0x48自然语言值标记类型0x001b名称长度属性自然语言属性自然-名称语言0x0005值长度en us en us值0x45 uri类型值标记0x000b名称长度打印机uri打印机uri名称0x002c值长度ipp://printer.example.com/ipp/ 打印机pinetree值打印/pinetree 0x42名称带外部语言值标记类型0x0008名称长度作业名称作业名称0x0006值长度foobar foobar值0x22布尔类型值标记0x0016名称长度ipp属性保真度ipp属性-名称保真度0x0001值长度0x01真值0x02开始作业属性作业属性-
tag 0x21 integer type value-tag 0x0006 name-length copies copies name 0x0004 value-length 0x00000014 20 value 0x44 keyword type value-tag 0x0005 name-length sides sides name 0x0013 value-length two-sided-long-edge two-sided-long-edge value 0x03 end-of-attributes end-of-attributes-tag %!PDF... <PDF Document> data
标记0x21整型值标记0x0006名称长度复制名称0x0004值长度0x00000014 20值0x44关键字类型值标记0x0005名称长度侧面名称0x0013值长度双面长边值0x03属性结束属性结束标记%！PDF<PDF文档>数据
Here is an example of a successful Print-Job response to the previous Print-Job request. The Printer supported the "copies" and "sides" attributes and their supplied values. The status-code returned is 'successful-ok'.
以下是成功响应上一个打印作业请求的打印作业的示例。打印机支持“副本”和“侧面”属性及其提供的值。返回的状态代码为“成功确定”。
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x0000 successful-ok status-code 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes- name natural-language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguag value-tag e type 0x000e name-length status-message status-message name 0x000d value-length successful-ok successful-ok value 0x02 start job- job-attributes-
0x0101 1.1版本号0x0000成功ok状态代码0x00000001 1请求id 0x01开始操作-操作属性标记0x47字符集类型值标记0x0012名称长度属性字符集属性字符集名称0x0005值长度utf-8 utf-8值0x48自然语言值标记类型0x001b名称长度属性自然语言属性-名称自然语言0x0005值长度en us en us值0x41 text带外域语言值标记e类型0x000e名称长度状态消息状态消息名称0x000d值长度成功确定成功确定值0x02开始作业-作业属性-
attributes tag 0x21 integer value-tag 0x0006 name-length job-id job-id name 0x0004 value-length 147 147 value 0x45 uri type value-tag 0x0007 name-length job-uri job-uri name 0x0030 value-length ipp://printer.example.com/ipp/pr job 147 on value int/pinetree/147 pinetree 0x23 enum type value-tag 0x0009 name-length job-state job-state name 0x0004 value-length 0x0003 pending value 0x03 end-of-attributes end-of-attributes-tag
属性标记0x21整数值标记0x0006名称长度作业id作业id名称0x0004值长度147 147值0x45 uri类型值标记0x0007名称长度作业uri作业uri名称0x0030值长度ipp://printer.example.com/ipp/pr 值int/pinetree/147 pinetree 0x23枚举类型值标记0x0009名称长度作业状态作业状态名称0x0004上的作业147值长度0x0003挂起值0x03属性结束属性结束标记
Here is an example of an unsuccessful Print-Job response to the previous Print-Job request. It fails because, in this case, the Printer does not support the "sides" attribute and because the value '20' for the "copies" attribute is not supported. Therefore, no Job is created, and neither a "job-id" nor a "job-uri" operation attribute is returned. The error code returned is 'client-error-attributes-or-values-not-supported' (0x040b).
以下是对上一个打印作业请求的打印作业响应失败的示例。它失败的原因是，在这种情况下，打印机不支持“sides”属性，并且“copies”属性的值“20”不受支持。因此，不会创建作业，也不会返回“作业id”或“作业uri”操作属性。返回的错误代码为“不支持客户端错误属性或值”（0x040b）。
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x040b client-error-attributes-or- status-code values-not-supported 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language type value-tag 0x001b name-length
0x0101 1.1版本号0x040b客户端错误属性或-不支持的状态代码值0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性字符集属性字符集名称0x0005值长度utf-8 utf-8值0x48自然语言类型值标记0x001b名称长度
attributes-natural-language attributes-natural-language name 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000e name-length status-message status-message name 0x002f value-length client-error-attributes-or- client-error-attributes-or- value values-not-supported values-not-supported 0x05 start unsupported- unsupported-attributes attributes tag 0x21 integer type value-tag 0x0006 name-length copies copies name 0x0004 value-length 0x00000014 20 value 0x10 unsupported (type) value-tag 0x0005 name-length sides sides name 0x0000 value-length 0x03 end-of-attributes end-of-attributes-tag
属性自然语言属性自然语言名称0x0005值长度en us en us值0x41 text带外语言类型值标记0x000e名称长度状态消息状态消息名称0x002f值长度客户端错误属性或-客户端错误属性或-值不支持值不支持值0x05开始不支持-不支持的属性属性标记0x21整型值标记0x0006名称长度复制名称0x0004值长度0x00000014 20值0x10不支持的（类型）值标记0x0005名称长度侧面名称0x0000值长度0x03属性结束属性结束标记
Here is an example of a successful Print-Job response to a Print-Job request like the previous Print-Job request, except that the value of "ipp-attribute-fidelity" is 'false'. The print request succeeds, even though, in this case, the Printer supports neither the "sides" attribute nor the value '20' for the "copies" attribute. Therefore, a Job is created and both a "job-id" and a "job-uri" operation attribute are returned. The unsupported attributes are also returned in an Unsupported Attributes group. The error code returned is 'successful-ok-ignored-or-substituted-attributes' (0x0001).
以下是一个成功响应打印作业请求的示例，与前一个打印作业请求类似，只是“ipp属性保真度”的值为“false”。打印请求成功，即使在这种情况下，打印机既不支持“sides”属性，也不支持“copies”属性的值“20”。因此，将创建一个作业，并返回“作业id”和“作业uri”操作属性。不支持的属性也会在不支持的属性组中返回。返回的错误代码为“成功确定忽略或替换的属性”（0x0001）。
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x0001 successful-ok-ignored-or- status-code substituted-attributes 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name
0x0101 1.1版本号0x0001成功忽略ok或-状态代码替换属性0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性字符集属性字符集名称
0x0005 value-length utf-8 UTF-8 value 0x48 natural-language type value-tag 0x001b name-length attributes-natural- attributes-natural-language name language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000e name-length status-message status-message name 0x002f value-length successful-ok-ignored-or- successful-ok-ignored-or- value substituted-attributes substituted-attributes 0x05 start unsupported- unsupported-attributes attributes tag 0x21 integer type value-tag 0x0006 name-length copies copies name 0x0004 value-length 0x00000014 20 value 0x10 unsupported (type) value-tag 0x0005 name-length sides sides name 0x0000 value-length 0x02 start job-attributes job-attributes-tag 0x21 integer value-tag 0x0006 name-length job-id job-id name 0x0004 value-length 147 147 value 0x45 uri type value-tag 0x0007 name-length job-uri job-uri name 0x0030 value-length ipp://printer.example.com/ job 147 on pinetree value ipp/print/pinetree/147 0x23 enum type value-tag 0x0009 name-length job-state job-state name 0x0004 value-length 0x0003 pending value 0x03 end-of-attributes end-of-attributes-tag
0x0005值长度utf-8 utf-8值0x48自然语言类型值标记0x001b名称长度属性自然-属性自然语言名称语言0x0005值长度en us en us值0x41 text带外域语言类型值标记0x000e名称长度状态消息状态消息名称0x002f值长度成功忽略或-成功确定忽略或-值替换属性替换属性0x05开始不支持-不支持的属性属性标记0x21整型值标记0x0006名称长度复制名称0x0004值长度0x00000014 20值0x10不支持（类型）值标记0x0005名称长度边名称0x0000值长度0x02开始作业属性作业属性标记0x21整数值标记0x0006名称长度作业id作业id名称0x0004值长度147 147值0x45 uri类型值标记0x0007名称长度作业uri作业uri名称0x0030值长度ipp://printer.example.com/ 关于松树价值的作业147ipp/print/pinetree/147 0x23枚举类型值标记0x0009名称长度作业状态作业状态名称0x0004值长度0x0003挂起值0x03属性结束属性结束标记
The following is an example of Print-URI request with "copies" and "job-name" parameters:
以下是带有“副本”和“作业名称”参数的打印URI请求示例：
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x0003 Print-URI operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/pinetree 0x45 uri type value-tag 0x000c name-length document-uri document-uri name 0x0019 value-length ftp://foo.example.com/foo ftp://foo.example.co value m/foo 0x42 nameWithoutLanguage value-tag type 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x02 start job-attributes job-attributes-tag 0x21 integer type value-tag 0x0006 name-length copies copies name 0x0004 value-length
0x0101 1.1版本号0x0003打印URI操作id 0x00000001 1请求id 0x01开始操作-操作属性属性标记0x47字符集类型值标记0x0012名称长度属性字符集属性字符集名称0x0005值长度utf-8 utf-8值0x48自然语言值标记类型0x001b名称长度属性自然语言属性自然-名称语言0x0005值长度en us en us值0x45 uri类型值标记0x000b名称长度打印机uri打印机uri名称0x002c值长度ipp://printer.example.com/ipp/ 打印机pinetree值打印/pinetree 0x45 uri类型值标记0x000c名称长度文档uri文档uri名称0x0019值长度ftp://foo.example.com/foo ftp://foo.example.co 值m/foo 0x42 name withoutlanguage值标记类型0x0008名称长度作业名称作业名称0x0006值长度foobar foobar值0x02开始作业属性作业属性标记0x21整型值标记0x0006名称长度复制名称0x0004值长度
0x00000001 1 value 0x03 end-of-attributes end-of-attributes-tag
0x00000001 1值0x03属性结束属性结束标记
The following is an example of Create-Job request with no parameters and no attributes:
以下是创建不带参数和属性的作业请求的示例：
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x0005 Create-Job operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/pinetree 0x03 end-of-attributes end-of-attributes-tag
0x0101 1.1版本号0x0005创建作业操作id 0x00000001 1请求id 0x01开始操作-操作属性属性标记0x47字符集类型值标记0x0012名称长度属性字符集属性字符集名称0x0005值长度utf-8 utf-8值0x48自然语言值标记类型0x001b名称长度属性自然语言属性自然-名称语言0x0005值长度en us en us值0x45 uri类型值标记0x000b名称长度打印机uri名称0x002c值长度ipp://printer.example.com/ipp/ 打印机pinetree值打印/pinetree 0x03属性结束属性结束标记
The following is an example of Create-Job request with the "media-col" collection attribute [PWG5100.3] with the value "media-size={x-dimension=21000 y-dimension=29700} media-type='stationery'":
下面是一个创建作业请求的示例，该作业请求具有值为“media size={x-dimension=21000 y-dimension=29700}media type='信纸'的“media col”集合属性[PWG5100.3]：
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x0005 Create-Job operation-id 0x00000001 1 request-id
0x0101 1.1版本号0x0005创建作业操作id 0x00000001 1请求id
0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/pinetree 0x34 begCollection value-tag 0x0009 9 name-length media-col media-col name 0x0000 0 value-length 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000a 10 value-length media-size media-size value (member-name) 0x34 begCollection member-value-tag 0x0000 0 name-length 0x0000 0 member-value-length 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000b 11 value-length x-dimension x-dimension value (member-name) 0x21 integer member-value-tag 0x0000 0 name-length 0x0004 4 member-value-length 0x00005208 21000 member-value 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000b 11 value-length y-dimension y-dimension value (member-name)
0x01开始操作-操作属性标记0x47字符集类型值标记0x0012名称长度属性字符集属性字符集名称0x0005值长度utf-8 utf-8值0x48自然语言值标记类型0x001b名称长度属性自然语言属性自然-名称语言0x0005值长度en us值0x45uri类型值标记0x000b名称长度打印机uri打印机uri名称0x002c值长度ipp://printer.example.com/ipp/ 打印机pinetree值打印/pinetree 0x34 begCollection值标记0x0009名称长度媒体列媒体列名称0x0000 0值长度0x4a memberAttrName值标记0x0000 0名称长度0x000a 10值长度媒体大小媒体大小值（成员名称）0x34 begCollection成员值标记0x0000 0名称长度0x0000 0成员值长度0x4a memberAttrName值标记0x0000 0名称长度0x000b 11值长度x维度x维度值（成员名称）0x21整型成员值标记0x0000 0名称长度0x0004 4成员值长度0x00005208 21000成员值0x4a成员属性名称值标记0x0000 0名称长度0x000b 11值长度y维度y维度值（成员名称）
0x21 integer member-value-tag 0x0000 0 name-length 0x0004 4 member-value-length 0x00007404 29700 member-value 0x37 endCollection end-value-tag 0x0000 0 end-name-length 0x0000 0 end-value-length 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000a 10 value-length media-type media-type value (member-name) 0x44 keyword member-value-tag 0x0000 0 name-length 0x000a 10 member-value-length stationery stationery member-value 0x37 endCollection end-value-tag 0x0000 0 end-name-length 0x0000 0 end-value-length 0x03 end-of-attributes end-of-attributes-tag
0x21整型成员值标记0x0000 0名称长度0x0004 4成员值长度0x00007404 29700成员值0x37 endCollection结束值标记0x0000 0结束名称长度0x0000 0结束值长度0x4a memberAttrName值标记0x0000 0名称长度0x000a 10值长度媒体类型媒体类型值（成员名称）0x44关键字成员值标记0x0000 0名称长度0x000a 10成员值长度信纸信纸成员值0x37 endCollection结束值标记0x0000 0结束名称长度0x0000 0结束值长度0x03属性结束属性结束标记
The following is an example of Get-Jobs request with parameters but no attributes:
以下是带有参数但没有属性的Get Jobs请求的示例：
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x000a Get-Jobs operation-id 0x0000007b 123 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value
0x0101 1.1版本号0x000a获取作业操作id 0x0000007b 123请求id 0x01开始操作-操作属性属性标记0x47字符集类型值标记0x0012名称长度属性字符集属性字符集名称0x0005值长度utf-8 utf-8值0x48自然语言值标记类型0x001b名称长度属性自然语言属性自然-名称语言0x0005值长度en us en us值
0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/pinetree 0x21 integer type value-tag 0x0005 name-length limit limit name 0x0004 value-length 0x00000032 50 value 0x44 keyword type value-tag 0x0014 name-length requested-attributes requested-attributes name 0x0006 value-length job-id job-id value 0x44 keyword type value-tag 0x0000 additional value name-length 0x0008 value-length job-name job-name value 0x44 keyword type value-tag 0x0000 additional value name-length 0x000f value-length document-format document-format value 0x03 end-of-attributes end-of-attributes-tag
0x45 uri类型值标记0x000b名称长度打印机uri打印机uri名称0x002c值长度ipp://printer.example.com/ipp/ 打印机pinetree值打印/pinetree 0x21整型值标记0x0005名称长度限制名称0x0004值长度0x00000032 50值0x44关键字类型值标记0x0014名称长度请求属性请求的属性名称0x0006值长度作业id作业id值0x44关键字类型值标记0x0000附加值名称长度0x0008值长度作业名称值0x44关键字类型值标记0x0000附加值名称长度0x000f值长度文档格式文档格式值0x03属性结束属性结束标记
The following is an example of a Get-Jobs response from a previous request with three Jobs. The Printer returns no information about the second Job (because of security reasons):
下面是一个来自前一个包含三个作业的请求的Get Jobs响应示例。打印机不返回有关第二个作业的信息（出于安全原因）：
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x0000 successful-ok status-code 0x0000007b 123 request-id (echoed back) 0x01 start operation- operation-attributes-attributes tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language type value-tag 0x001b name-length
0x0101 1.1版本号0x0000成功ok状态代码0x0000007b 123请求id（回显）0x01开始操作-操作属性标签0x47字符集类型值标签0x0012名称长度属性字符集属性字符集名称0x0005值长度utf-8 utf-8值0x48自然语言类型值标签0x001b名称长度
attributes-natural- attributes-natural- name language language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage value-tag type 0x000e name-length status-message status-message name 0x000d value-length successful-ok successful-ok value 0x02 start job-attributes job-attributes-tag (1st object) 0x21 integer type value-tag 0x0006 name-length job-id job-id name 0x0004 value-length 147 147 value 0x36 nameWithLanguage value-tag 0x0008 name-length job-name job-name name 0x000c value-length 0x0005 sub-value-length fr-ca fr-CA value 0x0003 sub-value-length fou fou name 0x02 start job-attributes job-attributes-tag (2nd object) 0x02 start job-attributes job-attributes-tag (3rd object) 0x21 integer type value-tag 0x0006 name-length job-id job-id name 0x0004 value-length 148 149 value 0x36 nameWithLanguage value-tag 0x0008 name-length job-name job-name name 0x0012 value-length 0x0005 sub-value-length de-CH de-CH value 0x0009 sub-value-length isch guet isch guet name 0x03 end-of-attributes end-of-attributes-tag
attributes natural-attributes natural-名称语言语言0x0005值长度en us en us值0x41 text带外部语言值标记类型0x000e名称长度状态消息状态消息名称0x000d值长度成功确定成功确定值0x02开始作业属性作业属性标记（第一个对象）0x21整型值标记0x0006名称长度作业id作业id名称0x0004值长度147 147值0x36名称带语言值标记0x0008名称长度作业名称作业名称0x000c值长度0x0005子值长度fr ca fr ca值0x0003子值长度fou名称0x02开始作业属性作业属性标记（第二个对象）0x02开始作业属性作业属性标记（第三个对象）0x21整型值标记0x0006名称长度作业id作业id名称0x0004值长度148 149值0x36名称带语言值标记0x0008名称长度作业名称作业名称0x0012值长度0x0005子值长度de CH de CH值0x0009子值长度isch guet isch guet名称0x03属性结束属性结束标记
Acknowledgements
致谢
The authors would like to acknowledge the following individuals for their contributions to the original IPP/1.1 specifications:
作者感谢以下个人对原始IPP/1.1规范的贡献：
Sylvan Butler, Roger deBry, Tom Hastings, Robert Herriot (the original editor of RFC 2910), Paul Moore, Kirk Ocke, Randy Turner, John Wenn, and Peter Zehler.
西尔文·巴特勒、罗杰·德布里、汤姆·黑斯廷斯、罗伯特·赫里奥特（RFC2910的原始编辑）、保罗·摩尔、柯克·奥克、兰迪·特纳、约翰·温恩和彼得·泽勒。
Authors' Addresses
作者地址
Michael Sweet Apple Inc. 1 Infinite Loop MS 111-HOMC Cupertino, CA 95014 United States of America
Michael Sweet Apple Inc.1无限环MS 111-HOMC Cupertino，加利福尼亚州，美国95014
Email: msweet@apple.com
Email: msweet@apple.com
Ira McDonald High North, Inc. PO Box 221 Grand Marais, MI 49839 United States of America
爱尔兰共和军麦克唐纳高北公司，美国密歇根州格兰德马雷市221号邮政信箱，邮编：49839
Phone: +1 906-494-2434
Email: blueroofmusic@gmail.com
Phone: +1 906-494-2434
Email: blueroofmusic@gmail.com