Internet Engineering Task Force (IETF) I. McDonald
Request for Comments: 7472 High North, Inc.
Updates: 2910, 2911 M. Sweet
Category: Standards Track Apple, Inc.
ISSN: 2070-1721 March 2015
Internet Engineering Task Force (IETF) I. McDonald
Request for Comments: 7472 High North, Inc.
Updates: 2910, 2911 M. Sweet
Category: Standards Track Apple, Inc.
ISSN: 2070-1721 March 2015
Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme
HTTPS传输绑定上的Internet打印协议（IPP）和“ipps”URI方案
Abstract
摘要
This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.
本文档定义了HTTPS传输绑定上的Internet打印协议（IPP）和相应的“ipps”URI方案，用于指定对安全IPP打印服务或此类服务管理的网络资源的网络位置的访问。
This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.
本文档定义了与原始IPP URL方案（RFC 3510）中定义的替代IPP传输绑定，但本文档不更新或废弃RFC 3510。
This document updates RFCs 2910 and 2911.
本文件更新了RFCs 2910和2911。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7472.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7472.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Structure of This Document .................................4
1.2. Rationale for This Document ................................5
2. Conventions Used in This Document ...............................5
2.1. Requirements Language ......................................5
2.2. Printing Terminology .......................................5
2.3. Abbreviations ..............................................6
3. IPP over HTTPS Transport Binding ................................7
4. Definition of 'ipps' URI Scheme .................................8
4.1. Applicability of 'ipps' URI Scheme .........................8
4.2. Syntax of 'ipps' URI Scheme ................................8
4.3. Associated Port for 'ipps' URI Scheme .....................10
4.4. Character Encoding of 'ipps' URI Scheme ...................10
4.5. Examples of 'ipps' URIs ...................................11
4.6. Comparisons of 'ipps' URIs ................................12
5. IANA Considerations ............................................12
6. Security Considerations ........................................13
6.1. Problem Statement .........................................13
6.1.1. Targets of Attacks .................................14
6.1.2. Layers of Attacks ..................................14
6.2. Attacks and Defenses ......................................14
6.2.1. Faked 'ipps' URI ...................................15
6.2.2. Unauthorized Access by IPP Client ..................15
6.2.3. Compromise at Application Layer Gateway ............15
6.2.4. No Client Authentication for 'ipps' URI ............15
6.3. TLS Version Requirements ..................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
Acknowledgments ...................................................19
Authors' Addresses ................................................19
1. Introduction ....................................................3
1.1. Structure of This Document .................................4
1.2. Rationale for This Document ................................5
2. Conventions Used in This Document ...............................5
2.1. Requirements Language ......................................5
2.2. Printing Terminology .......................................5
2.3. Abbreviations ..............................................6
3. IPP over HTTPS Transport Binding ................................7
4. Definition of 'ipps' URI Scheme .................................8
4.1. Applicability of 'ipps' URI Scheme .........................8
4.2. Syntax of 'ipps' URI Scheme ................................8
4.3. Associated Port for 'ipps' URI Scheme .....................10
4.4. Character Encoding of 'ipps' URI Scheme ...................10
4.5. Examples of 'ipps' URIs ...................................11
4.6. Comparisons of 'ipps' URIs ................................12
5. IANA Considerations ............................................12
6. Security Considerations ........................................13
6.1. Problem Statement .........................................13
6.1.1. Targets of Attacks .................................14
6.1.2. Layers of Attacks ..................................14
6.2. Attacks and Defenses ......................................14
6.2.1. Faked 'ipps' URI ...................................15
6.2.2. Unauthorized Access by IPP Client ..................15
6.2.3. Compromise at Application Layer Gateway ............15
6.2.4. No Client Authentication for 'ipps' URI ............15
6.3. TLS Version Requirements ..................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
Acknowledgments ...................................................19
Authors' Addresses ................................................19
This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.
本文档定义了HTTPS传输绑定上的Internet打印协议（IPP）和相应的“ipps”URI方案，用于指定对安全IPP打印服务或此类服务管理的网络资源的网络位置的访问。
This document has been submitted to the IETF by the Internet Printing Protocol Working Group (WG) of the IEEE-ISTO Printer Working Group, as part of their PWG "IPP Everywhere" (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software.
本文件已由IEEE-ISTO打印机工作组的互联网打印协议工作组（WG）提交给IETF，作为其PWG“IPP Everywhere”（PWG 5100.14）项目的一部分，用于使用供应商中立的客户端软件进行安全移动打印。
This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme [RFC3510], but this document does not update or obsolete [RFC3510].
本文档定义了与原始IPP URL方案[RFC3510]中定义的IPP传输绑定的备用IPP传输绑定，但本文档未更新或废弃[RFC3510]。
This document updates:
本文件更新：
a) "Internet Printing Protocol/1.1: Encoding and Transport" [RFC2910], by extending Section 4 ("Encoding of Transport Layer"), Section 5 ("IPP URL Scheme"); and Section 8.2 ("Using IPP with TLS") to add the new standard URI scheme of 'ipps' for IPP Printers; and
a) “互联网打印协议/1.1：编码和传输”[RFC2910]，通过扩展第4节（“传输层编码”）、第5节（“IPP URL方案”）；以及第8.2节（“将IPP与TLS一起使用”），以添加IPP打印机的“IPP”新标准URI方案；和
b) "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911], by extending Section 4.1.6 ("uriScheme") and Section 4.4.1 ("printer-uri-supported") to add the new standard URI scheme of 'ipps' for IPP Printers.
b) “互联网打印协议/1.1：模型和语义”[RFC2911]，通过扩展第4.1.6节（“uri模式”）和第4.4.1节（“支持的打印机uri”），为IPP打印机添加“IPP”的新标准uri方案。
The following versions of IPP are currently defined:
目前定义了以下IPP版本：
a) 1.0 in [RFC2566] (obsolete);
b) 1.1 in [RFC2911];
c) 2.0 in [PWG5100.12];
d) 2.1 in [PWG5100.12]; and
e) 2.2 in [PWG5100.12].
a) 1.0 in [RFC2566] (obsolete);
b) 1.1 in [RFC2911];
c) 2.0 in [PWG5100.12];
d) 2.1 in [PWG5100.12]; and
e) 2.2 in [PWG5100.12].
Overview information about IPP is available in Section 1 of [RFC2911], Section 1 of [RFC3196], and Section 1 of PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12].
[RFC2911]第1节、[RFC3196]第1节和PWG“IPP版本2.0第二版（IPP/2.0 SE）”[PWG5100.12]第1节中提供了有关IPP的概述信息。
This document contains the following sections:
本文件包含以下章节：
Section 2 defines the conventions and terms used throughout the document.
第2节定义了整个文件中使用的约定和术语。
Section 3 defines the IPP over HTTPS transport binding.
第3节定义了IPP over HTTPS传输绑定。
Section 4 defines the 'ipps' URI scheme.
第4节定义了“ipps”URI方案。
Sections 5 and 6 contain IANA and security considerations, respectively.
第5节和第6节分别包含IANA和安全注意事项。
Section 7 contains references.
第7节包含参考文献。
The 'ipps' URI scheme was defined for the following reasons:
定义“ipps”URI方案的原因如下：
1) Some existing IPP Client and IPP Printer implementations of "Upgrading to TLS Within HTTP/1.1" [RFC2817] are flawed and unreliable, although this is not due to specification defects in [RFC2817] itself.
1) “升级到HTTP/1.1内的TLS”[RFC2817]的一些现有IPP客户端和IPP打印机实现存在缺陷且不可靠，尽管这不是由于[RFC2817]本身存在规范缺陷所致。
2) Some existing IPP Client and IPP Printer implementations of HTTP upgrade [RFC2817] do not perform an upgrade at the beginning of every HTTP [RFC7230] connection; instead, they only shift to secure IPP for selected IPP operations (inherently dangerous behavior on the same underlying TCP [RFC793] connection).
2) HTTP升级[RFC2817]的一些现有IPP客户端和IPP打印机实现在每个HTTP[RFC7230]连接开始时不执行升级；相反，它们只会转移到保护选定IPP操作的IPP（同一底层TCP[RFC793]连接上的固有危险行为）。
3) IPP Printer server-mandated HTTP upgrade [RFC2817] can still lead to exposure of IPP Client data if the Expect request header is not used -- basically, the IPP Client can send its whole Print-Job request before the IPP Printer has a chance to respond and say, "Wait! You need to encrypt first!".
3) 如果未使用Expect请求标头，IPP打印机服务器强制HTTP升级[RFC2817]仍可能导致IPP客户端数据泄露——基本上，IPP客户端可以在IPP打印机有机会响应并说“等等！您需要先加密！”之前发送其整个打印作业请求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The reader of this document needs to be familiar with the printing terms defined in "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] as well as the following:
本文件的读者需要熟悉“互联网打印协议/1.1：模型和语义”[RFC2911]中定义的打印术语以及以下内容：
IPP Client: The software (on some hardware platform) that submits IPP Job creation and IPP Printer and IPP Job management operations via the IPP over HTTP transport binding defined in the IPP/1.1 Encoding and Transport document [RFC2910] and/or the IPP over HTTPS transport binding defined in Section 3 of this specification to an IPP Printer (print spooler, print gateway, or physical printing device).
IPP客户端：通过IPP/1.1编码和传输文件[RFC2910]中定义的IPP over HTTP传输绑定和/或本规范第3节中定义的IPP over HTTPS传输绑定向IPP打印机提交IPP作业创建、IPP打印机和IPP作业管理操作的软件（在某些硬件平台上）（打印后台打印程序、打印网关或物理打印设备）。
IPP Job: The set of attributes and documents for one print job instantiated in an IPP Printer.
IPP作业：在IPP打印机中实例化的一个打印作业的一组属性和文档。
IPP Job object: Synonym for IPP Job.
IPP作业对象：IPP作业的同义词。
IPP Printer: The software (on some hardware platform) that receives IPP Job creation and IPP Printer and IPP Job management operations via the IPP over HTTP transport binding defined in the IPP/1.1 Encoding and Transport document [RFC2910] and/or the IPP over HTTPS transport binding defined in Section 3 of this specification from an IPP Client.
IPP打印机：通过IPP/1.1编码和传输文档[RFC2910]中定义的IPP over HTTP传输绑定和/或本规范第3节中定义的IPP over HTTPS传输绑定，从IPP客户端接收IPP作业创建、IPP打印机和IPP作业管理操作的软件（在某些硬件平台上）。
IPP Printer object: Synonym for IPP Printer.
IPP打印机对象：IPP打印机的同义词。
'ipps' URI: A URI using the 'ipps' URI scheme defined in Section 4 of this specification.
“ipps”URI：使用本规范第4节中定义的“ipps”URI方案的URI。
This document makes use of the following abbreviations (given with their expanded forms and references for further reading):
本文件使用了以下缩写（给出了其扩展形式和参考，以供进一步阅读）：
ABNF - Augmented Backus-Naur Form [STD68]
ABNF-扩充的巴科斯诺尔表[STD68]
ASCII - American Standard Code for Information Interchange [ASCII]
ASCII-美国信息交换标准代码[ASCII]
HTTP - HyperText Transfer Protocol [RFC7230]
HTTP-超文本传输协议[RFC7230]
HTTPS - HTTP over TLS [RFC7230]
HTTPS-HTTP over TLS[RFC7230]
IANA - Internet Assigned Numbers Authority
<http://www.iana.org>
IANA - Internet Assigned Numbers Authority
<http://www.iana.org>
IEEE - Institute of Electrical and Electronics Engineers
<http://www.ieee.org>
IEEE - Institute of Electrical and Electronics Engineers
<http://www.ieee.org>
IESG - Internet Engineering Steering Group
<http://www.ietf.org/iesg/>
IESG - Internet Engineering Steering Group
<http://www.ietf.org/iesg/>
IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12]
<http://www.pwg.org/ipp/>
IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12]
<http://www.pwg.org/ipp/>
ISTO - IEEE Industry Standards and Technology Organization
<http://www.ieee-isto.org/>
ISTO - IEEE Industry Standards and Technology Organization
<http://www.ieee-isto.org/>
LPD - Line Printer Daemon Protocol [RFC1179]
LPD-行打印机守护程序协议[RFC1179]
PWG - IEEE-ISTO Printer Working Group
<http://www.pwg.org>
PWG - IEEE-ISTO Printer Working Group
<http://www.pwg.org>
RFC - Request for Comments
<http://www.rfc-editor.org>
RFC - Request for Comments
<http://www.rfc-editor.org>
TCP - Transmission Control Protocol [RFC793]
TCP-传输控制协议[RFC793]
TLS - Transport Layer Security [RFC5246]
TLS-传输层安全性[RFC5246]
URI - Uniform Resource Identifier [STD66]
URI-统一资源标识符[STD66]
URL - Uniform Resource Locator [STD66]
URL-统一资源定位器[STD66]
UTF-8 - Unicode Transformation Format - 8-bit [STD63]
UTF-8-Unicode转换格式-8位[STD63]
This document defines the following alternate IPP over HTTPS transport binding for the abstract protocol defined in "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] and IEEE-ISTO PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12].
本文件为“互联网打印协议/1.1：模型和语义”[RFC2911]和IEEE-ISTO PWG“IPP版本2.0第二版（IPP/2.0 SE）”[PWG5100.12]中定义的抽象协议定义了以下替代IPP over HTTPS传输绑定。
When using an 'ipps' URI, an IPP Client MUST establish an IPP application-layer connection according to the following sequence:
使用“ipps”URI时，IPP客户端必须按照以下顺序建立IPP应用层连接：
1) The IPP Client selects an 'ipps' URI value from a "printer-uri-supported" Printer attribute [RFC2911], a directory entry, discovery info, a web page, etc.;
1) IPP客户端从“支持的打印机URI”打印机属性[RFC2911]、目录条目、发现信息、网页等中选择“ipps”URI值。；
2) The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230] (replacing 'ipps' with 'https' and inserting the port number from the URI or port 631 if the URI doesn't include an explicit port number);
2) IPP客户端将“ipps”URI转换为“https”URI[RFC7230]（将“ipps”替换为“https”，并从URI或端口631插入端口号（如果URI不包含显式端口号）；
3) The IPP Client establishes an HTTPS [RFC7230] secure session layer connection to the target endpoint; and
3) IPP客户端与目标端点建立HTTPS[RFC7230]安全会话层连接；和
4) The IPP Client sends requests to and receives responses from the target IPP application-layer resource over the HTTPS [RFC7230] secure session layer connection using the POST method defined in [RFC7231].
4) IPP客户端使用[RFC7231]中定义的POST方法，通过HTTPS[RFC7230]安全会话层连接向目标IPP应用层资源发送请求并从中接收响应。
Per PWG "IPP Everywhere" [PWG5100.14], in IPP exchanges, the 'ipps' URI scheme MUST only be used:
根据PWG“IPP Everywhere”[PWG5100.14]，在IPP交换中，“IPP”URI方案只能用于：
a) To specify an absolute URI for IPP secure print services and their associated network resources;
a) 指定IPP安全打印服务及其相关网络资源的绝对URI；
b) To specify the use of the abstract protocol defined in "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] and IEEE-ISTO PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12]; and
b) 指定“互联网打印协议/1.1：模型和语义”[RFC2911]和IEEE-ISTO PWG“IPP版本2.0第二版（IPP/2.0 SE）”[PWG5100.12]中定义的抽象协议的使用；和
c) To specify the use of the transport binding defined in this document.
c) 指定本文档中定义的传输绑定的使用。
The 'ipps' URI scheme allows an IPP Client to choose an appropriate IPP secure print service (for example, from a directory). The IPP Client can establish an HTTPS connection to the specified IPP secure print service. The IPP Client can send IPP requests (for example, Print-Job requests) and receive IPP responses over that HTTPS connection.
“ipps”URI方案允许IPP客户端选择适当的IPP安全打印服务（例如，从目录）。IPP客户端可以建立到指定IPP安全打印服务的HTTPS连接。IPP客户端可以通过HTTPS连接发送IPP请求（例如，打印作业请求）和接收IPP响应。
See: Section 4.2 ("Syntax of 'ipps' URI Scheme") of this document.
参见：本文件第4.2节（“ipps”URI方案的语法）。
See: Section 4.4.1 ("printer-uri-supported") in [RFC2911].
请参阅[RFC2911]中的第4.4.1节（“支持的打印机uri”）。
See: Section 5 ("IPP URL Scheme") in [RFC2910].
参见[RFC2910]中的第5节（“IPP URL方案”）。
See: Section 4 ("IPP Standards") of IEEE-ISTO PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12].
参见IEEE-ISTO PWG“IPP版本2.0第二版（IPP/2.0 SE）”[PWG5100.12]第4节（“IPP标准”）。
The abstract protocol defined in [RFC2911] places a limit of 1023 octets (NOT characters) on the length of a URI.
[RFC2911]中定义的抽象协议对URI的长度限制为1023个八位字节（非字符）。
See: "Uniform Resource Identifier (URI): Generic Syntax" [STD66].
请参阅：“统一资源标识符（URI）：通用语法”[STD66]。
Per PWG "IPP Everywhere" [PWG5100.14], for compatibility with existing IPP implementations, IPP Printers SHOULD NOT generate 'ipp' [RFC3510] or 'ipps' URI (or allow administrators to configure) lengths above 255 octets, because many older IPP Client implementations do not properly support these lengths.
根据PWG“IPP Everywhere”[PWG5100.14]，为了与现有IPP实现兼容，IPP打印机不应生成超过255个八位字节的“IPP”[RFC3510]或“IPP”URI（或允许管理员配置）长度，因为许多较旧的IPP客户端实现不正确支持这些长度。
Per PWG "IPP Everywhere" [PWG5100.14], in IPP exchanges, 'ipps' URIs MUST be represented in absolute form. Absolute URIs always begin with a scheme name followed by a colon. For definitive information on URI syntax and semantics, see "Uniform Resource Identifier (URI): Generic Syntax and Semantics" [STD66]. This specification adopts the definitions of "host", "port", and "query" from [STD66]. This specification adopts the definition of "absolute-path" from [RFC7230].
根据PWG“IPP Everywhere”[PWG5100.14]，在IPP交换中，“IPP”URI必须以绝对形式表示。绝对URI始终以方案名称开头，后跟冒号。有关URI语法和语义的详细信息，请参阅“统一资源标识符（URI）：通用语法和语义”[STD66]。本规范采用[STD66]中“主机”、“端口”和“查询”的定义。本规范采用[RFC7230]中“绝对路径”的定义。
The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows:
ABNF[STD68]中的“ipps”URI方案语法定义如下：
ipps-uri =
"ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]]
ipps-uri =
"ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]]
Per [RFC2910], if the port is empty or not given, then port 631 MUST be used.
根据[RFC2910]，如果端口为空或未给定，则必须使用端口631。
See: Section 4.3 ("Associated Port for 'ipps' URI Scheme") in this document.
请参阅：本文件第4.3节（“ipps”URI方案的关联端口）。
The semantics are that the identified resource (see [RFC7230]) is located at the IPP secure print service listening for HTTPS connections on that port of that host; and the Request-URI for the identified resource is 'absolute-path'.
语义是，标识的资源（参见[RFC7230]）位于IPP安全打印服务上，侦听该主机端口上的HTTPS连接；标识资源的请求URI为“绝对路径”。
Note: The higher-level "authority" production is not imported from [STD66], because it includes an optional "userinfo" component that cannot be used in 'ipps' URIs.
注意：更高级别的“授权”产品不是从[STD66]导入的，因为它包含一个可选的“userinfo”组件，不能在“ipps”URI中使用。
Note: The "query" production does not have defined semantics in IPP and was never used in examples in the IPP/1.1 Encoding and Transport document [RFC2910] or the original IPP URL Scheme [RFC3510]. The "query" is retained here for consistency, but IPP Clients SHOULD avoid its use (because the semantics would be implementation defined).
注：“查询”产品在IPP中没有定义语义，在IPP/1.1编码和传输文档[RFC2910]或原始IPP URL方案[RFC3510]的示例中从未使用过。此处保留“查询”以保持一致性，但IPP客户端应避免使用它（因为语义将由实现定义）。
Note: Per PWG "IPP Everywhere" [PWG5100.14], literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' URIs, because:
注意：根据PWG“IPP Everywhere”[PWG5100.14]，文字IPv4或IPv6地址不应在“IPP”URI中使用，因为：
a) IP addresses are often changed after network device installation (for example, based on DHCP reassignment after a power cycle);
a) IP地址通常在网络设备安装后更改（例如，基于电源循环后的DHCP重新分配）；
b) IP addresses often don't map simply to security domains;
b) IP地址通常不会简单地映射到安全域；
c) IP addresses are difficult to validate with X.509 server certificates (because they do not map to common name or alternate name attributes); and
c) 使用X.509服务器证书很难验证IP地址（因为它们不映射到公共名称或备用名称属性）；和
d) IP link local addresses are not "portable" due to link identity.
d) 由于链路标识，IP链路本地地址不“可移植”。
Per [RFC2910], if the 'absolute-path' is not present in an IPP URI, it MUST be given as "/" when used as a Request-URI for a resource (see [RFC7230]). An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:" with "https:" and inserting port 631 (if an explicit 'port' is not present in the original 'ipps' URI).
根据[RFC2910]，如果IPP URI中不存在“绝对路径”，则在用作资源的请求URI时，必须将其指定为“/”（请参见[RFC7230]）。通过将“ipps:”替换为“https:”并插入端口631（如果原始“ipps”URI中不存在显式“端口”），将“ipps”URI转换为“https”URI。
See: Section 4.3 ("Associated Port for 'ipps' URI Scheme") in this document.
请参阅：本文件第4.3节（“ipps”URI方案的关联端口）。
Per [RFC2910], all 'ipps' URIs that do NOT explicitly specify a port MUST be resolved to IANA-assigned well-known port 631, already registered in [PORTREG] by [RFC2910].
根据[RFC2910]，所有未明确指定端口的“IPP”URI必须解析为IANA分配的已知端口631，该端口已由[RFC2910]在[PORTREG]中注册。
Note: Per direction of the IESG, as described in [RFC2910], port 631 is used for all IPP connections (with or without TLS [RFC5246]). Therefore, port 631 is used for both 'ipp' [RFC3510] and 'ipps' URIs, which both refer to an IPP Printer or a network resource managed by an IPP Printer. IPP Printer implementors can refer to the CUPS [CUPS] source code for an example of incoming connection handling for the dual use of port 631.
注：按照IESG的方向，如[RFC2910]所述，端口631用于所有IPP连接（带或不带TLS[RFC5246]）。因此，端口631同时用于“ipp”[RFC3510]和“ipp”URI，这两个URI都指ipp打印机或由ipp打印机管理的网络资源。IPP打印机实现者可以参考CUPS[CUPS]源代码，以了解端口631双重使用的传入连接处理示例。
See: IANA Port Numbers Registry [PORTREG].
请参阅：IANA端口号注册表[PORTREG]。
See: [RFC2910].
见：[RFC2910]。
Per PWG "IPP Everywhere" [PWG5100.14], 'ipps' URIs MUST:
根据PWG“IPP无处不在”[PWG5100.14]，“IPP”URI必须：
a) Use the UTF-8 [STD63] charset for all components; and
a) 对所有组件使用UTF-8[STD63]字符集；和
b) Use [STD66] rules for percent encoding data octets outside the US-ASCII-coded character set [ASCII].
b) 使用[STD66]规则对美国ASCII编码字符集[ASCII]之外的数据八位字节进行百分比编码。
The following are examples of well-formed 'ipps' URIs for IPP Printers (for example, to be used as protocol elements in 'printer-uri' operation attributes of Print-Job request messages):
以下是IPP打印机格式良好的“IPP”uri示例（例如，将用作打印作业请求消息的“打印机uri”操作属性中的协议元素）：
ipps://example.com/
ipps://example.com/ipp
ipps://example.com/ipp/faxout
ipps://example.com/ipp/print
ipps://example.com/ipp/scan
ipps://example.com/ipp/print/bob
ipps://example.com/ipp/print/ira
ipps://example.com/
ipps://example.com/ipp
ipps://example.com/ipp/faxout
ipps://example.com/ipp/print
ipps://example.com/ipp/scan
ipps://example.com/ipp/print/bob
ipps://example.com/ipp/print/ira
Note: The use of an explicit 'ipp' path component followed by explicit 'print', 'faxout', 'scan', or other standard or vendor service component is best practice per [PWG5100.14], [PWG5100.15], and [PWG5100.17].
注：根据[PWG5100.14]、[PWG5100.15]和[PWG5100.17]，使用显式“ipp”路径组件，然后使用显式“打印”、“传真输出”、“扫描”或其他标准或供应商服务组件是最佳做法。
Each of the above URIs is a well-formed URI for an IPP Printer and each would reference a logically different IPP Printer, even though some of those IPP Printers might share the same host system. Note that 'print' might represent some grouping of IPP Printers (for example, a load-balancing spooler), while the 'bob' or 'ira' last path components might represent two different physical printer devices, or 'bob' and 'ira' might represent separate human recipients on the same physical printer device (for example, a physical printer supporting two job queues). Regardless, both 'bob' and 'ira' would behave as different and independent IPP Printers.
上述每个URI都是IPP打印机的格式良好的URI，每个URI都引用逻辑上不同的IPP打印机，即使其中一些IPP打印机可能共享同一主机系统。请注意，“print”可能表示IPP打印机的某些分组（例如，负载平衡后台处理程序），而“bob”或“ira”最后路径组件可能表示两个不同的物理打印机设备，或者“bob”和“ira”可能表示同一物理打印机设备上的不同人工收件人（例如，支持两个作业队列的物理打印机）。无论如何，“bob”和“ira”都将作为不同的独立IPP打印机。
The following are examples of well-formed 'ipps' URIs for IPP Printers with (optional) ports and paths:
以下是用于具有（可选）端口和路径的IPP打印机的格式良好的“IPP”URI示例：
ipps://example.com/
ipps://example.com/ipp/print
ipps://example.com:631/ipp/print
ipps://example.com/
ipps://example.com/ipp/print
ipps://example.com:631/ipp/print
The first and second 'ipps' URIs above will be resolved to port 631 (IANA-assigned well-known port for IPP). The second and third 'ipps' URIs above are equivalent (see Section 4.6).
上述第一个和第二个“IPP”URI将解析为端口631（IANA为IPP分配的知名端口）。上述第二个和第三个“IPP”URI是等效的（见第4.6节）。
See: Sections 4.2 ("Syntax of 'ipps' URI Scheme") and 4.3 ("Associated Port for 'ipps' URI Scheme") in this document.
参见：本文件第4.2节（“ipps”URI方案的语法）和第4.3节（“ipps”URI方案的关联端口”）。
Per PWG "IPP Everywhere" [PWG5100.14], when comparing two 'ipps' URIs to decide whether or not they match, an IPP Client MUST use the same rules as those defined for 'http' and 'https' URI comparisons in [RFC7230], with the following single exception:
根据PWG“IPP Everywhere”[PWG5100.14]，在比较两个“IPP”URI以确定它们是否匹配时，IPP客户端必须使用与[RFC7230]中为“http”和“https”URI比较定义的规则相同的规则，但有以下一个例外：
- A port that is empty or not given MUST be treated as equivalent to the well-known port for that 'ipps' URI (port 631).
- 空的或未给定的端口必须被视为与“ipps”URI的已知端口（端口631）等效。
See: Section 4.3 ("Associated Port for 'ipps' URI Scheme") in this document.
请参阅：本文件第4.3节（“ipps”URI方案的关联端口）。
See: Section 2.7.3 ("http and https URI Normalization and Comparison") in [RFC7230].
请参阅[RFC7230]中的第2.7.3节（“http和https URI规范化和比较”）。
IANA has registered the new keyword value 'ipps' for the IPP Printer "printer-uri-supported" attribute in the IANA IPP Registry [IPPREG], per Section 6.2 ("Attribute Extensibility") of [RFC2911] as follows:
IANA已根据[RFC2911]第6.2节（“属性扩展性”）在IANA IPP注册表[IPPREG]中为IPP打印机“支持的打印机uri”属性注册了新的关键字值“ipps”，如下所示：
IANA has registered the 'ipps' URI scheme using the following template, which conforms to [BCP35].
IANA已使用符合[BCP35]的以下模板注册了“ipps”URI方案。
URI scheme name: ipps
URI方案名称：ipps
Status: Permanent
地位：永久
URI scheme syntax: See Section 4.2 of RFC 7472.
URI方案语法：参见RFC 7472第4.2节。
URI scheme semantics: The 'ipps' URI scheme is used to designate secure IPP Printer objects (print spoolers, print gateways, print devices, etc.) on Internet hosts accessible using the IPP enhanced to support guaranteed data integrity and negotiable data privacy using TLS [RFC5246] as specified in HTTP/1.1 [RFC7230].
URI方案语义：“ipps”URI方案用于指定Internet主机上的安全IPP打印机对象（后台打印程序、打印网关、打印设备等），可使用IPP增强，以支持HTTP/1.1[RFC7230]中规定的TLS[RFC5246]保证数据完整性和可协商数据隐私。
Encoding Considerations: See Section 4.4 of RFC 7472.
编码注意事项：见RFC 7472第4.4节。
Applications/protocols that use this URI scheme name: The 'ipps' URI scheme is intended to be used by applications that need to access secure IPP Printers using the IPP enhanced to support guaranteed data integrity and negotiable data privacy using TLS [RFC5246] as specified in HTTP/1.1 [RFC7230]. Such applications may include (but are not limited to) IPP-capable web browsers, IPP Clients that wish to print a file, and servers (for example, print spoolers) wishing to forward a Job for processing.
使用此URI方案名称的应用程序/协议：“ipps”URI方案旨在供需要使用HTTP/1.1[RFC7230]中规定的TLS[RFC5246]增强IPP以支持有保证的数据完整性和可协商的数据隐私来访问安全IPP打印机的应用程序使用。此类应用程序可能包括（但不限于）支持IPP的web浏览器、希望打印文件的IPP客户端以及希望转发作业以进行处理的服务器（例如，后台打印程序）。
Interoperability Considerations: The widely deployed, open source IPP print service CUPS [CUPS] (on most UNIX, Linux, and Apple OS X systems) has supported 'ipps' URI for several years before the publication of this document. PWG "IPP Everywhere" [PWG5100.14] (IPP secure, mobile printing extensions) requires the use of 'ipps' URI for mandatory data integrity and negotiable data confidentiality.
互操作性注意事项：广泛部署的开源IPP打印服务CUPS[CUPS]（在大多数UNIX、Linux和Apple OS X系统上）在本文档发布之前已经支持“ipps”URI好几年了。PWG“IPP Everywhere”[PWG5100.14]（IPP安全、移动打印扩展）要求使用“IPP”URI来实现强制数据完整性和可协商数据保密性。
Security Considerations: See Section 6 of RFC 7472.
安全注意事项：见RFC 7472第6节。
Contact: Ira McDonald <blueroofmusic@gmail.com>,
Michael Sweet <msweet@apple.com>
Contact: Ira McDonald <blueroofmusic@gmail.com>,
Michael Sweet <msweet@apple.com>
Author/Change controller: IESG
作者/变更控制员：IESG
References: RFCs 2910, 2911, and 7472; IEEE-ISTO PWG 5100.12.
参考文献：RFCs 2910、2911和7472；IEEE-ISTO PWG 5100.12。
Powerful mobile devices (laptops, tablets, smartphones, etc.) are now commonly used to access enterprise and Cloud print services across the public Internet. This is the primary use case for PWG "IPP Everywhere" [PWG5100.14], which has already been adopted by operating system and printer vendors and several other public standards bodies. End-user and enterprise documents and user privacy-sensitive information are at greater risk than ever before. This IPP-over-HTTPS transport binding and 'ipps' URI scheme specification was defined to enable high availability combined with secure operation in this dynamic environment (for example, wireless hotspots in hotels, airports, and restaurants).
强大的移动设备（笔记本电脑、平板电脑、智能手机等）现在通常用于通过公共互联网访问企业和云打印服务。这是PWG“IPP Everywhere”[PWG5100.14]的主要用例，该用例已被操作系统和打印机供应商以及其他几个公共标准机构采用。最终用户和企业文档以及用户隐私敏感信息的风险比以往任何时候都大。此IPP over HTTPS传输绑定和“ipps”URI方案规范的定义是为了在这种动态环境（例如，酒店、机场和餐厅的无线热点）中实现高可用性和安全操作。
See: Section 1 ("Introduction") of [PWG5100.14].
见[PWG5100.14]第1节（“引言”）。
See: Section 3.1 ("Rationale") of [PWG5100.14].
见[PWG5100.14]第3.1节（“基本原理”）。
A network print spooler (logical printer) or print device (physical printer) is potentially subject to attacks, which may target:
网络后台打印程序（逻辑打印机）或打印设备（物理打印机）可能会受到攻击，攻击的目标可能是：
a) The network (to compromise the routing infrastructure, for example, by creating congestion);
a) 网络（例如，通过造成拥塞破坏路由基础设施）；
b) The Internet Printing Protocol (IPP) [RFC2911] (for example, to compromise the normal behavior of IPP);
b) 互联网打印协议（IPP）[RFC2911]（例如，损害IPP的正常行为）；
c) The print job metadata (for example, to extract privacy-sensitive information from the job submission request or via query of the job on the IPP Printer); or
c) 打印作业元数据（例如，从作业提交请求或通过IPP打印机上的作业查询提取隐私敏感信息）；或
d) The print document content itself (for example, to steal the data or to corrupt the documents being transferred).
d) 打印文档内容本身（例如，窃取数据或损坏正在传输的文档）。
Attacks against print services can be launched:
可以通过以下方式对打印服务发起攻击：
a) Against the network infrastructure (for example, TCP [RFC793] congestion control);
a) 针对网络基础设施（例如，TCP[RFC793]拥塞控制）；
b) Against the IPP data flow itself (for example, by sending forged packets or forcing TLS [RFC5246] version downgrade); or
b) 针对IPP数据流本身（例如，通过发送伪造数据包或强制TLS[RFC5246]版本降级）；或
c) Against the IPP operation parameters (for example, by corrupting requested document processing attributes).
c) 针对IPP操作参数（例如，通过破坏请求的文档处理属性）。
This 'ipps' URI Scheme specification adds the following additional security considerations to those described in [RFC7230], [RFC2910], [RFC2911], [RFC5246], [RFC7230], [PWG5100.12], and [STD66].
此“ipps”URI方案规范在[RFC7230]、[RFC2910]、[RFC2911]、[RFC5246]、[RFC7230]、[PWG5100.12]和[STD66]中所述的安全注意事项基础上增加了以下额外的安全注意事项。
See: Section 8 ("Security Considerations") in [RFC2910].
参见[RFC2910]中的第8节（“安全注意事项”）。
See: Section 8 ("Security Considerations") in [RFC2911].
参见[RFC2911]中的第8节（“安全注意事项”）。
See: Appendix D ("Implementation Notes"), Appendix E ("Backward Compatibility"), and Appendix F ("Security Analysis") of [RFC5246].
参见[RFC5246]的附录D（“实施说明”）、附录E（“向后兼容性”）和附录F（“安全分析”）。
See: Section 10 ("Security Considerations") in [PWG5100.12].
参见[PWG5100.12]中的第10节（“安全注意事项”）。
See: Section 7 ("Security Considerations") in [STD66].
见[STD66]第7节（“安全注意事项”）。
An 'ipps' URI might be faked to point to a rogue IPP secure print service, thus collecting confidential job metadata or document contents from IPP Clients.
“ipps”URI可能被伪造为指向恶意IPP安全打印服务，从而从IPP客户端收集机密作业元数据或文档内容。
Due to administrator reconfiguration or physical relocation of an IPP Printer, a former literal IPv4 or IPv6 address might no longer be valid. See Section 4.2 ("Syntax of 'ipps' URI Scheme") for the recommendation against the use of literal IP addresses in 'ipps' URI.
由于管理员重新配置或IPP打印机的物理重新定位，以前的文字IPv4或IPv6地址可能不再有效。有关反对在“ipps”URI中使用文字IP地址的建议，请参见第4.2节（“ipps”URI方案的语法”）。
Server authentication mechanisms and security mechanisms specified in IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and TLS/1.2 [RFC5246] can be used to address this threat.
IPP/1.1编码和传输[RFC2910]、HTTP/1.1[RFC7230]和TLS/1.2[RFC5246]中指定的服务器身份验证机制和安全机制可用于解决此威胁。
An 'ipps' URI might be used to access an IPP secure print service by an unauthorized IPP Client, for example, extracting privacy-sensitive information such as "job-originating-user-name" job metadata defined in [RFC2911].
“ipps”URI可用于未经授权的IPP客户端访问IPP安全打印服务，例如，提取隐私敏感信息，如[RFC2911]中定义的“作业原始用户名”作业元数据。
Client authentication mechanisms and security mechanisms specified in IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and TLS/1.2 [RFC5246] can be used to address this threat.
IPP/1.1编码和传输[RFC2910]、HTTP/1.1[RFC7230]和TLS/1.2[RFC5246]中规定的客户端身份验证机制和安全机制可用于解决此威胁。
An 'ipps' URI might be used to access an IPP secure print service at a print protocol application layer gateway (for example, an IPP to LPD [RFC1179] gateway [RFC2569]), potentially causing silent compromise of IPP security mechanisms.
“ipps”URI可用于访问打印协议应用层网关（例如，IPP到LPD[RFC1179]网关[RFC2569]）上的IPP安全打印服务，这可能会导致IPP安全机制的无声泄漏。
There is no general defense against this threat by an IPP Client. System administrators SHOULD avoid such configurations.
IPP客户没有针对这种威胁的一般防御措施。系统管理员应避免此类配置。
An 'ipps' URI does not define parameters to specify the required IPP Client authentication mechanism (for example, 'certificate' as defined in Section 4.4.2 ("uri-authentication-supported") of [RFC2911]).
“ipps”URI未定义参数以指定所需的IPP客户端身份验证机制（例如，[RFC2911]第4.4.2节（“支持的URI身份验证”）中定义的“证书”）。
An IPP Client SHOULD first use service discovery or directory protocols (e.g., the "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services" [RFC3712]) or directly send an IPP Get-Printer-Attributes operation to the target IPP Printer to read
IPP客户端应首先使用服务发现或目录协议（例如“轻量级目录访问协议（LDAP）：打印机服务模式”[RFC3712]），或直接向目标IPP打印机发送IPP获取打印机属性操作以读取
"printer-uri-supported", "uri-authentication-supported", and "uri-security-supported" attributes to discover the required IPP Client authentication and security mechanisms for each supported URI.
“支持打印机uri”、“支持uri身份验证”和“支持uri安全性”属性，以发现每个受支持uri所需的IPP客户端身份验证和安全机制。
Per PWG "IPP Everywhere" [PWG5100.14] (and in accordance with security best practices and all existing deployments of the 'ipps' URI scheme), IPP Clients and IPP Printers that support this specification MUST use TLS/1.2 [RFC5246] or a higher version, for all 'ipps' secure transport layer connections.
根据PWG“IPP Everywhere”[PWG5100.14]（并根据安全最佳实践和“IPP”URI方案的所有现有部署），支持本规范的IPP客户端和IPP打印机必须使用TLS/1.2[RFC5246]或更高版本，用于所有“IPP”安全传输层连接。
Implementors will find useful advice in the "Recommendations for Secure Use of TLS and DTLS" [TLSBCP].
实施者将在“TLS和DTL安全使用建议”[TLSBCP]中找到有用的建议。
[ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ASCII]美国国家标准协会，“编码字符集——信息交换用7位美国标准代码”，ANSI X3.41986。
[PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, "Internet Printing Protocol", Version 2.0, Second Edition (IPP/2.0 SE), PWG 5100.12, February 2011, <http://www.pwg.org/standards.html>.
[PWG5100.12]伯格曼，R.，刘易斯，H.，麦克唐纳，I.，和M.斯威特，“互联网打印协议”，版本2.0，第二版（IPP/2.0 SE），PWG 5100.12，2011年2月<http://www.pwg.org/standards.html>.
[PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG 5100.14, January 2013, <http://www.pwg.org/standards.html>.
[PWG5100.14]McDonald，I.和M.Sweet，“PWG IPP无处不在”，PWG 5100.14，2013年1月<http://www.pwg.org/standards.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000, <http://www.rfc-editor.org/info/rfc2910>.
[RFC2910]Herriot，R.，Ed.，Butler，S.，Moore，P.，Turner，R.，和J.Wenn，“互联网打印协议/1.1：编码和传输”，RFC 29102000年9月<http://www.rfc-editor.org/info/rfc2910>.
[RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000, <http://www.rfc-editor.org/info/rfc2911>.
[RFC2911]黑斯廷斯，T.，Ed.，赫里奥特，R.，德布雷，R.，艾萨克森，S.，和P.鲍威尔，“互联网打印协议/1.1：模型和语义”，RFC 29112000年9月<http://www.rfc-editor.org/info/rfc2911>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/sstd63>.
[STD63]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 36292003年11月<http://www.rfc-editor.org/info/sstd63>.
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/std66>.
[STD66]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月<http://www.rfc-editor.org/info/std66>.
[STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/std68>.
[STD68]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/std68>.
[BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006, <http://www.rfc-editor.org/info/bcp35>.
[BCP35]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月<http://www.rfc-editor.org/info/bcp35>.
[CUPS] Apple, "CUPS", Version 2.0.2, <https://www.cups.org/>.
[CUPS]苹果，“CUPS”，2.0.2版<https://www.cups.org/>.
[IPPREG] Internet Assigned Numbers Authority (IANA) Registries, "Internet Printing Protocol (IPP) Registrations", <http://www.iana.org/assignments/ipp-registrations/>.
[IPPREG]互联网分配号码管理局（IANA）注册处，“互联网打印协议（IPP）注册”<http://www.iana.org/assignments/ipp-registrations/>.
[PORTREG] Internet Assigned Numbers Authority (IANA) Registries, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/port-numbers>.
[PORTREG]互联网分配号码管理局（IANA）注册中心，“服务名称和传输协议端口号注册中心”<http://www.iana.org/assignments/port-numbers>.
[PWG5100.15] M. Sweet, "PWG IPP FaxOut Service", PWG 5100.15, June 2014, <http://www.pwg.org/standards.html>.
[PWG5100.15]M.Sweet，“PWG IPP传真输出服务”，PWG 5100.152014年6月<http://www.pwg.org/standards.html>.
[PWG5100.17] P. Zehler, "PWG IPP Scan Service", PWG 5100.17, September 2014, <http://www.pwg.org/standards.html>.
[PWG5100.17]P.Zehler，“PWG IPP扫描服务”，PWG 5100.172014年9月<http://www.pwg.org/standards.html>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, August 1990, <http://www.rfc-editor.org/info/rfc1179>.
[RFC1179]McLaughlin，L.，“线路打印机守护程序协议”，RFC1179，1990年8月<http://www.rfc-editor.org/info/rfc1179>.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999, <http://www.rfc-editor.org/info/rfc2566>.
[RFC2566]deBry，R.，Hastings，T.，Herriot，R.，Isaacson，S.，和P.Powell，“互联网打印协议/1.0：模型和语义”，RFC 2566，1999年4月<http://www.rfc-editor.org/info/rfc2566>.
[RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999, <http://www.rfc-editor.org/info/rfc2569>.
[RFC2569]Herriot，R.，Ed.，Hastings，T.，Jacobs，N.，和J.Martin，“LPD和IPP协议之间的映射”，RFC 2569，1999年4月<http://www.rfc-editor.org/info/rfc2569>.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000, <http://www.rfc-editor.org/info/rfc2817>.
[RFC2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月<http://www.rfc-editor.org/info/rfc2817>.
[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, "Internet Printing Protocol/1.1: Implementor's Guide", RFC 3196, November 2001, <http://www.rfc-editor.org/info/rfc3196>.
[RFC3196]黑斯廷斯，T.，曼罗斯，C.，泽勒，P.，库格勒，C.，和H.霍尔斯特，“互联网打印协议/1.1：实施者指南”，RFC31962001年11月<http://www.rfc-editor.org/info/rfc3196>.
[RFC3510] Herriot, R. and I. McDonald, "Internet Printing Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003, <http://www.rfc-editor.org/info/rfc3510>.
[RFC3510]Herriot，R.和I.McDonald，“互联网打印协议/1.1:IPP URL方案”，RFC 35102003年4月<http://www.rfc-editor.org/info/rfc3510>.
[RFC3712] Fleming, P. and I. McDonald, "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", RFC 3712, February 2004, <http://www.rfc-editor.org/info/rfc3712>.
[RFC3712]Fleming，P.和I.McDonald，“轻量级目录访问协议（LDAP）：打印机服务模式”，RFC 3712，2004年2月<http://www.rfc-editor.org/info/rfc3712>.
[TLSBCP] Scheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of TLS and DTLS", Work in Progress, draft-ietf-uta-tls-bcp, December 2014.
[TLSBCP]Scheffer，Y.，Holz，R.，和P.Saint Andre，“TLS和DTL安全使用建议”，正在进行的工作，ietf uta TLS bcp草案，2014年12月。
Acknowledgments
致谢
This document has been submitted to the IETF by the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group, as part of their PWG IPP Everywhere [PWG5100.14] project for secure mobile printing with vendor-neutral Client software.
本文件已由IEEE-ISTO打印机工作组的互联网打印协议工作组提交给IETF，作为其PWG IPP Everywhere[PWG5100.14]项目的一部分，用于使用供应商中立的客户端软件进行安全移动打印。
This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme [RFC3510], but this document does not update or obsolete [RFC3510].
本文档定义了与原始IPP URL方案[RFC3510]中定义的IPP传输绑定的备用IPP传输绑定，但本文档未更新或废弃[RFC3510]。
Thanks to Claudio Allochio, Jari Arrko, Spencer Dawkins, Adrian Farrel, Tom Hastings, Bjoern Hoerhmann, Smith Kennedy, Graham Klyne, Barry Leiba, S. Moonesamy, Kathleen Moriarty, Sandra Murphy, Tom Petch, Pete Resnick, Benson Schliesser, Robert Sparks, Jerry Thrasher, Mykyta Yevstifeyev, Pete Zehler, and the members of the IEEE-ISTO PWG IPP WG.
感谢克劳迪奥·阿洛奇奥、贾里·阿尔科、斯宾塞·道金斯、阿德里安·法雷尔、汤姆·黑斯廷斯、比约恩·霍尔曼、史密斯·肯尼迪、格雷厄姆·克莱恩、巴里·莱巴、S·穆内萨米、凯瑟琳·莫里亚蒂、桑德拉·墨菲、汤姆·佩奇、皮特·雷斯尼克、本森·施利塞、罗伯特·斯帕克斯、杰瑞·斯勒舍尔、米基塔·叶夫斯蒂耶夫、皮特·泽勒以及IEEE-ISTO PWG IPP工作组的成员。
Authors' Addresses
作者地址
Ira McDonald High North, Inc. 221 Ridge Ave Grand Marais, MI 49839 United States
Ira麦克唐纳高北有限公司，美国密歇根州格兰德马雷市里奇大道221号，邮编49839
Phone: +1 906-494-2434
EMail: blueroofmusic@gmail.com
Phone: +1 906-494-2434
EMail: blueroofmusic@gmail.com
Michael Sweet Apple, Inc. 1 Infinite Loop, M/S 111-HOMC Cupertino, CA 95014 United States
Michael Sweet Apple，Inc.1 Infinite Loop，美国加利福尼亚州库珀蒂诺市霍姆斯111号，邮编95014
EMail: msweet@apple.com
EMail: msweet@apple.com