[要約] RFC 3510は、IPP URLスキームに関する仕様であり、インターネット印刷プロトコル(IPP)のバージョン1.1をサポートします。このRFCの目的は、IPPプリンターへのアクセスを容易にするために、標準化されたURLスキームを提供することです。

Network Working Group                                         R. Herriot
Request for Comments: 3510                                   I. McDonald
Updates: 2910                                            High North Inc.
Category: Standards Track                                     April 2003
        

Internet Printing Protocol/1.1: IPP URL Scheme

インターネット印刷プロトコル/1.1:IPP URLスキーム

Status of this Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の現在のエディションを参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2003). All Rights Reserved.

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

Abstract

概要

This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service.

このメモは、「IPP」URL(均一なリソースロケーター)スキームを定義します。このメモは、RFC 2910のセクション5「IPP URLスキーム」を拡張および明確にすることにより、IPP/1.1:エンコードとトランスポート(RFC 2910)を更新します。IPPプロトコル(RFC 2910)、またはそのような印刷サービスによって管理されるネットワークリソース(たとえば、印刷ジョブ)。

Table of Contents

目次

   1.  Introduction ...............................................  2
   2.  Terminology ................................................  3
       2.1.  Conformance Terminology ..............................  3
       2.2.  Model Terminology ....................................  3
   3.  IPP Model for Printers and Jobs ............................  3
   4.  IPP URL Scheme .............................................  4
       4.1.  IPP URL Scheme Applicability .........................  4
       4.2.  IPP URL Scheme Associated Port .......................  4
       4.3.  IPP URL Scheme Associated MIME Type ..................  5
       4.4.  IPP URL Scheme Character Encoding ....................  5
       4.5.  IPP URL Scheme Syntax ................................  5
       4.6.  IPP URL Examples .....................................  6
             4.6.1.  IPP Printer URL Examples .....................  6
             4.6.2.  IPP Job URL Examples .........................  6
       4.7.  IPP URL Comparisons ..................................  7
        
   5.  Conformance Requirements ...................................  8
       5.1.  IPP Client Conformance Requirements ..................  8
       5.2.  IPP Printer Conformance Requirements .................  8
   6.  IANA Considerations ........................................  9
   7.  Internationalization Considerations ........................  9
   8.  Security Considerations ....................................  9
   9.  Intellectual Property Rights ............................... 10
   10. Normative References ....................................... 11
   11. Informative References ..................................... 11
   12. Acknowledgments ............................................ 12
   Appendix A - Registration of "ipp" URL Scheme .................. 13
   Authors' Addresses ............................................. 15
   Full Copyright Statement ....................................... 16
        
1. Introduction
1. はじめに

This memo conforms to all of the requirements in Registration Procedures for URL Scheme Names [RFC2717]. This memo also follows all of the recommendations in Guidelines for new URL Schemes [RFC2718].

このメモは、URLスキーム名[RFC2717]の登録手順のすべての要件に準拠しています。このメモは、新しいURLスキームのガイドライン[RFC2718]のガイドラインのすべての推奨事項にも従います。

See section 1, "Introduction", of [RFC2911] and section 1, "Introduction", of [RFC3196] for overview information about IPP. See section 10, "Description of the Base IPP Documents", of [RFC3196] for a full description of the IPP document set.

IPPの概要情報については、[RFC2911]の[RFC2911]の[RFC2911]および[RFC3196]のセクション1「はじめに」を参照してください。IPPドキュメントセットの完全な説明については、[RFC3196]のセクション10「Base IPPドキュメントの説明」を参照してください。

This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910, but does not define any new parameters or other new extensions to the syntax of IPP URLs.

このメモは、RFC 2910のセクション5「IPP URLスキーム」を拡大および明確にすることにより、IPP/1.1:エンコードとトランスポート(RFC 2910)を更新しますが、IPP URLの構文に対する新しいパラメーターまたはその他の新しい拡張機能を定義しません。

The IPP URL scheme defined in this document is based on the ABNF for the HTTP URL scheme defined in HTTP [RFC2616], which in turn is derived from the URI Generic Syntax [RFC2396] and further updated for IPv6 by [RFC2732]. An IPP URL is transformed into an HTTP URL according to the rules specified in section 5 of IPP Protocol [RFC2910].

このドキュメントで定義されているIPP URLスキームは、HTTP [RFC2616]で定義されたHTTP URLスキームのABNFに基づいており、URIジェネリック構文[RFC2396]から派生し、[RFC2732]によってIPv6のためにさらに更新されます。IPP URLは、IPPプロトコル[RFC2910]のセクション5で指定されたルールに従って、HTTP URLに変換されます。

This document defines IPP URL scheme applicability, associated port (631), associated MIME type ("application/ipp"), character encoding, and syntax.

このドキュメントでは、IPP URLスキームのアプリケーション、関連するポート(631)、関連MIMEタイプ(「アプリケーション/IPP」)、文字エンコード、および構文を定義します。

This document is laid out as follows:

このドキュメントは次のようにレイアウトされています。

- Section 2 defines the terminology used throughout the document.

- セクション2では、ドキュメント全体で使用される用語を定義しています。

- Section 3 supplies references to the IPP Printer and IPP Job object model defined in IPP Model [RFC2911].

- セクション3は、IPPモデル[RFC2911]で定義されているIPPプリンターおよびIPPジョブオブジェクトモデルへの参照を提供します。

- Section 4 specifies the IPP URL scheme.

- セクション4は、IPP URLスキームを指定します。

- Section 5 specifies the conformance requirements for IPP Clients and IPP Printers that claim conformance to this document.

- セクション5では、このドキュメントへの適合を主張するIPPクライアントとIPPプリンターの適合要件を指定します。

- Sections 6, 7, and 8 specify IANA, internationalization, and security considerations.

- セクション6、7、および8は、IANA、国際化、およびセキュリティ上の考慮事項を指定します。

- Sections 9, 10, 11, 12, and 13 specify normative references, informative references, acknowledgements, authors' addresses, and full IETF copyright statement.

- セクション9、10、11、12、および13は、規範的参照、有益な参照、謝辞、著者のアドレス、および完全なIETF著作権ステートメントを指定します。

- Section 14 (Appendix A) is a completed registration template for the IPP URL Scheme (see section 6.0 of [RFC2717]).

- セクション14(付録A)は、IPP URLスキームの完了した登録テンプレートです([RFC2717]のセクション6.0を参照)。

2. Terminology
2. 用語

This specification document uses the terminology defined in this section.

この仕様文書では、このセクションで定義されている用語を使用します。

2.1. Conformance Terminology
2.1. 適合用語

The uppercase terms "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]. These terms are used to specify conformance requirements for all implementations (both print clients and print services) of this specification.

大文字の用語「必須」、「必須」、「必須」、「shall」、「 "" "" "ofs" "" ofs "of" obs "、" becommended "、" "、" optional "は、[RFC2119]で説明されているように解釈されます。これらの用語は、この仕様のすべての実装(印刷クライアントと印刷サービスの両方)の適合要件を指定するために使用されます。

2.2. Model Terminology
2.2. モデル用語

See section 12.2, "Model Terminology", in IPP Model [RFC2911].

IPPモデル[RFC2911]のセクション12.2「モデル用語」を参照してください。

3. IPP Model for Printers and Jobs
3. プリンターとジョブのIPPモデル

See section 2, "IPP Objects", section 2.1, "Printer Object", and section 2.2, "Job Object", in [RFC2911] for a full description of the IPP object model and terminology.

IPPオブジェクトモデルと用語の完全な説明については、セクション2、「IPPオブジェクト」、セクション2.1、「プリンターオブジェクト」、[RFC2911]のセクション2.2「ジョブオブジェクト」を参照してください。

In this document, "IPP Client" means the software (on some hardware platform) that submits, monitors, and/or manages print jobs via the IPP Protocol [RFC2910] to a print spooler, print gateway, or physical printing device.

このドキュメントでは、「IPPクライアント」とは、IPPプロトコル[RFC2910]を介して印刷ジョブを印刷スプーラー、印刷ゲートウェイ、または物理的な印刷デバイスに提出、モニター、および/または管理するソフトウェア(一部のハードウェアプラットフォーム)を意味します。

In this document, "IPP Printer object" means the software (on some hardware platform) that receives print jobs and/or printer/job operations via the IPP Protocol [RFC2910] from an "IPP Client".

このドキュメントでは、「IPPプリンターオブジェクト」とは、「IPPクライアント」からIPPプロトコル[RFC2910]を介して印刷ジョブおよび/またはプリンター/ジョブ操作を受信するソフトウェア(一部のハードウェアプラットフォーム)を意味します。

In this document, "IPP Printer" is a synonym for "IPP Printer object".

このドキュメントでは、「IPPプリンター」は「IPPプリンターオブジェクト」の同義語です。

In this document, "IPP Job object" means the set of attributes and documents for one print job instantiated on an "IPP Printer".

このドキュメントでは、「IPPジョブオブジェクト」とは、「IPPプリンター」にインスタンス化された1つの印刷ジョブの属性とドキュメントのセットを意味します。

In this document, "IPP Job" is a synonym for "IPP Job object".

このドキュメントでは、「IPPジョブ」は「IPPジョブオブジェクト」の同義語です。

In this document, "IPP URL" means a URL with the "ipp" scheme.

このドキュメントでは、「IPP URL」とは、「IPP」スキームを備えたURLを意味します。

Note: In this document, "IPP URL" is a synonym for "ipp-URL" (in section 4, "IPP URL Scheme", of this document) and "ipp-URL" (in section 5, "IPP URL Scheme", of [RFC2910]).

注:このドキュメントでは、「IPP URL」は「IPP-URL」(このドキュメントのセクション4、「IPP URLスキーム」)および「IPP-URL」(セクション5、「IPP URLスキーム」の同義語です。、[rfc2910])。

4. IPP URL Scheme
4. IPP URLスキーム
4.1. IPP URL Scheme Applicability
4.1. IPP URLスキームの適用性

The "ipp" URL scheme MUST only be used to specify absolute URLs (relative IPP URLs are not allowed) for IPP print services and their associated network resources. The "ipp" URL scheme MUST only be used to specify the use of the abstract protocol defined in IPP Model [RFC2911] over an HTTP [RFC2616] transport, as defined in IPP Protocol [RFC2910]. Any other transport binding for the abstract protocol defined in IPP Model [RFC2911] would require a different URL scheme.

「IPP」URLスキームは、IPPプリントサービスと関連するネットワークリソースの絶対URL(相対的なIPP URLは許可されていない)を指定するためにのみ使用する必要があります。「IPP」URLスキームは、IPPプロトコル[RFC2910]で定義されているように、HTTP [RFC2616]輸送を介してIPPモデル[RFC2911]で定義された抽象プロトコルの使用を指定するためにのみ使用する必要があります。IPPモデル[RFC2911]で定義されている抽象プロトコルのその他の輸送バインディングには、異なるURLスキームが必要です。

The "ipp" URL scheme allows an IPP client to choose an appropriate IPP print service (for example, from a directory). The IPP client can establish an HTTP connection to the specified IPP print service. The IPP client can send IPP protocol requests (for example, a "Print-Job" request) and receive IPP protocol responses over that HTTP connection.

「IPP」URLスキームにより、IPPクライアントは適切なIPP印刷サービス(たとえば、ディレクトリから)を選択できます。IPPクライアントは、指定されたIPP印刷サービスへのHTTP接続を確立できます。IPPクライアントは、IPPプロトコル要求(たとえば、「印刷」要求)を送信し、そのHTTP接続を介してIPPプロトコル応答を受信できます。

4.2. IPP URL Scheme Associated Port
4.2. IPP URLスキーム関連ポート

All IPP URLs which do NOT explicitly specify a port MUST be resolved to IANA-assigned well-known port 631, as registered in [IANA-PORTREG].

[IANA-PORTREG]に登録されているように、ポートを明示的に指定しないすべてのIPP URLは、IANAが割り当てられた有名なポート631に解決する必要があります。

See: IANA Port Numbers Registry [IANA-PORTREG]. See: IPP Protocol [RFC2910].

参照:IANAポート番号レジストリ[IANA-PORTREG]。参照:IPPプロトコル[RFC2910]。

4.3. IPP URL Scheme Associated MIME Type
4.3. IPP URLスキーム関連MIMEタイプに関連付けられています

All IPP URLs MUST be used to specify network print services which support the "application/ipp" MIME media type as registered in [IANA-MIMEREG] for IPP protocol requests and responses.

すべてのIPP URLを使用して、IPPプロトコル要求と応答のために[IANA-Mimereg]に登録されている「アプリケーション/IPP」MIMEメディアタイプをサポートするネットワーク印刷サービスを指定する必要があります。

See: IANA MIME Media Types Registry [IANA-MIMEREG]. See: IPP Protocol [RFC2910].

参照:Iana Mime Media Types Registry [Iana-Mimereg]。参照:IPPプロトコル[RFC2910]。

4.4. IPP URL Scheme Character Encoding
4.4. IPP URLスキーム文字エンコード

IPP URLs MUST use [RFC2396] encoding, as do their equivalent HTTP URLs. Characters other than those in the "reserved" and "unsafe" sets [RFC2396] are equivalent to their ""%" HEX HEX" encoding.

IPP URLは、同等のHTTP URLと同様に、[RFC2396]エンコードを使用する必要があります。「予約済み」および「安全でない」セットの文字以外の文字[RFC2396]は、「%」ヘックスヘックス "エンコードに相当します。

4.5. IPP URL Scheme Syntax
4.5. IPP URLスキーム構文

The abstract protocol defined in IPP Model [RFC2911] places a limit of 1023 octets (NOT characters) on the length of a URI (see section 4.1.5, "uri", in [RFC2911]).

IPPモデル[RFC2911]で定義されている要約プロトコルは、URIの長さに1023オクテット(文字ではなく)の制限を配置します([RFC2911]のセクション4.1.5「URI」を参照)。

Note: IPP Printers ought to be cautious about depending on URI lengths above 255 bytes, because some older client implementations might not properly support these lengths.

注:IPPプリンターは、255バイトを超えるURIの長さに応じて慎重になる必要があります。

IPP URLs MUST be represented in absolute form. Absolute URLs MUST always begin with a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics" [RFC2396]. This specification adopts the definitions of "host", "port", "abs_path", and "query" from [RFC2396], as updated for IPv6 by [RFC2732].

IPP URLは絶対的な形で表現する必要があります。絶対URLは、常にスキーム名から始まる必要があります。URL構文とセマンティクスに関する決定的な情報については、「ユニフォームリソース識別子(URI):ジェネリック構文とセマンティクス」[RFC2396]を参照してください。この仕様では、[RFC2732]によってIPv6のために更新されるように、[RFC2396]の「ホスト」、「ポート」、「ABS_PATH」、および「クエリ」の定義を採用しています。

The IPP URL scheme syntax in ABNF is as follows:

ABNFのIPP URLスキーム構文は次のとおりです。

   ipp-URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
        

If the port is empty or not given, port 631 is assumed. The semantics are that the identified resource (see section 5.1.2 of [RFC2616]) is located at the IPP print service listening for HTTP connections on that port of that host, and the Request-URI for the identified resource is 'abs_path'.

ポートが空であるか、与えられていない場合は、ポート631が想定されます。セマンティクスは、特定されたリソース([RFC2616]のセクション5.1.2を参照)は、そのホストのポートのHTTP接続をリスニングするIPPプリントサービスに配置され、特定されたリソースのリクエスト-URIは「ABS_PATH」です。

If the 'abs_path' is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (see section 5.1.2 of [RFC2616]).

「ABS_PATH」がURLに存在しない場合、リソースのリクエスト-URIとして使用する場合は「/」として指定する必要があります([RFC2616]のセクション5.1.2を参照)。

4.6. IPP URL Examples
4.6. IPP URLの例

Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in IPP URLs.

注:IPP URLSでは、文字通りのIPv4またはIPv6アドレスを使用しないでください。

4.6.1. IPP Printer URL Examples
4.6.1. IPPプリンターURLの例

The following are examples of well-formed IPP URLs for IPP Printers (for example, to be used as protocol elements in 'printer-uri' operation attributes of 'Print-Job' request messages):

以下は、IPPプリンター用のよく形成されたIPP URLの例です(たとえば、「Print-Job」リクエストメッセージの「プリンターURI」操作属性のプロトコル要素として使用される):

ipp://example.com ipp://example.com/printer ipp://example.com/printer/tiger ipp://example.com/printer/fox ipp://example.com/printer/tiger/bob ipp://example.com/printer/tiger/ira

ipp://example.com ipp://example.com/printer ipp://example.com/printer/tiger ipp://example.com/printer/fox ipp://example.com/printer/tiger/BOB IPP://example.com/printer/tiger/ira

Each of the above URLs are well-formed URLs for IPP Printers and each would reference a logically different IPP Printer, even though some of those IPP Printers might share the same host system. The 'bob' or 'ira' last path components might represent two different physical printer devices, while 'tiger' might represent some grouping of IPP Printers (for example, a load-balancing spooler). Or the 'bob' and 'ira' last path components might represent separate human recipients on the same physical printer device (for example, a physical printer supporting two job queues). In either case, both 'bob' and 'ira' would behave as different and independent IPP Printers.

上記の各URLは、IPPプリンター用のよく形成されたURLであり、それぞれが同じホストシステムを共有する場合でも、それぞれが論理的に異なるIPPプリンターを参照します。「ボブ」または「IRA」の最後のパスコンポーネントは、2つの異なる物理プリンターデバイスを表す場合がありますが、「Tiger」はIPPプリンターのグループ化(たとえば、負荷をかけるスプーラー)を表す場合があります。または、「ボブ」と「IRA」の最後のパスコンポーネントは、同じ物理プリンターデバイス上の個別の人間の受信者を表す場合があります(たとえば、2つのジョブキューをサポートする物理プリンター)。どちらの場合でも、「ボブ」と「IRA」の両方が、異なる独立したIPPプリンターとして動作します。

The following are examples of well-formed IPP URLs for IPP Printers with (optional) ports and paths:

以下は、(オプションの)ポートとパスを備えたIPPプリンター用のよく形成されたIPP URLの例です。

      ipp://example.com
      ipp://example.com/~smith/printer
      ipp://example.com:631/~smith/printer
        

The first and second IPP URLs above MUST be resolved to port 631 (IANA assigned well-known port for IPP). The second and third IPP URLs above are equivalent (see section 4.7 below).

上記の1番目と2番目のIPP URLは、ポート631に解決する必要があります(IANAはIPPに有名なポートを割り当てます)。上記の2番目と3番目のIPP URLは同等です(以下のセクション4.7を参照)。

4.6.2. IPP Job URL Examples
4.6.2. IPPジョブURLの例

The following are examples of well-formed IPP URLs for IPP Jobs (for example, to be used as protocol elements in 'job-uri' attributes of 'Print-Job' response messages):

以下は、IPPジョブ向けのよく形成されたIPP URLの例です(たとえば、「Print-Job」応答メッセージの「Job-uri」属性のプロトコル要素として使用される):

ipp://example.com/printer/123 ipp://example.com/printer/tiger/job123

ipp://example.com/printer/123 ipp://example.com/printer/tiger/job123

IPP Job URLs are valid and meaningful only until Job completion and possibly an implementation defined optional period of persistence after Job completion (see IPP Model [RFC2911]).

IPPジョブURLは、ジョブの完了までのみ有効で意味があり、おそらくジョブの完了後に実装がオプションの持続期間を定義した場合にのみ有効です(IPPモデル[RFC2911]を参照)。

Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states that:

あいまいに、IPPモデル[RFC2911]のセクション4.3.1「job-uri」は次のように述べています。

"the precise format of a Job URI is implementation dependent."

「URIのジョブの正確な形式は実装に依存しています。」

Thus, the relationship between the value of the "printer-uri" operation attribute used in a 'Print-Job' request and the value of the "job-uri" attribute returned in the corresponding 'Print-Job' response is implementation dependent. Also, section 4.3.3 'job-printer-uri' of IPP Model [RFC2911] states that the 'job-printer-uri' attribute of a Job object:

したがって、「プリントジョブ」要求で使用される「プリンターURI」操作属性の値と、対応する「印刷ジョブ」応答で返される「job-uri」属性の値との関係は、実装に依存します。また、IPPモデル[RFC2911]のセクション4.3.3「ジョブプリンター-RI」は、ジョブオブジェクトの「ジョブプリンター-RI」属性が

"permits a client to identify the Printer object that created this Job object when only the Job object's URI is available to the client."

「ジョブオブジェクトのURIのみがクライアントが利用できる場合、このジョブオブジェクトを作成したプリンターオブジェクトをクライアントに識別することができます。」

However, the above statement is false, because the transform from an IPP Job URL to the corresponding IPP Printer URL is unspecified in either IPP Model [RFC2911] or IPP Protocol [RFC2910].

ただし、上記のステートメントは偽です。なぜなら、IPPジョブURLから対応するIPPプリンターURLへの変換は、IPPモデル[RFC2911]またはIPPプロトコル[RFC2910]のいずれかで不明確であるためです。

IPP Printers that conform to this specification SHOULD only generate IPP Job URLs (for example, in the "job-uri" attribute in a 'Print-Job' response) by appending exactly one path component to the corresponding IPP Printer URL (for interoperability).

この仕様に準拠するIPPプリンターは、対応するIPPプリンターURLに正確に1つのパスコンポーネントを追加することにより、IPPジョブURL(たとえば、「Print-Job」応答の「ジョブURI」属性)のみを生成する必要があります(相互運用性のため)。

4.7. IPP URL Comparisons
4.7. IPP URL比較

When comparing two IPP URLs to decide if they match or not, an IPP Client MUST use the same rules as those defined for HTTP URI comparisons in [RFC2616], with the sole following exception:

2つのIPP URLを比較して一致するかどうかを決定する場合、IPPクライアントは[RFC2616]のHTTP URI比較で定義されたルールと同じルールを使用する必要があります。

- A port that is empty or not given MUST be treated as equivalent to the well-known port for that IPP URL (port 631);

- 空のポートまたは指定されていないポートは、そのIPP URL(ポート631)の有名なポートに相当するものとして扱わなければなりません。

See: Section 3.2.3, "URI Comparison", in [RFC2616].

参照:[RFC2616]のセクション3.2.3、「URI比較」。

5. Conformance Requirements
5. 適合要件
5.1. IPP Client Conformance Requirements
5.1. IPPクライアントの適合要件

IPP Clients that conform to this specification:

この仕様に準拠したIPPクライアント:

a) MUST only send IPP protocol connections to the port specified in each given IPP URL (if present) or otherwise to IANA assigned well-known port 631;

a) 指定された各IPP URL(存在する場合)で指定されたポートにIPPプロトコル接続を送信するか、有名なポート631を割り当てたIANAにその他の場合のみを送信する必要があります。

b) MUST only send IPP URLs used as protocol elements in outgoing IPP protocol request messages (for example, in the "printer-uri" operation attribute in a 'Print-Job' request) that conform to the ABNF specified in section 4.5, "IPP URL Scheme Syntax, of this document;

b) 発信IPPプロトコル要素メッセージ(たとえば、「プリントジョブ」要求の「プリンター-RI」操作属性などのプロトコル要素として使用されるIPP URLを送信する必要があります。このドキュメントのスキーム構文。

c) MUST only convert IPP URLs to their corresponding HTTP URL forms according to the rules in section 5, "IPP URL Scheme", in [RFC2910].

c) [RFC2910]のセクション5「IPP URLスキーム」のルールに従って、IPP URLを対応するHTTP URLフォームにのみ変換する必要があります。

5.2. IPP Printer Conformance Requirements
5.2. IPPプリンターの適合要件

IPP Printers that conform to this specification:

この仕様に準拠したIPPプリンター:

a) MUST listen for incoming IPP protocol connections on IANA-assigned well-known port 631, unless explicitly configured by system administrators or site policies;

a) システム管理者またはサイトポリシーによって明示的に構成されていない限り、IANAが割り当てられた有名なポート631で着信IPPプロトコル接続を聞く必要があります。

b) SHOULD NOT listen for incoming IPP protocol connections on any other port, unless explicitly configured by system administrators or site policies;

b) システム管理者またはサイトポリシーによって明示的に構成されていない限り、他のポートでIPPプロトコル接続を着信しないでください。

c) SHOULD only accept IPP URLs used as protocol elements in incoming IPP protocol request messages (for example, in the "printer-uri" operation attribute in a 'Print-Job' request) that conform to the ABNF specified in section 4.5, "IPP URL Scheme Syntax", of this document;

c) 受信IPPプロトコルリクエストメッセージ(たとえば、「プリントジョブ」要求の「プリントURI」操作属性の属性で)でプロトコル要素として使用されるIPP URLのみを受け入れる必要があります。このドキュメントのスキーム構文 "。

d) SHOULD only send IPP URLs used as protocol elements in outgoing IPP protocol response messages (for example, in the "job-uri" attribute in a 'Print-Job' response) that conform to the ABNF specified in section 4.5, "IPP URL Scheme Syntax", of this document;

d) 発信IPPプロトコル応答メッセージ(たとえば、「print-job」応答の「ジョブURI」属性)でプロトコル要素として使用されるIPP URLのみを送信する必要があります。このドキュメントの構文」。

e) SHOULD only generate IPP Job URLs (for example, in the "job-uri" attribute in a 'Print-Job' response) by appending exactly one path component to the corresponding IPP Printer URL (for interoperability);

e) 対応するIPPプリンターURLに正確に1つのパスコンポーネントを追加することにより、IPPジョブURL(たとえば、「Print-Job」応答の「ジョブURI」属性)のみを生成する必要があります(相互運用性のため)。

f) SHOULD NOT use literal IPv6 or IPv4 addresses in configured or locally generated IPP URLs.

f) 構成またはローカルで生成されたIPP URLでリテラルIPv6またはIPv4アドレスを使用しないでください。

6. IANA Considerations
6. IANAの考慮事項

This IPP URL Scheme specification does not introduce any additional IANA considerations, beyond those described in [RFC2910] and [RFC2911].

このIPP URLスキームの仕様では、[RFC2910]および[RFC2911]に記載されているものを超えて、追加のIANAに関する考慮事項は導入されません。

See: Section 6, "IANA Considerations" in [RFC2910] See: Section 6, "IANA Considerations" in [RFC2911].

参照:[RFC2910]のセクション6、「IANAの考慮事項」:[RFC2911]のセクション6、「IANA考慮事項」を参照してください。

7. Internationalization Considerations
7. 国際化の考慮事項

This IPP URL Scheme specification does not introduce any additional internationalization considerations, beyond those described in [RFC2910] and [RFC2911].

このIPP URLスキームの仕様では、[RFC2910]および[RFC2911]に記載されているものを超えて、追加の国際化に関する考慮事項は導入されません。

See: Section 7, "Internationalization Considerations", in [RFC2910]. See: Section 7, "Internationalization Considerations", in [RFC2911].

[RFC2910]のセクション7、「国際化に関する考慮事項」を参照してください。[RFC2911]のセクション7、「国際化に関する考慮事項」を参照してください。

8. Security Considerations
8. セキュリティに関する考慮事項

This IPP URL Scheme specification does not introduce any additional security considerations, beyond those described in [RFC2910] and [RFC2911], except the following:

このIPP URLスキームの仕様では、[RFC2910]および[RFC2911]に記載されているものを超えて、追加のセキュリティ上の考慮事項は導入されていません。

a) An IPP URL might be faked to point to a rogue IPP print service, thus collecting confidential document contents from IPP clients. Server authentication mechanisms and security mechanisms specified in the IPP Protocol [RFC2910] are sufficient to address this threat.

a) IPP URLは、Rogue IPPプリントサービスを指すために偽造される可能性があるため、IPPクライアントから機密文書のコンテンツを収集します。IPPプロトコル[RFC2910]で指定されているサーバー認証メカニズムとセキュリティメカニズムは、この脅威に対処するのに十分です。

b) An IPP URL might be used to access an IPP print service by an unauthorized IPP client. Client authentication mechanisms and security mechanisms specified in the IPP Protocol [RFC2910] are sufficient to address this threat.

b) IPP URLは、不正なIPPクライアントによるIPP印刷サービスにアクセスするために使用される場合があります。IPPプロトコル[RFC2910]で指定されたクライアント認証メカニズムとセキュリティメカニズムは、この脅威に対処するのに十分です。

c) An IPP URL might be used to access an IPP print service at a print protocol application layer gateway (for example, an IPP to LPD gateway [RFC2569]) causing silent compromise of IPP security mechanisms. There is no practical defense against this threat by a client system. System administrators should avoid such compromising configurations.

c) IPP URLは、印刷プロトコルアプリケーションレイヤーゲートウェイ(たとえば、IPPからLPDゲートウェイ[RFC2569]など)でIPPプリントサービスにアクセスするために使用される場合があります。クライアントシステムによるこの脅威に対する実際的な防御はありません。システム管理者は、そのような妥協する構成を回避する必要があります。

d) An IPP URL does not have parameters to specify the required client authentication mechanism (for example, 'certificate' as defined in section 4.4.2, "uri-authentication-supported", of IPP Model

d) IPP URLには、必要なクライアント認証メカニズムを指定するためのパラメーターがありません(たとえば、IPPモデルのセクション4.4.2「URI-Authentication-Supported」で定義されている「証明書」があります。

[RFC2911]) and required security mechanism (for example, 'tls' as defined in section 4.4.3, "uri-security-supported", of IPP Model [RFC2911]). Service discovery or directory protocols might be used to discover the required client authentication and security mechanisms associated with given IPP URLs.

[RFC2911])および必要なセキュリティメカニズム(たとえば、IPPモデル[RFC2911]のセクション4.4.3、「URI-Security-Supported」で定義されている「TLS」)。サービスの発見またはディレクトリプロトコルを使用して、指定されたIPP URLに関連する必要なクライアント認証とセキュリティメカニズムを発見する場合があります。

Historical Note: During the development of this document, consideration was given to the addition of standard IPP URL parameters for the client authentication and security mechanisms. However, based on a strong IETF IPP Working Group consensus, no parameters were added to the "ipp" URL scheme as originally defined in IPP Protocol [RFC2910] in September 2000, for reasons of backwards compatibility with the many currently shipping implementations of IPP/1.1.

履歴注:このドキュメントの開発中に、クライアント認証とセキュリティメカニズムの標準IPP URLパラメーターの追加を考慮しました。ただし、強力なIETF IPPワーキンググループのコンセンサスに基づいて、2000年9月にIPPプロトコル[RFC2910]で最初に定義された「IPP」URLスキームにパラメーターは追加されていません。1.1。

See: Section 8, "Security Considerations", in [RFC2910]. See: Section 8, "Security Considerations", in [RFC2911].

[RFC2910]のセクション8、「セキュリティ上の考慮事項」を参照してください。[RFC2911]のセクション8、「セキュリティ上の考慮事項」を参照してください。

9. Intellectual Property Rights
9. 知的財産権

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。

10. Normative References
10. 引用文献

[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[RFC2234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強:ABNF」、RFC 2234、1997年11月。

[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[RFC2396] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers(URI):Generic Syntax」、RFC 2396、1998年8月。

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "Hypertext Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。

[RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.

[RFC2732] Hinden、R.、Carpenter、B。and L. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。

[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn, "IPP/1.1 Encoding and Transport [IPP Protocol]", RFC 2910, September 2000.

[RFC2910] Herriot、R。、Butler、S.、Moore、P.、Turner、R。、およびJ. Wenn、「IPP/1.1エンコードと輸送[IPPプロトコル]」、RFC 2910、2000年9月。

[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P. Powell, "IPP/1.1 Model and Semantics [IPP Model]", RFC 2911, September 2000.

[RFC2911] Hastings、T.、Herriot、R.、Debry、R.、Isaacson、S。、およびP. Powell、「IPP/1.1モデルとセマンティクス[IPPモデル]」、RFC 2911、2000年9月。

[US-ASCII] Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.

[us-ascii]コード化された文字セット - 情報交換のための7ビットアメリカ標準コード、ANSI X3.4-1986。

11. Informative References
11. 参考引用

[IANA-MIMEREG] IANA MIME Media Types Registry. ftp://ftp.iana.org/in-notes/iana/assignments/media-types/...

[Iana-Mimereg] Iana Mime Mediaタイプレジストリ。ftp://ftp.iana.org/in-notes/iana/assignments/media-types/...

[IANA-PORTREG] IANA Port Numbers Registry. ftp://ftp.iana.org/in-notes/iana/assignments/port-numbers

[IANA-PORTREG] IANAポート番号レジストリ。ftp://ftp.iana.org/in-notes/iana/assignments/port-numbers

[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.

[RFC2569] Herriot、R.、Hastings、T.、Jacobs、N。およびJ. Martin、「LPDとIPPプロトコルのマッピング」、RFC 2569、1999年4月。

[RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", RFC 2717, November 1999.

[RFC2717] Petke、R。およびI. King、「URLスキーム名の登録手順」、RFC 2717、1999年11月。

[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.

[RFC2718] Masinter、L.、Alvestrand、H.、Zigmond、D。、およびR. Petke、「新しいURLスキームのガイドライン」、RFC 2718、1999年11月。

[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C. and H. Holst, "Internet Printing Protocol/1.1: Implementor's Guide", RFC 3196, November 2001.

[RFC3196] Hastings、T.、Manros、C.、Zehler、P.、Kugler、C。、およびH. Holst、「インターネット印刷プロトコル/1.1:実装ガイド」、RFC 3196、2001年11月。

12. Acknowledgments
12. 謝辞

This document is a product of the Internet Printing Protocol Working Group of the Internet Engineering Task Force (IETF).

このドキュメントは、インターネットエンジニアリングタスクフォース(IETF)のインターネット印刷プロトコルワーキンググループの製品です。

Thanks to Pat Fleming (IBM), Tom Hastings (Xerox), Harry Lewis (IBM), Hugo Parra (Novell), Don Wright (Lexmark), and all the members of the IETF IPP WG.

Pat Fleming(IBM)、Tom Hastings(Xerox)、Harry Lewis(IBM)、Hugo Parra(Novell)、Don Wright(Lexmark)、およびIETF IPP WGのすべてのメンバーに感謝します。

Section 5, "IPP URL Scheme", in IPP Protocol [RFC2910] was the primary input to this IPP URL Scheme specification.

IPPプロトコル[RFC2910]のセクション5「IPP URLスキーム」は、このIPP URLスキーム仕様への主要な入力でした。

Appendix A - Registration of "ipp" URL Scheme

付録A-「IPP」URLスキームの登録

Note: The following registration obsoletes section 5, "IPP URL Scheme", of IPP Protocol [RFC2911].

注:IPPプロトコル[RFC2911]の次の登録登録廃止セクション5「IPP URLスキーム」。

URL Scheme Name: ipp

URLスキーム名:IPP

URL Scheme Syntax:

URLスキーム構文:

      ipp-URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
        

Character Encoding Considerations:

考慮事項のキャラクターエンコード:

IPP URLs MUST use [RFC2396] encoding, as do their equivalent HTTP URLs. Characters other than those in the "reserved" and "unsafe" sets [RFC2396] are equivalent to their ""%" HEX HEX" encoding.

IPP URLは、同等のHTTP URLと同様に、[RFC2396]エンコードを使用する必要があります。「予約済み」および「安全でない」セットの文字以外の文字[RFC2396]は、「%」ヘックスヘックス "エンコードに相当します。

Intended Usage:

意図された使用法:

The intended usage of the "ipp" URL scheme is COMMON.

「IPP」URLスキームの意図された使用法は一般的です。

An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol [RFC2910], or of a network resource (for example, a print job) managed by such a print service. An IPP client can choose to establish an HTTP connection to the specified print service for transmission of IPP protocol requests (for example, IPP print job submission requests).

「IPP」URLは、IPPプロトコル[RFC2910]をサポートする印刷サービスのネットワーク位置を指定するために使用されます。IPPクライアントは、IPPプロトコルリクエストの送信のために指定された印刷サービスへのHTTP接続を確立することを選択できます(たとえば、IPP印刷ジョブ送信要求など)。

Applications or Protocols which use this URL scheme:

このURLスキームを使用するアプリケーションまたはプロトコル:

See: Section 5, "IPP URL Scheme", in IPP Protocol [RFC2910].

参照:IPPプロトコル[RFC2910]のセクション5、「IPP URLスキーム」。

Interoperability Considerations:

相互運用性の考慮事項:

See: Section 9, "Interoperability with IPP/1.0 Implementations", in IPP Protocol [RFC2910].

参照:IPPプロトコル[RFC2910]のセクション9、「IPP/1.0実装との相互運用性」。

Security Considerations:

セキュリティ上の考慮事項:

See: Section 8, "Security Considerations", in IPP Protocol [RFC2910].

参照:IPPプロトコル[RFC2910]のセクション8、「セキュリティ上の考慮事項」。

Relevant Publications:

関連する出版物:

[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn, "IPP/1.1 Encoding and Transport [IPP Protocol]", RFC 2910, September 2000.

[RFC2910] Herriot、R。、Butler、S.、Moore、P.、Turner、R。、およびJ. Wenn、「IPP/1.1エンコードと輸送[IPPプロトコル]」、RFC 2910、2000年9月。

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "Hypertext Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。

[RFC3510] Herriot, R. and I. McDonald, "IPP/1.1: IPP URL Scheme", RFC 3510, April 2003.

[RFC3510] Herriot、R。およびI. McDonald、「IPP/1.1:IPP URLスキーム」、RFC 3510、2003年4月。

Person & email address to contact for further information:

詳細については、連絡先への個人およびメールアドレス:

Robert Herriot Consultant 706 Colorado Ave Palo Alto, CA 94303

ロバートヘリオットコンサルタント706コロラドアベロパロアルト、カリフォルニア94303

   Phone: +1 650-327-4466
   EMail: bob@herriot.com
        

Ira McDonald High North Inc 221 Ridge Ave Grand Marais, MI 49839

Ira McDonald High North Inc 221 Ridge Ave Grand Marais、MI 49839

   Phone: +1 906-494-2434
   EMail: imcdonald@sharplabs.com
        

Authors' Addresses

著者のアドレス

Robert Herriot Consultant 706 Colorado Ave Palo Alto, CA 94303

ロバートヘリオットコンサルタント706コロラドアベロパロアルト、カリフォルニア94303

   Phone: +1 650-327-4466
   EMail: bob@herriot.com
        

Ira McDonald High North Inc 221 Ridge Ave Grand Marais, MI 49839

Ira McDonald High North Inc 221 Ridge Ave Grand Marais、MI 49839

   Phone: +1 906-494-2434
   EMail: imcdonald@sharplabs.com
        

Usage questions and comments on this IPP URL Scheme should be sent directly to the editors at their above addresses (and to the IPP mailing list, if you are a subscriber - see below).

このIPP URLスキームに関する使用の質問とコメントは、上記のアドレスの編集者に直接送信する必要があります(およびサブスクライバーの場合はIPPメーリングリストに - 以下を参照)。

   IPP Web Page:      http://www.pwg.org/ipp/
   IPP Mailing List:  ipp@pwg.org
        

To subscribe to the IPP mailing list, send the following email:

IPPメーリングリストを購読するには、次のメールを送信してください。

1) send it to majordomo@pwg.org

1) majordomo@pwg.orgに送信してください

2) leave the subject line blank

2) 件名を空白のままにします

3) put the following two lines in the message body: subscribe ipp

3) メッセージ本文に次の2行を置きます:ippを購読する

Implementers of this specification are encouraged to join the IPP Mailing List in order to participate in any discussions of clarification issues and comments. In order to reduce spam the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the IPP mailing list.

この仕様の実装者は、明確化の問題やコメントの議論に参加するために、IPPメーリングリストに参加することをお勧めします。スパムを削減するために、メーリングリストは非サブスクライダーからのメールを拒否するため、IPPメーリングリストに質問やコメントを送信するためにメーリングリストを購読する必要があります。

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。