Network Working Group R. Herriot, Ed.
Request for Comments: 2565 Xerox Corporation
Category: Experimental S. Butler
Hewlett-Packard
P. Moore
Microsoft
R. Turner
Sharp Labs
April 1999
Network Working Group R. Herriot, Ed.
Request for Comments: 2565 Xerox Corporation
Category: Experimental S. Butler
Hewlett-Packard
P. Moore
Microsoft
R. Turner
Sharp Labs
April 1999
Internet Printing Protocol/1.0: Encoding and Transport
Internet打印协议/1.0：编码和传输
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
IESG Note
IESG注释
This document defines an Experimental protocol for the Internet community. The IESG expects that a revised version of this protocol will be published as Proposed Standard protocol. The Proposed Standard, when published, is expected to change from the protocol defined in this memo. In particular, it is expected that the standards-track version of the protocol will incorporate strong authentication and privacy features, and that an "ipp:" URL type will be defined which supports those security measures. Other changes to the protocol are also possible. Implementors are warned that future versions of this protocol may not interoperate with the version of IPP defined in this document, or if they do interoperate, that some protocol features may not be available.
本文档为互联网社区定义了一个实验协议。IESG希望本协议的修订版将作为拟议标准协议出版。拟定标准发布后，预计将改变本备忘录中定义的协议。特别是，预计协议的标准跟踪版本将包含强大的身份验证和隐私功能，并且将定义支持这些安全措施的“ipp:”URL类型。协议的其他更改也是可能的。提醒实施者，本协议的未来版本可能无法与本文档中定义的IPP版本进行互操作，或者，如果实现了互操作，则某些协议功能可能不可用。
The IESG encourages experimentation with this protocol, especially in combination with Transport Layer Security (TLS) [RFC 2246], to help determine how TLS may effectively be used as a security layer for IPP.
IESG鼓励对该协议进行试验，特别是结合传输层安全（TLS）[RFC 2246]，以帮助确定如何将TLS有效地用作IPP的安全层。
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 HTTP a message body whose Content-Type is "application/ipp".
本文档是一组文档之一，这些文档共同描述了新Internet打印协议（IPP）的所有方面。IPP是一种应用程序级协议，可用于使用Internet工具和技术进行分布式打印。本文档定义了将IPP操作和IPP属性编码为称为“应用程序/IPP”的新Internet mime媒体类型的规则。本文档还定义了通过HTTP传输内容类型为“application/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.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport (this
document)
Internet Printing Protocol/1.0: 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.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport (this
document)
Internet Printing Protocol/1.0: 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.0. Operator and administrator requirements are out of scope for version 1.0.
“Internet打印协议的设计目标”文档广泛介绍了分布式打印功能，并列举了有助于澄清需要包含在Internet打印协议中的功能的实际场景。它确定了三类用户的需求：最终用户、操作员和管理员。它列出了IPP/1.0中满足的最终用户需求的子集。操作员和管理员要求超出了版本1.0的范围。
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 specifications, and gives background and rationale for the IETF working group's major decisions.
“互联网打印协议的结构、模型和协议的基本原理”文件从高层次上描述了IPP，定义了构成IPP规范套件的各种文件的路线图，并为IETF工作组的主要决策提供了背景和基本原理。
The document, "Internet Printing Protocol/1.0: 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.0：模型和语义”文档描述了一个简化模型，其中包含抽象对象、其属性以及独立于编码和传输的操作。它引入了打印机和作业对象。作业对象可以选择为每个作业支持多个文档。它还解决了安全性、国际化和目录问题。
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
本文件“Internet打印协议/1.0：实施者指南”为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.....................................5
3.2 Syntax of Encoding..........................................7
3.3 Version-number..............................................9
3.4 Operation-id................................................9
3.5 Status-code.................................................9
3.6 Request-id..................................................9
3.7 Tags.......................................................10
3.7.1 Delimiter Tags.........................................10
3.7.2 Value Tags.............................................11
3.8 Name-Length................................................13
3.9 (Attribute) Name...........................................13
3.10 Value Length...............................................16
3.11 (Attribute) Value..........................................16
3.12 Data.......................................................18
4. Encoding of Transport Layer.....................................18
5. Security Considerations.........................................19
5.1 Using IPP with SSL3........................................19
6. References......................................................20
7. Authors' Addresses..............................................22
8. Other Participants:.............................................24
9. Appendix A: Protocol Examples...................................25
9.1 Print-Job Request..........................................25
9.2 Print-Job Response (successful)............................26
9.3 Print-Job Response (failure)...............................27
9.4 Print-Job Response (success with attributes ignored).......28
9.5 Print-URI Request..........................................30
9.6 Create-Job Request.........................................31
9.7 Get-Jobs Request...........................................31
9.8 Get-Jobs Response..........................................32
10. Appendix C: Registration of MIME Media Type Information for
"application/ipp"..............................................35
11. Full Copyright Statement.......................................37
1. Introduction.....................................................4
2. Conformance Terminology..........................................4
3. Encoding of the Operation Layer.................................4
3.1 Picture of the Encoding.....................................5
3.2 Syntax of Encoding..........................................7
3.3 Version-number..............................................9
3.4 Operation-id................................................9
3.5 Status-code.................................................9
3.6 Request-id..................................................9
3.7 Tags.......................................................10
3.7.1 Delimiter Tags.........................................10
3.7.2 Value Tags.............................................11
3.8 Name-Length................................................13
3.9 (Attribute) Name...........................................13
3.10 Value Length...............................................16
3.11 (Attribute) Value..........................................16
3.12 Data.......................................................18
4. Encoding of Transport Layer.....................................18
5. Security Considerations.........................................19
5.1 Using IPP with SSL3........................................19
6. References......................................................20
7. Authors' Addresses..............................................22
8. Other Participants:.............................................24
9. Appendix A: Protocol Examples...................................25
9.1 Print-Job Request..........................................25
9.2 Print-Job Response (successful)............................26
9.3 Print-Job Response (failure)...............................27
9.4 Print-Job Response (success with attributes ignored).......28
9.5 Print-URI Request..........................................30
9.6 Create-Job Request.........................................31
9.7 Get-Jobs Request...........................................31
9.8 Get-Jobs Response..........................................32
10. Appendix C: Registration of MIME Media Type Information for
"application/ipp"..............................................35
11. Full Copyright Statement.......................................37
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 2068 [RFC2068] describes HTTP/1.1. This document specifies the HTTP headers that an IPP implementation supports.
传输层由HTTP/1.1请求或响应组成。RFC2068[RFC2068]描述了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.0: Model and Semantics" [RFC2566] defines the semantics of such a message body and the supported values. This document specifies the encoding of an IPP operation. The aforementioned document [RFC2566] is henceforth referred to as the "IPP model document"
操作层由HTTP请求或响应中的消息体组成。文档“Internet打印协议/1.0：模型和语义”[RFC2566]定义了此类消息体的语义和支持的值。本文档指定IPP操作的编码。上述文件[RFC2566]此后称为“IPP模型文件”
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 MUST contain a single operation request or 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
操作层必须包含单个操作请求或操作响应。每个请求或响应由一系列值和属性组组成。属性组由一系列属性组成，每个属性都是名称和值。名称和值最终是八位字节序列
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
编码由最原始的八位字节组成。有几种类型是从八位字节构建的，但有三种重要类型是整数、字符串和八位字节字符串，大多数其他数据类型都是基于这些类型构建的。此编码中的每个字符串都必须是一个字符序列，其中的字符与某些字符集和某些自然语言相关联。字符串必须是“读取顺序”，值中的第一个字符（根据读取顺序）是编码中的第一个字符。关联字符集为US-ASCII且关联自然语言为US-English的字符串从此被称为US-ASCII-string。如模型文档中所述，其相关字符集和自然语言在请求或响应中指定的字符串从此被称为本地化字符串。八位字节字符串必须为“IPP模型文档顺序”，值中的第一个八位字节（根据IPP模型文档顺序）是编码中的第一个八位字节。此编码中的每个整数必须使用带大端格式的二补二进制编码（也称为“网络顺序”）编码为有符号整数“最高有效字节
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 values fields and the sequence number.
第一"). 整数的八位字节数必须为1、2或4，具体取决于协议中的用法。这样的一个八位组整数（此后称为有符号字节）用于版本号和标记字段。这样的两字节整数（此后称为SIGNED-SHORT）用于操作id、状态代码和长度字段。四字节整数（此后称为有符号整数）用于值字段和序列号。
The following two sections present 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）
The encoding for an operation request or response consists of:
操作请求或响应的编码包括：
-----------------------------------------------
| version-number | 2 bytes - required
-----------------------------------------------
| operation-id (request) |
| or | 2 bytes - required
| status-code (response) |
-----------------------------------------------
| request-id | 4 bytes - required
-----------------------------------------------------------
| xxx-attributes-tag | 1 byte |
----------------------------------------------- |-0 or more
| xxx-attribute-sequence | n bytes |
-----------------------------------------------------------
| 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
-----------------------------------------------------------
| xxx-attributes-tag | 1 byte |
----------------------------------------------- |-0 or more
| xxx-attribute-sequence | n bytes |
-----------------------------------------------------------
| end-of-attributes-tag | 1 byte - required
-----------------------------------------------
| data | q bytes - optional
-----------------------------------------------
The xxx-attributes-tag and xxx-attribute-sequence represents four different values of "xxx", namely, operation, job, printer and unsupported. The xxx-attributes-tag and an xxx-attribute-sequence represent attribute groups in the model document. The xxx-attributes-tag identifies the attribute group and the xxx-attribute-sequence contains the attributes.
xxx属性标签和xxx属性序列表示“xxx”的四个不同值，即操作、作业、打印机和不支持。xxx属性标记和xxx属性序列表示模型文档中的属性组。xxx属性标签标识属性组，xxx属性序列包含属性。
The expected sequence of xxx-attributes-tag and xxx-attribute-sequence is specified in the IPP model document for each operation request and operation response.
IPP模型文件中为每个操作请求和操作响应指定了xxx属性标签和xxx属性序列的预期顺序。
A request or response SHOULD contain each xxx-attributes-tag defined for that request or response even if there are no attributes except for the unsupported-attributes-tag which SHOULD be present only if the unsupported-attribute-sequence is non-empty. A receiver of a request MUST be able to process as equivalent empty attribute groups:
请求或响应应包含为该请求或响应定义的每个xxx attributes标记，即使除了不支持的属性标记之外没有其他属性，该属性标记仅在不支持的属性序列为非空时才应出现。请求的接收者必须能够作为等效的空属性组进行处理：
a) an xxx-attributes-tag with an empty xxx-attribute-sequence, b) an expected but missing xxx-attributes-tag.
a) 具有空xxx属性序列的xxx属性标记，b）预期但缺少xxx属性标记。
The data is omitted from some operations, but the end-of-attributes-tag is present even when the data is omitted. Note, the xxx-attributes-tags and end-of-attributes-tag are called 'delimiter-tags'. Note: the xxx-attribute-sequence, shown above may consist of 0 bytes, according to the rule below.
某些操作中省略了数据，但即使省略了数据，也会出现属性结束标记。注意，xxx属性标记和属性结束标记称为“分隔符标记”。注意：根据下面的规则，上面显示的xxx属性序列可能由0字节组成。
An xxx-attributes-sequence consists of zero or more compound-attributes.
xxx属性序列由零个或多个复合属性组成。
-----------------------------------------------
| compound-attribute | s bytes - 0 or more
-----------------------------------------------
-----------------------------------------------
| compound-attribute | s bytes - 0 or more
-----------------------------------------------
A compound-attribute consists of an attribute with a single value followed by zero or more additional values.
复合属性由单个值后跟零个或多个附加值的属性组成。
Note: a 'compound-attribute' represents a single attribute in the model document. The 'additional value' syntax is for attributes with 2 or more values.
注意：“复合属性”表示模型文档中的单个属性。“附加值”语法用于具有2个或更多值的属性。
Each attribute consists of:
每个属性包括：
-----------------------------------------------
| 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 additional value consists of:
附加值包括：
-----------------------------------------------------------
| value-tag | 1 byte |
----------------------------------------------- |
| name-length (value is 0x0000) | 2 bytes |
----------------------------------------------- |-0 or more
| value-length (value is w) | 2 bytes |
----------------------------------------------- |
| value | w bytes |
-----------------------------------------------------------
-----------------------------------------------------------
| value-tag | 1 byte |
----------------------------------------------- |
| name-length (value is 0x0000) | 2 bytes |
----------------------------------------------- |-0 or more
| value-length (value is w) | 2 bytes |
----------------------------------------------- |
| value | w bytes |
-----------------------------------------------------------
Note: an additional value is like an attribute whose name-length is 0.
注意：附加值类似于名称长度为0的属性。
From the standpoint of a parsing loop, 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 | 2 bytes - 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 | 2 bytes - required
-----------------------------------------------
| data | y bytes - optional
-----------------------------------------------
The value of the tag determines whether the bytes following the tag are:
标记的值确定标记后面的字节是否为：
- attributes - data - the remainder of a single attribute where the tag specifies the type of the value.
- 属性-数据-单个属性的剩余部分，其中标记指定值的类型。
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
*(xxx-attributes-tag xxx-attribute-sequence)
end-of-attributes-tag data
ipp-response = version-number status-code request-id
*(xxx-attributes-tag xxx-attribute-sequence)
end-of-attributes-tag data
xxx-attribute-sequence = *compound-attribute
ipp-message = ipp-request / ipp-response
ipp-request = version-number operation-id request-id
*(xxx-attributes-tag xxx-attribute-sequence)
end-of-attributes-tag data
ipp-response = version-number status-code request-id
*(xxx-attributes-tag xxx-attribute-sequence)
end-of-attributes-tag data
xxx-attribute-sequence = *compound-attribute
xxx-attributes-tag = operation-attributes-tag / job-attributes-tag /
printer-attributes-tag / unsupported-attributes-tag
xxx-attributes-tag = operation-attributes-tag / job-attributes-tag /
printer-attributes-tag / unsupported-attributes-tag
version-number = major-version-number minor-version-number
major-version-number = SIGNED-BYTE ; initially %d1
minor-version-number = SIGNED-BYTE ; initially %d0
version-number = major-version-number minor-version-number
major-version-number = SIGNED-BYTE ; initially %d1
minor-version-number = SIGNED-BYTE ; initially %d0
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
compound-attribute = attribute *additional-values attribute = value-tag name-length name value-length value additional-values = 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
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
end-of-attributes-tag = %x03 ; tag of 3
value-tag = %x10-FF
zero-name-length = %x00.00 ; name-length of 0
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
end-of-attributes-tag = %x03 ; tag of 3
value-tag = %x10-FF
SIGNED-BYTE = BYTE
SIGNED-SHORT = 2BYTE
SIGNED-INTEGER = 4BYTE
DIGIT = %x30-39 ; "0" to "9"
LALPHA = %x61-7A ; "a" to "z"
BYTE = %x00-FF
OCTET-STRING = *BYTE
SIGNED-BYTE = BYTE
SIGNED-SHORT = 2BYTE
SIGNED-INTEGER = 4BYTE
DIGIT = %x30-39 ; "0" to "9"
LALPHA = %x61-7A ; "a" to "z"
BYTE = %x00-FF
OCTET-STRING = *BYTE
The syntax allows an xxx-attributes-tag to be present when the xxx-attribute-sequence that follows is empty. The syntax is defined this way to allow for the response of Get-Jobs where no attributes are returned for some job-objects. Although it is RECOMMENDED that the sender not send an xxx-attributes-tag if there are no attributes (except in the Get-Jobs response just mentioned), the receiver MUST be able to decode such syntax.
当下面的xxx属性序列为空时，该语法允许出现xxx属性标记。语法是这样定义的，以允许在某些作业对象没有返回属性的情况下响应Get作业。尽管建议发送方在没有属性的情况下（除了刚才提到的Get Jobs响应之外）不要发送xxx attributes标记，但接收方必须能够解码这种语法。
The version-number MUST consist of a major and minor version-number, each of which MUST be represented by a SIGNED-BYTE. The protocol described in this document MUST have a major version-number of 1 (0x01) and a minor version-number of 0 (0x00). The ABNF for these two bytes MUST be %x01.00.
版本号必须由主版本号和次版本号组成，每个版本号必须由带符号字节表示。本文档中描述的协议的主要版本号必须为1（0x01），次要版本号必须为0（0x00）。这两个字节的ABNF必须为%x01.00。
Operation-ids are defined as enums in the model document. An operation-ids enum value MUST be encoded as a SIGNED-SHORT.
操作ID在模型文档中定义为枚举。操作ID枚举值必须编码为带符号的短字符。
Note: the values 0x4000 to 0xFFFF are reserved for private extensions.
注意：0x4000到0xFFFF的值是为专用扩展保留的。
Status-codes are defined as enums in the model document. A status-code enum value MUST be encoded as a SIGNED-SHORT.
状态代码在模型文档中定义为枚举。状态代码枚举值必须编码为有符号短字符。
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 allows a client to match a response with a request. This mechanism is unnecessary in HTTP, but may be useful when application/ipp entity bodies are used in another context.
请求id允许客户端将响应与请求匹配。此机制在HTTP中是不必要的，但在另一个上下文中使用应用程序/ipp实体体时可能有用。
The request-id in a response MUST be the value of the request-id received in the corresponding request. A client can set the request-id in each request to a unique value or a constant value, such as 1, depending on what the client does with the request-id
响应中的请求id必须是相应请求中接收的请求id的值。客户机可以将每个请求中的请求id设置为唯一值或常量值，如1，具体取决于客户机对请求id所做的操作
returned in the response. The value of the request-id MUST be greater than zero.
在响应中返回。请求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) Delimiter
标记值（十六进制）分隔符
0x00 reserved 0x01 operation-attributes-tag 0x02 job-attributes-tag 0x03 end-of-attributes-tag 0x04 printer-attributes-tag 0x05 unsupported-attributes-tag 0x06-0x0e reserved for future delimiters 0x0F reserved for future chunking-end-of-attributes-tag
0x00保留0x01操作属性标记0x02作业属性标记0x03属性结束标记0x04打印机属性标记0x05不支持的属性标记0x06-0x0e保留给将来的分隔符0x0F保留给将来的分块属性结束标记
When an xxx-attributes-tag occurs in the protocol, it MUST mean that zero or more following attributes up to the next delimiter tag are attributes belonging to group xxx as defined in the model document, where xxx is operation, job, printer, unsupported.
当协议中出现xxx attributes标记时，这意味着直到下一个分隔符标记的零个或多个后续属性都是属于模型文档中定义的组xxx的属性，其中xxx是操作、作业、打印机，不受支持。
Doing substitution for xxx in the above paragraph, this means the following. When an operation-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are operation attributes as defined in the model document. When an job-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are job attributes or job template attributes as defined in the model document. When a printer-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are printer attributes as defined in the model document. When an unsupported-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are unsupported attributes as defined in the model document.
在上述段落中替换xxx，这意味着：。当协议中出现操作属性标记时，它必须意味着直到下一个分隔符标记的零个或多个后续属性都是模型文档中定义的操作属性。当协议中出现作业属性标记时，它必须意味着下一个分隔符标记之前的零个或多个后续属性是模型文档中定义的作业属性或作业模板属性。当协议中出现打印机属性标记时，它必须意味着直到下一个分隔符标记的零个或多个后续属性都是模型文档中定义的打印机属性。当协议中出现不受支持的属性标记时，这意味着直到下一个分隔符标记的零个或多个后续属性都是模型文档中定义的不受支持的属性。
The operation-attributes-tag and end-of-attributes-tag MUST each occur exactly once in an operation. The operation-attributes-tag MUST be the first tag delimiter, and the end-of-attributes-tag MUST be the last tag delimiter. If the operation has a document-content group, the document data in that group MUST follow the end-of-attributes-tag.
operation attributes标记和end of attributes标记必须在一个操作中精确出现一次。操作属性标记必须是第一个标记分隔符，属性结束标记必须是最后一个标记分隔符。如果操作具有文档内容组，则该组中的文档数据必须位于属性结束标记之后。
Each of the other three xxx-attributes-tags defined above is OPTIONAL in an operation and each MUST occur at most once in an operation, except for job-attributes-tag in a Get-Jobs response which may occur zero or more times.
上面定义的其他三个xxx attributes标记在操作中都是可选的，每个标记在操作中最多只能出现一次，但Get Jobs响应中的job attributes标记可能出现零次或多次。
The order and presence of delimiter tags for each operation request and each operation response MUST be that defined in the model document. For further details, see section 3.9 "(Attribute) Name" and section 9 "Appendix A: Protocol Examples".
每个操作请求和每个操作响应的分隔符标记的顺序和存在性必须与模型文档中定义的一致。有关更多详细信息，请参见第3.9节“属性名称”和第9节“附录A：协议示例”。
A Printer MUST treat the reserved delimiter tags differently from reserved value tags 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.
打印机必须以不同于保留值标记的方式处理保留分隔符标记，以便打印机知道它不理解的是整个属性组，而不是它不理解的单个值。
The remaining tables show values for the value-tag, which is the first octet of an attribute. The value-tag specifies the type of the value of the attribute. The following table specifies the "out-of-band" values for the value-tag.
其余的表显示值标记的值，它是属性的第一个八位字节。值标记指定属性值的类型。下表指定了值标记的“带外”值。
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x10 unsupported 0x11 reserved for future 'default' 0x12 unknown 0x13 no-value
0x10不受支持的0x11保留用于将来的“默认值”0x12未知0x13无值
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x14-0x1F reserved for future "out-of-band" values.
0x14-0x1F为将来的“带外”值保留。
The "unsupported" value MUST be used in the attribute-sequence of an error response for those attributes which the printer does not support. The "default" value is reserved for future use of setting value back to their default value. The "unknown" value is used for the value of a supported attribute when its value is temporarily unknown. The "no-value" value is used for a supported attribute to which
对于打印机不支持的属性，必须在错误响应的属性序列中使用“unsupported”值。“默认”值保留用于将来将值设置回其默认值。当支持的属性的值暂时未知时，“未知”值用于该属性的值。“无值”值用于支持的属性，该属性
no value has been assigned, e.g. "job-k-octets-supported" has no value if an implementation supports this attribute, but an administrator has not configured the printer to have a limit.
未分配任何值，例如，如果实现支持此属性，则“job-k-octets-supported”没有值，但管理员尚未将打印机配置为具有限制。
The following table specifies the integer values for the value-tag:
下表指定了值标记的整数值：
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x20 reserved 0x21 integer 0x22 boolean 0x23 enum 0x24-0x2F reserved for future integer types
0x20保留0x21整数0x22布尔0x23枚举0x24-0x2F保留用于将来的整数类型
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:
下表指定了值标记的八进制字符串值：
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x30 octetString with an unspecified format 0x31 dateTime 0x32 resolution 0x33 rangeOfInteger 0x34 reserved for collection (in the future) 0x35 textWithLanguage 0x36 nameWithLanguage 0x37-0x3F reserved for future octetString types
未指定格式的0x30八位字符串0x31日期时间0x32分辨率0x33范围整数0x34保留用于收集（将来）0x35文本带有语言0x36名称带有语言0x37-0x3F保留用于将来的八位字符串类型
The following table specifies the character-string values for the value-tag:
下表指定了值标记的字符串值：
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x40 reserved 0x41 textWithoutLanguage 0x42 nameWithoutLanguage 0x43 reserved 0x44 keyword 0x45 uri 0x46 uriScheme 0x47 charset 0x48 naturalLanguage
0x40保留0x41文本带外语言0x42名称带外语言0x43保留0x44关键字0x45 uri 0x46 uri模式0x47字符集0x48自然语言
Tag Value (Hex) Meaning
标记值（十六进制）含义
0x49 mimeMediaType 0x4A-0x5F reserved for future character string types
0x49 mimeMediaType 0x4A-0x5F保留给将来的字符串类型
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 types. There are no values allocated for private extensions. A new type MUST be registered via the type 2 registration process [RFC2566].
值0x60-0xFF保留给将来的类型。没有为专用扩展分配值。必须通过类型2注册过程[RFC2566]注册新类型。
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. All these 4 byte tag values are currently unallocated except that the values 0x40000000- 0x7FFFFFFF are reserved for experimental use.
标记0x7F保留用于将类型扩展到单个字节可用的255个值之外。标记值0x7F必须表示值字段的前4个字节被解释为标记值。注意，这个未来的扩展不会影响不知道这个特殊标记的解析器。该标记类似于任何其他未知标记，value length指定一个值的长度，该值包含解析器原子化处理的值。除0x40000000-0x7FFFFFFF值保留供实验使用外，所有这些4字节标记值当前未分配。
The name-length field MUST consist of a SIGNED-SHORT. This field MUST specify the number of octets in the name field which follows the name-length field, excluding the two bytes of the name-length field.
名称长度字段必须由带符号的短字符组成。此字段必须指定名称长度字段后面的名称字段中的八位字节数，不包括名称长度字段的两个字节。
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 preceding attribute. Within an attribute-sequence, if two attributes have the same name, the first occurrence MUST be ignored. The zero-length name is the only mechanism for multi-valued attributes.
如果名称长度字段的值为零，则以下名称字段必须为空，并且必须将以下值视为前一属性的附加值。在属性序列中，如果两个属性具有相同的名称，则必须忽略第一次出现。零长度名称是多值属性的唯一机制。
Some operation elements are called parameters in the model document [RFC2566]. They MUST be encoded in a special position and they MUST NOT appear as an operation attributes. These parameters are:
一些操作元素在模型文档[RFC2566]中称为参数。它们必须在特殊位置进行编码，并且不能作为操作属性出现。这些参数是：
- "version-number": The parameter named "version-number" in the IPP model document MUST become the "version-number" field in the operation layer request or response.
- “版本号”：IPP模型文档中名为“版本号”的参数必须成为操作层请求或响应中的“版本号”字段。
- "operation-id": The parameter named "operation-id" in the IPP model document MUST become the "operation-id" field in the operation layer request. - "status-code": The parameter named "status-code" in the IPP model document MUST become the "status-code" field in the operation layer response. - "request-id": The parameter named "request-id" in the IPP model document MUST become the "request-id" field in the operation layer request or response.
- “操作id”：IPP模型文档中名为“操作id”的参数必须成为操作层请求中的“操作id”字段。-“状态代码”：IPP模型文档中名为“状态代码”的参数必须成为操作层响应中的“状态代码”字段。-“请求id”：IPP模型文档中名为“请求id”的参数必须成为操作层请求或响应中的“请求id”字段。
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. The notion of a URI is a useful concept, however, until the notion of URI is more stable (i.e., defined more completely and deployed more widely), it is expected that the URIs used for IPP objects will actually be URLs [RFC1738] [RFC1808]. 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]标识，以便可以持久和明确地引用它们。URI的概念是一个有用的概念，但是，在URI的概念更稳定（即定义更完整、部署更广泛）之前，预计IPP对象使用的URI实际上是URL[RFC1738][RFC1808]。由于每个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:
一些操作元素被编码两次，一次作为HTTP请求行上的请求URI，另一次作为应用程序/ipp实体中所需的操作属性。这些属性是操作的目标URI：
- "printer-uri": When the target is a printer and the transport is HTTP or HTTPS (for SSL3 [ssl]), the target printer-uri defined in each operation in the IPP model document MUST be an operation attribute called "printer-uri" and it MUST also be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level. - "job-uri": When the target is a job and the transport is HTTP or HTTPS (for SSL3), the target job-uri of each operation in the IPP model document MUST be an operation attribute called "job-uri" and it MUST also be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level.
- “打印机uri”：当目标为打印机且传输为HTTP或HTTPS（对于SSL3[ssl]）时，IPP模型文档中每个操作中定义的目标打印机uri必须是一个名为“打印机uri”的操作属性，并且还必须在操作层外指定为HTTP级别请求行上的请求uri。-“作业uri”：当目标为作业且传输为HTTP或HTTPS（对于SSL3）时，IPP模型文档中每个操作的目标作业uri必须是一个名为“作业uri”的操作属性，并且还必须在操作层之外指定为HTTP级别请求行上的请求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:
注意：目标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. 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对象。3.HTTP层中的URI是相对的或绝对的，HTTP服务器使用它将HTTP请求路由到相对于该HTTP服务器的正确资源。HTTP服务器不需要知道操作请求中的URI。4.一旦HTTP服务器资源开始处理HTTP请求，它可能会从HTTP URI（将相对URL用于HTTP服务器的上下文）或操作请求中的URI获取对适当IPP打印机对象的引用；选择取决于实现。5.HTTP URI可以是相对的，也可以是绝对的，但操作中的目标URI必须是绝对URI。
The model document arranges the remaining attributes into groups for each operation request and response. Each such group MUST be represented in the protocol by an xxx-attribute-sequence preceded by the appropriate xxx-attributes-tag (See the table below and section 9 "Appendix A: Protocol Examples"). In addition, the order of these xxx-attributes-tags and xxx-attribute-sequences in the protocol MUST be the same as in the model document, but the order of attributes within each xxx-attribute-sequence MUST be unspecified. The table below maps the model document group name to xxx-attributes-sequence:
模型文档为每个操作请求和响应将其余属性分组。协议中的每个此类组必须由xxx属性序列表示，该序列前面有相应的xxx属性标记（见下表和第9节“附录A：协议示例”）。此外，协议中这些xxx属性标签和xxx属性序列的顺序必须与模型文档中的相同，但每个xxx属性序列中的属性顺序必须未指定。下表将模型文档组名称映射到xxx属性序列：
Model Document Group xxx-attributes-sequence
模型文档组xxx属性序列
Operation Attributes operations-attributes-sequence Job Template Attributes job-attributes-sequence Job Object Attributes job-attributes-sequence Unsupported Attributes unsupported-attributes-sequence Requested Attributes job-attributes-sequence Get-Job-Attributes) Requested Attributes printer-attributes-sequence Get-Printer-Attributes) Document Content in a special position as described above
操作属性操作属性序列作业模板属性作业属性序列作业对象属性作业属性序列不支持的属性不支持的属性序列请求的属性作业属性序列获取作业属性）请求的属性打印机属性序列获取打印机属性）文档内容位于如上所述的特殊位置
If an operation contains attributes from more than one job object (e.g. Get-Jobs response), the attributes from each job object MUST be in a separate job-attribute-sequence, such that the attributes
如果操作包含多个作业对象的属性（例如Get Jobs response），则每个作业对象的属性必须位于单独的作业属性序列中，以便
from the ith job object are in the ith job-attribute-sequence. See Section 9 "Appendix A: Protocol Examples" for table showing the application of the rules above.
来自第i个作业对象的数据位于第i个作业属性序列中。有关上述规则应用的表格，请参见第9节“附录A：协议示例”。
Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST specify the number of octets in the value which follows this length, exclusive of the two bytes specifying the length.
每个属性值前面必须有一个带符号的短字符，它必须指定该长度后面的值中的八位字节数，不包括指定长度的两个字节。
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.
对于由字符串表示的任何类型，发送方必须使用字符串的所有字符对值进行编码，并且不使用任何填充字符。
If a value-tag contains an "out-of-band" value, such as "unsupported", the value-length MUST be 0 and the value empty. The value has no meaning when the value-tag has an "out-of-band" value. If a client receives a response with a nonzero value-length in this case, it MUST ignore the value field. If a printer receives a request with a nonzero value-length in this case, it MUST reject the request.
如果值标记包含“带外”值，例如“unsupported”，则值长度必须为0，且值为空。当值标记具有“带外”值时，该值没有意义。在这种情况下，如果客户端接收到长度为非零值的响应，则必须忽略值字段。在这种情况下，如果打印机接收到长度为非零值的请求，则必须拒绝该请求。
The syntax types and most of the details of their representation 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.
textWithLanguage八位字节\由4个字段组成的字符串：a）有符号短字符，表示以下字段中的八位字节数b）自然语言类型的值，c）有符号短字符，表示以下字段中的八位字节数，d）textWithoutLanguage类型的值。
The length of a textWithLanguage value MUST be 4 + the value of field a + the value of field c.
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.
nameWithLanguage八位字节\由4个字段组成的字符串：a）有符号短字符，表示以下字段中的八位字节数b）自然语言类型的值，c）有符号短字符，表示以下字段中的八位字节数d）nameWithoutLanguage类型的值。
The length of a nameWithLanguage value MUST be 4 + the value of field a + the value of field c.
nameWithLanguage值的长度必须为4+字段a的值+字段c的值。
charset, US-ASCII-STRING. naturalLanguage, mimeMediaType, keyword, uri, and uriScheme
字符集，US-ASCII-STRING。自然语言、mimediatype、关键字、uri和uri模式
boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 'true'.
布尔有符号字节，其中0x00为“假”，0x01为“真”。
Syntax of Attribute Encoding Value
属性编码值的语法
integer and enum a SIGNED-INTEGER.
整数和枚举有符号整数。
dateTime OCTET-STRING consisting of eleven octets whose contents are defined by "DateAndTime" in RFC 2579 [RFC2579].
dateTime八位字节—由十一个八位字节组成的字符串，其内容由RFC 2579[RFC2579]中的“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 value.
解析八位字节\由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 type of the value in the model document determines the encoding in the value and the value of the value-tag.
模型文档中的值类型决定了值中的编码和值标记的值。
The data part MUST include any data required by the operation
数据部分必须包括操作所需的任何数据
HTTP/1.1 [RFC2068] is the transport layer for this protocol.
HTTP/1.1[RFC2068]是此协议的传输层。
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. In addition, a printer may have to support another port for privacy (See Section 5 "Security Considerations").
要求打印机实现支持IANA分配的已知端口631（IPP默认端口）上的HTTP，但打印机实现也可以支持其他端口上的HTTP。此外，为了隐私，打印机可能必须支持另一个端口（请参阅第5节“安全注意事项”）。
Note: even though port 631 is the IPP default, port 80 remains the default for an HTTP URI. Thus a URI for a printer using port 631 MUST contain an explicit port, e.g. "http://forest:631/pinetree". An HTTP URI for IPP with no explicit port implicitly reference port 80, which is consistent with the rules for HTTP/1.1. 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 [RFC2068]. A printer (server) implementation MUST adhere the rules for an origin server described for HTTP1.1 [RFC2068].
注意：即使端口631是IPP默认值，端口80仍然是HTTP URI的默认值。因此，使用端口631的打印机的URI必须包含显式端口，例如。“http://forest:631/pinetree". 没有显式端口的IPP的HTTP URI隐式引用端口80，这与HTTP/1.1的规则一致。每个HTTP操作必须使用POST方法，其中请求URI是操作的对象目标，并且每个请求和响应中消息体的“内容类型”必须是“应用程序/ipp”。消息正文必须包含操作层，并且必须具有第3.2节“编码语法”中描述的语法。客户机实现必须遵守HTTP1.1[RFC2068]中描述的客户机规则。打印机（服务器）实现必须遵守HTTP1.1[RFC2068]中描述的源服务器规则。
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
IPP服务器为其收到的每个请求发送响应。如果IPP服务器检测到错误，它可能会在读取整个请求之前发送响应。如果IPP服务器的HTTP层成功完成对HTTP头的处理，则可能会发送
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 [RFC2068].
中间响应，如“100 Continue”，在发送IPP响应之前没有IPP数据。客户机必须期望IPP服务器做出各种响应。有关HTTP/1.1的更多信息，请参阅HTTP文档[RFC2068]。
The IPP Model document defines an IPP implementation with "privacy" as one that implements Secure Socket Layer Version 3 (SSL3). Note: SSL3 is not an IETF standards track specification. SSL3 meets the requirements for IPP security with regards to features such as mutual authentication and privacy (via encryption). The IPP Model document also outlines IPP-specific security considerations and should be the primary reference for security implications with regards to the IPP protocol itself.
IPP模型文档将具有“隐私”的IPP实现定义为实现安全套接字层版本3（SSL3）的IPP实现。注：SSL3不是IETF标准轨道规范。SSL3满足IPP安全方面的要求，如相互认证和隐私（通过加密）。IPP模型文件还概述了IPP特定的安全注意事项，应作为IPP协议本身安全影响的主要参考。
The IPP Model document defines an IPP implementation with "authentication" as one that implements the standard way for transporting IPP messages within HTTP 1.1. These include the security considerations outlined in the HTTP 1.1 standard document [RFC2068] and Digest Access Authentication extension [RFC2069].
IPP模型文档将带有“身份验证”的IPP实现定义为实现HTTP 1.1中传输IPP消息的标准方式。其中包括HTTP 1.1标准文档[RFC2068]和摘要访问身份验证扩展[RFC2069]中概述的安全注意事项。
The current HTTP infrastructure supports HTTP over TCP port 80. IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port.
当前HTTP基础结构支持HTTP over TCP端口80。IPP服务器实现必须通过IANA分配的众所周知的端口631（IPP默认端口）使用HTTP提供IPP服务。IPP服务器实现可能支持除此端口之外的其他端口。
See further discussion of IPP security concepts in the model document [RFC2566].
请参阅模型文档[RFC2566]中对IPP安全概念的进一步讨论。
An assumption is that the URI for a secure IPP Printer object has been found by means outside the IPP printing protocol, via a directory service, web site or other means.
假设安全IPP打印机对象的URI是通过IPP打印协议之外的方式，通过目录服务、网站或其他方式找到的。
IPP provides a transparent connection to SSL by calling the corresponding URL (a https URI connects by default to port 443). However, the following functions can be provided to ease the integration of IPP with SSL during implementation:
IPP通过调用相应的URL（https URI默认连接到端口443）提供到SSL的透明连接。但是，可以提供以下功能，以便在实施过程中简化IPP与SSL的集成：
connect (URI), returns a status
连接（URI），返回一个状态
"connect" makes an https call and returns the immediate status of the connection as returned by SSL to the user. The status values are explained in section 5.4.2 of the SSL document [ssl].
“connect”进行https调用，并将SSL返回给用户的连接的即时状态返回给用户。SSL文档[SSL]的第5.4.2节解释了状态值。
A session-id may also be retained to later resume a session. The SSL handshake protocol may also require the cipher specifications supported by the client, key length of the ciphers, compression methods, certificates, etc. These should be sent to the server and hence should be available to the IPP client (although as part of administration features).
还可以保留会话id，以便以后恢复会话。SSL握手协议还可能需要客户端支持的密码规范、密码的密钥长度、压缩方法、证书等。这些规范应发送到服务器，因此IPP客户端应可用（尽管作为管理功能的一部分）。
disconnect (session)
断开连接（会话）
to disconnect a particular session.
断开特定会话的连接。
The session-id available from the "connect" could be used.
可以使用“连接”中可用的会话id。
resume (session)
续会（会议）
to reconnect using a previous session-id.
使用上一个会话id重新连接。
The availability of this information as administration features are left for implementers, and need not be specified at this time.
此信息作为管理功能的可用性留给实施者，此时无需指定。
[RFC2278] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998.
[RFC2278]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2278，1998年1月。
[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.
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.0: Implementer's Guide", Work in Progress.
[ipp iig]Hastings，Tom等，“互联网打印协议/1.0：实施者指南”，正在进行的工作。
[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月。
[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月。
[RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565]Herriot，R.，Butler，S.，Moore，P.，Tuner，R.，“互联网打印协议/1.0：编码和传输”，RFC 25651999年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月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567]Wright，D.，“互联网打印协议的设计目标”，RFC2567，1999年4月。
[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, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，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月。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2046] Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，多用途互联网邮件扩展（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 20481996年11月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[RFC2069]Franks，J.，Hallam Baker，P.，Hostetler，J.，Leach，P.，Lootonen，A.，Sink，E.和L.Stewart，“HTTP的扩展：摘要访问认证”，RFC 2069，1997年1月。
[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. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234. November 1997.
[RFC2234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234。1997年11月。
[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月。
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: rherriot@pahv.xerox.com
电话：650-813-7696传真：650-813-6860电子邮件：rherriot@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 Microsoft One Microsoft Way Redmond, WA 98053
Paul Moore Microsoft One Microsoft Way Redmond，WA 98053
Phone: 425-936-0908 Fax: 425-93MS-FAX EMail: paulmo@microsoft.com
电话：425-936-0908传真：425-93MS-Fax电子邮件：paulmo@microsoft.com
Randy Turner Sharp Laboratories 5750 NW Pacific Rim Blvd Camas, WA 98607
Randy Turner Sharp Laboratories 5750西北环太平洋大道Camas，WA 98607
Phone: 360-817-8456 Fax: 360-817-8436 EMail: rturner@sharplabs.com
电话：360-817-8456传真：360-817-8436电子邮件：rturner@sharplabs.com
IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
8. Other Participants:
8. 其他与会者：
Chuck Adams - Tektronix Harry Lewis - IBM
Ron Bergman - Dataproducts Tony Liao - Vivid Image
Keith Carter - IBM David Manchala - Xerox
Angelo Caruso - Xerox Carl-Uno Manros - Xerox
Jeff Copeland - QMS Jay Martin - Underscore
Roger deBry - IBM Larry Masinter - Xerox
Lee Farrell - Canon Ira McDonald - High North Inc.
Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard
Charles Gordon - Osicom Patrick Powell - Astart
Technologies
Brian Grimshaw - Apple Jeff Rackowitz - Intermec
Jerry Hadsell - IBM Xavier Riley - Xerox
Richard Hart - Digital Gary Roberts - Ricoh
Tom Hastings - Xerox Stuart Rowley - Kyocera
Stephen Holmstead Richard Schneider - Epson
Zhi-Hong Huang - Zenographics Shigern Ueda - Canon
Scott Isaacson - Novell Bob Von Andel - Allegro Software
Rich Lomicka - Digital William Wagner - Digital Products
David Kellerman - Northlake Jasper Wong - Xionics
Software
Robert Kline - TrueSpectra Don Wright - Lexmark
Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox
Takami Kurono - Brother Lloyd Young - Lexmark
Rich Landau - Digital Peter Zehler - Xerox
Greg LeClair - Epson Frank Zhao - Panasonic
Steve Zilles - Adobe
Chuck Adams - Tektronix Harry Lewis - IBM
Ron Bergman - Dataproducts Tony Liao - Vivid Image
Keith Carter - IBM David Manchala - Xerox
Angelo Caruso - Xerox Carl-Uno Manros - Xerox
Jeff Copeland - QMS Jay Martin - Underscore
Roger deBry - IBM Larry Masinter - Xerox
Lee Farrell - Canon Ira McDonald - High North Inc.
Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard
Charles Gordon - Osicom Patrick Powell - Astart
Technologies
Brian Grimshaw - Apple Jeff Rackowitz - Intermec
Jerry Hadsell - IBM Xavier Riley - Xerox
Richard Hart - Digital Gary Roberts - Ricoh
Tom Hastings - Xerox Stuart Rowley - Kyocera
Stephen Holmstead Richard Schneider - Epson
Zhi-Hong Huang - Zenographics Shigern Ueda - Canon
Scott Isaacson - Novell Bob Von Andel - Allegro Software
Rich Lomicka - Digital William Wagner - Digital Products
David Kellerman - Northlake Jasper Wong - Xionics
Software
Robert Kline - TrueSpectra Don Wright - Lexmark
Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox
Takami Kurono - Brother Lloyd Young - Lexmark
Rich Landau - Digital Peter Zehler - Xerox
Greg LeClair - Epson Frank Zhao - Panasonic
Steve Zilles - Adobe
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
八位字节符号值协议字段
0x0100 1.0 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- 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 0x001A value-length http://forest: printer pinetree value 631/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 0x16 name-length ipp-attribute- ipp-attribute-fidelity name fidelity 0x01 value-length 0x01 true value 0x02 start job-attributes job-attributes-tag 0x21 integer type value-tag
0x0100 1.0版本号0x0002打印作业操作id 0x00000001 1请求id 0x01开始操作属性操作属性标签0x47字符集类型值标签0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标签0x001B名称长度属性-属性自然语言名称自然语言0x0005值长度en us en us值0x45 uri类型值标记0x000B名称长度打印机uri名称0x001A值长度http://forest: 打印机pinetree值631/pinetree 0x42名称带外部语言类型值标记0x0008名称长度作业名称作业名称0x0006值长度foobar foobar值0x22布尔类型值标记0x16名称长度ipp属性-ipp属性保真度名称保真度0x01值长度0x01真值0x02开始作业属性作业属性标记0x21整型值标记
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
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
八位字节符号值协议字段
0x0100 1.0 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 successful-ok successful-ok value 0x02 start job-attributes job-attributes-tag 0x21 integer value-tag 0x0006 name-length
0x0100 1.0版本号0x0000成功ok状态代码0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-attributes natural-name natural language language 0x0005值长度en us en us值0x41 text带外文语言类型值标记0x000E名称长度状态消息状态消息名称0x000D值长度成功确定成功确定值0x02开始作业属性作业属性标记0x21整数值标记0x0006名称长度
Octets Symbolic Value Protocol field
八位字节符号值协议字段
job-id job-id name 0x0004 value-length 147 147 value 0x45 uri type value-tag 0x0007 name-length job-uri job-uri name 0x001E value-length http://forest:63 job 123 on pinetree value 1/pinetree/123 0x42 nameWithoutLanguage 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
作业id作业id名称0x0004值长度147 147值0x45 uri类型值标记0x0007名称长度作业uri作业uri名称0x001E值长度http://forest:63 pinetree值1/pinetree/123 0x42 nameWithoutLanguage类型值标记0x0009名称长度作业状态作业状态名称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）。
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0100 1.0 version-number 0x040B client-error-attributes-or- status-code values-not-supported 0x00000001 1 request-id 0x01 start operation-attributes operation-attribute 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
0x0100 1.0版本号0x040B客户端错误属性或-不支持的状态代码值0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-属性自然语言名称自然语言0x0005值长度
Octets Symbolic Value Protocol field
八位字节符号值协议字段
en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000E name-length status- status-message name message 0x002F value-length client-error- client-error-attributes-or- value attributes- values-not-supported or-values-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
en us en us value 0x41 textWithoutLanguage类型值标记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
八位字节符号值协议字段
0x0100 1.0 version-number 0x0001 successful-ok-ignored-or- status-code substituted-attributes 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length
0x0100 1.0版本号0x0001成功ok忽略或-状态代码替换属性0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度属性-属性字符集名称字符集0x0008值长度
Octets Symbolic Value Protocol field
八位字节符号值协议字段
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 0x001E value-length http://forest:63 job 123 on pinetree value 1/pinetree/123 0x42 nameWithoutLanguage 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
us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-自然属性-名称自然语言语言0x0005值长度en us en us值0x41文本带外部语言类型值标记0x000E名称长度状态消息状态消息名称0x002F值长度成功确定-成功确定忽略或-值忽略或-替换属性替换属性0x05开始不受支持-不受支持的属性属性标记0x21整型值标记0x0006名称长度复制名称0x0004值长度0x00000014 20值0x10不受支持（类型）值标记0x0005名称长度边名称0x0000值长度0x02开始作业属性作业属性标记0x21整数值标记0x0006名称长度作业id作业id名称0x0004值长度147 147值0x45 uri类型值标记0x0007名称长度作业uri作业uri名称0x001E值长度http://forest:63 松树值1/pinetree/123上的作业1230x42名称WithOutlanguage类型值标记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
八位字节符号值协议字段
0x0100 1.0 version-number
0x0100 1.0版本号
Octets Symbolic Value Protocol field 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 0x001A value-length http://forest printer pinetree value :631/pinetree 0x45 uri type value-tag 0x000C name-length document-uri document-uri name 0x11 value-length ftp://foo.com ftp://foo.com/foo value /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
八位字节符号值协议字段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名称0x001A值长度http://forest 打印机pinetree值：631/pinetree 0x45 uri类型值标记0x000C名称长度文档uri名称0x11值长度ftp://foo.com ftp://foo.com/foo 值/foo 0x42 name With外部语言类型值标记0x0008名称长度作业名称作业名称0x0006值长度foobar foobar值0x02开始作业属性作业属性标记0x21整型值标记0x0006名称长度复制名称0x0004值长度
0x00000001 1 value 0x03 end-of-attributes end-of-attributes-tag
0x00000001 1值0x03属性结束属性结束标记
The following is an example of Create-Job request with no parameters and no attributes:
以下是创建不带参数和属性的作业请求的示例：
Octets Symbolic Value Protocol field 0x0100 1.0 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
八位字节符号值协议字段0x0100 1.0版本号0x0005创建作业操作id 0x00000001 1请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记0x0012名称长度
Octets Symbolic Value Protocol field 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 0x001A value-length http://forest: printer pinetree value 631/pinetree 0x03 end-of-attributes end-of-attributes-tag
八位字节符号值协议字段属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-属性自然语言名称自然语言0x0005值长度en us en us值0x45 uri类型值标记0x000B名称长度打印机uri名称0x001A值长度http://forest: 打印机pinetree值631/pinetree 0x03属性结束属性结束标记
The following is an example of Get-Jobs request with parameters but no attributes:
以下是带有参数但没有属性的Get Jobs请求的示例：
Octets Symbolic Value Protocol field
八位字节符号值协议字段
0x0100 1.0 version-number 0x000A Get-Jobs operation-id 0x00000123 0x123 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag
0x0100 1.0版本号0x000A获取作业操作id 0x0000123 0x123请求id 0x01开始操作属性操作属性标记0x47字符集类型值标记
Octets Symbolic Value Protocol field
八位字节符号值协议字段
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 0x001A value-length http://forest:6 printer pinetree value 31/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 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
0x0012名称长度属性-属性字符集名称字符集0x0008值长度us ascii us-ascii值0x48自然语言类型值标记0x001B名称长度属性-属性自然语言名称自然语言0x0005值长度en us en us值0x45 uri类型值标记0x000B名称长度打印机uri打印机uri名称0x001A值长度http://forest:6 打印机pinetree值31/pinetree 0x21整型值标记0x0005名称长度限制名称0x0004值长度0x00000032 50值0x44关键字类型值标记0x0014请求的名称长度-请求的属性名称属性0x0006值长度作业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
八位字节符号值协议字段
0x0100 1.0 version-number 0x0000 successful-ok status-code 0x00000123 0x123 request-id (echoed back) 0x01 start operation-attributes operation-attribute-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 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
0x0100 1.0版本号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开始作业属性（第一个作业属性标记对象）0x21整型值标记0x0006名称长度作业id作业id名称0x0004值长度147 147值0x36名称带语言值标记0x0008名称长度作业名称作业名称0x000C值长度0x0005子值长度fr ca fr ca值0x0003子值长度fou名称0x02开始作业属性（第二个作业属性标记对象）0x02开始作业属性（第三个作业属性标记对象）0x21整型值标记0x0006名称长度作业id作业id名称0x0004值长度
Octets Symbolic Value Protocol field
八位字节符号值协议字段
148 148 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
148 148值0x36名称带语言值标记0x0008名称长度作业名称作业名称名称0x0012值长度0x0005子值长度de CH de CH值0x0009子值长度isch guet isch guet名称0x03属性结束属性结束标记
10. Appendix C: Registration of MIME Media Type Information for "application/ipp"
10. 附录C：“应用程序/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.0, whose syntax is described in Section 3 "Encoding of the Operation Layer" of [RFC2565], and whose semantics are described in [RFC2566].
“应用程序/ipp”的内容类型表示Internet打印协议消息体（请求或响应）。目前有一个版本：IPP/1.0，其语法在[RFC2565]第3节“操作层编码”中描述，其语义在[RFC2566]中描述。
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations:
编码注意事项：
IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths).
IPP/1.0协议请求/响应可能包含长行，并且始终包含二进制数据（例如属性值长度）。
Security considerations:
安全考虑：
IPP/1.0 protocol requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. Protocol mixed-version interworking rules in [RFC2566] as well as protocol encoding rules in [RFC2565] are complete and unambiguous.
IPP/1.0协议请求/响应不会引入基础传输协议中尚未固有的任何安全风险。[RFC2566]中的协议混合版本互通规则以及[RFC2565]中的协议编码规则是完整且明确的。
Interoperability considerations:
互操作性注意事项：
IPP/1.0 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [RFC2566] and [RFC2565]. Protocol encoding rules specified in [RFC2565] 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.0 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.0请求（由客户端生成）和响应（由服务器生成）必须符合标准规范[RFC2566]和[RFC2565]规定的所有一致性要求。[RFC2565]中规定的协议编码规则是全面的，因此可以保证一致性实现之间的互操作性（尽管无法确保对特定可选功能的支持）。作为本地化字符串的所有IPP/1.0属性值的“字符集”和“自然语言”在IPP协议请求/响应中都是明确的（无需求助于HTTP、SMTP或其他邮件传输头中的任何外部信息）。
Published specification:
已发布的规范：
[RFC2566] Isaacson, S., deBry, R., Hastings, T., Herriot, R. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics" RFC 2566, April 1999.
[RFC2566]Isaacson，S.，deBry，R.，Hastings，T.，Herriot，R.和P.Powell，“互联网打印协议/1.0：模型和语义”，RFC 2566，1999年4月。
[RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565]Herriot，R.，Butler，S.，Moore，P.，Tuner，R.，“互联网打印协议/1.0：编码和传输”，RFC 25651999年4月。
Applications which use this media type:
使用此媒体类型的应用程序：
Internet Printing Protocol (IPP) print clients and print servers, communicating using HTTP/1.1 (see [RFC2565]), 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（参见[RFC2565]）、SMTP/ESMTP、FTP或其他传输协议进行通信。“application/ipp”类型的消息是自包含且独立于传输的，包括任何本地化字符串值的“charset”和“natural language”上下文。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606
Scott A.Isaacson Novell，Inc.美国犹他州普罗沃南部122 E 1700，邮编84606
Phone: 801-861-7366 Fax: 801-861-4025 Email: sisaacson@novell.com
电话：801-861-7366传真：801-861-4025电子邮件：sisaacson@novell.com
or
或
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: rherriot@pahv.xerox.com
电话：650-813-7696传真：650-813-6860电子邮件：rherriot@pahv.xerox.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。