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
        

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.

著作権(C)インターネット協会(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(ユニフォームリソースロケータ)方式を定義します。このメモはIPP / 1.1を更新:RFC 2910アン「IPP」URLのセクション5、「IPP URLスキーム」を拡充し、明確化することにより符号化及びトランスポート(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の概要については、[RFC3196]の "はじめに"、[RFC2911]とセクション1の、セクション1、 "はじめに" を参照してください。セクション10を参照して、IPP文書セットの完全な説明については、[RFC3196]の「ベース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.

このメモはIPP / 1.1を更新:エンコーディングおよびトランスポート(RFC 2910)、拡大・明確化第5節を、「IPP URLスキーム」は、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スキームは順番にURIジェネリック構文[RFC2396]、さらに[RFC2732]でIPv6の更新に由来するHTTP [RFC2616]で定義されたHTTP URLスキームのためのABNFに基づいています。 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)は、([RFC2717]のセクション6.0を参照)IPP URLスキームのために完成した登録テンプレートです。

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.
        
2.2. Model Terminology
2.2. モデルの用語

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

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

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.
        

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 Printerオブジェクトは、」「IPPクライアント」からIPPプロトコル[RFC2910]を介して印刷ジョブおよび/またはプリンタ/ジョブ操作を受け付ける(一部のハードウェアプラットフォーム上で)ソフトウェアを意味します。

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

この文書では、「IPPプリンタは、」「IPP Printerオブジェクト」の同義語です。

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は、"(この文書のセクション4で、 "IPP URLスキーム") "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.
        

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].
        

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.
        

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

参照:IANA MIMEメディアタイプレジストリ[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.
        
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]).
        

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は常にコロンスキーム名で開始する必要があります。 [RFC2396]:URLの構文およびセマンティクスに関する明確な情報については、「一般的な構文とセマンティクスユニフォームリソース識別子(URI)」を参照してください。 [RFC2732]でIPv6用の更新として、この仕様は、[RFC2396]から「ホスト」、「ポート」、「腹筋_経路」、および「クエリ」の定義を採用しています。

The IPP URL scheme syntax in ABNF is as follows:

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

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

IPP-URL = "IPP:" "//" ホスト[ ":" ポート] [腹筋_経路の[ "?"クエリ]]

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プリントサービスに配置されている、と識別されるリソースのためのRequest-URIは「腹筋_経路」です。

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]).

「腹筋_経路は」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.

注意:リテラルIPv4またはIPv6アドレスがIPPのURLでは使用しないでください。

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の例を示し(例えば、「印刷ジョブ」要求メッセージの「プリンタ-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/ボブ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プリンタのいくつかは、同じホスト・システムを共有する場合でも、論理的に異なるIPPプリンタを参照することになります。 「ボブ」または「トラ」はIPPプリンタのいくつかのグループを表すかもしれないが「IRA」最後のパスコンポーネントは、二つの異なる物理プリンタデバイスを表すかもしれない(例えば、負荷バランシングスプーラ)。又は「ボブ」と「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

IPP://example.com IPP://example.com/~smith/printer IPP://example.com:631 /〜・スミス/プリンタ

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).

第一及び第二のIPP URLは上記ポート631(IPPためのIANA割り当てられたwell-knownポート)に解決されなければなりません。上記第二及び第三の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ジョブ(例えば、「印刷ジョブの応答メッセージの「仕事-URIの属性におけるプロトコル要素として使用される)のための整形式IPPのURLの例を示します。

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 '仕事-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」操作属性の値と「仕事-URI」属性の値との関係が対応する「印刷ジョブの応答で返されることは実装依存です。また、IPPモデルのセクション4.3.3「ジョブのプリンタ-URI」[RFC2911]は、ジョブオブジェクトの「ジョブのプリンタ-URI」属性状態:

"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."

「唯一のJobオブジェクトの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ジョブのURLを生成する必要があります、この仕様に準拠してIPPプリンタ(例えば、「印刷ジョブの応答では、「ジョブのuri」属性で)対応するIPPプリンタのURLを正確に一つのパスコンポーネントを追加することにより、(相互運用性のため) 。

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)用のwell-knownポートと同等に扱われなければならない与えられていないポート。

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

参照:セクション3.2.3、[RFC2616]で "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)のみのwell-knownポート631を割り当てIANAにそうでない場合には(存在する場合)または各所与IPPのURLで指定されたポートにIPPプロトコル接続を送らなければなりません。

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 URLは(例えば、「印刷ジョブの要求で「プリンタ-URI」操作属性での発信IPPプロトコル要求メッセージにおけるプロトコル要素として使用送らなければなりません)セクション4.5で指定されたABNFに準拠します、 " 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スキーム」の規則に従って、それらの対応するHTTPのURLフォームにIPP 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によって割り当てられたwell-knownポート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 URLは「、(例えば、「印刷ジョブの要求で「プリンタ-URI」操作属性)にセクション4.5で指定されたABNFに準拠する、着信IPPプロトコル要求メッセージにおけるプロトコル要素として使用受け入れるべきこのドキュメントの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)だけで、「ジョブのuri」属性で、例えば(発信IPPプロトコルの応答メッセージでプロトコル要素として使用するIPPのURLを送るべきであるセクション4.5で指定されたABNFに従わ「印刷ジョブの応答)、「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を生成する必要があります(例えば、相互運用性のために、対応するIPPプリンタのURL()に正確に一つのパスコンポーネントを追加することによって、「印刷ジョブの応答では、「ジョブの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 Schemeの仕様は、[RFC2910]と[RFC2911]に記載されているものを超えて、任意の追加のIANAの考慮事項を導入しません。

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

参照:第6節は、[RFC2910]の "IANAの考慮事項" を参照してください:第6節、[RFC2911]の "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 Schemeの仕様は、[RFC2910]と[RFC2911]に記載されているものを超えて、任意の追加的な国際化の考慮事項を導入しません。

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

参照:セクション7、[RFC2910]で "国際化に関する注意事項"、。参照:セクション7、[RFC2911]で "国際化に関する注意事項"、。

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 Schemeの仕様は以下を除いて、[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は、このように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ゲートウェイへの(例えば、IPP [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-認証サポート」を、指定するパラメータはありません。

[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セキュリティサポート" で定義されたセキュリティメカニズム(例えば、 '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パラメータの追加に与えられました。もともとIPPプロトコル[RFC2910]で定義されているようしかし、強いIETF IPPワーキンググループのコンセンサスに基づいて、どのパラメータがIPPの多く、現在出荷の実装との後方互換性のため、2000年9月に「IPP」URLスキームに追加されませんでした/ 1.1。

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

項目:第8、 "セキュリティの考慮事項"、[RFC2910]で。項目:第8、 "セキュリティの考慮事項"、[RFC2911]で。

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]クロッカー、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]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子(URI):一般的な構文"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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.

"URLの中にリテラルIPv6アドレスのフォーマット" [RFC2732] HindenとR.、大工、B.およびL. Masinter、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]エリオ、R.、バトラー、S.、ムーア、P.、ターナー、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]ヘイスティングス、T.、エリオ、R.、deBry、R.、イサクソン、S.およびP.パウエル、 "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/...

[MIMEREG IANA] IANA MIMEメディアタイプレジストリ。 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]エリオ、R.、ヘイスティングス、T.、ジェイコブズ、N.とJ.マーチン、 "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.キング、RFC 2717、1999年11月 "URLスキーム名の登録手順"。

[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]ヘイスティングズ、T.、Manros、C.、Zehler、P.、クーグラー、C.およびH.ホルスト、 "インターネット印刷プロトコル/ 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.

パット・フレミング(IBM)、トム・ヘイスティングス(ゼロックス)、ハリー・ルイス(IBM)、ヒューゴ・パーラ(ノベル)、ドン・ライト(レックスマーク)、およびIETF IPP WGのすべてのメンバーに感謝します。

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

第5節では、IPPプロトコルで "IPP URLスキーム"、[RFC2910]は、このIPP URL Schemeの仕様への主要な入力でした。

Appendix A - Registration of "ipp" URL Scheme

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

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

注意:以下の登録は、セクション5、IPPプロトコル[RFC2911]の "IPP URLスキーム" を、廃止します。

URL Scheme Name: ipp

URLスキーム名:IPP

URL Scheme Syntax:

URLスキーム構文:

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

IPP-URL = "IPP:" "//" ホスト[ ":" ポート] [腹筋_経路の[ "?"クエリ]]

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.

それらと同等のHTTP URLを行うようIPPのURLは、[RFC2396]エンコードを使用する必要があります。 「予約」と「安全でない」セット[RFC2396]のもの以外の文字は、その「」%「HEX HEX」符号化と等価です。

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印刷ジョブ送信要求)IPPプロトコル要求を送信するための指定されたプリントサービスへのHTTP接続を確立するために選択することができます。

Applications or Protocols which use this URL scheme:

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

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

参照:第5節、IPPプロトコル[RFC2910]で "IPP URLスキーム"、。

Interoperability Considerations:

相互運用性に関する注意事項:

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

項目:第9、 "IPPとの相互運用性/ 1.0の実装"、IPPプロトコル[RFC2910]で。

Security Considerations:

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

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

項目:第8、IPPプロトコル[RFC2910]で "セキュリティの考慮事項"、。

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]エリオ、R.、バトラー、S.、ムーア、P.、ターナー、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。

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

[RFC3510]エリオ、R.とI.マクドナルド、 "IPP / 1.1:IPP URLスキーム"、RFC 3510、2003年4月。

Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

Robert Herriot Consultant 706 Colorado Ave Palo Alto, CA 94303

コンサルタントロバート・ヘリオット706コロラドアベニューパロアルト、CA 94303

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

電話:+1 650-327-4466電子メール:bob@herriot.com

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

アイラマクドナルド高い北株式会社221リッジアベニューグランドマレー、MI 49839

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

電話:+1 906-494-2434電子メール:imcdonald@sharplabs.com

Authors' Addresses

著者のアドレス

Robert Herriot Consultant 706 Colorado Ave Palo Alto, CA 94303

コンサルタントロバート・ヘリオット706コロラドアベニューパロアルト、CA 94303

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

電話:+1 650-327-4466電子メール:bob@herriot.com

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

アイラマクドナルド高い北株式会社221リッジアベニューグランドマレー、MI 49839

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

電話:+1 906-494-2434電子メール: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

IPPのWebページ:http://www.pwg.org/ipp/ IPPメーリングリスト: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.

著作権(C)インターネット協会(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 Editor機能のための基金は現在、インターネット協会によって提供されます。