[要約] RFC 7472は、IPPプロトコルをHTTPSトランスポートバインディングと'ipps' URIスキームで使用するための仕様です。目的は、セキュアな印刷通信を提供し、プリンターとクライアント間の通信を保護することです。
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トランスポートバインディング上のインターネット印刷プロトコル（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トランスポートバインディングを介したインターネット印刷プロトコル（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.
このドキュメントは、RFC 2910および2911を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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トランスポートバインディングを介したインターネット印刷プロトコル（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.
このドキュメントは、ベンダーニュートラルクライアントによる安全なモバイル印刷のためのPWG "IPP Everywhere"（PWG 5100.14）プロジェクトの一部として、IEEE-ISTOプリンターワーキンググループのインターネット印刷プロトコルワーキンググループ（WG）によってIETFに提出されました。ソフトウェア。
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トランスポートバインディングを定義しますが、このドキュメントは更新または廃止されません[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（「TLSでのIPPの使用」）は、IPPプリンター用の「ipps」という新しい標準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（「uriScheme」）およびセクション4.4.1（「printer-uri-supported」）を拡張して「ipps」の新しい標準URIスキームを追加'IPPプリンター用。
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].
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].
IPPに関する概要情報は、[RFC2911]のセクション1、[RFC3196]のセクション1、およびPWG「IPPバージョン2.0 Second Edition（IPP / 2.0 SE）」のセクション1 [PWG5100.12]で入手できます。
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操作（同じ基本的なTCP [RFC793]接続での本質的に危険な動作）のセキュアIPPにシフトするだけです。
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）IPPプリンターのサーバー必須のHTTPアップグレード[RFC2817]は、Expectリクエストヘッダーが使用されていない場合でも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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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:
このドキュメントの読者は、「Internet Printing Protocol / 1.1：Model and Semantics」[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で定義されたIPP over HTTPトランスポートバインディングを介してIPPジョブの作成とIPPプリンターおよびIPPジョブ管理操作を送信するソフトウェア（一部のハードウェアプラットフォーム）この仕様のセクション3でIPPプリンター（印刷スプーラー、印刷ゲートウェイ、または物理印刷デバイス）に定義されたHTTPSトランスポートバインディング。
IPP Job: The set of attributes and documents for one print job instantiated in an IPP Printer.
IPPジョブ：IPPプリンターでインスタンス化された1つの印刷ジョブの属性とドキュメントのセット。
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で定義されたIPP over HTTPトランスポートバインディングを介してIPPジョブの作成とIPPプリンターおよびIPPジョブ管理操作を受信するソフトウェア（一部のハードウェアプラットフォーム）この仕様のセクション3でIPPクライアントから定義されたHTTPSトランスポートバインディング。
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>
IEEE - Institute of Electrical and Electronics Engineers
<http://www.ieee.org>
IESG - Internet Engineering Steering Group
<http://www.ietf.org/iesg/>
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/>
LPD - Line Printer Daemon Protocol [RFC1179]
LPD-ラインプリンターデーモンプロトコル[RFC1179]
PWG - IEEE-ISTO Printer Working Group
<http://www.pwg.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]
うり ー うにふぉｒｍ れそうｒせ いでんちふぃえｒ 「ＳＴＤ６６」
URL - Uniform Resource Locator [STD66]
URL-Uniform Resource Locator [STD66]
UTF-8 - Unicode Transformation Format - 8-bit [STD63]
UTF-8-Unicode Transformation Format-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）」で定義された抽象プロトコル用に、次の代替IPP over HTTPSトランスポートバインディングを定義します。 PWG5100.12]。
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クライアントは、「printer-uri-supported」プリンター属性[RFC2911]、ディレクトリエントリ、検出情報、Webページなどから「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にポート番号を挿入します（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交換では、「ipps」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クライアントは、IPP要求（たとえば、Print-Job要求）を送信し、そのHTTPS接続を介して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（ "printer-uri-supported"）を参照してください。
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 Second Edition（IPP / 2.0 SE）」のセクション4（「IPP標準」）[PWG5100.12]。
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].
「Uniform Resource Identifier（URI）：Generic Syntax」[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]または「ipps」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交換では、「ipps」URIは絶対形式で表現する必要があります。絶対URIは常にスキーム名で始まり、その後にコロンが続きます。 URIの構文とセマンティクスの決定的な情報については、「Uniform Resource Identifier（URI）：Generic Syntax and Semantics」[STD66]を参照してください。この仕様は、[STD66]の「ホスト」、「ポート」、「クエリ」の定義を採用しています。この仕様は、[RFC7230]の「absolute-path」の定義を採用しています。
The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows:
ABNF [STD68]の「ipps」URIスキーム構文は、次のように定義されています。
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]を参照）が、そのホストのそのポートでHTTPS接続をリッスンするIPPセキュアプリントサービスにあることです。識別されたリソースのRequest-URIは「absolute-path」です。
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]からインポートされません。これは、「ipps」URIで使用できないオプションの「userinfo」コンポーネントが含まれているためです。
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アドレスは 'ipps' 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) IPアドレスは、X.509サーバー証明書で検証することが困難です（一般名または代替名の属性にマップされないため）。そして
d) IP link local addresses are not "portable" due to link identity.
d) リンクIDのため、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]によると、「absolute-path」がIPP URIに存在しない場合、リソースのRequest-URIとして使用する場合は「/」として指定する必要があります（[RFC7230]を参照）。 「ipps」URIは、「ipps：」を「https：」に置き換え、ポート631を挿入することで「https」URIに変換されます（元の「ipps」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]に従い、ポートを明示的に指定しないすべての 'ipps' URIは、[RFC2910]によって[PORTREG]にすでに登録されているIANA割り当ての既知のポート631に解決される必要があります。
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.
注：[RFC2910]で説明されているように、IESGの方向ごとに、すべてのIPP接続（TLSありまたはなし[RFC5246]）にポート631が使用されます。したがって、ポート631は、「ipp」[RFC3510]と「ipps」の両方のURIに使用されます。どちらのURIも、IPPプリンターまたはIPPプリンターによって管理されるネットワークリソースを参照します。 IPPプリンターの実装者は、ポート631の二重使用のための着信接続処理の例について、CUPS [CUPS]ソースコードを参照できます。
See: IANA Port Numbers Registry [PORTREG].
参照：IANAポート番号レジストリ[PORTREG]。
See: [RFC2910].
[RFC2910]を参照してください。
Per PWG "IPP Everywhere" [PWG5100.14], 'ipps' URIs MUST:
PWG「IPP Everywhere」[PWG5100.14]に従い、「ipps」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) US-ASCIIでコード化された文字セット[ASCII]以外のパーセントエンコードデータオクテットの[STD66]ルールを使用します。
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プリンター用の整形式の「ipps」URIの例です（たとえば、Print-Job要求メッセージの「printer-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
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].
注：明示的な「ipp」パスコンポーネントの後に明示的な「print」、「faxout」、「scan」、またはその他の標準またはベンダーのサービスコンポーネントを使用することは、[PWG5100.14]、[PWG5100.15]によるベストプラクティスです。および[PWG5100.17]。
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であり、一部のIPPプリンターが同じホストシステムを共有している場合でも、論理的に異なるIPPプリンターを参照します。 'print'はIPPプリンターのいくつかのグループ（たとえば、負荷分散スプーラー）を表す場合がありますが、 'bob'または 'ira'の最終パスコンポーネントは2つの異なる物理プリンターデバイス、または 'bob'と 'ira 'は、同じ物理プリンターデバイス（たとえば、2つのジョブキューをサポートする物理プリンター）上の別々の人間の受信者を表す場合があります。いずれにしても、「bob」と「ira」はどちらも、異なる独立したIPPプリンターとして動作します。
The following are examples of well-formed 'ipps' URIs for IPP Printers with (optional) ports and paths:
以下は、（オプションの）ポートとパスを備えたIPPプリンター用の整形式の「ipps」URIの例です。
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).
上記の最初と2番目の「ipps」URIは、ポート631（IANAが割り当てたIPPの既知のポート）に解決されます。上記の2番目と3番目の「ipps」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]によると、2つの 'ipps' URIを比較してそれらが一致するかどうかを決定する場合、IPPクライアントは、[の 'http'および 'https' URI比較に定義されたものと同じルールを使用する必要があります。 RFC7230]、ただし次の1つの例外があります。
- 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プリンター「printer-uri-supported」属性の新しいキーワード値「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スキームは、TLSを使用して保証されたデータの整合性と交渉可能なデータのプライバシーをサポートするように拡張されたIPPを使用してアクセスできるインターネットホスト上の安全なIPPプリンターオブジェクト（印刷スプーラー、印刷ゲートウェイ、印刷デバイスなど）を指定するために使用されます[RFC5246] HTTP / 1.1 [RFC7230]で指定されています。
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スキームは、指定されたTLS [RFC5246]を使用して保証されたデータ整合性と交渉可能なデータプライバシーをサポートするように拡張されたIPPを使用して、セキュアIPPプリンターにアクセスする必要があるアプリケーションによって使用されることを目的としていますHTTP / 1.1 [RFC7230]。このようなアプリケーションには、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（ほとんどのUNIX、Linux、およびApple OS Xシステム）は、このドキュメントの公開前の数年間、「ipps」URIをサポートしてきました。 PWG "IPP Everywhere" [PWG5100.14]（IPPセキュアモバイル印刷拡張）では、必須のデータ整合性と交渉可能なデータの機密性のために「ipps」URIを使用する必要があります。
Security Considerations: See Section 6 of RFC 7472.
セキュリティに関する考慮事項：RFC 7472のセクション6をご覧ください。
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.
参照：RFC 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]で定義されている「job-originating-user-name」ジョブメタデータなどのプライバシー機密情報を抽出します。
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-authentication-supported」）で定義されている「証明書」）。
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 Get-Printer-Attributes操作を直接送信する必要があります（SHOULD）。読んだ
"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.
「printer-uri-supported」、「uri-authentication-supported」、および「uri-security-supported」属性。サポートされている各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]（およびセキュリティのベストプラクティスと「ipps」URIスキームの既存のすべてのデプロイメント）に従って、この仕様をサポートするIPPクライアントとIPPプリンターはTLS / 1.2 [RFC5246]を使用する必要があります。すべての「ipps」セキュアトランスポート層接続用の上位バージョン。
Implementors will find useful advice in the "Recommendations for Secure Use of TLS and DTLS" [TLSBCP].
実装者は、「TLSとDTLSの安全な使用に関する推奨事項」[TLSBCP]に役立つアドバイスがあります。
[ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ASCII] American National Standards Institute、「Coded Character Set-7-bit American Standard Code for Information Interchange」、ANSI X3.4、1986。
[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] 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.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG 5100.14, January 2013, <http://www.pwg.org/standards.html>.
[PWG5100.14]マクドナルド、I。およびM.スウィート、「PWG IPP Everywhere」、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.、and J. Wenn、 "Internet Printing Protocol / 1.1：Encoding and Transport"、RFC 2910、September 2000、< 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] 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>。
[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、「The Transport Layer Security（TLS）Protocol Version 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。、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>。
[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。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content"、RFC 7231、June 2014、<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 3629、2003年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、「Uniform Resource Identifier（URI）：Generic Syntax」、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] Apple、「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] Internet Assigned Numbers Authority（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] Internet Assigned Numbers Authority（IANA）レジストリ、「Service Name and Transport Protocol Port Number Registry」、<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 FaxOut Service」、PWG 5100.15、2014年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 Scan Service」、PWG 5100.17、2014年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。、「Transmission Control Protocol」、STD 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。、「ラインプリンターデーモンプロトコル」、RFC 1179、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、「Internet Printing Protocol / 1.0：Model and Semantics」、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.、and J. Martin、 "Mapping between LPD and IPP Protocols"、RFC 2569、April 1999、<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、「Upgrading to TLS within HTTP / 1.1」、RFC 2817、2000年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] Hastings、T.、Manros、C.、Zehler、P.、Kugler、C。、およびH. Holst、「Internet Printing Protocol / 1.1：Implementor's Guide」、RFC 3196、2001年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、「Internet Printing Protocol / 1.1：IPP URL Scheme」、RFC 3510、2003年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]フレミング、P。およびI.マクドナルド、「Lightweight Directory Access Protocol（LDAP）：Schema for Printer Services」、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およびDTLSの安全な使用に関する推奨事項」、作業中、draft-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.
このドキュメントは、ベンダー中立のクライアントソフトウェアを使用した安全なモバイル印刷のためのPWG IPP Everywhere [PWG5100.14]プロジェクトの一環として、IEEE-ISTOプリンターワーキンググループのインターネット印刷プロトコルワーキンググループによってIETFに提出されました。
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トランスポートバインディングを定義しますが、このドキュメントは更新または廃止されません[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.
Claudio Allochio、Jari Arrko、Spencer Dawkins、Adrian Farrel、Tom Hastings、Bjoern Hoerhmann、Smith Kennedy、Graham Klyne、Barry Leiba、S。Moonesamy、Cathleen Moriarty、Sandra Murphy、Tom Petch、Pete Resnick、Benson Schliesser、Robert Sparksに感謝、Jerry Thrasher、Mykyta Yevstifeyev、Pete Zehler、およびIEEE-ISTO PWG IPP WGのメンバー。
Authors' Addresses
著者のアドレス
Ira McDonald High North, Inc. 221 Ridge Ave Grand Marais, MI 49839 United States
Ira McDonald High North、Inc. 221 Ridge Ave Grand Marais、MI 49839アメリカ
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、M / S 111-HOMC Cupertino、CA 95014アメリカ合衆国
EMail: msweet@apple.com