[要約] RFC 3997は、IPP通知の要件について説明しており、IPPプロトコルの拡張機能としての通知機能を提供することを目的としています。
Network Working Group T. Hastings, Ed.
Request for Comments: 3997 Xerox Corporation
Category: Informational R. K. deBry
Utah Valley State College
H. Lewis
IBM Corporation
March 2005
Internet Printing Protocol (IPP): Requirements for IPP Notifications
インターネット印刷プロトコル（IPP）：IPP通知の要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service.
このドキュメントは、インターネット印刷プロトコル（IPP）のすべての側面を一緒に説明する一連のドキュメントの1つです。IPPは、インターネット上での分散印刷に使用できるアプリケーションレベルのプロトコルです。IPPには複数の部品がありますが、主要なアーキテクチャコンポーネントはモデル、プロトコル、ディレクトリサービスへのインターフェイスです。このドキュメントは、IPPサービスのオプションの部分としての通知の要件のステートメントを提供します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations for IPP Notifications Requirements. . 12
6. Internationalization Considerations . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References. . . . . . . . . . . . . . . . . . 14
8.2. Informative References. . . . . . . . . . . . . . . . . 14
9. Appendix A: Description of the Base IPP Documents . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service. See section 10 for a description of the base IPP documents.
このドキュメントは、インターネット印刷プロトコル（IPP）のすべての側面を一緒に説明する一連のドキュメントの1つです。IPPは、インターネット上での分散印刷に使用できるアプリケーションレベルのプロトコルです。IPPには複数の部品がありますが、主要なアーキテクチャコンポーネントはモデル、プロトコル、ディレクトリサービスへのインターフェイスです。このドキュメントは、IPPサービスのオプションの部分としての通知の要件のステートメントを提供します。ベースIPPドキュメントの説明については、セクション10を参照してください。
The scope of this requirements document covers functionality used by the following kinds of IPP Users: End Users, Print Administrators, and Operators. See [RFC3995] for the extensions to the Internet Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911], [RFC2910], and future versions.
この要件の範囲は、次の種類のIPPユーザーが使用する機能をカバーしています：エンドユーザー、印刷管理者、オペレーター。インターネット印刷プロトコル/1.0（IPP）[RFC2565]、[RFC2566]、IPP/1.1 [RFC2911]、[RFC2910]、および将来のバージョンについては、[RFC3995]を参照してください。
It is necessary to define a set of terms to be able to clearly express the requirements for notification services in an IPP System.
IPPシステムで通知サービスの要件を明確に表現できるように、一連の用語を定義する必要があります。
A human end user who submits a print job to an IPP Printer. This person may or may not be within the same security domain as the Printer. This person may or may not be geographically near the printer.
印刷ジョブをIPPプリンターに提出する人間のエンドユーザー。この人は、プリンターと同じセキュリティドメイン内にいる場合とそうでない場合があります。この人は、プリンターの近くに地理的にある場合とそうでない場合があります。
A human user who established policy for and configures the print system.
印刷システムのポリシーを確立し、構成する人間のユーザー。
A human user who carries out the policy established by the Administrator and controls the day-to-day running of the print system.
管理者によって確立されたポリシーを実行し、印刷システムの日々の実行を管理する人間のユーザー。
An application (for example, a batch application), acting on behalf of a Job Submitting End User, that submits a print job to an IPP Printer. The application may or may not be within the same security domain as the Printer. This application may or may not be geographically near the printer.
エンドユーザーを提出するジョブに代わって行動するアプリケーション（たとえば、バッチアプリケーション）は、印刷ジョブをIPPプリンターに提出します。アプリケーションは、プリンターと同じセキュリティドメイン内にある場合とそうでない場合があります。このアプリケーションは、プリンターの近くに地理的にある場合とそうでない場合があります。
For the purposes of this discussion, the set of network components that can communicate without going through a proxy or firewall. A security domain may be geographically very large; for example, anywhere within example.com.
この議論の目的のために、プロキシやファイアウォールを通過せずに通信できるネットワークコンポーネントのセット。セキュリティドメインは地理的に非常に大きい場合があります。たとえば、example.comのどこかに。
The software component that sends IPP requests to an IPP Printer object and accepts IPP responses from an IPP Printer.
IPPリクエストをIPPプリンターオブジェクトに送信するソフトウェアコンポーネントは、IPPプリンターからIPP応答を受け入れます。
A human who is the ultimate consumer of the print job. In many cases this will be the same person as the Job-Submitting End User, but this need not always be the case. For example, if I use IPP to print a document on a printer in a business partner's office, I am the Job-Submitting End User, and the person whom I intend the document for in my business partner's office is the Job Recipient. Since one of the goals of IPP is to be able to print near the Job Recipient, we would normally expect that person to be in the same security domain as, and geographically near, the Printer. However, this may not always be the case. For example, I submit a print job across the Internet to a XYZ's print shop. I am both the Submitting End User and the Job Recipient, but I am neither near nor in the same security domain as the Printer.
印刷の仕事の究極の消費者である人間。多くの場合、これはジョブを担当するエンドユーザーと同じ人物になりますが、これが必ずしもそうであるとは限りません。たとえば、IPPを使用してビジネスパートナーのオフィスのプリンターにドキュメントを印刷すると、私は求人的なエンドユーザーであり、ビジネスパートナーのオフィスでドキュメントを意図している人は仕事の受信者です。IPPの目標の1つは、ジョブの受信者の近くで印刷できることであるため、通常、その人がプリンターと同じセキュリティドメインと地理的に近くにいることを期待します。ただし、これは必ずしもそうであるとは限りません。たとえば、インターネットを越えて印刷ジョブをXYZのプリントショップに提出します。私は提出したエンドユーザーとジョブの受信者の両方ですが、プリンターと同じセキュリティドメインに近いものでもありません。
A person acting on behalf of the Job Recipient. The Job Recipient Proxy physically picks up the printed document from the Printer if the Job Recipient cannot do so. The Proxy is by definition geographically near and in the same security domain as the printer. For example, I submit a print job from home to be printed on a printer at work. I'd like my secretary to pick up the print job and put it on my desk. In this case, I am acting as both a Job-Submitting End User and a Job Recipient. My secretary is acting as a Job Recipient Proxy.
職務受信者に代わって行動する人。Job受信者のプロキシは、ジョブの受信者がそうすることができない場合、プリンターから印刷されたドキュメントを物理的に選択します。プロキシは、定義により地理的に近くで、プリンターと同じセキュリティドメインにあります。たとえば、自宅から印刷ジョブを提出して、職場のプリンターに印刷されます。秘書に印刷の仕事を手に入れて、それを私の机の上に置いてほしい。この場合、私はジョブを提出するエンドユーザーとジョブの受信者の両方として行動しています。私の秘書は仕事の受信者のプロキシとして行動しています。
A client that requests the IPP Printer to send Event Notifications to one or more Notification Recipients. A Notification Subscriber may be a Job-Submitting End User or an End User, an Operator, or an Administrator that is not submitting a job.
IPPプリンターに1つ以上の通知受信者にイベント通知を送信するクライアント。通知サブスクライバーは、ジョブを提出するエンドユーザーまたはエンドユーザー、オペレーター、またはジョブを提出していない管理者である場合があります。
The entity that sends Event Notifications.
イベント通知を送信するエンティティ。
The entity that receives IPP Notifications about Job and/or Printer events. A Notification Recipient may be a Job Submitting End User, a Job-Submitting Application, a Job Recipient, a Job Recipient Proxy, an Operator, an Administrator, etc., and his or her representative, log file, usage statistics-gathering application, or other active or passive entities.
ジョブおよび/またはプリンターイベントに関するIPP通知を受け取るエンティティ。通知受信者は、エンドユーザーを提出するジョブ、ジョブサブリットアプリケーション、ジョブ受信者、ジョブ受信者のプロキシ、オペレーター、管理者など、およびその代表者、ログファイル、使用法統計収集アプリケーション、または他のアクティブまたはパッシブエンティティ。
A program that receives Event Notifications on behalf of the Notification Recipient. The agent may take some action on behalf of the recipient, forward the notification to the recipient via some alternative means (for example, page the recipient), or queue the notification for later retrieval by the recipient.
通知受信者に代わってイベント通知を受信するプログラム。エージェントは、受信者に代わって何らかのアクションを実行したり、通知を受信者に転送したり（受信者のページなど）、受信者による後の検索の通知をキューにします。
An Event is an occurrence (either expected or unexpected) within the printing system of a change of state, condition, or configuration of a Job or Printer object.
イベントは、ジョブまたはプリンターオブジェクトの状態、状態、または構成の変更システム内での発生（予想または予期しない）です。
When an event occurs, an Event Notification is generated that fully describes the event (what the event was, where it occurred, when it occurred, etc.). Event Notifications are delivered to all the Notification Recipients that are subscribed to that Event, if any. The Event Notification is delivered to the address of the Notification Recipient by using the notification delivery method defined in the subscription. However, an Event Notification is sent ONLY if there is a corresponding subscription.
イベントが発生すると、イベントを完全に説明するイベント通知が生成されます（イベントが何であるか、発生した場所、発生したときなど）。イベント通知は、そのイベントに購読されているすべての通知受信者に配信されます。イベント通知は、サブスクリプションで定義された通知配信方法を使用して、通知受信者のアドレスに配信されます。ただし、イベント通知は、対応するサブスクリプションがある場合にのみ送信されます。
A Notification Subscription is a request by a Notification Subscriber to the IPP Printer to send Event Notifications to specified Notification Recipient(s) when an event occurs.
通知サブスクリプションは、IPPプリンターへの通知サブスクライバーによる要求であり、イベントが発生したときに指定された通知受信者にイベント通知を送信します。
IPP Objects (for example, a print job) from which notification are being sent may have associated attributes. A user may want to have one or more of these returned along with a particular notification. In general, these may include any attribute associated with the object emitting the notification. Examples include the following:
通知が送信されているIPPオブジェクト（たとえば、印刷ジョブ）には関連する属性がある可能性があります。ユーザーは、特定の通知とともにこれらの1つ以上を返したい場合があります。一般に、これらには、通知を発するオブジェクトに関連付けられた属性が含まれる場合があります。例には、以下が含まれます。
number-of-intervening jobs job-k-octets job-k-octets processed job impressions job-impressions-interpreted job-impressions-completed impressionsCompletedCurrentCopy (job MIB) sheetCompletedCopyNumber (job MIB) sheetsCompletedDocumentNumber (job MIB) Copies-requested Copy-type Output-destination Job-state-reasons Job ID Printer URI Subscription ID (for job independent subscription)
インターブン数のジョブジョブK-OCTETSジョブK-OCTETS処理されたジョブインプレッションインプレッション - インプレッション - 完了したインプレットインプレッションコンプレットCURRENTCOPY（job mib）sheetcompletedcopynumber（jib）sheetscompleteddocumentnumbumb出力廃棄物のジョブステートリーズンズジョブIDプリンターURIサブスクリプションID（ジョブ独立サブスクリプション用）
Event Notifications are delivered by using a Delivery Method. An example of a Delivery Method is email.
イベント通知は、配信方法を使用して配信されます。配信方法の例はメールです。
Notifications sent to the Notification Recipient or the Notification Recipient's agent in such a way that the notification arrives immediately, within the limits of common addressing, routing, network congestion, and quality of service.
通知受信者または通知受信者のエージェントに送信された通知は、一般的なアドレス指定、ルーティング、ネットワーク輻輳、およびサービス品質の制限内で、通知がすぐに到着するようにします。
Notifications that are not necessarily delivered to Notification Recipients immediately but are queued for delivery by an intermediate network application, for later retrieval. Email is an example of a store-and-forward notification delivery method.
必ずしも通知受信者にすぐに配信されるわけではありませんが、後の検索のために、中間ネットワークアプリケーションによる配信のためにキューに留められます。電子メールは、ストアアンドフォワード通知配信方法の例です。
Notifications that are delivered by a reliable delivery of packets or character stream, with acknowledgement and retry, so that delivery of the notification is guaranteed within determinate time limits. For example, if the Notification Recipient has logged off and gone home for the day, an immediate notification cannot be guaranteed, even when sent over a reliable transport, because there is nothing there to catch it. Guaranteed delivery requires both store-and-forward notification and a reliable transport.
承認と再試行を伴うパケットまたは文字ストリームの信頼できる配信によって配信される通知。たとえば、通知の受信者がその日のためにログオフして家に帰った場合、信頼できる輸送機関で送られた場合でも、即時の通知を保証することはできません。保証された配送には、店舗とフォワード通知と信頼できる輸送の両方が必要です。
Notifications are delivered via the fundamental transport address and routing framework, but no acknowledgement or retry is required. Process-to-process communications, if involved, are unconstrained.
通知は、基本的な輸送アドレスとルーティングフレームワークを介して配信されますが、承認または再試行は必要ありません。プロセス間通信は、関与している場合、制約されていません。
Notifications intended to be consumed by human end users only. Email would be an example of a Human-Consumable Notification, though it could also contain Machine-Consumable Notification.
人間のエンドユーザーのみが消費することを目的とした通知。電子メールは、人工通知の例になりますが、機械消費の通知も含まれている可能性があります。
Notifications that are intended for consumption by a program only, such as an IPP Client. Machine-Consumable Notifications may not contain human-readable information. Do we need both human and machine? Machine readable is intended for application-to-application only. The Notification Recipient could process the machine-readable Event Notification into human-readable format.
IPPクライアントなど、プログラムのみが消費することを目的とした通知。機械に適した通知には、人間が読むことができる情報が含まれていない場合があります。人間と機械の両方が必要ですか？Machine Readableは、アプリケーションとアプリケーションのみを目的としています。通知受信者は、マシン読み取り可能なイベント通知を人間の読み取り可能な形式に処理できます。
A mixed notification contains both Human-Consumable and Machine-Consumable information.
混合通知には、人が消費可能と機械消費性の両方の情報の両方が含まれています。
1. Sitting in my office, I submit a print job to the printer down the hall. I am in the same security domain as the printer and, of course, geographically near. I want to know immediately when my print job will be completed (or if there is a problem) because the document I am working on is urgent. I submit the print job with the following attributes:
1. 私のオフィスに座って、私はホールの下のプリンターに印刷の仕事を提出します。私はプリンターと同じセキュリティドメインにあり、もちろん地理的に近くにいます。私が取り組んでいるドキュメントが緊急であるため、印刷ジョブがいつ完了するか（または問題がある場合）をすぐに知りたいです。次の属性で印刷ジョブを提出します。
- Notification Recipient: Me - Notification Events: All - Notification Attributes: Job-state-reason - Notification Type: Immediate
- 通知受信者：私 - 通知イベント：すべて - 通知属性：ジョブステートリアン - 通知タイプ：即時
2. Working from home, I submit a print job to the same printer as in the previous example. However, I am not at work, I cannot physically get the print file or do anything with it. It can wait until I get to work this afternoon. However, I'd like my secretary to pick up the output and put it on my desk so that it doesn't get lost or misfiled. I'd also like a store-and-forward notification sent to my email so that when I get to work I can tell whether there was a problem with the print job. I submit a print job with the following attributes:
2. 自宅で作業して、前の例と同じプリンターに印刷ジョブを提出します。しかし、私は仕事をしていません、私は物理的に印刷ファイルを取得したり、それで何もすることはできません。今日の午後に仕事に取り掛かるまで待つことができます。ただし、秘書に出力を拾い、机に置いて、迷子になったり誤ったりしないようにしたいと思います。また、私の電子メールに送信されたストアとフォワードの通知が欲しいので、仕事に就いたら、印刷の仕事に問題があるかどうかがわかります。次の属性を含む印刷ジョブを提出します。
- Notification Recipient: My secretary - Notification Events: Print complete - Notification Type: Immediate
- 通知受信者：私の秘書 - 通知イベント：印刷完了 - 通知タイプ：即時
- Notification Recipient: Me - Notification Events: Print complete - Notification Attributes: Impressions completed - Notification Type: Store and forward
- 通知受信者：私 - 通知イベント：完了 - 通知属性：完了したインプレッション - 通知タイプ：ストアとフォワード
3. Sitting in my office, I submit a print job to a client at an engineering firm my company works with on a daily basis. The engineering firm is in Belgium. I would like my client to know when the print job is complete so that she can pick it up from the printer in her building. It is important that she review it right away and send her comments back to me. I submit the print job with the following attributes:
3. 私のオフィスに座って、私は私の会社が毎日働いているエンジニアリング会社のクライアントに印刷の仕事を提出します。エンジニアリング会社はベルギーにいます。彼女が建物のプリンターからそれを拾うことができるように、私のクライアントに印刷ジョブがいつ完成したかを知ってほしい。彼女がすぐにそれをレビューし、彼女のコメントを私に送ってくれることが重要です。次の属性で印刷ジョブを提出します。
- Notification Recipient: Client at engineering firm - Notification Events: Print complete - Notification Type: Immediate - Notification Language: French
- 通知受信者：エンジニアリング会社のクライアント - 通知イベント：完了 - 通知タイプ：即時通知言語：フランス語
4. From a hotel room, I send a print job to a Kinko's store in the town I am working in, in order to get a printed report for the meeting I am attending in the morning. As I'm going out to dinner after I get this job submitted, an immediate notification won't do me much good. However, I'd like to check in the morning before I drive to the Kinko's store to see whether the file has been printed. An email notification is sufficient for this purpose. I submit the print job with the following attributes:
4. ホテルの部屋から、私が働いている町のキンコの店に印刷の仕事を送ります。この仕事を提出した後、夕食に出かけるので、すぐに通知することであまり良いことはありません。ただし、キンコの店に車で行く前に、ファイルが印刷されているかどうかを確認する前に、朝にチェックインしたいと思います。この目的のために電子メール通知で十分です。次の属性で印刷ジョブを提出します。
- Notification Recipient: Me - Notification Events: Print complete - Notification Type: Store and forward
- 通知受信者：私 - 通知イベント：完了 - 通知タイプ：ストアとフォワード
5. I am printing a large, complex print file. I want to have some immediate feedback on the progress of the print job as it prints. I submit the print job with the following attributes:
5. 私は大きな複雑な印刷ファイルを印刷しています。印刷物が印刷されたときに、プリントジョブの進行について即座にフィードバックしたいと思います。次の属性で印刷ジョブを提出します。
- Notification Recipient: Me - Notification Type: Immediate - Notification Events: All state transitions - Notification Attributes: Impression completed
- 通知受信者：私 - 通知タイプ：即時 - 通知イベント：すべての州の移行 - 通知属性：印象が完了しました
6. I am an operator and one of my duties is to keep the printer running. I subscribe independently from a job submission so that my subscription outlasts any particular job. I subscribe with the following attributes:
6. 私はオペレーターであり、私の義務の1つは、プリンターを実行し続けることです。私は、サブスクリプションが特定の仕事よりも長持ちするように、求人の提出から独立して購読します。次の属性を登録します。
- Notification Recipient: Me - Notification Type: Immediate - Notification Events: All Printer state transitions - Notification Attributes: Printer state, printer state reasons, device powering up, device powering down
- 通知受信者：ME-通知タイプ：即時通知イベント：すべてのプリンター状態遷移 - 通知属性：プリンター状態、プリンター状態の理由、デバイスの電源を入れる、デバイスの電源
7. I am a usage statistics gathering application. I subscribe independently from a job submission so that my subscription outlasts any particular job. My subscription may persist across power cycles. I subscribe with the following attributes:
7. 私は、アプリケーションを収集する使用法統計です。私は、サブスクリプションが特定の仕事よりも長持ちするように、求人の提出から独立して購読します。私のサブスクリプションは、パワーサイクル全体で持続する場合があります。次の属性を登録します。
- Notification Recipient: Me - Notification Type: Immediate - Notification Events: Job completion - Notification Attributes: Impression completed, sheets completed, time submitted, time started, time completed, job owner, job size in octets, etc.
- 通知受信者：ME-通知タイプ：即時 - 通知イベント：ジョブの完了 - 通知属性：印象が完了し、シートが完了し、シートが提出された時間、時間の開始、時間が完了し、ジョブオーナー、オクテットのジョブサイズなど
8. I am a client application program that displays a list of jobs currently queued for printing on a printer. I display the "job-name", "job-state", "job-state-reasons", "page-count", and "intervening-jobs", either for the user's jobs or for all jobs. The window displaying the job list remains open for an independent amount of time, and it is desired that it represent the current state of the queue. It is desired that the application only perform a slow poll in order to recover from any missed notifications. So the event delivery mechanism provides the means to update the screen on all needed changes, including querying for some attributes that may not be delivered in the Notification.
8. 私は、プリンターに印刷するために現在キューになっているジョブのリストを表示するクライアントアプリケーションプログラムです。ユーザーのジョブまたはすべてのジョブのいずれかで、「ジョブ名」、「ジョブステート」、「ジョブステートレゾン」、「ジョブステートリゾン」、「ページカウント」、「介入ジョブ」を表示します。ジョブリストを表示するウィンドウは、独立した時間の間開いたままであり、キューの現在の状態を表すことが望まれます。逃した通知から回復するために、アプリケーションは遅い投票のみを実行することが望まれます。したがって、イベント配信メカニズムは、通知で提供されない可能性のあるいくつかの属性のクエリなど、必要なすべての変更について画面を更新する手段を提供します。
9. I am a client application program that displays a list of printers. For each Printer, I display the current state and configuration. The window displaying the printer list remains open for an independent amount of time, and it is desired that it represent the current state of each printer. It is desired that the application only need to perform a slow poll in order to recover from any missed notifications. So the event delivery mechanism provides the means to update the screen on all needed changes, including querying for some attributes that may not be delivered in the Notification.
9. 私は、プリンターのリストを表示するクライアントアプリケーションプログラムです。各プリンターについて、現在の状態と構成を表示します。プリンターリストを表示するウィンドウは、独立した時間の間開いたままであり、各プリンターの現在の状態を表すことが望まれます。見逃された通知から回復するために、アプリケーションは遅い投票を実行するだけであることが望まれます。したがって、イベント配信メカニズムは、通知で提供されない可能性のあるいくつかの属性のクエリなど、必要なすべての変更について画面を更新する手段を提供します。
10. I am an IPP Server that controls one or more devices and that implements an IPP Printer object to represent each device. I want to support IPP Notification for each of the IPP Printer objects that I implement. Many of these devices do not support notification (or IPP). So I need to support the IPP Notification semantics specified for each IPP Printer object myself on behalf of each of the devices that each of the IPP Printer objects represents. When I accept an IPP job creation requests, I convert it to what the device will accept. In some cases, I must poll the devices in order to be informed of their job and device state and state changes to be able to send IPP Notifications to subscribed Notification Recipients.
10. 私は、1つ以上のデバイスを制御するIPPサーバーであり、各デバイスを表すIPPプリンターオブジェクトを実装しています。実装するIPPプリンターオブジェクトごとにIPP通知をサポートしたいと思います。これらのデバイスの多くは、通知（またはIPP）をサポートしていません。そのため、各IPPプリンターオブジェクトが表す各デバイスに代わって、各IPPプリンターオブジェクトに指定されたIPP通知セマンティクスをサポートする必要があります。IPPの雇用作成リクエストを受け入れると、デバイスが受け入れるものに変換します。場合によっては、IPP通知を購読した通知受信者に送信できるように、彼らの仕事とデバイスの状態および状態の変更を通知するためにデバイスを投票する必要があります。
11. I am an IPP Server that controls one or more devices and that implements an IPP Printer object to represent each device. I want to support IPP Notification for each of the IPP Printer objects that I implement. These devices all support IPP, including IPP Notification. I would like the design choice for supporting IPP Notification for these objects either (1) by forwarding the notification to the IPP Printers that I, alone, control and have them send the notifications to the intended Notification Recipients without my involvement, or (2) by replacing the notification submitted with the Job to indicate me as the Notification Recipient; in turn I will forward Notifications to the Notification Recipients requested by my clients. Most of the rest of the contents of the IPP Job I send to the IPP Printers I control will be the same as those that I receive from my IPP clients.
11. 私は、1つ以上のデバイスを制御するIPPサーバーであり、各デバイスを表すIPPプリンターオブジェクトを実装しています。実装するIPPプリンターオブジェクトごとにIPP通知をサポートしたいと思います。これらのデバイスはすべて、IPP通知を含むIPPをサポートしています。これらのオブジェクトのIPP通知をサポートするための設計選択をご希望の場合（1）、IPPプリンターに通知を転送して、私だけで、私の関与なしに意図した通知受信者に通知を送信してもらうことをお勧めします。私を通知受信者として示すために、ジョブに送信された通知を交換することにより。次に、クライアントが要求した通知受信者に通知を転送します。私がコントロールするIPPプリンターに送信するIPPジョブの残りのコンテンツのほとんどは、IPPクライアントから受け取ったIPPプリンターと同じです。
12. I am an IPP Server that controls one or more devices and that implements an IPP Printer object to represent each device. I want to support IPP Notification for each of the IPP Printer objects that I implement. These devices all support IPP, including IPP Notification. Because these IPP Printers MAY also be controlled by other servers (using IPP or other protocols), I only want job events for the jobs that I send, but I do want Printer events all the time, so that I can show proper Printer state to my clients. So I subscribe to these IPP Printers for Printer events with a long-standing subscription, with myself as the Notification Recipient. When I get a Job Creation request, I decide to which IPP Printer to send the job. When I do so, I also add a job subscription for Job events, with me as the Notification Recipient to the job's job subscriptions supplied by my clients (this usage is called "piggybacking"). These IPP Printers automatically remove their job subscriptions when the job finishes, as for all job subscriptions, so that I no longer get Job events when my jobs are completed.
12. 私は、1つ以上のデバイスを制御するIPPサーバーであり、各デバイスを表すIPPプリンターオブジェクトを実装しています。実装するIPPプリンターオブジェクトごとにIPP通知をサポートしたいと思います。これらのデバイスはすべて、IPP通知を含むIPPをサポートしています。これらのIPPプリンターは他のサーバー（IPPまたは他のプロトコルを使用）によって制御される場合があるため、送信するジョブのジョブイベントのみが必要ですが、常にプリンターイベントが必要なので、適切なプリンター状態を表示できるように私のクライアント。そこで、私自身を通知受信者として、長年のサブスクリプションを備えたプリンターイベントのこれらのIPPプリンターを購読します。雇用創出のリクエストを受け取ったとき、私はどのIPPプリンターが仕事を送るかを決めます。私がそうするとき、私はジョブイベントのジョブサブスクリプションも追加します。私はクライアントが提供するジョブのジョブサブスクリプションの通知受信者として（この使用法は「ピギーバック」と呼ばれます）。これらのIPPプリンターは、すべてのジョブサブスクリプションと同様に、ジョブが終了したときにジョブサブスクリプションを自動的に削除するため、ジョブが完了したときにジョブイベントを取得できなくなります。
The following requirements are intended to be met by the IPP Notification specification (not the implementation). The following are true for the resulting IPP Notification Specification document:
以下の要件は、IPP通知仕様（実装ではなく）によって満たされることを目的としています。結果のIPP通知仕様文書には、以下が当てはまります。
1. It must indicate which of these requirements are REQUIRED and which are OPTIONAL for a conforming implementation to support. See [RFC2911], section 12.1, for the definition of these important conformance terms.
1. これらの要件のどれが必要かを示し、どの適合実装がサポートするためにオプションであるかを示す必要があります。これらの重要な適合用語の定義については、[RFC2911]、セクション12.1を参照してください。
2. It must be designed so that an IPP Printer can transparently support the IPP Notification semantics by using third-party notification services that exist today or that may be standardized in the future.
2. IPPプリンターが、今日存在する、または将来標準化される可能性のあるサードパーティ通知サービスを使用して、IPP通知セマンティクスを透過的にサポートできるように設計する必要があります。
3. It must define a means for a Job-Submitting End User to specify zero or more Notification Recipients when submitting a print job. A Submitter will not be able to prevent out-of-band subscriptions from authorized persons, such as Operators.
3. ジョブを提出するエンドユーザーが印刷ジョブを送信するときにゼロ以上の通知受信者を指定するための手段を定義する必要があります。提出者は、オペレーターなどの認定者から帯域外のサブスクリプションを防ぐことができません。
4. It must define a means, when specifying a Notification Recipient, for a Notification Subscriber to specify one or more notification events for that Notification Recipient, subject to administrative and security policy restrictions. Any of the following constitute Job or Printer Events for which a Job Submitting End User can specify that notifications be sent:
4. 通知受信者を指定する場合、通知サブスクライバーがその通知受信者の1つ以上の通知イベントを指定して、管理およびセキュリティポリシーの制限を条件として定義する必要があります。次のいずれかが、エンドユーザーを提出するジョブが通知を送信することを指定できるジョブまたはプリンターのイベントを構成します。
- Any standard Printer MIB alert - Job Received (transition from Unknown to Pending) - Job Started (transition from Pending to Processing) - Page Complete (page is stacked) - Collated Copy Complete (last sheet of collated copy is stacked)
- 任意の標準プリンターMIBアラート - 受信したジョブ（不明から保留中への移行） - ジョブの開始（保留から処理への移行） - ページComplete（ページが積み重ねられます） - 照合コピーコンプリート
- Job Complete (transition from Processing or Processing-stopped to Completed) - Job Aborted (transition from Pending, Pending-held, - Processing, or Processing-stopped to Aborted) - Job Canceled (transition from Pending, Pending-held, - Processing, or Processing-held to Canceled) - Other job state changes, such as paused, purged - Device problems for which the job is destined - Job (interpreter) issues
- ジョブの完了（処理または処理止めから完了までの移行） - ジョブが中止されました（保留中の、保留中の、処理、または処理止め止めされて停止して停止する） - ジョブはキャンセルされます（保留中、保留中の、処理、処理、処理、またはキャンセルするために処理する） - 一時停止、パージされた - ジョブが運命づけられているデバイスの問題など、その他のジョブ状態の変更 - ヨブ（インタープリター）の問題
5. It must define how an End User or Operator subscribes for
5. エンドユーザーまたはオペレーターがどのようにサブスクライブするかを定義する必要があります
- any set of Job Events for a specific job, or - any set of Printer Events while a specific job is not complete.
- 特定のジョブのための一連のジョブイベント、または - 特定のジョブが完了していないときにプリンターイベントのセット。
6. It must define how an End User or Operator subscribes for the following without having to submit a Job:
6. ジョブを提出することなく、エンドユーザーまたはオペレーターが以下をどのように購読するかを定義する必要があります。
- Any set of Printer Events for a defined period. - Any set of Job Events for all jobs, with no control over which jobs.
- 定義された期間の一連のプリンターイベント。 - すべてのジョブの職務イベントのセットは、どのジョブを制御できません。
7. It must define how the Notification Subscriber is able to specify either immediate or store-and-forward notification independently for each Notification Recipient. The means may be explicit, or implied by the method of delivery chosen by the Job Submitting End User.
7. 通知サブスクライバーが、各通知受信者に対して独立して即時またはストアアンドフォワード通知を指定する方法を定義する必要があります。手段は、エンドユーザーを提出するジョブによって選択された配信方法によって明示的であるか、暗示される場合があります。
8. It must define common delivery methods: e.g., email.
8. 一般的な配信方法を定義する必要があります。たとえば、電子メール。
9. It must define how an IPP Printer validates its ability to deliver an Event by using the specified delivery scheme. If it does not support the specified scheme, or if the specified scheme is invalid for some reason, then the IPP Printer accepts and performs the request anyway and indicates the unsupported attribute values. There is no requirement for the IPP Printer receiving the print request to validate the identity of a Notification Recipient, or the ability of the system to deliver an event to that recipient as requested (for example, if the Notification Recipient is not at work today).
9. 指定された配信スキームを使用して、IPPプリンターがイベントを配信する機能を検証する方法を定義する必要があります。指定されたスキームをサポートしていない場合、または指定されたスキームが何らかの理由で無効である場合、IPPプリンターはとにかくリクエストを受け入れて実行し、サポートされていない属性値を示します。IPPプリンターが通知受信者のIDを検証するための印刷要求を受信した場合、または要求に応じてその受信者にイベントを配信するシステムの能力（たとえば、通知受信者が今日機能していない場合）には要件はありません。。
10. It must define a class of IPP event notification delivery methods that can flow through corporate firewalls. However, an IPP printer need not test to guarantee delivery of the notification through a firewall before accepting a print job.
10. 企業のファイアウォールを流れる可能性のあるIPPイベント通知配信方法のクラスを定義する必要があります。ただし、IPPプリンターは、印刷ジョブを受け入れる前にファイアウォールを介して通知の配信を保証するためにテストする必要はありません。
11. It may define a means to deliver a notification to the submitting client when the delivery of an event notification to a specified Notification Recipient fails. A fallback means of subscribers to determine whether notifications have failed (i.e., polling) may be provided.
11. 指定された通知受信者へのイベント通知の配信が失敗したときに、送信クライアントに通知を配信する手段を定義する場合があります。通知が失敗したかどうか（つまり、ポーリング）が提供されるかどうかを判断するためのサブスクライバーのフォールバック手段。
12. It must define a mechanism for localizing Human-Consumable Notifications by the Notification Source.
12. 通知ソースによって人間化可能な通知をローカルするためのメカニズムを定義する必要があります。
13. It may define a way to specify whether event delivery requires acknowledgement back to the Notification Source.
13. イベント配信が通知ソースへの確認が必要かどうかを指定する方法を定義する場合があります。
14. There must be a mechanism defined so that job-independent subscriptions do not become stale and do not require human intervention to be removed. However, a subscription must not be deemed stale only if it is unable to deliver an Event Notification, as temporary Notification delivery problems must be tolerated.
14. ジョブに依存しないサブスクリプションが古くなくなり、人間の介入を削除する必要がないように、メカニズムが定義されている必要があります。ただし、一時的な通知配信の問題を許容する必要があるため、サブスクリプションはイベント通知を配信できない場合にのみ古くみなされてはなりません。
15. A mechanism must be defined so that an Event Subscriber is able to add an Event Subscription to a Job after the Job has been submitted.
15. イベントサブスクライバーがジョブが提出された後にイベントサブスクリプションをジョブに追加できるように、メカニズムを定義する必要があります。
16. A mechanism must be defined so that a client is able to cancel an Event Subscription on a job or printer after the job has been submitted.
16. ジョブが提出された後、クライアントがジョブまたはプリンターのイベントサブスクリプションをキャンセルできるように、メカニズムを定義する必要があります。
17. A mechanism must be defined so that a client can obtain the set of current Subscriptions.
17. クライアントが現在のサブスクリプションのセットを取得できるように、メカニズムを定義する必要があります。
By far the biggest security concern is the abuse of notification: sending unwanted notifications sent to third parties (i.e., spam). The problem is made worse by notification addresses that may be redistributed to multiple parties (e.g., mailing lists). Scenarios exist in which third-party notification is required (see scenarios 2 and 3). The fully secure solution would require active agreement of all recipients before anything is sent out. However, requirement 9 ("There is no requirement for an IPP Printer receiving the print request to validate the identity of an event recipient") argues against this. Certain systems may decide to disallow third-party notifications (a traditional fax model).
最大のセキュリティ上の懸念は、通知の濫用です。サードパーティ（つまり、SPAM）に送信された不要な通知を送信します。この問題は、複数の当事者に再配布される可能性のある通知アドレス（メーリングリストなど）によって悪化します。サードパーティの通知が必要なシナリオが存在します（シナリオ2および3を参照）。完全に安全なソリューションには、何かが送信される前に、すべての受信者の積極的な合意が必要になります。ただし、要件9（「イベント受信者のIDを検証するための印刷リクエストを受信するIPPプリンターには要件はありません」）はこれに反対しています。特定のシステムは、サードパーティ通知（従来のFAXモデル）を禁止することを決定する場合があります。
The same security issues are present when Clients submit notification requests to the IPP Printer as when they submit an IPP/1.1 print job request. The same mechanisms used by IPP/1.1 can therefore be used by the client notification submission. Operations that require authentication can use the HTTP authentication. Operations that require privacy can use the HTTP/TLS privacy.
クライアントがIPP/1.1の印刷ジョブリクエストを送信するときと同様に、クライアントがIPPプリンターに通知要求を送信する場合、同じセキュリティの問題が存在します。したがって、IPP/1.1で使用されるのと同じメカニズムは、クライアント通知の提出で使用できます。認証を必要とする操作は、HTTP認証を使用できます。プライバシーを必要とする運用は、HTTP/TLSプライバシーを使用できます。
The notification access control model should be similar to the IPP access control model. Creating a notification subscription is associated with a user. Only the creator or an operator can cancel the subscription. The system may limit the listing of items to items owned by the user. Some subscriptions (e.g., those that have a lifetime longer than a job) can be done only by privileged users (operators and/or administrators), if that is the authorization policy.
通知アクセス制御モデルは、IPPアクセス制御モデルに似ている必要があります。通知サブスクリプションの作成は、ユーザーに関連付けられています。作成者またはオペレーターのみがサブスクリプションをキャンセルできます。システムは、アイテムのリストをユーザーが所有するアイテムに制限する場合があります。一部のサブスクリプション（たとえば、ジョブよりも生涯長いものを持っているもの）は、承認ポリシーである場合、特権ユーザー（オペレーターおよび/または管理者）によってのみ行うことができます。
The standard security concerns (delivery to the right user, privacy of content, tamper-proof content) apply to the notification delivery. IPP should use the security mechanism of the delivery method used. Some delivery mechanisms are more secure than others. Therefore, sensitive notifications should use the delivery method that has the strongest security.
標準的なセキュリティの懸念（適切なユーザーへの配信、コンテンツのプライバシー、改ざんコンテンツ）は、通知配信に適用されます。IPPは、使用される配信方法のセキュリティメカニズムを使用する必要があります。一部の配信メカニズムは、他のメカニズムよりも安全です。したがって、機密通知は、最も強力なセキュリティを持つ配信方法を使用する必要があります。
The Human-Consumable Notification must be localized to the natural language and charset that Notification Subscriber specifies within the choice of natural languages and charsets that the IPP Printer supports.
人間に合った通知は、IPPプリンターがサポートする自然言語とcharセットの選択内で通知サブスクライバーが指定する自然言語とcharsetにローカライズする必要があります。
The Machine-Consumable Notification data uses the "application/ipp" MIME media type. It contains attributes whose text values are required to be in the natural language and charset that the Notification Subscriber specifies within the choice of natural languages and charsets that the IPP Printer supports. See [RFC2566].
マシンに適した通知データは、「アプリケーション/IPP」MIMEメディアタイプを使用します。これには、テキスト値が自然言語で必要である属性と、通知サブスクライバーがIPPプリンターがサポートする自然言語とcharセットの選択内で指定するcharsetを含んでいます。[RFC2566]を参照してください。
Some notification delivery methods have been registered with IANA for use in URLs. These will be defined in other documents.
一部の通知配信方法は、URLで使用するためにIANAに登録されています。これらは他のドキュメントで定義されます。
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[RFC2910] Herriot、R。、Butler、S.、Moore、P.、Turner、R。、およびJ. Wenn、「インターネット印刷プロトコル/1.1：エンコーディングとトランスポート」、RFC 2910、2000年9月。
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000.
[RFC2911] Hastings、T.、Herriot、R.、Debry、R.、Isaacson、S。、およびP. Powell、「インターネット印刷プロトコル/1.1：モデルとセマンティクス」、RFC 2911、2000年9月。
[RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", RFC 3995, March 2005.
[RFC3995] Herriot、R。およびT. Hastings、「インターネット印刷プロトコル（IPP）：イベント通知とサブスクリプション」、RFC 3995、2005年3月。
[RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565] Herriot、R。、Butler、S.、Moore、P。、およびR. Turner、「インターネット印刷プロトコル/1.0：エンコーディングとトランスポート」、RFC 2565、1999年4月。
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2566] Debry、R.、Hastings、T.、Herriot、R.、Isaacson、S。、およびP. Powell、「インターネット印刷プロトコル/1.0：モデルとセマンティクス」、RFC 2566、1999年4月。
[RFC2567] Wright, F., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567] Wright、F。、「インターネット印刷プロトコルの設計目標」、RFC 2567、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2568] Zilles、S。、「インターネット印刷プロトコルのモデルとプロトコルの構造の理論的根拠」、RFC 2568、1999年4月。
[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月。
[RFC2639] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, "Internet Printing Protocol/1.1: Implementor's Guide", RFC 3196, November 2001.
[RFC2639] Hastings、T.、Manros、C.、Zehler、P.、Kugler、C。、およびH. Holst、「インターネット印刷プロトコル/1.1：実装ガイド」、RFC 3196、2001年11月。
The base set of IPP documents includes the following:
IPPドキュメントのベースセットには、次のものが含まれています。
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
Mapping between LPD and IPP Protocols [RFC2569]
"Design Goals for an Internet Printing Protocol" takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end-user requirements that are satisfied in IPP/1.0 [RFC2566], [RFC2565]. A few OPTIONAL operator operations have been added to IPP/1.1 [RFC2911], [RFC2910].
「インターネット印刷プロトコルの設計目標」は、分散した印刷機能を幅広く見ています。また、インターネットの印刷プロトコルに含める必要がある機能を明確にするのに役立つ実生活のシナリオを列挙します。エンドユーザー、オペレーター、および管理者の3種類のユーザーの要件を特定します。IPP/1.0 [RFC2566]、[RFC2565]で満たされるエンドユーザー要件のサブセットを呼び出します。IPP/1.1 [RFC2911]、[RFC2910]にいくつかのオプションのオペレーター操作が追加されています。
"Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" describes IPP from a high-level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF IPP working group's major decisions.
「インターネット印刷プロトコルの構造とモデル、およびプロトコルの根拠」は、高レベルのビューからのIPPを説明し、IPP仕様ドキュメントのスイートを形成するさまざまなドキュメントのロードマップを定義し、IETF IPPの背景と根拠を提供しますグループの主要な決定。
"Internet Printing Protocol/1.1: Model and Semantics" describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses security, internationalization, and directory issues.
「インターネット印刷プロトコル/1.1：モデルとセマンティクス」は、抽象的なオブジェクト、属性、および操作を備えた簡略化されたモデルについて説明しています。このモデルは、プリンターとジョブを紹介します。ジョブは、ジョブあたりの複数のドキュメントをサポートしています。モデルドキュメントは、セキュリティ、国際化、およびディレクトリの問題にも対応しています。
"Internet Printing Protocol/1.1: Encoding and Transport" is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It also defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines the "ipp" scheme for identifying IPP printers and jobs.
「インターネット印刷プロトコル/1.1：エンコードとトランスポート」は、モデルドキュメントで定義されている抽象操作とhttp/1.1 [RFC2616]に定義されている属性の正式なマッピングです。また、「Application/IPP」と呼ばれる新しいインターネットMIMEメディアタイプのエンコーディングルールを定義します。このドキュメントでは、コンテンツタイプが「アプリケーション/IPP」であるメッセージ本文をHTTPで輸送するためのルールも定義しています。このドキュメントでは、IPPプリンターとジョブを識別するための「IPP」スキームを定義します。
"Internet Printing Protocol/1.1: Implementer's Guide" gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
「インターネット印刷プロトコル/1.1：実装者ガイド」は、IPPクライアントとIPPオブジェクトの実装者への洞察とアドバイスを提供します。IPP/1.1と、クライアントおよび/またはIPPオブジェクトの実装の設計に役立つ可能性のある考慮事項の一部を理解するのに役立つことを目的としています。たとえば、エラーチェックを含む、処理リクエストの典型的な順序が与えられます。仕様決定のいくつかの動機も含まれています。
"Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon ) implementations.
「LPDとIPPプロトコル間のマッピング」は、IPPとLPD（Line Printer Daemon）の実装の間のゲートウェイの実装者にアドバイスを提供します。
Authors' Addresses
著者のアドレス
Tom Hastings (editor) Xerox Corporation 701 S Aviation Blvd, ESAE 242 El Segundo, CA 90245
Tom Hastings（編集者）Xerox Corporation 701 S Aviation Blvd、ESAE 242 El Segundo、CA 90245
Phone: 310-333-6413 Fax: 310-333-6342 EMail: hastings@cp10.es.xerox.com
電話：310-333-6413ファックス：310-333-6342メール：hastings@cp10.es.xerox.com
Roger deBry Utah Valley State College
ロジャー・デブリー・ユタ・バレー州立大学
Phone: (801) 863-8848 EMail: debryro@uvsc.edu
電話：（801）863-8848メール：debryro@uvsc.edu
Harry Lewis IBM Corporation 6300 Diagonal Hwy Boulder, CO 80301
ハリー・ルイスIBMコーポレーション6300斜めのハイウェイボルダー、CO 80301
Phone: (303) 924-5337 EMail: harryl@us.ibm.com
電話：（303）924-5337メール：harryl@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。