Network Working Group R. Herriot, Editor
Request for Comments: 2910 Xerox Corporation
Obsoletes: 2565 S. Butler
Category: Standards Track Hewlett-Packard
P. Moore
Peerless Systems Networking
R. Turner
2wire.com
J. Wenn
Xerox Corporation
September 2000
Network Working Group R. Herriot, Editor
Request for Comments: 2910 Xerox Corporation
Obsoletes: 2565 S. Butler
Category: Standards Track Hewlett-Packard
P. Moore
Peerless Systems Networking
R. Turner
2wire.com
J. Wenn
Xerox Corporation
September 2000
Internet Printing Protocol/1.1: Encoding and Transport
Internet打印协议/1.1：编码和传输
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over Hypertext Transfer Protocol (HTTP) a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
本文档是一组文档之一，这些文档共同描述了新Internet打印协议（IPP）的所有方面。IPP是一种应用程序级协议，可用于使用Internet工具和技术进行分布式打印。本文档定义了将IPP操作和IPP属性编码为称为“应用程序/IPP”的新Internet mime媒体类型的规则。本文档还定义了通过超文本传输协议（HTTP）传输内容类型为“应用程序/ipp”的消息体的规则。本文档定义了一个名为“ipp”的新方案，用于识别ipp打印机和作业。
The full set of IPP documents includes:
整套IPP文件包括：
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport (this
document)
Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport (this
document)
Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.1. A few OPTIONAL operator operations have been added to IPP/1.1.
“Internet打印协议的设计目标”文档广泛介绍了分布式打印功能，并列举了有助于澄清需要包含在Internet打印协议中的功能的实际场景。它确定了三类用户的需求：最终用户、操作员和管理员。它列出了IPP/1.1中满足的最终用户需求子集。IPP/1.1中增加了一些可选的操作员操作。
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.
“互联网打印协议的结构、模型和协议的基本原理”文件从高层次上描述了IPP，定义了构成IPP规范文件套件的各种文件的路线图，并给出了IETF工作组主要决策的背景和基本原理。
The document, "Internet Printing Protocol/1.1: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport. It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
“Internet打印协议/1.1：模型和语义”文档描述了一个简化模型，其中包含抽象对象、其属性以及独立于编码和传输的操作。它引入了打印机和作业对象。作业对象可以选择为每个作业支持多个文档。它还解决了安全性、国际化和目录问题。
The document "Internet Printing Protocol/1.1: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
“互联网打印协议/1.1：实施者指南”文件为IPP客户端和IPP对象的实施者提供了建议。
The document "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
“LPD和IPP协议之间的映射”文档为IPP和LPD（Line Printer Daemon）实现之间网关的实现者提供了一些建议。
Table of Contents
目录
1. Introduction ...................................................4
2. Conformance Terminology ........................................4
3. Encoding of the Operation Layer ...............................4
3.1 Picture of the Encoding ...................................6
3.1.1 Request and Response...................................6
3.1.2 Attribute Group........................................6
3.1.3 Attribute..............................................7
3.1.4 Picture of the Encoding of an Attribute-with-one-value.7
3.1.5 Additional-value.......................................8
3.1.6 Alternative Picture of the Encoding of a Request Or a
Response...............................................9
3.2 Syntax of Encoding ........................................9
3.3 Attribute-group ..........................................11
3.4 Required Parameters ......................................12
3.4.1 Version-number........................................12
3.4.2 Operation-id..........................................12
3.4.3 Status-code...........................................12
3.4.4 Request-id............................................13
3.5 Tags .....................................................13
3.5.1 Delimiter Tags........................................13
3.5.2 Value Tags............................................14
3.6 Name-Length ..............................................16
3.7 (Attribute) Name .........................................16
3.8 Value Length .............................................16
3.9 (Attribute) Value ........................................17
3.10 Data .....................................................18
4. Encoding of Transport Layer ...................................18
4.1 Printer-uri and job-uri ..................................19
5. IPP URL Scheme ................................................20
6. IANA Considerations ...........................................22
7. Internationalization Considerations ...........................23
8. Security Considerations .......................................23
8.1 Security Conformance Requirements ........................23
8.1.1 Digest Authentication.................................23
8.1.2 Transport Layer Security (TLS)........................24
8.2 Using IPP with TLS .......................................25
9. Interoperability with IPP/1.0 Implementations .................25
9.1 The "version-number" Parameter ...........................25
9.2 Security and URL Schemes .................................26
10. References ...................................................27
11. Authors' Addresses ...........................................29
12. Other Participants: ..........................................31
13. Appendix A: Protocol Examples ................................33
13.1 Print-Job Request ........................................33
13.2 Print-Job Response (successful) ..........................34
13.3 Print-Job Response (failure) .............................35
1. Introduction ...................................................4
2. Conformance Terminology ........................................4
3. Encoding of the Operation Layer ...............................4
3.1 Picture of the Encoding ...................................6
3.1.1 Request and Response...................................6
3.1.2 Attribute Group........................................6
3.1.3 Attribute..............................................7
3.1.4 Picture of the Encoding of an Attribute-with-one-value.7
3.1.5 Additional-value.......................................8
3.1.6 Alternative Picture of the Encoding of a Request Or a
Response...............................................9
3.2 Syntax of Encoding ........................................9
3.3 Attribute-group ..........................................11
3.4 Required Parameters ......................................12
3.4.1 Version-number........................................12
3.4.2 Operation-id..........................................12
3.4.3 Status-code...........................................12
3.4.4 Request-id............................................13
3.5 Tags .....................................................13
3.5.1 Delimiter Tags........................................13
3.5.2 Value Tags............................................14
3.6 Name-Length ..............................................16
3.7 (Attribute) Name .........................................16
3.8 Value Length .............................................16
3.9 (Attribute) Value ........................................17
3.10 Data .....................................................18
4. Encoding of Transport Layer ...................................18
4.1 Printer-uri and job-uri ..................................19
5. IPP URL Scheme ................................................20
6. IANA Considerations ...........................................22
7. Internationalization Considerations ...........................23
8. Security Considerations .......................................23
8.1 Security Conformance Requirements ........................23
8.1.1 Digest Authentication.................................23
8.1.2 Transport Layer Security (TLS)........................24
8.2 Using IPP with TLS .......................................25
9. Interoperability with IPP/1.0 Implementations .................25
9.1 The "version-number" Parameter ...........................25
9.2 Security and URL Schemes .................................26
10. References ...................................................27
11. Authors' Addresses ...........................................29
12. Other Participants: ..........................................31
13. Appendix A: Protocol Examples ................................33
13.1 Print-Job Request ........................................33
13.2 Print-Job Response (successful) ..........................34
13.3 Print-Job Response (failure) .............................35
13.4 Print-Job Response (success with attributes ignored) .....36
13.5 Print-URI Request ........................................38
13.6 Create-Job Request .......................................39
13.7 Get-Jobs Request .........................................40
13.8 Get-Jobs Response ........................................41
14. Appendix B: Registration of MIME Media Type Information for
"application/ipp".............................................42
15. Appendix C: Changes from IPP/1.0 .............................44
16. Full Copyright Statement .....................................45
13.4 Print-Job Response (success with attributes ignored) .....36
13.5 Print-URI Request ........................................38
13.6 Create-Job Request .......................................39
13.7 Get-Jobs Request .........................................40
13.8 Get-Jobs Response ........................................41
14. Appendix B: Registration of MIME Media Type Information for
"application/ipp".............................................42
15. Appendix C: Changes from IPP/1.0 .............................44
16. Full Copyright Statement .....................................45
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/1.1 request or response. RFC 2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP headers that an IPP implementation supports.
传输层由HTTP/1.1请求或响应组成。RFC 2616[RFC2616]描述了HTTP/1.1。本文档指定IPP实现支持的HTTP头。
The operation layer consists of a message body in an HTTP request or response. The document "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] defines the semantics of such a message body and the supported values. This document specifies the encoding of an IPP operation. The aforementioned document [RFC2911] is henceforth referred to as the "IPP model document" or simply "model document".
操作层由HTTP请求或响应中的消息体组成。文档“Internet打印协议/1.1：模型和语义”[RFC2911]定义了此类消息体的语义和支持的值。本文档指定IPP操作的编码。此后，上述文件[RFC2911]被称为“IPP模型文件”或简称为“模型文件”。
Note: the version number of IPP (1.1) and HTTP (1.1) are not linked. They both just happen to be 1.1.
注意：IPP（1.1）和HTTP（1.1）的版本号没有链接。它们正好都是1.1。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可能”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
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 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 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 document is henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP model document order" with the first octet in the value (according to the IPP model document 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. Such one-octet integers, henceforth called SIGNED-BYTE, are used for the version-number and tag fields. Such two-byte integers, henceforth called SIGNED-SHORT are used for the operation-id, status-code and length fields. Four byte integers, henceforth called SIGNED-INTEGER, are used for value fields and the request-id.
一种字符序列，其中字符与某些字符集和某些自然语言相关联。字符串必须是“读取顺序”，值中的第一个字符（根据读取顺序）是编码中的第一个字符。关联字符集为US-ASCII且关联自然语言为US-English的字符串从此被称为US-ASCII-string。如模型文档中所述，其相关字符集和自然语言在请求或响应中指定的字符串从此被称为本地化字符串。八位字节字符串必须为“IPP模型文档顺序”，值中的第一个八位字节（根据IPP模型文档顺序）是编码中的第一个八位字节。此编码中的每个整数都必须使用big-endian格式的双补二进制编码（也称为“网络顺序”和“最高有效字节优先”）编码为有符号整数。整数的八位字节数必须为1、2或4，具体取决于协议中的用法。这样的一个八位组整数（此后称为有符号字节）用于版本号和标记字段。这样的两字节整数（此后称为SIGNED-SHORT）用于操作id、状态代码和长度字段。四字节整数（此后称为有符号整数）用于值字段和请求id。
The following two sections present the encoding of the operation layer in two ways:
以下两部分以两种方式介绍操作层的编码：
- informally through pictures and description - formally through Augmented Backus-Naur Form (ABNF), as specified by RFC 2234 [RFC2234]
- 非正式地通过图片和描述-按照RFC 2234[RFC2234]的规定，正式地通过增广的巴科斯诺尔表格（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
-----------------------------------------------
The first three fields in the above diagram contain the value of attributes described in section 3.1.1 of the Model document.
上图中的前三个字段包含模型文档第3.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 document). The IPP model document specifies the required attribute groups and their order for each operation request and response.
第四个字段是“属性组”字段，它出现0次或更多次。每个“属性组”字段表示一组属性，例如操作属性组或作业属性组（请参见模型文档）。IPP模型文档指定了每个操作请求和响应所需的属性组及其顺序。
The "end-of-attributes-tag" field is always present, even when the "data" is not present. The Model document specifies for each operation request and response whether the "data" field is present or absent.
“属性结束标记”字段始终存在，即使“数据”不存在。模型文档为每个操作请求和响应指定“数据”字段是否存在。
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
----------------------------------------------------------
The "begin-attribute-group-tag" field marks the beginning of an "attribute-group" field and its value identifies the type of attribute group, e.g. Operations Attributes group versus a Job Attributes group. The "begin-attribute-group-tag" field also marks the end of the previous attribute group except for the "begin-attribute-group-tag" field in the first "attribute-group" field of a request or response. The "begin-attribute-group-tag" field acts as an "attribute-group" terminator because an "attribute-group" field cannot nest inside another "attribute-group" field.
“开始属性组标记”字段标记“属性组”字段的开始，其值标识属性组的类型，例如操作属性组与作业属性组。“开始属性组标记”字段还标记前一个属性组的结束，请求或响应的第一个“属性组”字段中的“开始属性组标记”字段除外。“开始属性组标记”字段用作“属性组”终止符，因为“属性组”字段不能嵌套在另一个“属性组”字段中。
An "attribute-group" field contains zero or more "attribute" fields.
“属性组”字段包含零个或多个“属性”字段。
Note, 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
----------------------------------------------------------
When an attribute is single valued (e.g. "copies" with 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
-----------------------------------------------
An "attribute-with-one-value" field is encoded with five subfields:
“具有一个值的属性”字段由五个子字段编码：
The "value-tag" field specifies the attribute syntax, e.g. 0x44 for the attribute syntax 'keyword'.
“值标记”字段指定属性语法，例如属性语法“关键字”的0x44。
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".
“名称长度”字段以字节为单位指定“名称”字段的长度，例如上图中的u或15表示名称“支持的边”。
The "name" field contains the textual name of the attribute, e.g. "sides-supported".
“名称”字段包含属性的文本名称，例如“支持的边”。
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'.
“值长度”字段以字节为单位指定“值”字段的长度，例如上图中的v或（关键字）值“单侧”的9。
The "value" field contains the value of the attribute, e.g. the textual value 'one-sided'.
“值”字段包含属性值，例如文本值“单边”。
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
-----------------------------------------------
An "additional-value" is encoded with four subfields:
“附加值”由四个子字段编码：
The "value-tag" field specifies the attribute syntax, e.g. 0x44 for the attribute syntax 'keyword'.
“值标记”字段指定属性语法，例如属性语法“关键字”的0x44。
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).
“名称长度”字段的值为0，表示它是一个“附加值”。“名称长度”字段的值将“附加值”字段（“名称长度”为0）与“具有一个值的属性”字段（“名称长度”不是0）区分开来。
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'.
“值长度”字段以字节为单位指定“值”字段的长度，例如上图中的w或（关键字）值“双面长边”的19。
The "value" field contains the value of the attribute, e.g. the textual value 'two-sided-long-edge'.
“值”字段包含属性值，例如文本值“双面长边”。
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
-----------------------------------------------
The following show what fields the parser would expect after each type of "tag":
下面显示了解析器在每种类型的“标记”之后需要哪些字段：
- "begin-attribute-group-tag": expect zero or more "attribute" fields - "value-tag": expect the remainder of an "attribute-with-one-value" or an "additional-value". - "end-of-attributes-tag": expect that "attribute" fields are complete and there is optional "data"
- “开始属性组标记”：预期零个或多个“属性”字段-“值标记”：预期“具有一个值的属性”或“附加值的属性”的剩余部分“属性结束标记”：期望“属性”字段完整，并且有可选的“数据”
The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be case sensitive. For example 'a' means lower case 'a' and not upper case 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented as '%x' values which show their range of values.
以下语法为ABNF[RFC2234]，但“文本字符串”必须区分大小写。例如，“a”表示小写的“a”，而不是大写的“a”。此外，有符号字节字段和有符号短字段表示为“%x”值，这些值显示了它们的值范围。
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*属性组属性标记数据结尾
attribute-group = begin-attribute-group-tag *attribute
属性组=开始属性组标记*属性
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 defined below
status-code = SIGNED-SHORT ; mapping from model defined below
request-id = SIGNED-INTEGER ; whose value is > 0
operation-id = SIGNED-SHORT ; mapping from model defined below
status-code = SIGNED-SHORT ; mapping from model defined below
request-id = SIGNED-INTEGER ; whose value is > 0
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
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
data = OCTET-STRING
zero-name-length = %x00.00 ; name-length of 0
value-tag = %x10-FF ;see section 3.7.2
begin-attribute-group-tag = %x00-02 / %04-0F ; see section 3.7.1
end-of-attributes-tag = %x03 ; tag of 3
; see section 3.7.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
zero-name-length = %x00.00 ; name-length of 0
value-tag = %x10-FF ;see section 3.7.2
begin-attribute-group-tag = %x00-02 / %04-0F ; see section 3.7.1
end-of-attributes-tag = %x03 ; tag of 3
; see section 3.7.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
The syntax below defines additional terms that are referenced in this document. This syntax provides an alternate grouping of the delimiter tags.
下面的语法定义了本文档中引用的其他术语。此语法提供分隔符标记的备用分组。
delimiter-tag = begin-attribute-group-tag / ; see section 3.7.1
end-of-attributes-tag
delimiter-tag = %x00-0F ; see section 3.7.1
delimiter-tag = begin-attribute-group-tag / ; see section 3.7.1
end-of-attributes-tag
delimiter-tag = %x00-0F ; see section 3.7.1
begin-attribute-group-tag = %x00 / operation-attributes-tag /
job-attributes-tag / printer-attributes-tag /
unsupported-attributes-tag / %x06-0F
operation-attributes-tag = %x01 ; tag of 1
begin-attribute-group-tag = %x00 / operation-attributes-tag /
job-attributes-tag / printer-attributes-tag /
unsupported-attributes-tag / %x06-0F
operation-attributes-tag = %x01 ; tag of 1
job-attributes-tag = %x02 ; tag of 2
printer-attributes-tag = %x04 ; tag of 4
unsupported-attributes-tag = %x05 ; tag of 5
job-attributes-tag = %x02 ; tag of 2
printer-attributes-tag = %x04 ; tag of 4
unsupported-attributes-tag = %x05 ; tag of 5
Each "attribute-group" field MUST be encoded with the "begin-attribute-group-tag" field followed by zero or more "attribute" sub-fields.
每个“属性组”字段必须编码为“开始属性组标记”字段，后跟零个或多个“属性”子字段。
The table below maps the model document group name to value of the "begin-attribute-group-tag" field:
下表将模型文档组名称映射到“开始属性组标记”字段的值：
Model Document Group "begin-attribute-group-tag" field values
模型文档组“开始属性组标记”字段值
Operation Attributes "operations-attributes-tag" Job Template Attributes "job-attributes-tag" Job Object Attributes "job-attributes-tag" Unsupported Attributes "unsupported-attributes-tag" Requested Attributes "job-attributes-tag" (Get-Job-Attributes) Requested Attributes "printer-attributes-tag" (Get-Printer-Attributes) Document Content in a special position as described above
操作属性“操作属性标签”作业模板属性“作业属性标签”作业对象属性“作业属性标签”不支持的属性“不支持的属性标签”请求的属性“作业属性标签”（获取作业属性）请求的属性“打印机属性标签”（获取打印机属性）如上所述，将文档内容置于特殊位置
For each operation request and response, the model document prescribes the required and optional attribute groups, along with their order. Within each attribute group, the model document prescribes the required and optional attributes, along with their order.
对于每个操作请求和响应，模型文档规定了必需和可选属性组及其顺序。在每个属性组中，模型文档规定了必需和可选属性及其顺序。
When the Model document 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 document, 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) An expected but missing "begin-attribute-group-tag" field.
b) 预期但缺少“开始属性组标记”字段。
When the Model document 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, for 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.
当模型文档需要未知数量的属性组序列时，每个属性组的类型相同，编码必须为每个属性组包含一个“开始属性组标记”字段，即使“属性组”字段包含零个“属性”子字段。例如，对于Get Jobs，操作可能会为某些作业返回零属性，而不是为其他作业返回零属性。“begin attribute group tag”字段后跟零个“attribute”字段，告诉收件人队列中有一个作业，除了该作业在队列中之外，没有其他可用信息。
Some operation elements are called parameters in the model document [RFC2911]. They MUST be encoded in a special position and they MUST NOT appear as operation attributes. These parameters are described in the subsections below.
一些操作元素在模型文档[RFC2911]中称为参数。它们必须在特殊位置进行编码，并且不能作为操作属性出现。这些参数在下面的小节中描述。
The "version-number" field MUST consist of a major and minor version-number, each of which MUST be represented by a SIGNED-BYTE. The major version-number MUST be the first byte of the encoding and the minor version-number MUST be the second byte of the encoding. The protocol described in this document MUST have a major version-number of 1 (0x01) and a minor version-number of 1 (0x01). The ABNF for these two bytes MUST be %x01.01.
“版本号”字段必须由主版本号和次版本号组成，每个版本号必须由带符号字节表示。主版本号必须是编码的第一个字节，次版本号必须是编码的第二个字节。本文档中描述的协议的主要版本号必须为1（0x01），次要版本号必须为1（0x01）。这两个字节的ABNF必须为%x01.01。
The "operation-id" field MUST contain an operation-id value defined in the model document. The value MUST be encoded as a SIGNED-SHORT and it MUST be in the third and fourth bytes of the encoding of an operation request.
“操作id”字段必须包含模型文档中定义的操作id值。该值必须编码为有符号短字符，并且必须位于操作请求编码的第三和第四个字节中。
The "status-code" field MUST contain a status-code value defined in the model document. The value MUST be encoded as a SIGNED-SHORT and it MUST be in the third and fourth bytes of the encoding of an operation response.
“状态代码”字段必须包含模型文档中定义的状态代码值。该值必须编码为有符号短字符，并且必须位于操作响应编码的第三和第四个字节中。
The status-code is an operation attribute in the model document. In the protocol, the status-code is in a special position, outside of the operation attributes.
状态代码是模型文档中的操作属性。在协议中，状态代码位于操作属性之外的特殊位置。
If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 (successful-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 MUST contain a request-id value as defined in the model document. The value MUST be encoded as a SIGNED-INTEGER and it MUST be in the fifth through eighth bytes of the encoding.
“请求id”字段必须包含模型文档中定义的请求id值。该值必须编码为有符号整数，并且必须在编码的第五到第八个字节中。
There are two kinds of tags:
有两种类型的标记：
- delimiter tags: delimit major sections of the protocol, namely attributes and data - value tags: specify the type of each attribute value
- 分隔符标记：分隔协议的主要部分，即属性和数据值标记：指定每个属性值的类型
The following table specifies the values for the delimiter tags:
下表指定了分隔符标记的值：
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x00 reserved for definition in a future IETF standards track document 0x01 "operation-attributes-tag" 0x02 "job-attributes-tag" 0x03 "end-of-attributes-tag" 0x04 "printer-attributes-tag" 0x05 "unsupported-attributes-tag" 0x06-0x0f reserved for future delimiters in IETF standards track documents
0x00保留用于未来IETF标准跟踪文档中的定义0x01“操作属性标签”0x02“作业属性标签”0x03“属性结束标签”0x04“打印机属性标签”0x05“不支持的属性标签”0x06-0x0f保留用于未来IETF标准跟踪文档中的分隔符
When a "begin-attribute-group-tag" field occurs in the protocol, it means that zero or more following attributes up to the next delimiter tag MUST be 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 MUST be members of the Operations Attributes group.
当协议中出现“begin attribute group tag”字段时，这意味着下一个分隔符标记之前的零个或多个后续属性必须是属于“begin attribute group tag”值指定的属性组的属性。例如，如果“开始属性组标记”的值为0x01，则以下属性必须是操作属性组的成员。
The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in an operation. It MUST be the last "delimiter-tag". If the operation has a document-content group, the document data in that group MUST follow 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 document. For further details, see section 3.7 "(Attribute) Name" and 13 "Appendix A: Protocol Examples".
每个操作请求和每个操作响应的“属性组”字段（其开头由“开始属性组标记”子字段标记）的顺序和存在性必须与模型文档中定义的相同。有关更多详细信息，请参见第3.7节“属性名称”和第13节“附录A：协议示例”。
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 that there is an entire attribute group that it doesn't understand as opposed to a single value that it doesn't understand.
打印机必须将“分隔符标记”（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.
其余的表显示“值标记”字段的值，该字段是属性的第一个八位字节。“值标记”字段指定属性值的类型。
The following table specifies the "out-of-band" values for the "value-tag" field.
下表指定了“值标记”字段的“带外”值。
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x10 unsupported 0x11 reserved for 'default' for definition in a future IETF standards track document 0x12 unknown 0x13 no-value 0x14-0x1F reserved for "out-of-band" values in future IETF standards track documents.
0x10不支持0x11保留用于未来IETF标准跟踪文档中定义的“默认值”0x12未知0x13没有值0x14-0x1F保留用于未来IETF标准跟踪文档中的“带外”值。
The following table specifies the integer values for the "value-tag" field:
下表指定了“值标记”字段的整数值：
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x20 reserved for definition in a future IETF standards track document 0x21 integer 0x22 boolean 0x23 enum 0x24-0x2F reserved for integer types for definition in future IETF standards track documents
0x20保留用于在未来IETF标准跟踪文档中定义0x21整数0x22布尔0x23枚举0x24-0x2F保留用于在未来IETF标准跟踪文档中定义整数类型
NOTE: 0x20 is reserved for "generic integer" if it should ever be needed.
注意：0x20是为“通用整数”保留的，如果需要的话。
The following table specifies the octetString values for the "value-tag" field:
下表指定了“值标记”字段的八进制字符串值：
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x30 octetString with an unspecified format 0x31 dateTime 0x32 resolution 0x33 rangeOfInteger 0x34 reserved for definition in a future IETF standards track document 0x35 textWithLanguage 0x36 nameWithLanguage 0x37-0x3F reserved for octetString type definitions in future IETF standards track documents
未指定格式的0x30八位字符串0x31日期时间0x32分辨率0x33整数范围0x34保留用于将来的IETF标准跟踪文档中的定义0x35文本带有语言0x36名称带有语言0x37-0x3F保留用于将来的IETF标准跟踪文档中的八位字符串类型定义
The following table specifies the character-string values for the "value-tag" field:
下表指定了“值标记”字段的字符串值：
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x40 reserved for definition in a future IETF standards track document 0x41 textWithoutLanguage 0x42 nameWithoutLanguage 0x43 reserved for definition in a future IETF standards track document 0x44 keyword 0x45 uri 0x46 uriScheme 0x47 charset 0x48 naturalLanguage 0x49 mimeMediaType 0x4A-0x5F reserved for character string type definitions in future IETF standards track documents
0x40保留用于未来IETF标准跟踪文档中的定义0x41 text withoutlanguage 0x42 name withoutlanguage 0x43保留用于未来IETF标准跟踪文档中的定义0x44关键字0x45 uri 0x46 uriScheme 0x47字符集0x48 naturalLanguage 0x49 mimediatype 0x4A-0x5F保留用于未来字符串类型定义IETF标准跟踪文档
NOTE: 0x40 is reserved for "generic character-string" if it should ever be needed.
注意：如果需要，0x40保留给“通用字符串”。
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 IETF standards track documents.
值0x60-0xFF保留给IETF标准跟踪文档中的未来类型定义。
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 4 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 0x00 to 0x37777777 are reserved for definition in future IETF standard track documents. The values 0x40000000 to 0x7FFFFFFF are reserved for vendor extensions.
标记0x7F保留用于将类型扩展到单个字节可用的255个值之外。标记值0x7F必须表示值字段的前4个字节被解释为标记值。注意，这个未来的扩展不会影响不知道这个特殊标记的解析器。该标记类似于任何其他未知标记，值长度指定值的长度，该值包含解析器原子处理的值。0x00到0x377777之间的值保留用于将来IETF标准跟踪文档中的定义。0x40000000到0x7FFFFFFF的值保留给供应商扩展。
The "name-length" field MUST consist of a SIGNED-SHORT. This field MUST specify 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 MUST be empty, and the following value MUST be 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 mal-formed (see [RFC2911] section 3.1.3). The zero-length name is the only mechanism for multi-valued attributes.
如果“名称长度”字段的值为零，则以下“名称”字段必须为空，并且必须将以下值视为前一个最近的“具有一个值的属性”字段中编码的属性的附加值。在一个属性组中，如果两个或多个属性具有相同的名称，则该属性组是错误的（请参见[RFC2911]第3.1.3节）。零长度名称是多值属性的唯一机制。
The "name" field MUST contain the name of an attribute. The model document [RFC2911] specifies such names.
“名称”字段必须包含属性的名称。模型文件[RFC2911]规定了此类名称。
The "value-length" field MUST consist of a SIGNED-SHORT. This field MUST specify 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 (text) 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 character-strings, the sender MUST encode the value with all the characters of the string and without any padding characters.
对于由字符串表示的任何类型，发送方必须使用字符串的所有字符对值进行编码，并且不使用任何填充字符。
For "out-of-band" "value-tag" fields 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 IPP model document. The table below augments the information in the model document, and defines the syntax types from the model document in terms of the 5 basic types defined in section 3, "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING.
IPP模型文档中定义了语法类型（由“值标记”字段指定）和属性值表示的大多数详细信息。下表扩充了模型文档中的信息，并根据第3节“操作层编码”中定义的5种基本类型定义了模型文档中的语法类型。这5种类型是US-ASCII-STRING、本地化-STRING、有符号整数、有符号短、有符号字节和八位字节字符串。
Syntax of Attribute Encoding Value
属性编码值的语法
textWithoutLanguage, LOCALIZED-STRING. nameWithoutLanguage
textWithoutLanguage，本地化的字符串。使用外文命名
textWithLanguage OCTET-STRING consisting of 4 fields: a. a SIGNED-SHORT which is the number of octets in the following field b. a value of type natural-language, c. a SIGNED-SHORT which is the number of octets in the following field, d. a value of type textWithoutLanguage. The length of a textWithLanguage value MUST be 4 + the value of field a + the value of field c.
textWithLanguage八进制字符串，由4个字段组成：a。有符号短字符，表示以下字段b中的八位字节数。自然语言类型的值，c。一种有符号短字符，表示以下字段中的八位字节数，d。textWithoutLanguage类型的值。textWithLanguage值的长度必须为4+字段a的值+字段c的值。
nameWithLanguage OCTET-STRING consisting of 4 fields: a. a SIGNED-SHORT which is the number of octets in the following field b. a value of type natural-language, c. a SIGNED-SHORT which is the number of octets in the following field d. a value of type nameWithoutLanguage. The length of a nameWithLanguage value MUST be 4 + the value of field a + the value of field c.
nameWithLanguage八进制字符串，由4个字段组成：a。有符号短字符，表示以下字段b中的八位字节数。自然语言类型的值，c。有符号短字符，表示以下字段d中的八位字节数。类型为nameWithoutLanguage的值。nameWithLanguage值的长度必须为4+字段a的值+字段c的值。
charset, US-ASCII-STRING. naturalLanguage, mimeMediaType, keyword, uri, and uriScheme
字符集，US-ASCII-STRING。自然语言、mimediatype、关键字、uri和uri模式
Syntax of Attribute Encoding Value
属性编码值的语法
boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 'true'.
布尔有符号字节，其中0x00为“假”，0x01为“真”。
integer and enum a SIGNED-INTEGER.
整数和枚举有符号整数。
dateTime OCTET-STRING consisting of eleven octets whose contents are defined by "DateAndTime" in RFC 1903 [RFC1903].
dateTime八位字节—由十一个八位字节组成的字符串，其内容由RFC 1903[RFC1903]中的“DateAndTime”定义。
resolution OCTET-STRING consisting of nine octets of 2 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
解析八位字节字符串，由9个八位字节组成，其中包含2个有符号整数，后跟一个有符号字节。第一个有符号整数包含交叉馈送方向分辨率的值。第二个有符号整数包含馈送方向分辨率的值。带符号字节包含单位
rangeOfInteger Eight octets consisting of 2 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 1 value. Each value X is encoded according to the rules for encoding its type.
1根据超过1个值的属性的规则进行X编码。每个值X都根据其类型的编码规则进行编码。
octetString OCTET-STRING
八位字符串八位字符串
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 [RFC2616] is the transport layer for this protocol.
HTTP/1.1[RFC2616]是该协议的传输层。
The operation layer has been designed with the assumption that the transport layer contains the following information:
操作层的设计假设传输层包含以下信息：
- the URI of the target job or printer operation - 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.
- 目标作业或打印机操作的URI—操作层中数据的总长度，可以是单个长度，也可以是每个具有一个长度的块序列。
It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631 (the IPP default port), though a printer implementation may support HTTP over some other port as well.
要求打印机实现支持IANA分配的已知端口631（IPP默认端口）上的HTTP，但打印机实现也可以支持其他端口上的HTTP。
Each HTTP operation MUST use the POST method where the request-URI 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 HTTP1.1 [RFC2616]. A printer (server) implementation MUST adhere the rules for an origin server described for HTTP1.1 [RFC2616].
每个HTTP操作必须使用POST方法，其中请求URI是操作的对象目标，并且每个请求和响应中消息体的“内容类型”必须是“应用程序/ipp”。消息正文必须包含操作层，并且必须具有第3.2节“编码语法”中描述的语法。客户机实现必须遵守HTTP1.1[RFC2616]中描述的客户机规则。打印机（服务器）实现必须遵守HTTP1.1[RFC2616]中描述的源服务器规则。
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/1.1, consult the HTTP documents [RFC2616].
IPP服务器为其收到的每个请求发送响应。如果IPP服务器检测到错误，它可能会在读取整个请求之前发送响应。如果IPP服务器的HTTP层成功完成对HTTP头的处理，它可能会发送一个中间响应，例如“100 Continue”，在发送IPP响应之前没有IPP数据。客户机必须期望IPP服务器做出各种响应。有关HTTP/1.1的更多信息，请参阅HTTP文档[RFC2616]。
An HTTP server MUST support chunking for IPP requests, and an IPP client MUST support chunking for IPP responses according to HTTP/1.1 [RFC2616]. Note: this rule causes a conflict with non-compliant implementations of HTTP/1.1 that don't support chunking for POST methods, and this rule may cause a conflict with non-compliant implementations of HTTP/1.1 that don't support chunking for CGI scripts.
根据HTTP/1.1[RFC2616]，HTTP服务器必须支持IPP请求的分块，IPP客户端必须支持IPP响应的分块。注意：此规则会导致与不支持POST方法分块的HTTP/1.1的不兼容实现冲突，并且此规则可能会导致与不支持CGI脚本分块的HTTP/1.1的不兼容实现冲突。
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.
所有打印机和作业对象都由统一资源标识符（URI）[RFC2396]标识，以便可以持久和明确地引用它们。由于每个URL都是URI的一种特殊形式，即使在本文档的其余部分中使用了更通用的术语URI，其用法也旨在涵盖URL的更具体概念。
Some operation elements are encoded twice, once as the request-URI on the HTTP Request-Line and a second time as a REQUIRED operation attribute in the application/ipp entity. These attributes are the target URI for the operation and are called printer-uri and job-uri. Note: The target URI is included twice in an operation referencing the same IPP object, but the two URIs NEED NOT be literally identical. One can be a relative URI and the other can be an absolute URI. HTTP/1.1 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 URLs should be used in the mapping of IPP onto HTTP/1.1:
一些操作元素被编码两次，一次作为HTTP请求行上的请求URI，另一次作为应用程序/ipp实体中所需的操作属性。这些属性是操作的目标URI，称为打印机URI和作业URI。注意：目标URI在引用同一IPP对象的操作中包含两次，但两个URI不必完全相同。一个可以是相对URI，另一个可以是绝对URI。HTTP/1.1允许客户端生成和发送相对URI，而不是绝对URI。相对URI标识HTTP服务器范围内的资源，但不包括方案、主机或端口。以下语句描述了在将IPP映射到HTTP/1.1时应如何使用URL：
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 URLs are not used as the addressing mechanism in the transport layer. 2. Even though these two URLs might not be literally identical (one being relative and the other being absolute), they MUST both reference the same IPP object. However, a Printer NEED NOT verify that the two URLs reference the same IPP object, and NEED NOT take any action if it determines the two URLs to be different. 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. The HTTP server need not be aware of the URI within the operation request. 4. Once the HTTP server resource begins to process the HTTP request, it might get the reference to the appropriate IPP Printer object from either the HTTP URI (using to the context of the HTTP server for relative URLs) or from the URI within the operation request; the choice is up to the implementation. 5. HTTP URIs can be relative or absolute, but the target URI in the operation MUST be an absolute URI.
1. 尽管可能是冗余的，但客户机必须在HTTP层提供操作目标作为操作属性和URI。这一决定的基本原理是维护一套一致的规则，以便将应用程序/ipp映射到可能的多个通信层，即使URL未用作传输层中的寻址机制。2.尽管这两个URL可能并不完全相同（一个是相对的，另一个是绝对的），但它们必须都引用相同的IPP对象。但是，打印机无需验证两个URL是否引用相同的IPP对象，并且如果确定两个URL不同，则无需采取任何操作。3.HTTP层中的URI是相对的或绝对的，HTTP服务器使用它将HTTP请求路由到相对于该HTTP服务器的正确资源。HTTP服务器不需要知道操作请求中的URI。4.一旦HTTP服务器资源开始处理HTTP请求，它可能会从HTTP URI（将相对URL用于HTTP服务器的上下文）或操作请求中的URI获取对适当IPP打印机对象的引用；选择取决于实现。5.HTTP URI可以是相对的，也可以是绝对的，但操作中的目标URI必须是绝对URI。
The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL that identifies either an IPP printer object or an IPP job object. The IPP attributes using the 'ipp' scheme are specified below. Because the HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP headers. The mapping is simple because the 'ipp' scheme implies all of the same protocol semantics as that of the 'http' scheme
IPP/1.1文档将新方案“IPP”定义为标识IPP打印机对象或IPP作业对象的URL值。下面指定了使用“IPP”方案的IPP属性。由于HTTP层不支持“ipp”方案，因此客户端必须将“ipp”URL映射到“HTTP”URL，然后遵循HTTP[RFC2616][RFC2617]规则来构造请求行和HTTP头。映射很简单，因为“ipp”方案暗示了与“http”方案相同的所有协议语义
[RFC2616], except that it represents a print service and the implicit (default) port number that clients use to connect to a server is port 631.
[RFC2616]，但它表示打印服务，客户端用于连接到服务器的隐式（默认）端口号为端口631。
In the remainder of this section the term 'ipp-URL' means a URL whose scheme is 'ipp' and whose implicit (default) port is 631. The term 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' means a URL whose scheme is 'https',
在本节剩余部分中，术语“ipp URL”是指方案为“ipp”且隐式（默认）端口为631的URL。术语“http URL”表示其方案为“http”的URL，术语“https URL”表示其方案为“https”的URL，
A client and an IPP object (i.e. the server) MUST support the ipp-URL value in the following IPP attributes. job attributes: job-uri job-printer-uri printer attributes: printer-uri-supported operation attributes: job-uri printer-uri Each of the above attributes identifies a printer or job object. The ipp-URL is intended as the value of the attributes in this list, and for no other attributes. 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对象（即服务器）必须支持以下IPP属性中的IPP URL值。作业属性：作业uri作业打印机uri打印机属性：打印机uri支持的操作属性：作业uri打印机uri上述每个属性都标识打印机或作业对象。ipp URL用作此列表中属性的值，不用于其他属性。所有这些属性的语法类型均为“uri”，但也有一些语法类型为“uri”的属性不使用“ipp”方案，例如“job more info”。
If a printer registers its URL with a directory service, the printer MUST register an ipp-URL.
如果打印机向目录服务注册其URL，则打印机必须注册ipp URL。
User interfaces are beyond the scope of this document. But if software exposes the ipp-URL values of any of the above five attributes to a human user, it is REQUIRED that the human see the ipp-URL as is.
用户界面超出了本文档的范围。但是，如果软件将上述五个属性中任何一个的ipp URL值公开给人类用户，则人类必须看到ipp URL的原样。
When a client sends a request, it MUST convert a target ipp-URL to a target http-URL for the HTTP layer according to the following rules:
客户端发送请求时，必须根据以下规则将目标ipp URL转换为http层的目标http URL：
1. change the 'ipp' scheme to 'http' 2. add an explicit port 631 if the URL does not contain an explicit port. Note: port 631 is the IANA assigned Well Known Port for the 'ipp' scheme.
1. 将“ipp”方案更改为“http”2。如果URL不包含显式端口，请添加显式端口631。注：631端口是IANA为“ipp”方案指定的知名端口。
The client MUST use the target http-URL in both the HTTP Request-Line and HTTP headers, as specified by HTTP [RFC2616] [RFC2617] . However, the client MUST use the target ipp-URL 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 ipp-URL
客户端必须在http请求行和http头中使用目标http URL，如http[RFC2616][RFC2617]所指定。但是，客户端必须使用目标ipp URL作为请求的应用程序/ipp正文中的“打印机uri”或“作业uri”操作属性的值。服务器必须使用ipp URL
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”属性的值。
For example, when an IPP client sends a request directly (i.e. no proxy) to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP connection to port 631 (the ipp implicit port) on the host "myhost.com" and sends the following data:
例如，当IPP客户端直接（即无代理）向IPP URL发送请求时“ipp://myhost.com/myprinter/myqueue，它将打开到主机“myhost.com”上的端口631（ipp隐式端口）的TCP连接，并发送以下数据：
POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in application/ipp message body) ...
POST/myprinter/myqueue HTTP/1.1主机：myhost.com:631内容类型：应用程序/ipp传输编码：分块。。。“打印机uri”ipp://myhost.com/myprinter/myqueue“（在应用程序/ipp消息正文中编码）。。。
As another example, when an IPP client sends the same request as above via a proxy "myproxy.com", it opens a TCP connection to the proxy port 8080 on the proxy host "myproxy.com" and sends the following data:
作为另一个示例，当IPP客户端通过代理“myproxy.com”发送与上述相同的请求时，它会打开到代理主机“myproxy.com”上的代理端口8080的TCP连接，并发送以下数据：
POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in application/ipp message body) ...
邮递http://myhost.com:631/myprinter/myqueue HTTP/1.1主机：myhost.com:631内容类型：应用程序/ipp传输编码：分块。。。“打印机uri”ipp://myhost.com/myprinter/myqueue“（在应用程序/ipp消息正文中编码）。。。
The proxy then connects to the IPP origin server with headers that are the same as the "no-proxy" example above.
然后，代理使用与上述“无代理”示例相同的头连接到IPP源服务器。
This section describes the procedures for allocating encoding for the following IETF standards track extensions and vendor extensions to the IPP/1.1 Encoding and Transport document:
本节描述了将以下IETF标准轨道扩展和供应商扩展的编码分配到IPP/1.1编码和传输文件的过程：
1. attribute syntaxes - see [RFC2911] section 6.3 2. attribute groups - see [RFC2911] section 6.5 3. out-of-band attribute values - see [RFC2911] section 6.7
1. 属性语法-参见[RFC2911]第6.3.2节。属性组-参见[RFC2911]第6.5.3节。带外属性值-参见[RFC2911]第6.7节
These extensions follow the "type2" registration procedures defined in [RFC2911] section 6. Extensions registered for use with IPP/1.1 are OPTIONAL for client and IPP object conformance to the IPP/1.1 Encoding and Transport document.
这些扩展遵循[RFC2911]第6节中定义的“类型2”注册程序。对于客户端和IPP对象是否符合IPP/1.1编码和传输文档，注册用于IPP/1.1的扩展是可选的。
These extension procedures are aligned with the guidelines as set forth by the IESG [IANA-CON]. The [RFC2911] Section 11 describes how to propose new registrations for consideration. IANA will reject registration proposals that leave out required information or do not follow the appropriate format described in [RFC2911] Section 11. The IPP/1.1 Encoding and Transport document may also be extended by an appropriate RFC that specifies any of the above extensions.
这些扩展程序符合IESG[IANA-CON]规定的指南。[RFC2911]第11节描述了如何提出新注册供考虑。IANA将拒绝遗漏所需信息或未遵循[RFC2911]第11节所述适当格式的注册提案。IPP/1.1编码和运输文件也可通过指定上述任何扩展的适当RFC进行扩展。
See the section on "Internationalization Considerations" in the document "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] for information on internationalization. This document adds no additional issues.
有关国际化的信息，请参阅文档“Internet打印协议/1.1：模型和语义”[RFC2911]中的“国际化注意事项”部分。本文件不增加其他问题。
The IPP Model and Semantics document [RFC2911] 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模型和语义文档[RFC2911]讨论了高级安全要求（客户端身份验证、服务器身份验证和操作隐私）。客户端身份验证是客户端以安全的方式向服务器证明其身份的机制。服务器身份验证是服务器以安全的方式向客户端证明其身份的机制。操作隐私被定义为防止操作被窃听的机制。
This section defines the security requirements for IPP clients and IPP objects.
本节定义了IPP客户端和IPP对象的安全要求。
IPP clients MUST support:
IPP客户必须支持：
Digest Authentication [RFC2617].
摘要认证[RFC2617]。
MD5 and MD5-sess MUST be implemented and supported.
必须实施和支持MD5和MD5 SES。
The Message Integrity feature NEED NOT be used.
不需要使用消息完整性功能。
IPP Printers SHOULD support:
IPP打印机应支持：
Digest Authentication [RFC2617].
摘要认证[RFC2617]。
MD5 and MD5-sess MUST be implemented and supported.
必须实施和支持MD5和MD5 SES。
The Message Integrity feature NEED NOT be used.
不需要使用消息完整性功能。
The reasons that IPP Printers SHOULD (rather than MUST) support Digest Authentication are:
IPP打印机应（而非必须）支持摘要身份验证的原因如下：
1. While Client Authentication is important, there is a certain class of printer 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 and could potentially stall the adoption of the standard.
1. 虽然客户端身份验证很重要，但在某些类型的打印机设备中，它是没有意义的。具体而言，具有有限ROM空间和较低纸张吞吐量的低端设备可能不需要客户端身份验证。这类设备通常需要固件设计者在协议和功能之间进行权衡，以获得尽可能低的成本解决方案。设计师的决策不仅考虑到代码的大小，还考虑到交付给客户的每个特性的测试、维护、有用性和上市时间影响。强制这些低端设备提供安全性以声明IPP/1.1合规性在商业上是没有意义的，可能会阻碍标准的采用。
2. Print devices that have high-volume throughput and have available ROM space have a compelling argument to provide support for Client Authentication that safeguards the device from unauthorized access. These devices are prone to a high loss of consumables and paper if unauthorized access should occur.
2. 具有高吞吐量和可用ROM空间的打印设备有一个令人信服的理由，即支持客户端身份验证，以保护设备免受未经授权的访问。如果发生未经授权的访问，这些设备很容易造成耗材和纸张的大量损失。
IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for Server Authentication and Operation Privacy. IPP Printers MAY also support TLS for Client Authentication. If an IPP Printer supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL. An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 [RFC2617]) for Client Authentication if the channel is secure. TLS with the above mandated cipher suite can provide such a secure channel.
IPP打印机应支持传输层安全（TLS）[RFC2246]以实现服务器身份验证和操作隐私。IPP打印机还可以支持TLS进行客户端身份验证。如果IPP打印机支持TLS，则必须按照RFC 2246[RFC2246]的规定，支持TLS\u DHE\u DSS\u和\u 3DES\u EDE\u CBC\u SHA密码套件。所有其他密码套件都是可选的。如果通道是安全的，IPP打印机可以支持客户端身份验证的基本身份验证（如HTTP/1.1[RFC2617]所述）。具有上述强制密码套件的TLS可以提供这样一个安全通道。
If a IPP client supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL.
如果IPP客户端支持TLS，则它必须按照RFC 2246[RFC2246]的规定，支持TLS\u DHE\u DSS\u和\u 3DES\u EDE\u CBC\u SHA密码套件。所有其他密码套件都是可选的。
The IPP Model and Semantics document 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 should be the primary reference for security implications with regard to the IPP protocol itself. For backward compatibility with IPP version 1.0, IPP clients and printers may also support SSL3 [ssl]. This is in addition to the security required in this document.
IPP模型和语义文档定义了两个打印机属性（“支持uri身份验证”和“支持uri安全”），客户端可以使用它们来发现打印机的安全策略。该文件还概述了IPP特定的安全注意事项，并应作为IPP协议本身安全影响的主要参考。为了与IPP版本1.0向后兼容，IPP客户端和打印机也可以支持SSL3[ssl]。这是对本文件要求的安全性的补充。
IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817]. An initial IPP request never uses TLS. 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/1.1使用“在HTTP/1.1中升级到TLS”机制[RFC2817]。初始IPP请求从不使用TLS。客户端使用HTTP“升级”头请求安全TLS连接，而服务器在HTTP响应中表示同意。切换到TLS的原因可能是服务器授予客户端升级到TLS的请求，或者服务器在其响应中请求切换到TLS。安全通信从服务器对切换到TLS的响应开始。
It is beyond the scope of this specification to mandate conformance with previous versions. IPP/1.1 was deliberately designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification (1999), we would expect IPP/1.1 Printer implementations to:
强制要求与以前版本的一致性超出了本规范的范围。然而，IPP/1.1的设计初衷是为了使支持以前的版本变得容易。值得注意的是，在编写本规范（1999年）时，我们希望IPP/1.1打印机实现：
understand any valid request in the format of IPP/1.0, or 1.1;
理解IPP/1.0或1.1格式的任何有效请求；
respond appropriately with a response containing the same "version-number" parameter value used by the client in the request.
使用包含客户端在请求中使用的相同“版本号”参数值的响应进行适当响应。
And we would expect IPP/1.1 clients to:
我们希望IPP/1.1客户：
understand any valid response in the format of IPP/1.0, or 1.1.
理解IPP/1.0或1.1格式的任何有效响应。
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 a '1.1' value and SHOULD try supplying alternate version numbers if they receive a 'server-error-version-not-supported' error return in a response.
1. 客户端必须发送包含“version number”参数和“1.1”值的请求，如果在响应中收到“server error version not supported”错误返回，则应尝试提供备用版本号。
2. IPP objects 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. It is recommended that IPP objects accept any request with the major version '1' (or reject the request for reasons other than 'server-error-version-not-supported'). See [RFC2911] "versions" sub-section.
3. 建议IPP对象接受主版本为“1”的任何请求（或以“不支持服务器错误版本”以外的原因拒绝请求）。参见[RFC2911]“版本”小节。
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/1.1 conforming Printer object accepts version '1.0' requests and is configured to enforce Digest Authentication, it MUST do the same for a version '1.0' request.
4. 在任何情况下，当客户端在请求中提供较低的“版本号”参数时，安全性都不得受到损害。例如，如果符合IPP/1.1的打印机对象接受版本“1.0”请求并配置为强制摘要身份验证，则它必须对版本“1.0”请求执行相同的操作。
The following are rules regarding security, the "version-number" parameter, and the URL scheme supplied in target attributes and responses:
以下是有关安全性、“版本号”参数以及目标属性和响应中提供的URL方案的规则：
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 server returns the "job-printer-uri" or "job-uri" Job Description attributes, it SHOULD return the same scheme ('ipp', 'https', 'http', 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 attributes that the server 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.
2. 当服务器返回“作业打印机uri”或“作业uri”作业描述属性时，它应该返回客户端在Get job attributes或Get Jobs请求中的“打印机uri”或“作业uri”目标操作属性中提供的相同方案（“ipp”、“https”、“http”等），而不是创建作业时使用的方案。但是，当客户端使用“获取作业属性”或“获取作业”操作请求作业属性时，服务器返回的作业和作业属性取决于：（1）创建作业时有效的安全性，（2）查询请求中有效的安全性，以及（3）有效的安全策略。
3. It is recommended that if a server registers a non-secure ipp-URL with a directory service (see [RFC2911] "Generic Directory Schema" Appendix), then it also register an http-URL for interoperability with IPP/1.0 clients (see section 9).
3. 建议如果服务器向目录服务注册一个不安全的ipp URL（请参见[RFC2911]“通用目录架构”附录），那么它还应注册一个http URL，以便与ipp/1.0客户端进行互操作（请参见第9节）。
4. In any case, security MUST NOT be compromised when a client supplies an 'http' or other non-secure URL scheme in the target "printer-uri" and "job-uri" operation attributes in a request.
4. 在任何情况下，当客户机在请求中的目标“打印机uri”和“作业uri”操作属性中提供“http”或其他不安全的URL方案时，都不得损害安全性。
[dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996.
[dpa]ISO/IEC 10175文件打印应用（dpa），1996年6月。
[iana] IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
[iana]iana编码字符集注册表：ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
[IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-CON]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: Implementer's Guide", Work in Progress.
[ipp iig]Hastings，Tom等，“互联网打印协议/1.1：实施者指南”，正在进行的工作。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October, 1989.
[RFC1123]Braden，S.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol", RFC 1179, August 1990.
[RFC1179]McLaughlin，L.III，（编辑），“行打印机守护程序协议”，RFC1179，1990年8月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223]Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1759]Smith，R.，Wright，F.，Hastings，T.，Zilles，S.和J.Gylenskog，“打印机MIB”，RFC 1759，1995年3月。
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766]Alvestrand，H.，“语言识别标签”，RFC1766，1995年3月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[RFC1808]菲尔丁，R.，“相对统一资源定位器”，RFC18081995年6月。
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC1903]Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的文本约定”，RFC 1903，1996年1月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[RFC2048]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997.
[RFC2184]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC2184，1997年8月。
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]Crocker，D.和P.总体，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246. January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议”，RFC 2246。1999年1月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565]Herriot，R.，Butler，S.，Moore，P.和R.Turner，“互联网打印协议/1.0：编码和传输”，RFC 25651999年4月。
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2566]deBry，R.，Hastings，T.，Herriot，R.，Isaacson，S.和P.Powell，“互联网打印协议/1.0：模型和语义”，RFC 2566，1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC2567, April 1999.
[RFC2567]Wright，D.，“互联网打印协议的设计目标”，RFC2567，1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2568]Zilles，S.“互联网打印协议的结构、模型和协议的基本原理”，RFC 2568，1999年4月。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2569]Herriot，R.，Hastings，T.，Jacobs，N.和J.Martin，“LPD和IPP协议之间的映射”，RFC 2569，1999年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议-HTTP/1.1”，RFC 2616，1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[RFC2910]Herriot，R.，Butler，S.，Moore，P.，Turner，R.和J.Wenn，“互联网打印协议/1.1：编码和传输”，RFC 29102000年9月。
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000.
[RFC2911]黑斯廷斯，T.，赫里奥特，R.，德布雷，R.，艾萨克森，S.和P.鲍威尔，“互联网打印协议/1.1：模型和语义”，RFC 29112000年9月。
[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.
[SSL]Netscape，SSL协议，版本3，（文本版本3.02），1996年11月。
Robert Herriot, Editor Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
罗伯特·赫里奥特，编辑施乐公司3400希尔维尤大道，帕洛阿尔托1号楼，加利福尼亚州94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: robert.herriot@pahv.xerox.com
电话：650-813-7696传真：650-813-6860电子邮件：罗伯特。herriot@pahv.xerox.com
Sylvan Butler Hewlett-Packard 11311 Chinden Blvd. Boise, ID 83714
希尔万·巴特勒-惠普公司钦登大道11311号。博伊西，身份证号码83714
Phone: 208-396-6000 Fax: 208-396-3457 EMail: sbutler@boi.hp.com
电话：208-396-6000传真：208-396-3457电子邮件：sbutler@boi.hp.com
Paul Moore Peerless Systems Networking 10900 NE 8th St #900 Bellevue, WA 98004
Paul Moore Peerless Systems Networking 10900东北第八街900号华盛顿州贝尔维尤，邮编：98004
Phone: 425-462-5852 EMail: pmoore@peerless.com
电话：425-462-5852电子邮件：pmoore@peerless.com
Randy Turner 2Wire, Inc. 694 Tasman Dr. Milpitas, CA 95035
Randy Turner 2Wire，Inc.694 Tasman Milpitas博士，加利福尼亚州95035
Phone: 408-546-1273
电话：408-546-1273
John Wenn Xerox Corporation 737 Hawaii St El Segundo, CA 90245
约翰·温·施乐公司，美国加利福尼亚州夏威夷圣塞贡多737号，邮编90245
Phone: 310-333-5764 Fax: 310-333-5514 EMail: jwenn@cp10.es.xerox.com
电话：310-333-5764传真：310-333-5514电子邮件：jwenn@cp10.es.xerox.com
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.org
To subscribe to the ipp mailing list, send the following email: 1) send it to majordomo@pwg.org 2) leave the subject line blank 3) put the following two lines in the message body: subscribe ipp end
要订阅ipp邮件列表，请发送以下电子邮件：1）发送至majordomo@pwg.org2）主题行留空3）在消息正文中插入以下两行：subscribe ipp end
12. Other Participants:
12. 其他与会者：
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Information Systems
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Information Systems
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.
Systems
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Canon Information Lloyd Young - Lexmark
Systems
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang - Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon Information
Systems
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.
Systems
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Canon Information Lloyd Young - Lexmark
Systems
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang - Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon Information
Systems
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 are 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-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- name natural- attributes-natural-language language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x0015 value-length ipp://forest/ printer pinetree value pinetree 0x42 nameWithoutLanguage type value-tag 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x22 boolean type value-tag 0x0016 name-length ipp-attribute- ipp-attribute-fidelity name fidelity 0x0001 value-length 0x01 true value
0x0101 1.1版本号0x0002打印作业操作id 0x00000001 1请求id 0x01开始操作属性操作属性标签0x47字符集类型值标签0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标签0x001B名称长度属性-名称natural-属性自然语言语言0x0005值长度en us en us值0x45 uri类型值标记0x000B名称长度打印机uri名称0x0015值长度ipp://forest/ 打印机pinetree值pinetree 0x42名称带外部语言类型值标记0x0008名称长度作业名称作业名称0x0006值长度foobar foobar值0x22布尔类型值标记0x0016名称长度ipp属性-ipp属性保真度名称保真度0x0001值长度0x01真值
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x02 start job-attributes job-attributes-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- two-sided-long-edge value long-edge 0x03 end-of-attributes end-of-attributes-tag %!PS... <PostScript> data
0x02开始作业属性作业属性标记0x21整型值标记0x0006名称长度复制名称0x0004值长度0x00000014 20值0x44关键字类型值标记0x0005名称长度侧面名称0x0013值长度双面-双面长边值长边0x03属性结束属性结束标记%！PS<PostScript>数据
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-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural- name natural-language language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000E name-length status-message status-message name 0x000D value-length
0x0101 1.1版本号0x0000成功ok状态代码0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-属性自然-名称自然语言0x0005值长度en us en us值0x41文本带外部语言类型值标记0x000E名称长度状态消息状态消息名称0x000D值长度
Octets Symbolic Value Protocol field
八位字节符号值协议字段
successful-ok successful-ok value 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 0x0019 value-length ipp://forest/ job 123 on pinetree value pinetree/123 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
成功确定成功确定值0x02开始作业属性作业属性标记0x21整数值标记0x0006名称长度作业id作业id名称0x0004值长度147值0x45 uri类型值标记0x0007名称长度作业uri名称0x0019值长度ipp://forest/ pinetree值pinetree/123 0x23枚举类型值标记0x0009上的作业123名称长度作业状态作业状态名称0x0004值长度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）。
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- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value
0x0101 1.1版本号0x040B客户端错误属性或-不支持的状态代码值0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural-language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000E name-length status- status-message name message 0x002F value-length client-error- value attributes- values-not-supported or-values- client-error-attributes-or-not-supported 0x05 start unsupported-attributes unsupported-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
0x48自然语言类型值标记0x001B名称长度属性-属性自然语言名称自然语言0x0005值长度en us en us值0x41 text WithOutlanguage类型值标记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
0x0101 1.1版本号0x0001成功ok忽略或-状态代码
Octets Symbolic Value Protocol field
八位字节符号值协议字段
substituted-attributes 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural- name natural-language 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- successful-ok-ignored-or- value ignored-or- 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 0x0019 value-length ipp://forest/ job 123 on pinetree value pinetree/123
替换属性0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-自然属性-名称自然语言语言0x0005值长度en us en us值0x41 textWithoutLanguage类型值标记0x000E名称长度状态消息状态消息名称0x002F值长度成功确定-成功确定忽略或-值忽略或-替换属性替换属性0x05开始不支持-不支持的属性属性标记0x21整数类型值标记0x0006名称长度复制不支持的副本名称0x0004值长度0x00000014 20值0x10（类型）值标记0x0005名称长度边名称0x0000值长度0x02开始作业属性作业属性标记0x21整数值标记0x0006名称长度作业id作业id名称0x0004值长度147 147值0x45 uri类型值标记0x0007名称长度作业uri作业uri名称0x0019值长度ipp://forest/ 作业123关于松树价值松树/123
Octets Symbolic Value Protocol field
八位字节符号值协议字段
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
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-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural-language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x0015 value-length ipp://forest/ printer pinetree value pinetree 0x45 uri type value-tag 0x000C name-length document-uri document-uri name 0x0011 value-length ftp://foo.com ftp://foo.com/foo value
0x0101 1.1版本号0x0003打印URI操作id 0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-属性自然语言名称自然语言0x0005值长度en us en us值0x45 uri类型值标记0x000B名称长度打印机uri名称0x0015值长度ipp://forest/ 打印机pinetree值pinetree 0x45 uri类型值标记0x000C名称长度文档uri文档uri名称0x0011值长度ftp://foo.com ftp://foo.com/foo 价值
Octets Symbolic Value Protocol field
八位字节符号值协议字段
/foo 0x42 nameWithoutLanguage type value-tag 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 0x00000001 1 value 0x03 end-of-attributes end-of-attributes-tag
/foo 0x42名称WithOutlanguage类型值标记0x0008名称长度作业名称作业名称名称0x0006值长度foobar foobar值0x02开始作业属性作业属性标记0x21整型值标记0x0006名称长度复制名称0x0004值长度0x00000001值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-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural-language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x0015 value-length ipp://forest/ printer pinetree value pinetree
0x0101 1.1版本号0x0005创建作业操作id 0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-属性自然语言名称自然语言0x0005值长度en us en us值0x45 uri类型值标记0x000B名称长度打印机uri名称0x0015值长度ipp://forest/ 打印机pinetree值pinetree
Octets Symbolic Value Protocol field
八位字节符号值协议字段
inetree 0x03 end-of-attributes end-of-attributes-tag
inetree 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 0x00000123 0x123 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural-language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x0015 value-length ipp://forest/ printer pinetree value 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- requested-attributes name attributes 0x0006 value-length
0x0101 1.1版本号0x000A获取作业操作id 0x0000123 0x123请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-属性自然语言名称自然语言0x0005值长度en us en us值0x45 uri类型值标记0x000B名称长度打印机uri名称0x0015值长度ipp://forest/ 打印机pinetree值pinetree 0x21整型值标记0x0005名称长度限制名称0x0004值长度0x00000032 50值0x44关键字类型请求的值标记0x0014名称长度-请求的属性名称属性0x0006值长度
Octets Symbolic Value Protocol field
八位字节符号值协议字段
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
作业id作业id值0x44关键字类型值标记0x0000附加值名称长度0x0008值长度作业名称作业名称值0x44关键字类型值标记0x0000附加值名称长度0x000F值长度文档格式文档格式值0x03属性结束属性结束标记
The following is an of Get-Jobs response from previous request with 3 jobs. The Printer returns no information about the second job (because of security reasons):
下面是来自前一个请求的Get Jobs响应的示例，其中包含3个作业。打印机不返回有关第二个作业的信息（出于安全原因）：
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0101 1.1 version-number 0x0000 successful-ok status-code 0x00000123 0x123 request-id (echoed back) 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x000A value-length ISO-8859-1 ISO-8859-1 value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural-language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000E name-length status-message status-message name 0x000D value-length successful-ok successful-ok value 0x02 start job-attributes (1st job-attributes-tag
0x0101 1.1版本号0x0000成功正常状态代码0x00000123 0x123请求id（回显）0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x000A值长度ISO-8859-1 ISO-8859-1值0x48自然语言类型值标记0x001B名称长度属性-属性自然语言名称自然语言0x0005值长度en us en us值0x41 text WithOutlanguage类型值标记0x000E名称长度状态消息状态消息名称0x000D值长度成功确定成功确定值0x02开始作业属性（第一个作业属性标记
Octets Symbolic Value Protocol field
八位字节符号值协议字段
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 (2nd job-attributes-tag object) 0x02 start job-attributes (3rd job-attributes-tag 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
对象）0x21整型值标记0x0006名称长度作业id作业id名称0x0004值长度147 147值0x36名称带语言值标记0x0008名称长度作业名称作业名称0x000C值长度0x0005子值长度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属性结束属性结束标记
14. Appendix B: Registration of MIME Media Type Information for "application/ipp"
14. 附录B：“应用程序/ipp”MIME媒体类型信息的注册
This appendix contains the information that IANA requires for registering a MIME media type. The information following this paragraph will be forwarded to IANA to register application/ipp whose contents are defined in Section 3 "Encoding of the Operation Layer" in this document:
本附录包含IANA注册MIME媒体类型所需的信息。本段之后的信息将转发给IANA，以注册本文件第3节“操作层编码”中定义的内容的应用程序/ipp：
MIME type name: application
MIME类型名称：应用程序
MIME subtype name: ipp
MIME子类型名称：ipp
A Content-Type of "application/ipp" indicates an Internet Printing Protocol message body (request or response). Currently there is one version: IPP/1.1, whose syntax is described in Section 3 "Encoding of the Operation Layer" of [RFC2910], and whose semantics are described in [RFC2911].
“应用程序/ipp”的内容类型表示Internet打印协议消息体（请求或响应）。目前有一个版本：IPP/1.1，其语法在[RFC2910]第3节“操作层编码”中描述，其语义在[RFC2911]中描述。
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations:
编码注意事项：
IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths).
IPP/1.1协议请求/响应可能包含长行，并且始终包含二进制数据（例如属性值长度）。
Security considerations:
安全考虑：
IPP/1.1 protocol requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. Protocol mixed-version interworking rules in [RFC2911] as well as protocol encoding rules in [RFC2910] are complete and unambiguous.
IPP/1.1协议请求/响应不会引入基础传输协议中尚未固有的任何安全风险。[RFC2911]中的协议混合版本互通规则以及[RFC2910]中的协议编码规则是完整且明确的。
Interoperability considerations:
互操作性注意事项：
IPP/1.1 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [RFC2911] and [RFC2910]. Protocol encoding rules specified in [RFC2910] 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/1.1 attribute values which are a LOCALIZED-STRING are explicit within IPP protocol requests/responses (without recourse to any external information in HTTP, SMTP, or other message transport headers).
IPP/1.1请求（由客户端生成）和响应（由服务器生成）必须符合规范性规范[RFC2911]和[RFC2910]规定的所有一致性要求。[RFC2910]中规定的协议编码规则是全面的，因此可以保证一致性实现之间的互操作性（尽管无法确保对特定可选功能的支持）。作为本地化字符串的所有IPP/1.1属性值的“字符集”和“自然语言”在IPP协议请求/响应中都是明确的（无需求助于HTTP、SMTP或其他邮件传输头中的任何外部信息）。
Published specifications:
公布的规格：
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000.
[RFC2911]黑斯廷斯，T.，赫里奥特，R.，德布雷，R.，艾萨克森，S.和P.鲍威尔，“互联网打印协议/1.1：模型和语义”，RFC 29112000年9月。
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[RFC2910]Herriot，R.，Butler，S.，Moore，P.，Turner，R.和J.Wenn，“互联网打印协议/1.1：编码和传输”，RFC 29102000年9月。
Applications which use this media type:
使用此媒体类型的应用程序：
Internet Printing Protocol (IPP) print clients and print servers, communicating using HTTP/1.1 (see [RFC2910]), SMTP/ESMTP, FTP, or other transport protocol. Messages of type "application/ipp" are self-contained and transport-independent, including "charset" and "natural-language" context for any LOCALIZED-STRING value.
Internet打印协议（IPP）打印客户端和打印服务器，使用HTTP/1.1（参见[RFC2910]）、SMTP/ESMTP、FTP或其他传输协议进行通信。“application/ipp”类型的消息是自包含且独立于传输的，包括任何本地化字符串值的“charset”和“natural language”上下文。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Tom Hastings Xerox Corporation 737 Hawaii St. ESAE-231 El Segundo, CA
汤姆·黑斯廷斯施乐公司737夏威夷圣埃塞-231埃尔塞贡多，加利福尼亚州
Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com
电话：310-333-6413传真：310-333-5514电子邮件：hastings@cp10.es.xerox.com
or
或
Robert Herriot Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
罗伯特·赫里奥特施乐公司加利福尼亚州帕洛阿尔托市希尔维尤大道3400号1栋94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: robert.herriot@pahv.xerox.com
电话：650-813-7696传真：650-813-6860电子邮件：罗伯特。herriot@pahv.xerox.com
Intended usage:
预期用途：
COMMON
常见的
IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes:
IPP/1.1与IPP/1.0[RFC2565]相同，但有以下变化：
1. Attributes values that identify a printer or job object use a new 'ipp' scheme. The 'http' and 'https' schemes are supported only for backward compatibility. See section 5.
1. 标识打印机或作业对象的属性值使用新的“ipp”方案。“http”和“https”方案仅支持向后兼容。见第5节。
2. Clients MUST support of Digest Authentication, IPP Printers SHOULD support Digest Authentication. See Section 8.1.1
2. 客户端必须支持摘要身份验证，IPP打印机应支持摘要身份验证。见第8.1.1节
3. TLS is recommended for channel security. In addition, SSL3 may be supported for backward compatibility. See Section 8.1.2
3. 建议使用TLS实现通道安全。此外，可能支持SSL3以实现向后兼容性。见第8.1.2节
4. It is recommended that IPP/1.1 objects accept any request with major version number '1'. See section 9.1.
4. 建议IPP/1.1对象接受主版本号为“1”的任何请求。见第9.1节。
5. IPP objects SHOULD return the URL scheme requested for "job-printer-uri" and "job-uri" Job Attributes, rather than the URL scheme used to create the job. See section 9.2.
5. IPP对象应返回为“作业打印机uri”和“作业uri”作业属性请求的URL方案，而不是用于创建作业的URL方案。见第9.2节。
6. The IANA and Internationalization sections have been added. The terms "private use" and "experimental" have been changed to "vendor extension". The reserved allocations for attribute group tags, attribute syntax tags, and out-of-band attribute values have been clarified as to which are reserved to future IETF standards track documents and which are reserved to vendor extension. Both kinds of extensions use the type2 registration procedures as defined in [RFC2911].
6. 增加了IANA和国际化部分。术语“私人使用”和“实验性”已改为“供应商扩展”。属性组标记、属性语法标记和带外属性值的保留分配已经澄清，哪些保留给未来的IETF标准跟踪文档，哪些保留给供应商扩展。这两种扩展都使用[RFC2911]中定义的type2注册过程。
7. Clarified that future "out-of-band" value definitions may use the value field if additional information is needed.
7. 阐明如果需要其他信息，未来的“带外”值定义可能会使用值字段。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。