Network Working Group R. Herriot
Request for Comments: 3996 Global Workflow Solutions
Updates: 2911 T. Hastings
Category: Standards Track Xerox Corp.
H. Lewis
IBM Corp.
March 2005
Internet Printing Protocol (IPP):
The 'ippget' Delivery Method for Event Notifications
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes an extension to the Internet Printing Protocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this document.
この文書は、インターネット印刷Protocol1.1の拡張について説明します。モデルとセマンティクス（RFC 2911、RFC 2910）。 「：イベント通知とサブスクリプションインターネット印刷プロトコル（IPP）」仕様（RFC 3995）この文書では、との使用のための「ippget」プル配信方法を指定します。このIPPGET配信方法は、クライアントとして機能し、通知の受信者のRFC 3995をサポートするすべてのクライアントおよびプリンターのためのフェッチを必要としている。この文書で定義されます。Get-通知操作を使用してイベント通知を（引きます）。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conformance Terminology . . . . . . . . . . . . . . . . 4
2.2. Other Terminology . . . . . . . . . . . . . . . . . . . 4
3. Model and Operation . . . . . . . . . . . . . . . . . . . . . 4
4. General Information . . . . . . . . . . . . . . . . . . . . . 5
5. Get-Notifications Operation . . . . . . . . . . . . . . . . . 7
5.1. Get-Notifications Request . . . . . . . . . . . . . . . 8
5.1.1. notify-subscription-ids (1setOf integer(1:MAX)) 8
5.1.2. notify-sequence-numbers (1setOf integer(1:MAX)) 9
5.1.3. notify-wait (boolean) . . . . . . . . . . . . . 10
5.2. Get-Notifications Response. . . . . . . . . . . . . . . 10
5.2.1. notify-get-interval (integer(0:MAX)). . . . . . 13
5.2.2. printer-up-time (integer(1:MAX)). . . . . . . . 14
6. Additional Information about Subscription Template Attributes 17
6.1. notify-pull-method (type2 keyword). . . . . . . . . . . 17
7. Subscription Description Attributes . . . . . . . . . . . . . 18
8. Additional Printer Description Attributes . . . . . . . . . . 18
8.1. ippget-event-life (integer(15:MAX)) . . . . . . . . . . 18
9. New Values for Existing Printer Description Attributes. . . . 19
9.1. notify-pull-method-supported (1setOf type2 keyword) . . 19
9.2. operations-supported (1setOf type2 enum). . . . . . . . 19
10. New Status Codes. . . . . . . . . . . . . . . . . . . . . . . 19
10.1. successful-ok-events-complete (0x0007) . . . . . . . . 20
11. Encoding and Transport. . . . . . . . . . . . . . . . . . . . 20
12. Conformance Requirements. . . . . . . . . . . . . . . . . . . 21
12.1. Conformance for IPP Printers . . . . . . . . . . . . . 21
12.2. Conformance for IPP Clients. . . . . . . . . . . . . . 22
13. Normative References. . . . . . . . . . . . . . . . . . . . . 23
14. Informative References. . . . . . . . . . . . . . . . . . . . 23
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
15.1. Attribute Registrations. . . . . . . . . . . . . . . . 24
15.2. Delivery Method and Additional Keyword Attribute Value
registrations for Existing Attributes. . . . . . . . . 24
15.3. Additional Enum Attribute Values . . . . . . . . . . . 25
15.4. Operation Registrations. . . . . . . . . . . . . . . . 25
15.5. Status Code Registrations. . . . . . . . . . . . . . . 25
16. Internationalization Considerations . . . . . . . . . . . . . 25
17. Security Considerations . . . . . . . . . . . . . . . . . . . 26
17.1. Notification Recipient Client Access Rights. . . . . . 26
17.2. Printer Security Threats . . . . . . . . . . . . . . . 27
17.3. Notification Recipient Security Threats. . . . . . . . 27
17.4. Security Requirements for Printers . . . . . . . . . . 27
17.5. Security Requirements for clients. . . . . . . . . . . 28
18. Description of Base IPP Documents (Informative) . . . . . . . 28
19. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 31
Table of Tables
テーブルの表
Table 1. Information about the Delivery Method. . . . . . . . . . 5
Table 2. Combinations of "notify-wait", "status-code", and
"notify-get-interval". . . . . . . . . . . . . . . . . . 13
Table 3. Attributes in Event Notification Content . . . . . . . . 15
Table 4. Additional Attributes in Event Notification Content for
Job Events . . . . . . . . . . . . . . . . . . . . . . . 16
Table 5. Combinations of Events and Subscribed Events for "job-
impressions-completed" . . . . . . . . . . . . . . . . . 17
Table 6. Additional Attributes in Event Notification Content for
Printer Events . . . . . . . . . . . . . . . . . . . . . 17
Table 7. Operation-id Assignments . . . . . . . . . . . . . . . . 19
Table 8. The "event-notification-attributes-tag" Value. . . . . . 21
This document describes an extension to the Internet Printing Protocol/1.1: Model and Semantics [RFC 2911], [RFC 2910]. This document specifies the 'ippget' Pull Delivery Method for use with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" specification [RFC3995]. This IPPGET Delivery Method is REQUIRED for all clients and Printers that support [RFC3995]. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this document. For a description of the base IPP documents, see section 21 of this document. For a description of the IPP Event Notification Model, see [RFC3995].
モデルと意味論[RFC 2911]、[RFC 2910]：この文書は、インターネット印刷プロトコル/ 1.1の拡張について説明します。 「：イベント通知とサブスクリプションインターネット印刷プロトコル（IPP）」仕様[RFC3995]この文書では、との使用のための「ippget」プル配信方法を指定します。このIPPGET配信方法は[RFC3995]をサポートしているすべてのクライアントおよびプリンターのために必要です。通知の受信者は、クライアントとして動作し、フェッチは、この文書で定義されます。Get-通知操作を使用してイベント通知（プル）を。ベースIPPドキュメントの説明については、このドキュメントのセクション21を参照してください。 IPPイベント通知モデルの詳細については、[RFC3995]を参照してください。
With this Pull Delivery Method, when an Event occurs, the Printer saves the Event Notification for a period of time called the Event Life. The Notification Recipient fetches (pulls) the Event Notifications by using the Get-Notifications operation. This operation causes the Printer to return all Event Notifications held for the specified Subscription object(s). If the Notification Recipient has selected the Event Wait Mode option to wait for additional Event Notifications, the Printer MAY continue to return Event Notifications to the Notification Recipient as asynchronous Get-Notification responses as Events occur using the transaction originated by the Notification Recipient.
イベントが発生したときに、このプル配信方法では、プリンタは、イベントライフと呼ばれる期間のためのイベント通知を保存します。通知の受信者は、Get-通知操作を使用してイベント通知をフェッチ（プル）。この操作は、指定されたサブスクリプションオブジェクト（複数可）のために開催されたすべてのイベント通知を返すために、プリンタの原因となります。通知の受信者は、追加のイベント通知を待つイベント待ちのモードオプションを選択した場合、プリンタは、イベント通知受信者が発信したトランザクションを使用して発生すると、非同期の取得通知の応答として通知受信者にイベント通知を返すために継続してもよいです。
The Notification Recipient can terminate Event Wait Mode (without closing the connection) by supplying the "notify-wait" (boolean) attribute with a 'false' value in a subsequent Get-Notifications request. Similarly, the Printer can terminate Event Wait Mode (without closing the connection) by returning the "notify-get-interval" (integer) operation attribute in a Get-Notifications response that tells the Notification Recipient how long to wait before trying again.
通知の受信者は、イベントが、その後は、Get-通知要求に「偽」の値を持つ「通知待ち」（ブール値）属性を供給することにより（接続を閉じずに）モードを待って終了することができます。同様に、プリンタは、イベントが再試行する前に待機する時間を通知受信者に伝えるには、Get-通知応答で、「通知・取得間隔」（整数）操作属性を返すことで（接続を閉じずに）モードを待って終了することができます。
This section defines the following terms that are used throughout this document:
このセクションでは、このドキュメントで使用されている次の用語を定義しています。
Capitalized terms such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL have special meaning relating to conformance as defined in [RFC2119] and [RFC2911], section 12.1. If an implementation supports the extension defined in this document, then these terms apply; otherwise, they do not. These terms define conformance to this document only; they do not affect conformance to other documents, unless it is explicitly stated otherwise.
このようMUSTとして資産の用語は、REQUIRED、SHOULD、べきではない、MAY、NOT NEED、およびオプションは、[RFC2119]と[RFC2911]、セクション12.1で定義された適合性に関する特別な意味を持ってはいけません。実装は、この文書で定義された拡張をサポートしている場合、これらの条件が適用されます。それ以外の場合は、そうではありません。これらの用語は、この文書への適合性を定義します。それは特に明記されない限り、彼らは、他の文書への適合に影響を与えません。
This document uses the same terminology as [RFC2911], including "client", "Printer", "Job", "attribute", "attribute value", "keyword", "operation", "request", "response", and "support", with the same meanings. This document also uses terminology defined in [RFC3995], such as "Subscription (object)", "Notification Recipient", "Event", "Event Notification", "Compound Event Notification", "Event Life", and "Event Notification Attribute Group", with the same meanings. In addition, this document defines the following terms for use in this document:
この文書では、「クライアント」、「プリンタ」、「仕事」、「属性」、「属性値」、「キーワード」、「操作」、「要求」、「応答」を含む、[RFC2911]と同じ用語を使用し、同じ意味で、「サポート」。この文書はまた、「サブスクリプション（オブジェクト）」、「通知受信者」、「イベント」として、[RFC3995]で定義された用語を使用し、「イベント通知」、「化合物イベント通知」、「イベント・ライフ」、および「イベント通知属性同じ意味を持つグループ」、。また、この文書は、この文書で使用する次の用語を定義しています。
Event Wait Mode: The mode requested by a Notification Recipient client in its Get-Notifications Request and granted by a Printer to keep the connection open while the Printer sends subsequent Get-Notification operation responses to the Notification Recipient in the form of Event Notifications as they occur.
イベントは、モードを待っ：モードは、その取得・通知の要求に通知受信者のクライアントから要求されたとプリンタが彼らのようにイベント通知の形で通知受信者の後には、Get-通知操作の応答を送信しながら、オープンな接続を維持するためにプリンタによって付与されました発生する。
In a Subscription Creation Operation, when the "notify-pull-method" attribute is present and has the "ippget" keyword value, the client is requesting that the Printer use the "ippget" Pull Delivery Method for the Event Notifications associated with the new Subscription Object.
サブスクリプションの作成操作では、「通知プル法は」属性が存在し、「ippget」キーワード値を持つ、クライアントプリンタが使用することを要求しているとき、「ippget」新に関連したイベント通知のための配信方法をプルサブスクリプション・オブジェクト。
When an Event occurs, the Printer MUST generate an Event Notification and MUST assign it the Event Life. The Printer MUST hold an Event Notification for its assigned Event Life.
イベントが発生した場合、プリンタは、イベント通知を発生させなければなりませんし、イベントライフを割り当てる必要があります。プリンタは、その割り当てられたイベントライフのためのイベント通知を保持しなければなりません。
When a Notification Recipient wants to receive Event Notifications for a Subscription object, it performs the Get-Notifications operation supplying the Subscription object's subscription-id, which causes the Printer to return all un-expired Event Notifications held for that Subscription object. If the Notification Recipient has selected the Event Wait Mode option to wait for additional Event Notifications, the response to the Get-Notifications request continues indefinitely as the Printer continues to send Event
通知の受信者は、サブスクリプションオブジェクトのためのイベント通知を受信したい場合は、そのサブスクリプションオブジェクトに対して保持されているすべての非期限切れのイベント通知を返すために、プリンタの原因となるサブスクリプションオブジェクトのサブスクリプションIDを供給するには、Get-通知動作を実行します。通知の受信者は、追加のイベント通知を待つイベント待ちのモードオプションを選択した場合、プリンタがイベントを送信し続けるようには、Get-通知要求に対する応答が無限に続きます
Notifications in the response as Events occur for that Subscription object.
イベントとして応答した通知は、そのサブスクリプションオブジェクトに対して発生します。
When the Notification Recipient requests Event Notifications for Per-Job Subscription Objects, the Notification Recipient typically performs the Get-Notifications operation within a second of performing the Subscription Creation operation. Because the Printer MUST save Event Notifications for at least 15 seconds (see section 8.1), the Notification Recipient is unlikely to miss any Event Notifications that occur between the Subscription Creation and the Get-Notifications operation.
通知の受信者は、ジョブごとのサブスクリプションのオブジェクトのイベント通知を要求すると、通知の受信者は、通常、サブスクリプションの作成操作を行う第2の内には、Get-通知動作を実行します。プリンタは、少なくとも15秒間、イベント通知を保存しなければならないので（セクション8.1を参照）、通知の受信者は、サブスクリプションの作成とは、Get-通知操作の間に発生した任意のイベント通知を欠場することはほとんどありません。
The 'ippget' Delivery Method is designed primarily for (1) a client that wants to get Events (from the job's Per-Job Subscription object) for a job that it has submitted and (2) a privileged client that wants to get all job or printer Events from a Per-Printer Subscription object.
「ippget」の配信方法は、主にそれが提出したことを仕事のために（ジョブのジョブごとのサブスクリプションオブジェクトから）のイベントを取得したい（1）クライアントとすべてのジョブを取得したい（2）特権クライアントのために設計されていますごとのプリンタSubscriptionオブジェクトから、プリンタのイベント。
If a Printer supports this Delivery Method, the following are its characteristics.
プリンタは、この配信方法をサポートしている場合は、次の特性です。
Table 1. Information about the Delivery Method
配送方法についての表1.情報
Document Method Conformance Requirement Delivery Method Realization
文書法適合性要件配信方法の実現
1. What is the URL scheme name for the 'ippget' keyword method Push Delivery Method, or the keyword name method name for the Pull Delivery Method?
1.「ippget」キーワード方式プッシュ配信方法、またはプル配信方法のためのキーワード名メソッド名のURLのスキーム名は何ですか？
2. Is the Delivery Method REQUIRED, REQUIRED RECOMMENDED, or OPTIONAL for an IPP Printer to support?
2.配信方法REQUIRED、IPPプリンタをサポートするために推奨、またはオプション必須ですか？
3. What transport and delivery protocols IPP with one new does the Printer use to deliver the operation. Event Notification Content; i.e., what is the entire network stack?
3.どのような輸配送オペレーションを実現するためにプリンタを使用しない1つの新しいでIPPをプロトコル。イベント通知の内容。すなわち、全体のネットワークスタックは何ですか？
4. Can several Event Notifications be Yes. combined into a Compound Event Notification?
4.いくつかのイベント通知はいことができます。複合イベント通知にまとめますか？
5. Is the Delivery Method initiated by This Delivery Method is the Notification Recipient (pull), a pull method with or by the Printer (push)? aspects of a push method, though the Printer does not initiate the operation.
5.この配信方法によって開始配信方法は、通知受信者（プル）、プリンタ（プッシュ）を持つかによって、プル方式ですか？プリンタの操作を開始しませんがプッシュ方式の側面、。
6. Is the Event Notification content Machine Consumable. Machine Consumable or Human Consumable?
6.イベント通知内容機消耗品です。マシンの消耗品や消耗品人間？
7. What section in this document answers Section 5. the following questions? For a Machine Consumable Event Notification, what is the representation and encoding of values defined in section 9.1 of [RFC3995], and what are the conformance requirements thereof? For a Human Consumable Event Notification, what is the representation and encoding of pieces of information defined in section 9.2 of [RFC3995], and the conformance requirements thereof?
この文書に記載されている7。どのようなセクションは、セクション5.以下の質問に答えますか？機械消耗イベント通知のために、[RFC3995]のセクション9.1で定義された値の表現とエンコーディングものであり、適合性要件は、何ですか？ヒト消耗イベント通知のために、どのような[RFC3995]のセクション9.2で定義された情報の表現および符号化され、そしてそれらの適合性要件？
8. What are the latency and reliability Same as IPP and the of the transport and delivery underlying HTTP protocol? transport.
8.待ち時間と信頼性は、HTTPプロトコルの基礎となる輸配送のIPPと同じとは何ですか？輸送。
9. What are the security aspects of the Same as IPP and the transport and delivery protocol; underlying HTTP e.g., how it is handled in transport and in the firewalls? same direction, so no new firewall considerations.
9. IPPと輸配送プロトコルと同じのセキュリティ面ではどのようなものです。それは輸送中やファイアウォールでどのように扱われるかを、例えばHTTPの基礎となりますか？同じ方向なので、ノー新しいファイアウォールの考慮。
10. What are the content length None. restrictions?
10.コンテンツ長なしにはどのようなものがありません。制限はありますか？
11. What are the additional values or None. pieces of information that a Printer sends in an Event Notification content and the conformance requirements thereof?
11.追加の値またはNone何ですか。プリンタは、イベント通知の内容とその適合性要件に送信する情報の断片？
12. What are the additional Subscription None. Template and/or Subscription Description attributes and the conformance requirements thereof?
12.追加のサブスクリプションなしどのようなものがありません。テンプレートおよび/またはサブスクリプションの説明属性とその適合性要件？
13. What are the additional Printer "ipp-event-life" Description attributes and the (integer (15: MAX)) conformance requirements thereof?
その適合性要件：13追加のプリンター「IPP-イベント・ライフ」の説明属性と（MAX）の整数（15）は何ですか？
This operation is issued by a client acting in the role of a Notification Recipient requesting the Printer to return all Event Notifications held for the identified Subscription object(s).
この操作は、特定されSubscriptionオブジェクト（複数可）のために開催されたすべてのイベント通知を返すようにプリンタを要求する通知受信者の役割で動作するクライアントによって発行されます。
A Printer MUST support this operation, MUST accept the request in any state (see [RFC2911] "printer-state" and "printer-state-reasons" attributes), and MUST remain in the same state with the same "printer-state-reasons" values.
プリンタ（属性[RFC2911]「プリンタ状態」および「プリンタ状態理由」を参照）、任意の状態で要求を受け入れなければなりません、この操作をサポートしなければならない、と同じ「プリンタ状態 - と同じ状態のままでなければなりません理由」の値。
When a Printer performs this operation, it MUST return all and only those Event Notifications
プリンタは、この操作を行うと、それがすべてとのみイベント通知を返さなければなりません
1. whose associated Subscription Object's "notify-subscription-id" Subscription Description attribute equals one of the values of the "notify-subscription-ids" (1setOf integer(1:MAX)) operation attribute AND
1.その関連付けられたサブスクリプション・オブジェクトの「通知サブスクリプション-ID」サブスクリプションの説明属性が「通知サブスクリプション・IDS」（1setOf整数（1：MAX））の値が1に等しい操作属性と
2. whose associated Subscription Object contains the "notify-pull-method" attribute and it has the 'ippget' keyword value, AND
2.その関連するサブスクリプション・オブジェクトは、「通知プル方式」属性が含まれており、それはippget 'キーワードの値を持ち、
3. whose "notify-sequence-number" is equal to or greater than the corresponding value of the "notify-sequence-numbers" (1setOf integer(1:MAX)) operation attribute if supplied AND
3.その「通知シーケンス番号」「通知シーケンスナンバー」（1setOf整数（1：MAX））の対応する値以上である操作属性供給される場合に
5. where the Notification Recipient client has read-access rights to the identified Subscription Object (see Access Rights paragraph below).
通知の受信者のクライアントが読み取りアクセスしている識別サブスクリプションオブジェクトに権利を5.（以下アクセス権の段落を参照）。
The Notification Recipient client MUST either (a) request Event Wait Mode by supplying the "notify-wait" operation attribute with a 'true' value or (b) suppress Event Wait Mode by omitting the "notify-wait" operation attribute or by supplying it with a 'false' value. To terminate Event Wait Mode subsequently, the Notification Recipient client MUST close the connection. To terminate Event Wait Mode, the Printer MUST either (a) return the "notify-get-interval" operation attribute in a Get-Notifications response (RECOMMENDED behavior) or (b) close the connection. The "notify-get-interval" operation attributes tell the Notification Recipient how long to wait before trying a subsequent Get-Notifications request.
通知の受信者のクライアントは、（a）はリクエストイベントは、イベントは、「通知待ち」操作属性を省略することにより、または供給することによってモードを待っ抑える「真」値と「通知待ち」操作属性を供給することによってモードを待つか、（b）にしなければならないのいずれかそれは「偽」の値を持ちます。イベントがその後モードを待って終了するには、通知の受信者のクライアントが接続を閉じる必要があります。イベントモードを待って終了するには、プリンタは、（a）には、Get-通知応答（推奨動作）または（b）の接続を閉じるには、「通知・取得間隔」操作属性を返さなければなりません。 「通知・取得間隔」の操作属性は、後続のGet-通知要求をしようとする前に待機する時間を通知受信者に伝えます。
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation MUST be (1) the owner of each Subscription Object identified by the "notify-subscription-ids" operation attribute (see section 5.1.1), (2) an operator or administrator of the Printer (see [RFC2911], sections 1 and 8.5), or (3) otherwise authorized by the Printer's administrator-configured security policy to request Event Notifications from the target Subscription Object(s). Otherwise, the IPP Printer MUST reject the operation and return: 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' status code, as appropriate. Furthermore, the Printer's security policy MAY limit the attributes returned by the Get-Notifications operation, in a manner similar to that of the Get-Job-Attributes operation (see [RFC2911], end of section 3.3.4.2).
アクセス権：認証されたユーザ（セクション8.3、[RFC2911]を参照）この操作を行うには、（1）各サブスクリプション・オブジェクトの所有者が「通知サブスクリプション・IDS」操作属性（セクション5.1.1を参照）、（によって識別されなければなりません2）プリンタのオペレータまたは管理者（[RFC2911]を参照し、セクション1および8.5）、または（3）そうでなければターゲット・サブスクリプション・オブジェクト（複数可）からのイベント通知を要求するために、プリンタの管理者が設定したセキュリティポリシーによって許可。それ以外の場合は、IPPプリンタは、操作を拒絶しなければなりませんし、返却：「クライアント誤り禁じられた」、「クライアント・エラー・認証されていない」または「クライアント誤り - 権限がありません」ステータスコード、適宜。さらに、プリンタのセキュリティポリシーは、（、セクション3.3.4.2の終わりに[RFC2911]を参照）には、Get-ジョブ・属性の操作と同様に、取得・通知操作で返される属性を制限することがあります。
The following groups of attributes are part of the Get-Notifications Request:
属性の以下のグループは、Get-通知要求の一部です：
Group 1: Operation Attributes
グループ1：操作の属性
Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes, as described in [RFC2911], section 3.1.4.1.
自然言語と文字セット：[RFC2911]で説明したように「属性-文字セット」と「属性自然言語」は、属性、セクション3.1.4.1。
Target: The "printer-uri" (uri) operation attribute that is the target for this operation as described in [RFC2911], section 3.1.5.
ターゲット：[RFC2911]に記載されているように、この操作の対象となる「プリンタ-URI」（URI）操作属性、セクション3.1.5。
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in [RFC2911], section 8.3.
「要求ユーザ名」（名前（MAX））[RFC2911]に記載されているように属性がクライアントによって供給されるべきであり、セクション8.3：ユーザー名を要求します。
This attribute identifies one or more Subscription objects for which Events are requested. The client MUST supply this attribute with at least one value. The Printer object MUST support this attribute with multiple values.
この属性は、イベントが要求されるために1つ以上のサブスクリプション・オブジェクトを識別します。クライアントは、少なくとも1つの値でこの属性を供給しなければなりません。 Printerオブジェクトは、複数の値でこの属性をサポートしなければなりません。
If no Subscription Object exists with the supplied identifier, or if the identified Subscription Object does not contain the "notify- pull-method" attribute with the 'ippget' keyword value, the Printer MUST return the 'client-error-not-found' status code.
何のサブスクリプションオブジェクトは、供給識別子で存在しない、または識別サブスクリプションオブジェクトが「ippget」キーワードの値を持つ「のnotify-プル方式」属性が含まれていない場合、プリンタは、「クライアント誤り-が見つからない」返さなければならない場合ステータスコード。
Note: The name of both the "notify-subscription-ids" and
"notify-sequence-numbers" end in 's', as they are multi-valued.
However, there are other occurrences of these attribute names
without the 's' that are single valued.
This attribute specifies one or more of the lowest Event Notification sequence number values for the Subscription objects identified by the corresponding values of the "notify-subscription-ids" operation attribute. The Notification Recipient SHOULD supply this attribute, and the number of values SHOULD be the same as that of the "notify-subscriptions-ids" attribute. The Printer MUST support this attribute with multiple values.
この属性は、「通知サブスクリプション・IDS」操作属性の対応する値によって識別されるサブスクリプションオブジェクトの最安イベント通知シーケンス番号値を1つ以上指定します。通知受信者がこの属性を提供する必要があり、そして値の数は、「通知・サブスクリプション・IDS」属性のものと同じでなければなりません。プリンタは、複数の値でこの属性をサポートしなければなりません。
The Printer MUST NOT return Notification Events with lower sequence numbers for the corresponding Subscription object. Therefore, by supplying the proper values for this attribute the Notification Recipient can prevent getting the same Event Notifications from a Subscription object that were returned on a previous Get-Notifications request. The Notification Recipient SHOULD remember the highest "notify-sequence-number" value returned for each Subscription object requested and SHOULD pass that value for each requested Subscription object on the next Get-Notifications request.
プリンタが対応するサブスクリプション・オブジェクトの下のシーケンス番号を通知イベントを返してはなりません。したがって、この属性の適切な値に通知受信者を供給することにより、以前には、Get-通知要求に返されたサブスクリプションの対象から同じイベント通知を取得防ぐことができます。通知の受信者は、最高の「通知シーケンス番号を」値が要求された各サブスクリプションオブジェクトに返され、次のGet-通知要求の各要求されたサブスクリプションオブジェクトに対して、その値を渡す必要があります覚えておいてください。
If the Notification Recipient supplies fewer values for this attribute (including omitting this attribute) than it does for the "notify-subscription-ids" operation attribute, the Printer assumes a '1' value for each missing value. A value of '1' causes the Printer to return any un-expired Event Notification for that Subscription object, as '1' is the lowest possible sequence number. If the Notification Recipient supplies more values for this attribute than the number of values for the "notify-subscription-ids" operation attribute, the Printer ignores the extra values.
通知の受信者は、それが「通知サブスクリプション-idを」操作属性のためよりも（この属性を省略した、など）この属性の少ない値を提供した場合、プリンタは、各欠損値は「1」の値を前提としています。 「1」の値が「1」は、可能な限り低いシーケンス番号であるとして、そのサブスクリプションオブジェクトのための任意の非期限切れのイベント通知を返すために、プリンタの原因となります。通知受信者が「通知サブスクリプション-idを」操作属性の値の数よりも、この属性の複数の値を与えた場合、プリンタは、余分な値を無視します。
Note: If a Notification Recipient performs two consecutive Get-Notifications operations with the same value for "notify-sequence-number" (or omits the attribute), the time stamp value of the first Event Notification in the second Get-Notifications Response may be less than that of the time stamp of the last Event Notification in the first Get-Notification Response. This happens because the Printer sends all unexpired Event Notifications with an equal or higher sequence number according to the ordering specified in [RFC3995], and some Event Notifications from the first Get-
注：通知受信者「は、通知シーケンス番号」について同じ値を持つ2つの連続的な取得、通知動作を行う（または属性を省略）した場合、第二のGet-通知応答して、第1のイベント通知のタイムスタンプ値であってもよいです最初のGet-通知応答の最後のイベント通知のタイムスタンプよりも少ないです。これは、プリンタが[RFC3995]で指定された順序に従って、同等以上のシーケンス番号を有するすべての期限が切れていないイベント通知を送信するため発生し、そして第一GET-からいくつかのイベント通知
Notifications operation may not have expired by the time the second Get-Notifications operation occurs.
通知の操作は、第二には、Get-通知操作が発生した時点で有効期限が切れていない可能性があります。
This value indicates whether the Notification Recipient wants Event Wait Mode. The client MAY supply this attribute. The Printer object MUST support both values of this attribute.
この値は、通知の受信者は、イベントモードを待って望んでいるかどうかを示します。クライアントがこの属性を供給することができます。 Printerオブジェクトは、この属性の両方の値をサポートしなければなりません。
If the client supplies the 'false' value or omits this attribute, the client is not requesting Event Wait Mode. If the value is 'true', the client is requesting Event Wait Mode. See the beginning of section 5.2 for the rules for Event Wait Mode.
クライアントが「偽」値を提供するか、この属性を省略した場合、クライアントは、イベントモードを待って要求していません。値が「本当」である場合、クライアントは、イベントモードを待って要求しています。イベントウェイトモードのための規則はセクション5.2の始まりを参照してください。
The Printer has the following options for responding to a Get-Notifications Request:
プリンタは、Get-通知要求に応答するために、次のオプションがあります。
1. The Printer can reject the request and return the 'server-error-busy' status code if the Printer is too busy to accept this operation at this time. In this case, the Printer MUST return the "get-notify-interval" operation attribute to indicate when the client SHOULD try again.
1.プリンタは要求を拒否し、プリンターは、この時点でこの操作を受け入れることがビジー状態である場合は、「サーバー・エラー・ビジー」ステータスコードを返すことができます。この場合、プリンタは、クライアントが再び試みるべきときを示すために「-通知を受ける間隔」操作属性を返さなければなりません。
2. If the Notification Recipient did not request Event Wait Mode ("notify-wait-mode" = 'false' or omitted), the Printer MUST immediately return whatever Event Notifications it currently holds in the requested Subscription object(s) and MUST return the "notify-get-interval" operation attribute with the number of seconds from now, at which the Notification Recipient SHOULD repeat the Get-Notifications Request to get future Event Notifications.
2.通知受信者は、イベントモード（「通知待ちモード」=「偽の」または省略）を待って要求しなかった場合、プリンタはすぐにそれが現在要求スクリプションオブジェクト（複数可）に保持しているものは何でもイベント通知返さなければならないと返さなければなりません通知の受信者は、将来のイベント通知を取得するには、Get-通知リクエストを繰り返す必要れる今からの秒数で、「通知・取得間隔」操作属性。
3. If the Notification Recipient requested Event Wait Mode ("notify-wait-mode" = 'true'), the Printer MUST immediately return whatever Event Notifications it currently holds in the requested Subscription object(s) and MUST continue to return Event Notifications as they occur until all the requested Subscription Objects are canceled. A Subscription Object is canceled either via the Cancel-Subscription operation or by the Printer (e.g., the Subscription Object is canceled when the associated Job completes and is no longer in the Job Retention or Job History phase; see the "ippget-event-life (integer(15:MAX))" attribute discussion in section 8.1).
3.通知の受信者は、イベントモード（「通知待ちモード」=「真」）を待って要求された場合、プリンタはすぐにそれが現在要求スクリプションオブジェクト（複数可）に保持し、イベント通知を返し続けなければならどんなイベント通知返さなければなりません彼らが起こるよう要求されたすべてのサブスクリプションオブジェクトがキャンセルされるまで。サブスクリプションオブジェクトがキャンセル・サブスクリプションの操作を介して、またはプリンタ（例えばどちらかによってキャンセルされる関連した仕事を完了していないとジョブの保存やジョブ履歴相されなくなったときに、サブスクリプションオブジェクトがキャンセルされ、「ippgetイベント期を見ます（整数（15：MAX））」セクション8.1の属性議論）。
However, the Printer MAY decide to terminate Event Wait Mode at
any time, including in the first response. In this case, the
Printer MUST return the "notify-get-interval" operation attribute. This attribute indicates that the Printer wishes to leave Event Wait Mode and the number of seconds in the future that the Notification Recipient SHOULD try the Get-Notifications operation again. The Notification Recipient MUST accept this response and MUST disconnect. If the Notification Recipient does not disconnect, the Printer SHOULD do so.
プリンタは、「通知・取得間隔」操作属性を返さなければなりません。この属性は、プリンタは、通知受信者が再び取得・通知の操作を試してみてくださいすることを将来的にはイベント待ちモードと秒数を残すために望んでいることを示しています。通知受信者は、この応答を受け入れなければならないし、切断する必要があります。通知受信者が切断されない場合は、プリンタは、そうすべきです。
From the Notification Recipient's view, the response appears as an initial burst of data, which includes the Operation Attributes Group and one Event Notification Attributes Group per Event Notification that the Printer is holding. After the initial burst of data, if the Notification Recipient has selected the Event Wait Mode option to wait for additional Event Notifications, the Notification Recipient receives occasional Event Notification Attribute Groups. Proxy servers may delay some Event Notifications or cause time-outs to occur. The client MUST be prepared to perform the Get-Notifications operation again when time-outs occur.
通知受信者の視点からは、応答操作がグループ属性と1つのイベント通知は、プリンタが保持しているイベント通知ごとにグループ属性含むデータの初期バースト、として表示されます。通知の受信者が選択した場合、データの初期バースト後、イベントが追加のイベント通知を待つモードオプションを待って、通知の受信者は、時折イベント通知は、グループ属性受けます。プロキシサーバーは、いくつかのイベント通知を遅らせるか、タイムアウトが発生する場合があります。クライアントは、タイムアウトが発生した場合、再び取得 - 通知操作を実行するために準備しなければなりません。
Each attribute is encoded by using the IPP rules for encoding attributes [RFC2910] and MAY be encoded in any order. Note: the Get-Jobs response in [RFC2911] acts as a model for encoding multiple groups of attributes. See section 11 for the encoding and transport rules.
各属性は、符号化は[RFC2910]を属性と任意の順序で符号化することができるためIPPルールを使用して符号化されます。注意：[RFC2911]でGet-ジョブの応答は、属性の複数のグループを符号化するためのモデルとして機能します。エンコードとトランスポートルールのセクション11を参照してください。
The following groups of attributes are part of the Get-Notifications Response:
属性の以下のグループは、Get-通知応答の一部です：
Group 1: Operation Attributes
グループ1：操作の属性
Status Message: In addition to the REQUIRED status code returned in every response, the response OPTIONALLY includes a "status-message" (text(255)) and/or a "detailed-status-message" (text(MAX)) operation attribute, as described in [RFC2911], sections 13 and 3.1.6.
ステータスメッセージ：すべての応答で返さREQUIREDステータスコードに加えて、応答は、必要に応じて、「ステータスメッセージ」（テキスト（255））および/または「詳細ステータスメッセージ」（テキスト（MAX））操作属性を含みます、[RFC2911]に記載されているように、セクション13及び3.1.6。
The Printer can return any status codes defined in [RFC2911]. If the status code is not 'successful-xxx', the Printer MUST NOT return any Event Notification Attribute groups. The following are descriptions of the important status codes:
プリンタは、[RFC2911]で定義された任意のステータスコードを返すことができます。ステータスコードが「成功-XXX」でない場合は、プリンタは、任意のイベント通知属性グループを返してはなりません。次の重要なステータスコードの説明は、次のとおりです。
successful-ok: The response contains all Event Notification associated with the specified subscription-ids that had been supplied in the "notify-subscription-ids" operation attribute in the request. If the requested Subscription Objects have no associated Event Notification, the response MUST contain zero Event Notifications.
成功-OK：応答が要求の「通知サブスクリプション-idを」操作属性で供給されていた指定されたサブスクリプション-IDSに関連するすべてのイベント通知が含まれています。要求されたサブスクリプションオブジェクトに関連付けられているイベントの通知を持っていない場合は、応答がゼロにイベント通知を含まなければなりません。
successful-ok-events-complete: Indicates when this return is the last return for all Subscription objects that match the request, whether or not Event Notifications are returned. This condition occurs for Event Wait Mode with Notification Recipients waiting for responses when (1) the Subscription Object is canceled with a Cancel-Subscription operation, (2) the Subscription Object is deleted, when the Per-Printer Subscription lease time expires, or (3) the 'job-completed' event occurs for a Per-Job Subscription. This condition also occurs for a Get-Notifications request that a Notification Recipient makes after the job completes, but before the Event Life expires. See section 10.1. client-error-not-found: The Printer has no Subscription Objects whose "notify-subscription-id" attribute equals any of the values of the "notify-subscription-ids" operation attribute supplied, or the identified Subscription Object does not contain the "notify-pull-method" attribute with the 'ippget' keyword value. server-error-busy: The Printer is too busy to accept this operation. The Printer SHOULD return the "notify-get-interval" operation attribute in the Operation Attributes of the response; then the Notification Recipient SHOULD wait for the number of seconds specified by the "notify-get-interval" operation attribute before performing this operation again. If the "notify-get-interval" Operation Attribute is not present, the Notification Recipient SHOULD use the normal network back-off algorithms to determine when to perform this operation again.
成功-OK-イベント-完全：このリターンが要求に一致するすべてのサブスクリプションオブジェクトのための最後のリターンであるときにイベント通知が返されるかどうかを、示します。この条件は、（2）サブスクリプションオブジェクトをごとのプリンタサブスクリプションのリース期間が満了したときに、削除、またはされた通知の受信者は、（1）サブスクリプションオブジェクトがキャンセル・サブスクリプション操作でキャンセルされた応答を待っていると、イベントウェイトモードで発生します（ 3）「ジョブ完了」イベントは、ジョブごとのサブスクリプションのために発生します。この条件はまた、ジョブが完了した後、通知受信者はなりますが、イベントライフの有効期限が切れる前には、Get-通知要求のために発生します。項10.1を参照してください。クライアント・エラー - 見つかりません：プリンタは、「通知サブスクリプション-id」属性が等しい「通知サブスクリプション-IDS」の値のいずれかが操作属性が付属、または識別サブスクリプションオブジェクトが含まれていない何もサブスクリプションオブジェクトを持っていません「通知プル方式」「ippget」キーワードの値を持つ属性を。サーバー・エラー・ビジー：プリンタは、この操作を受け入れることができないくらい忙しいです。プリンタは、応答の操作属性に「通知・取得間隔」操作属性を返すべきです。そして、通知受信者は、再びこの操作を実行する前に、「通知・取得間隔」操作属性で指定した秒数を待つべき。 「通知・取得間隔」操作属性が存在しない場合は、通知の受信者は、再びこの操作を実行するタイミングを決定するためにバックオフアルゴリズムを通常のネットワークを使用すべきです。
Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes, as described in [RFC2911], section 3.1.4.2.
自然言語と文字セット：[RFC2911]で説明したように「属性-文字セット」と「属性自然言語」は、属性、セクション3.1.4.2。
The Printer MUST use the values of "notify-charset" and "notify-natural-language", respectively, from one Subscription Object associated with the Event Notifications in this response.
プリンタは、この応答でイベント通知に関連付けられた1つのサブスクリプションオブジェクトから、それぞれ、「通知-文字セットを」の値と、「通知・自然言語」を使用しなければなりません。
Normally, there is only one matched Subscription Object, or the value of the "notify-charset" and "notify-natural-language" attributes is the same in all Subscription Objects. If not, the Printer MUST pick one Subscription Object from which to obtain the value of these attributes. The algorithm for picking the Subscription Object is implementation dependent. The choice of natural language is not critical, because 'text' and 'name' values can override the "attributes-natural-language" operation attribute. The Printer's choice of charset is critical because a bad choice may leave it unable to send some 'text' and 'name' values accurately.
通常、一つだけマッチしたサブスクリプションオブジェクト、または「通知-文字セット」と「通知-自然言語」の値が、すべてのサブスクリプションのオブジェクトで同じれる属性です。そうでない場合、プリンタは、これらの属性の値を取得するから、1つのサブスクリプションオブジェクトを選択する必要があります。サブスクリプションオブジェクトを取り出すためのアルゴリズムは実装依存です。自然言語の選択は、重要ではないので、「テキスト」と「名前」の値が「属性自然言語」操作属性をオーバーライドすることができます。悪い選択は正確にいくつかの「テキスト」と「名」の値を送信することができませんそれを残すことができるので、文字セットのプリンタの選択は重要です。
The value of this operation attribute is the number of seconds that the Notification Recipient SHOULD wait before trying the Get-Notifications operation again. The Printer MUST return this operation attribute if (1) it is too busy to return events, (2) the Notification Recipient client did not request Event Wait Mode, or (3) the Printer is terminating Event Wait Mode. The client MUST accept this attribute and SHOULD reissue the Get-Notifications operation (with or without "notify-wait" = 'true') at the indicated number of seconds in the future in order to get more Event Notifications This value is intended to help the client be a good network citizen.
この操作属性の値は、通知の受信者が再び取得・通知の操作をしようとする前に待機する秒数です。 （1）イベントを返すことがビジー状態である場合、プリンタは（2）通知受信者のクライアントは、イベントモードを待って要求していない、または（3）プリンタは、イベントモードを待って終了し、この操作属性を返さなければなりません。クライアントは、支援することを目的として、この属性を受け入れなければならないし、より多くのイベント通知この値を取得するために、将来的には指定された秒数で（または=「真」「通知待ち」なし）は、Get-通知操作を再発行すべきですクライアントは、良いネットワーク市民であること。
The value of this attribute MUST be at least as large as that of the Printer's "ippget-event-life" Printer Description attribute (see section 8.1). The Printer MAY return a value that is larger than that of the "ippget-event-life" Printer Description attribute provided that the Printer increases the Event Life for this Subscription object so that Notification Recipients taking account of the larger value and polling with a longer interval will not miss events. Note: Implementing such an algorithm requires some hidden attributes in the Subscription object that are IMPLEMENTATION DEPENDENT.
この属性の値は、プリンタの「ippget・イベント・ライフ」プリンタ記述属性（セクション8.1を参照）のそれと少なくとも同じ大きさでなければなりません。 「ippgetイベント期を」プリンタ記述属性のそれよりも大きい値を返すかもしれないプリンタは、プリンタが長いと大きな値とポーリングを考慮して、その通知の受信者ので、このサブスクリプション・オブジェクトのイベント・ライフを増加させることを提供しました間隔は、イベントを見逃すことはありません。注意：このようなアルゴリズムを実装する実装に依存するサブスクリプション・オブジェクト内のいくつかの隠し属性が必要です。
If the Printer wants to remain in Event Wait Mode, then the Printer MUST NOT return this attribute in the response.
プリンタは、イベント待ちモードのままにしたい場合は、[プリンタが反応して、この属性を返してはなりません。
Here is a complete table of combinations of "notify-wait", "status-code", "notify-get-interval", and Event Notification Attributes Groups for Get-Notification initial (Wait and No Wait) Responses and subsequent Event Wait Mode Responses (which may stay in Event Wait Mode or may request the Notification Recipient to leave Event Wait Mode):
ここで、「ステータスコード」、「通知-取得間隔」、およびイベント通知「通知待ち」の組み合わせの完全な表があるの取得通知の初期（待ってから、ノーウェイト）の対応とその後のイベント待ちモードのためのグループ属性（モードを待つか、モードを待ってイベントを残すように通知受信者を要求することができるイベントで滞在可能）回答：
Table 2. Combinations of "notify-wait", "status-code", and
"notify-get-interval"
Client sends: Printer returns: Printer Event returns: Notification "notify-wait" "status-code" "notify-get- Attribute interval" Groups
クライアントが送信：プリンタを返します：プリンタのイベント戻り値：通知「「通知待ち」ステータスコード」「通知-GET-属性間隔」グループ
1. 'false'* 'successful-ok' MUST return N maybe 2. 'false'* 'not-found' MUST NOT MUST NOT 3. 'false'* 'busy' MUST return N MUST NOT
1. '偽' * '成功-OK' * '-見つからない' 多分2. 'false' にする必要がありますしないMUST NOT 3. '偽' * '忙しい' を返しなければならNではないMUST Nを返さなければなりません
4. 'false'* 'events- MUST NOT 'job-complete' completed' 5. 'true' 'successful-ok' MUST NOT MUST 6. 'true' 'successful-ok' MUST return N maybe 7. 'true' 'not-found' MUST NOT MUST NOT 8. 'true' 'busy' MUST return N MUST NOT 9. 'true' 'events- MUST NOT 'job-complete' completed' or maybe other * 'false' or client omits the "notify-wait" attribute.
4. '偽' * 'イベントを紹介てはならない '仕事-完全に' 完了' 5. '真' '成功-OK' をしてはならない6. MUST ' '成功し、[OK]を'' trueを返さなければなりませんN 7. '真' 多分「-が見つからない」ではない8.「真」「忙しい」真「イベントを紹介はならない（MUST NOT） 『ジョブ完了』完成」や多分他*「偽」またはクライアントは省略「Nが9てはならない返さなければならない」MUSTてはなりません「通知待ち」属性。
Explanation:
説明：
1-4: Client does not request Event Wait Mode. 5-9: Client requests Event Wait Mode. 2,7: Subscription object not found, or was canceled earlier; client should NOT try again. 3,8: Server busy, tells client to try later; client should try again in N seconds. 4: Client polled after job completed, but before Event Life expired, and got the 'job-completed' event, so the client shouldn't bother trying again; client should NOT try again later. 5: Printer returns one or more Event Notifications and is OK to stay in Event Wait Mode; the client waits for more Event Notifications to be returned. 6: Printer wants to leave Event Wait mode. Can happen on the first response (with or without Event Notifications) or happen on a subsequent response with or without Event Notifications; the client SHOULD try again in N seconds. 9: Either (1) the printer returns 'job-completed' event, or (2) the Subscription Object was canceled by either a Cancel-Job or a Per-Printer Subscription expired without being renewed. For case (1), at least one Event Notification MUST be returned; for case (2), it is unlikely that any Event Notifications are returned, and the client should NOT try again.
1-4：クライアントがイベントモードを待って要求しません。 5-9：クライアントがイベントモードを待って要求します。 2,7：サブスクリプションオブジェクトが見つかり、以前取り消されたわけではありません。クライアントは、もう一度試してはいけません。 3,8：忙しいServerは、後にしようとするクライアントに指示します。クライアントは、N秒で再び試してみてください。 4：クライアントが終了したジョブの後にポーリングされますが、クライアントが再試行する気にはならないので、イベント生命は、期限切れ、および「ジョブ完了」イベントを持って前に。クライアントは、後で再試行しないでください。 5：プリンタは、一つ以上のイベント通知を返し、モードを待ってイベントに滞在してOKです。クライアントが返されるより多くのイベント通知を待ちます。 6：プリンタは、イベント待ちモードを終了したいと考えています。 （またはイベント通知なし）最初の応答に起こるか、イベント通知の有無にかかわらず、その後の応答に発生する可能性があります。クライアントは、N秒で再び試してみてください。 9：どちらか（1）プリンタ戻っ「ジョブ完了」イベント、または（2）サブスクリプションオブジェクトは、Aキャンセル・ジョブまたはプリンタごとのサブスクリプションのいずれかによって取り消されましたが更新されずに失効しました。ケース（1）と、少なくとも1つのイベント通知が返されなければなりません。ケース（2）のために、どんなイベント通知が返され、クライアントは、もう一度試してはならないことはほとんどありません。
The value of this attribute is the Printer's "printer-up-time" attribute at the time when the Printer sends this response. The Printer MUST return this attribute. Because each Event Notification also contains the value of this attribute when the event occurred, the value of this attribute lets a Notification Recipient know when each Event Notification occurred relative to the time of this response.
この属性の値は、プリンタは、この応答を送信する時にプリンタの「プリンタ・アップ・タイム」属性です。プリンタは、この属性を返さなければなりません。各イベント通知は、イベントが発生し、この属性の値が含まれているため、この属性の値は、各イベント通知は、この応答の時間に対する発生したときに通知の受信者が知ることができます。
Group 2: Unsupported Attributes See [RFC2911], section 3.1.7, for details on returning Unsupported Attributes.
グループ2：サポートされていない属性はサポートされていない属性を返すの詳細については、[RFC2911]、セクション3.1.7を参照してください。
Group 3 through N: Event Notification Attributes The Printer responds with one Event Notification Attributes Group per matched Event Notification. The entire response is considered a single Compound Event Notification (see [RFC3995]). The matched Event Notifications are all un-expired Event Notifications associated with the matched Subscription Objects and MUST follow the "Event Notification Ordering" requirements for Event Notifications within a Compound Event Notification specified in [RFC3995] section 9. In other words, the Printer MUST order these Event Notification groups in ascending time stamp (and sequence number) order for a Subscription object. If Event Notifications for multiple Subscription objects are being returned, the Notification Events for the next Subscription object follow in ascending time stamp order, etc.
Nによるグループ3：イベント通知は、1つのイベント通知がマッチしたイベント通知ごとにグループ属性を持つプリンタが応答属性。全体の応答は、単一の化合物イベント通知（[RFC3995]を参照）であると考えられます。マッチしたイベント通知は、一致したサブスクリプション・オブジェクトに関連付けられているすべての非期限切れのイベント通知であり、言い換えれば部9、プリンタで指定した複合イベント通知内のイベント通知のための「イベント通知の順序」要件[RFC3995]に続かなければなりませんMUSTサブスクリプションオブジェクトに対して昇順タイムスタンプ（シーケンス番号）順でこれらのイベント通知グループを注文。複数のサブスクリプション・オブジェクトのイベント通知が返送されている場合は、次のサブスクリプションオブジェクトの通知イベント等、タイムスタンプの昇順に従ってください
Each Event Notification Group MUST contain all of attributes
specified in section 9.1 ("Content of Machine Consumable Event
Notifications") of [RFC3995], with exceptions denoted by
asterisks in the tables below.
The tables below are identical to those in section 9.1 ("Content of Machine Consumable Event Notifications") of [RFC3995], except that each cell in the "Sends" column is a "MUST".
それ以外の列「を送信する」の各セルは、「MUST」である。以下の表は、[RFC3995]のセクション9.1（「マシン消耗イベント通知のコンテンツ」）と同じです
If more than one Event Notification is being returned and the status of each is not the same, then the Printer MUST return a "notify-status-code" attribute in each Event Notification Attributes group to indicate the differing status values.
複数のイベント通知が返送されており、それぞれの状態が同じでない場合は、[プリンタは、各イベント通知の「通知ステータス・コード」属性が異なるステータス値を示すために、グループ属性返さなければなりません。
For an Event Notification for all Events, the Printer includes the attributes shown in Table 3.
すべてのイベントのイベント通知の場合、プリンタは、表3に示した属性を含んでいます。
Table 3. Attributes in Event Notification Content
表3は、イベント通知コンテンツの属性
Source Value Sends Source Object
ソース値は、ソースオブジェクトを送信します
notify-subscription-id (integer(1:MAX)) MUST Subscription notify-printer-uri (uri) MUST Subscription notify-subscribed-event (type2 keyword) MUST Event Notification printer-up-time (integer(1:MAX)) * MUST Printer printer-current-time (dateTime) MUST ** Printer notify-sequence-number (integer (0:MAX)) MUST Subscription notify-charset (charset) MUST Subscription notify-natural-language (naturalLanguage) MUST Subscription notify-user-data (octetString(63)) MUST *** Subscription notify-text (text) MUST Event Notification attributes from the "notify-attributes" MUST **** Printer attribute attributes from the "notify-attributes" MUST **** Job attribute attributes from the "notify-attributes" MUST **** Subscription attribute
通知サブスクリプション-ID（整数（1：MAX））を通知し、プリンタ-URI（URI）申しなければならないサブスクリプション・MUST-通知サブスクライブ・イベント（TYPE2キーワード）MUSTイベント通知プリンタ・アップ・タイム（整数（1：MAX）） * MUSTプリンタのプリンタ - 現在時刻（dateTimeの）MUST **プリンタ通知シーケンス番号（整数（0：MAX））に通知-文字セット（文字セットを）申しなければならない通知、自然言語（自然言語）申しなければならないのnotify-サブスクリプション・MUSTユーザデータ（OCTETSTRING（63））MUST ***購読通知テキスト（文章）がイベント通知は、 "通知-属性" MUSTから属性をしなければならない**** Printer属性は、 "通知-属性" MUSTから属性*** *ジョブの属性は、「通知-属性を」MUST ****サブスクリプションの属性から属性
* As specified in [RFC3995] section 9, the value of the "printer-up-time" attribute sent in each Event Notification MUST be the time at which the Event occurred, not the time at which the Event Notification was sent.
*で指定されているように[RFC3995]セクション9、イベントが発生した時刻ではなく、イベント通知が送信された時刻でなければなりません各イベント通知で送信される「プリンタアップ時間」属性の値。
** The Printer MUST send the "printer-current-time" attribute if and only if it supports the "printer-current-time" attribute on the Printer object.
**プリンタは、プリンタオブジェクトの「プリンタの現在時刻」属性であれば、それは「プリンタの現在時刻」をサポートしている場合にのみ、属性を送らなければなりません。
*** If the associated Subscription Object does not contain a "notify-user-data" attribute, the Printer MUST send an octet-string of length 0.
***関連するサブスクリプションオブジェクトには、「通知・ユーザー・データを」属性が含まれていない場合、プリンタは長さ0のオクテット文字列を送らなければなりません。
**** If the "notify-attributes" attribute is present on the Subscription Object, the Printer MUST send all attributes specified by the "notify-attributes" attribute. Note: If the Printer doesn't support the "notify-attributes" attribute, it is not present on the associated Subscription Object.
****「通知-属性」属性がサブスクリプションオブジェクトに存在する場合、プリンタは「-属性を通知し」属性で指定されたすべての属性を送らなければなりません。注意：プリンタは、「通知-属性」属性をサポートしていない場合、それは、関連するサブスクリプションオブジェクトには存在しません。
For Event Notifications for Job Events, the Printer includes the additional attributes shown in Table 4.
ジョブイベントのイベント通知の場合、プリンタは表4に示した追加の属性を含んでいます。
Table 4. Additional Attributes in Event Notification Content for Job Events
ジョブイベントのイベント通知の内容表4.追加属性
Source Value Sends Source Object
ソース値は、ソースオブジェクトを送信します
job-id (integer(1:MAX)) MUST Job job-state (type1 enum) MUST Job job-state-reasons (1setOf type2 keyword) MUST Job job-impressions-completed (integer(0:MAX)) MUST * Job
ジョブID（整数（1：MAX））MUSTジョブのジョブ状態（TYPE1列挙）MUSTジョブのジョブ状態理由（1setOf TYPE2キーワード）MUSTジョブのジョブインプレッションが完了（整数（0：MAX））MUST * JOB
* The Printer MUST send the "job-impressions-completed" attribute in an Event Notification only for the combinations of Events and Subscribed Events shown in Table 5.
*プリンタのみイベントと表5に示したサブスクライブイベントの組み合わせのためのイベント通知の「ジョブ感想完了」属性を送らなければなりません。
Table 5. Combinations of Events and Subscribed Events for "job-impressions-completed"
イベントの表5の組み合わせと、「ジョブ感想完了」を引き受けイベント
Job Event Subscribed Job Event
ジョブイベント購読求人イベント
'job-progress' 'job-progress' 'job-completed' 'job-completed' 'job-completed' 'job-state-changed'
「ジョブの進行状況」「ジョブの進行状況」「ジョブ完了」「ジョブ完了」「ジョブ完了」「ジョブ状態変更」
For Event Notification for Printer Events, the Printer includes the additional attributes shown in Table 6.
プリンタのイベントのためのイベント通知の場合、プリンタは、表6に示した追加の属性を含んでいます。
Table 6. Additional Attributes in Event Notification Content for Printer Events
プリンタのイベントのためのイベント通知の内容表6.追加属性
Source Value Sends Source Object
ソース値は、ソースオブジェクトを送信します
printer-state (type1 enum) MUST Printer printer-state-reasons (1setOf type2 keyword) MUST Printer printer-is-accepting-jobs (boolean) MUST Printer
プリンタ状態（タイプ1列挙）MUSTプリンタのプリンタ状態の理由（1setOf TYPE2キーワード）MUSTプリンタのプリンタ - 受容され、ジョブ（ブール値）MUSTプリンター
The 'ippget' Delivery Method does not define any addition Subscription Template attributes and has the conformance requirements for Subscription Template attributes defined in [RFC3995]. This section defines additional information about Subscription Template attributes defined in [RFC3995].
「ippgetは、」配信方法は、任意の追加サブスクリプションテンプレートの属性を定義して、[RFC3995]で定義されたサブスクリプションテンプレート属性の適合性要件を持っていません。このセクションでは、[RFC3995]で定義されたサブスクリプションテンプレートの属性に関する追加情報を定義します。
This Subscription Template attribute identifies the Pull Delivery Method to be used for the Subscription Object (see [RFC3995]). To support the 'ippget' Pull Delivery Method defined in this document, the Printer MUST support this attribute with the following keyword value:
このサブスクリプション・テンプレートの属性は（[RFC3995]を参照）サブスクリプションオブジェクトに使用するプル配信方法を特定します。この文書で定義された「ippget」プル配信方法をサポートするために、プリンタには、以下のキーワードの値でこの属性をサポートしなければなりません：
'ippget': Indicates that the 'ippget' Pull Delivery Method is to be used for this Subscription Object.
「ippgetは」：「ippget」プル配信方法は、このサブスクリプション・オブジェクトのために使用されるべきであることを示します。
The 'ippget' Delivery Method has the conformance requirements for Subscription Description attributes defined in [RFC3995]. The 'ippget' Delivery Method does not define any addition Subscription Description attributes.
「ippget」配送方法は[RFC3995]で定義されたサブスクリプションの説明属性の適合性要件を持っています。 「ippget」配信方法は、任意の追加のサブスクリプションの説明属性を定義していません。
This section defines additional Printer Description attributes for use with the 'ippget' Delivery Method.
このセクションでは、追加のプリンタ記述は、「ippget」配送方法で使用するための属性を定義します。
This Printer Description attribute specifies the Event Life value that the Printer assigns to each Event; i.e., the number of seconds after an Event occurs during which a Printer will return that Event in an Event Notification in a Get-Notifications response. After the Event Life expires for the Event, the Printer MAY no longer return an Event Notification for that Event in a Get-Notifications response.
このプリンタ記述属性は、プリンタが各イベントに割り当てるイベントライフ値を指定します。すなわち、イベント後の秒数は、プリンタがゲット-通知応答でイベント通知にそのイベントを返される時に発生します。イベントライフイベントのために有効期限が切れた後、プリンタはもはや入手-通知応答でそのイベントのイベント通知を返さないかもしれません。
The Printer MUST support this attribute if it supports the 'ippget' Delivery Method. The value MUST be 15 or more (at least 15 seconds), and 60 (seconds) is the RECOMMENDED value to align with the PWG Job Monitoring MIB [RFC2707] jmGeneralJobPersistence and jmGeneralAttributePersistence objects.
それはippget "配送方法をサポートしている場合、プリンタは、この属性をサポートしなければなりません。値が15以上（少なくとも15秒）、及び60（秒）PWGジョブ監視MIB [RFC2707] jmGeneralJobPersistenceとjmGeneralAttributePersistenceオブジェクトと整列することを推奨値でなければなりません。
For example, assume the following:
たとえば、次のことを前提としています。
1. A client performs a Job Creation operation that creates a Subscription Object associated with the 'ippget' Delivery Method;
1.クライアントが「ippget」配送方法に関連付けられたサブスクリプション・オブジェクトを作成し、雇用創出操作を行います。
2. An Event associated with the new Job occurs immediately after the Subscription Object is created;
2.新しい仕事に関連したイベントは、サブスクリプションオブジェクトが作成された直後に発生します。
3. the same client or some other client performs a Get-Notifications operation so that the client is connected N seconds after the Job Creation operation.
3.同じクライアントまたは他のクライアントは、クライアントがジョブ作成操作後N秒に接続されているようには、Get-通知動作を実行します。
Then, if N is less than the value of this attribute, the client(s) performing the Get-Notifications operations can expect not to miss any Event-Notifications, barring some unforeseen lack of memory space in the Printer. Note: The client MUST initiate the Get-Notifications at a time that is sufficiently less that N seconds to account for network latency so that it is connected to the Printer before N seconds elapses.
Nは、この属性の値よりも小さい場合次に、は、Get-通知の操作を実行するクライアント（複数可）プリンタにメモリ空間の一部不測の欠如を除けば、すべてのイベントの通知を見逃さないように期待することができます。注意：クライアントが十分に少ないそれがN秒経過する前に、プリンタに接続されるように、N秒がネットワークの遅延を考慮していることである時には、Get-通知を開始しなければなりません。
If a Printer supports the 'ippget' Delivery Method, it MUST keep 'completed', 'canceled', or 'aborted' Job objects in the Job Retention and/or Job History phases for at least as long as this attribute's value. The Printer MAY retain jobs longer that this value. See [RFC2911], section 4.3.7.1, and the discussion in [RFC3995] (regarding the 'job-completed' event). The latter explains that a Notification Recipient can query the Job after receiving a 'job-completed' Event Notification in order to find out other information about the job that is 'completed', 'aborted', or 'canceled'. However, this attribute has no effect on the Cancel-Subscription operation, which deletes the Subscription object immediately whether or not it contains the "notify-pull-method" attribute with the 'ippget' keyword value. Immediately thereafter, subsequent Get-Notifications Responses MUST NOT contain Event Notifications associated with the canceled Subscription object.
プリンタは「ippget」配信方法をサポートしている場合、それは、「キャンセル」「完了」、または少なくとも限り、この属性の値としてのジョブの保存および/またはジョブ履歴の段階でジョブオブジェクトを「中止に」続けなければなりません。プリンタが長く、この値はそのジョブを保持することができます。 （「ジョブ完了」イベントに関する）[RFC2911]、セクション4.3.7.1、および[RFC3995]での議論を参照してください。後者は、通知の受信者は、「中止に」、または「キャンセル」、「完了」はジョブに関するその他の情報を見つけるために、「ジョブ完了」イベント通知を受けた後、ジョブを照会することができることを説明しています。ただし、この属性は、それが「ippget」キーワードの値を持つ「通知プル方式」属性が含まれているかどうかをすぐにサブスクリプションオブジェクトを削除キャンセル・サブスクリプションの動作には影響を与えません。その直後、その後の取得・通知の応答はキャンセルSubscriptionオブジェクトに関連付けられたイベント通知を含めることはできません。
This section defines additional values for existing Printer Description attributes as defined in [RFC3995].
[RFC3995]で定義されるように、このセクションでは、既存のプリンタ記述属性の追加の値を定義します。
The following keyword value for the "notify-pull-method-supported" attribute is added in order to support the new Delivery Method defined in this document:
「通知プル方式がサポート」については、以下のキーワード値は、属性は、この文書で定義された新しい配信方法をサポートするために追加されます：
'ippget': The IPP Notification Pull Delivery Method defined in this document.
「ippget」：この文書で定義されたIPP通知プル配信方法。
Table 7 lists the "operation-id" value defined in order to support the new Get-Notifications operation defined in this document.
表7に、このドキュメントで定義された新しいゲット-通知の操作をサポートするために定義された「オペレーション-ID」の値。
Table 7. Operation-id Assignments
表7.操作-IDの割り当て
Value Operation Name
バリュー操作名
0x001C Get-Notifications
0x001Cは、Get-通知
The following status code is defined as an extension for this Delivery Method and is returned as the status code of the Get-Notifications operation in Group 1 or Group 3 to N (see section 5.2).
次のステータスコードは、この送達方法に拡張として定義され、N（セクション5.2を参照）グループ1又はグループ3でGet-通知オペレーションのステータスコードとして返されます。
The Printer MUST return the 'successful-ok-events-complete' status code to indicate when this Get-Notifications response is the last response for a Subscription object, whether or not there are Event Notifications being returned. This condition occurs for Event Wait Mode with Notification Recipients waiting for responses when (1) the Subscription Object is canceled with a Cancel-Subscription operation, (2) the Subscription object is deleted, when the Per-Printer Subscription lease time expires, or (3) the 'job-completed' event occurs for a Per-Job Subscription. This condition also occurs for a Get-Notifications request that a Notification Recipient makes after the job completes, but before the Event Life expires.
プリンタは、この取得-通知応答が返されるイベント通知があるかどうかにかかわらず、サブスクリプションオブジェクトに対する最後の応答であることを示すために「成功-OK-イベント-完了」ステータスコードを返さなければなりません。この条件は、（2）サブスクリプションオブジェクトはプリンタ毎のサブスクリプションのリース期間が満了したときに、削除、またはされた通知の受信者は、（1）サブスクリプションオブジェクトがキャンセル・サブスクリプション操作でキャンセルされた応答を待っていると、イベントウェイトモードで発生します（ 3）「ジョブ完了」イベントは、ジョブごとのサブスクリプションのために発生します。この条件はまた、ジョブが完了した後、通知受信者はなりますが、イベントライフの有効期限が切れる前には、Get-通知要求のために発生します。
This section defines the encoding and transport considerations for this Delivery Method based on [RFC2910].
このセクションでは、[RFC2910]に基づいて、この送達方法に符号化及びトランスポート考慮事項を規定しています。
The encoding of a Get-Notifications Response is modeled after the Get-Jobs Response (see [RFC2911]). In a Get-Notifications Response, each Event Notification Attributes Group MUST start with an 'event-notification-attributes-tag' (see the section "Encodings of Additional Attribute Tags" in [RFC3995]), and end with an 'end-of-attributes-tag'. In addition, for Event Wait Mode the multi-part/related is used to separate each multiple response (in time) to a single Get-Notifications Request.
Get-通知レスポンスのエンコーディングを取得し、ジョブの応答の後にモデル化されている（参照[RFC2911]）。 Get-通知応答では、各イベントの通知は、当社グループは、「イベント通知属性タグ」（[RFC3995]で「その他の属性タグのエンコーディング」を参照）、および「末端-ので終わるで始まるなければならない属性-attributesタグ」。また、イベントは、マルチパート/関連モードを待機するために、単一のGet-通知要求に（時間的に）各複数の応答を分離するために使用されます。
The Printer returns Get-Notification Response as follows:
プリンタのリターンは、Get-通知応答を次のように：
1. If the Notification Recipient client did not request Event Wait Mode ("notify-wait" = 'false' or omitted), the Printer ends the response with an 'end-of-attributes-tag' (see [RFC2911], Get-Jobs encoding), as with any operation response.
1.通知受信者のクライアントは、イベント（「通知待ちを」= falseまたは省略）モードを待って要求しなかった場合は、プリンタが「エンド・オブ・属性タグ」で応答を終了する（[RFC2911]を参照してください、ゲット任意の動作応答と同様-Jobsエンコーディング）。
2. If the Notification Recipient client requests Event Wait Mode ("notify-wait" = 'true') and the Printer wishes to honor the request, the Printer MUST return the response as an application/ipp part inside a multi-part/related MIME media type. When one or more additional Events occur, the Printer returns each as an additional Event Notification Group using a separate application/ipp part under the multi-part/related type.
2.通知の受信者のクライアントは、イベント（「通知待ち」=「真」）モードを待って要求し、プリンタが要求を尊重することを希望する場合は、プリンタがマルチパート/関連内部アプリケーション/ IPPの一部として応答を返さなければなりませんMIMEメディアタイプ。 1つのまたは複数の追加のイベントが発生した場合、プリンタは、マルチパート/関連タイプの下に別個のアプリケーション/ IPPの一部を使用して、追加のイベント通知グループとしてそれぞれを返します。
3. If the client requested Event Wait Mode ("notify-wait" = 'true'), but the Printer does not wish to honor the request in the initial response and wants the client explicitly polled for Event Notifications, the Printer MUST return the "notify-get-interval" operation attribute (see section 5.2.1). The Printer returns the
3.クライアントは、イベントモードを待って要求された場合（=「真」「待ち通知」）が、プリンタが初期応答で要求を尊重したいと明示的にイベント通知のためにポーリングクライアントを望んでいない、プリンターを返さなければなりません「通知・取得間隔」操作属性を（セクション5.2.1を参照してください）。プリンタを返します
response as an application/ipp part that MAY be inside an multi-
part/related type. The client MUST accept this response and
reissue the Get-Notifications request in the future indicated by
the value of the "notify-get-interval" attribute value.
4. If the client requested Event Wait Mode ("notify-wait" = 'true'), and the Printer initially honored the request but later wishes to leave Event Wait Mode, the Printer MUST return the "notify-get-interval" operation attribute (see section 5.2.1). The Printer returns the response as an application/ipp part that MUST be inside an multi-part/related type.
4.イベント（=「真」「通知待ち」）モードを待って要求したクライアント、およびプリンタが最初に要求を光栄が、後のイベントは、モードを待って残すことを希望する場合、返さなければならないプリンタ「通知・取得間隔」の操作属性（セクション5.2.1を参照してください）。プリンタは、マルチパート/関連型内に配置する必要があり、アプリケーション/ IPPの一部として応答を返します。
NOTE: If a Notification Recipient fails to receive a response, it can ask the Printer for the same Event Notifications again. The Notification Recipient will receive the same Event Notifications that it should have received the first time, except for those Event Notifications that have expired in the meantime.
注：通知の受信者が応答を受信できなかった場合は、再度同じイベント通知用プリンタを求めることができます。通知の受信者は、それがその間に期限が切れたものをイベント通知を除いて、最初の時間を受け取っているはず同じイベント通知を受け取ることになります。
The Printer MAY chunk the responses, but this has no significance to the IPP semantics.
プリンタMAYチャンクは応答が、これはIPPのセマンティクスに意味はありません。
This notification delivery method uses the IPP transport and encoding [RFC2910] for the Get-Notifications operation with the following extension, allocated in [RFC3995]:
この通知配信方法は、次の拡張、[RFC3995]に割り当てられたとは、Get-通知動作のためIPP輸送およびエンコーディング[RFC2910]を使用します。
Table 8. The "event-notification-attributes-tag" Value
表8.「イベント通知属性タグ」バリュー
Tag Value (Hex) Meaning
タグ値（16進数）の意味
0x07 "event-notification-attributes-tag"
0x07の「イベント通知属性タグ」
This section lists the conformance requirements for clients and Printers.
このセクションでは、クライアントとプリンタの適合性要件を示しています。
It is OPTIONAL for a Printer to support IPP Notifications as defined in [RFC3995]. However, if a Printer supports IPP Notifications, the Printer MUST support the 'ippget' Delivery Method, as defined in this document, as one of its Delivery Methods. IPP Printers that conform to this specification
[RFC3995]で定義されているプリンタがIPPの通知をサポートすることは任意です。プリンタがIPPの通知をサポートしている場合、その送達方法の一つとして、この文書で定義されているようしかし、プリンタは、「ippget」配送方法をサポートしなければなりません。この仕様に準拠してIPPプリンタ
1. MUST meet the conformance requirements defined in [RFC3995] for a Pull Delivery Method;
1.プル送達方法に[RFC3995]で定義された適合性要件を満たさなければなりません。
2. MUST support the Get-Notifications operation defined in section 5, including Event Wait Mode;
2.イベントモードを待っ含めて、セクション5で定義されます。Get-通知の操作をサポートしなければなりません。
3. MUST support the Subscription Template object attributes, as defined in section 6;
セクション6で定義されるよう3.サブスクリプションテンプレートオブジェクトの属性をサポートしなければなりません。
4. MUST support the Subscription Description object attributes, as defined in section 7;
セクション7で定義されるように4.契約内容オブジェクト属性をサポートしなければなりません。
5. MUST support the "ippget-event-life" Printer Description attribute defined in section 8.1, including retaining jobs in the Job Retention and/or Job History phases for at least as long as the value specified by the Printer's "ippget-event-life";
5.少なくとも同じ長プリンタの「ippget-event-で指定された値としてのジョブの保存および/またはジョブ履歴の段階で保持ジョブを含むセクション8.1で定義された「ippget・イベント・ライフ」プリンタ記述属性を、サポートしなければなりません生活";
6. MUST support the additional values for IPP/1.1 Printer Description attributes defined in section 9;
6.セクション9で定義されたIPP / 1.1プリンタ記述属性の追加の値をサポートしなければなりません。
7. MUST support the 'successful-ok-events-complete' status code, as described in section 10.1;
セクション10.1で説明したように7は、「成功した-OK-イベント-完了」ステータスコードをサポートしなければなりません。
8. MUST listen for the IPP Get-Notifications operation requests on IANA-assigned well-known port 631, unless explicitly configured by system administrators or site policies;
明示的に、システム管理者またはサイトのポリシーによって構成されていない限り8.、IANAによって割り当てられたwell-knownポート631上のIPPは、Get-通知を操作要求を待機しなければなりません。
9. SHOULD NOT listen for IPP Get-Notifications operation requests on any other port, unless explicitly configured by system administrators or site policies; and
明示的に、システム管理者またはサイトのポリシーによって構成されていない限り9は、他のポート上のIPPが入手-通知を操作要求を聞くべきではありません。そして
10. MUST meet the security conformance requirements stated in section 18.4.
10.セクション18.4に記載されたセキュリティ上の適合性要件を満たす必要があります。
It is OPTIONAL for an IPP Client to support IPP Notifications as defined in [RFC3995]. However, if a client supports IPP Notifications, the client MUST support the 'ippget' Delivery Method as defined in this document as one of its Delivery Methods. IPP Clients that conform to this specification:
[RFC3995]で定義されるようにIPPクライアントは、IPP通知をサポートすることは任意です。クライアントは、IPPの通知をサポートしている場合、その送達方法の一つとして、この文書で定義されているようしかし、クライアントが「ippget」配送方法をサポートしなければなりません。この仕様に準拠してIPPクライアント：
1. MUST create Subscription Objects by sending Subscription Creation operation requests containing the "notify-pull-method" attribute (as opposed to the "notify-recipient-uri" attribute) using the 'ippget' keyword value (see sections 6.1 and 15.2);
1.「ippget」キーワードの値を使用します（セクション6.1及び15.2）（「通知受信者-URI」属性ではなく）「通知プル方式を」属性を含むサブスクリプションの作成操作要求を送信することによって、サブスクリプションオブジェクトを作成する必要があります;
2. MUST send IPP Get-Notifications operation requests (see section 5.1) via the port specified in the associated 'ipp' URL (if present) or otherwise via IANA-assigned well-known port 631;
; 2. IPPにIANAによって割り当てられたwell-knownポート631を介して、関連する「IPP」URL（存在する場合）または他の方法で指定されたポートを介して取得し、通知の操作要求（セクション5.1を参照）を送信しなければなりません
3. MUST convert the associated 'ipp' URLs for use in IPP Get-Notifications operation to their corresponding 'http' URL forms for use in the HTTP layer, according to the rules in section 5, "IPP URL Scheme", in [RFC2910]; and
3. [RFC2910に、セクション5の規則に従ってHTTP層に使用するためのそれらの対応する「HTTP」URLフォーム、「IPP URLスキーム」をIPPには、Get-通知の操作に使用するための関連した「IPP」URLを変換する必要があります];そして
4. MUST meet the security conformance requirements stated in section 18.5.
4.セクション18.5に記載されたセキュリティ上の適合性要件を満たす必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]エリオ、R.、バトラー、S.、ムーア、P.、ターナー、R.、およびJ. Wenn、 "インターネット印刷プロトコル/ 1.1：コード化とTransport"、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]ヘイスティングズ、T.、エリオ、R.、deBry、R.、Isaacson氏、S.、およびP.パウエル、 "インターネット印刷プロトコル/ 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]エリオ、R.とT.ヘイスティングズ、 "インターネット印刷プロトコル（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]エリオ、R.、バトラー、S.、ムーア、P.、およびR.ターナー、 "インターネット印刷プロトコル/ 1.0：コード化とTransport"、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.、ヘイスティングズ、T.、エリオ、R.、Isaacson氏、S.、およびP.パウエル、 "インターネット印刷プロトコル/ 1.0：モデルと意味論"、RFC 2566、1999年4月。
[RFC2567] Wright, F., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567]ライト、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.
"LPDとIPPプロトコルとの間のマッピング" [RFC2569]エリオ、R.、ヘイスティングス、T.、ジェイコブズ、N.、およびJ.マーチン、RFC 2569、1999年4月。
[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月。
[RFC2707] Bergman, R., Hastings, T., Isaacson, S., and H. Lewis, "Job Monitoring MIB - V1.0", RFC 2707, November 1999.
[RFC2707]バーグマン、R.、ヘイスティングス、T.、アイザックソン、S.、およびH.ルイス、 "ジョブ監視MIB - V1.0"、RFC 2707、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月。
[RFC3997] Hastings, T., Ed., deBry, R., and H. Lewis, "Internet Printing Protocol (IPP): Requirements for IPP Notifications", RFC 3997, March 2005.
[RFC3997]ヘイスティングズ、T.、エド、deBry、R.、およびH.ルイス、 "インターネット印刷プロトコル（IPP）：IPP通知のための要件"、RFC 3997、2005年3月。
This section contains the exact information that the IANA has added to the IPP Registries according to the procedures defined in [RFC2911], section 6. These registrations have been published in the http://www.iana.org/assignments/ipp-registrations registry.
このセクションでは、IANAは[RFC2911]で定義された手順に従ってIPPレジストリに追加されたことを正確な情報が含まれ、セクション6は、これらの登録はhttp://www.iana.org/assignments/ipp-registrationsに公開されていますレジストリ。
The following table lists the attributes defined in this document. This has been registered according to the procedures in RFC 2911 [RFC2911] section 6.2.
次の表に、この文書で定義された属性を示します。これは、RFC 2911 [RFC2911]セクション6.2の手順に従って登録されています。
Printer Description attributes: Reference Section
------------------------------- --------- -------
ippget-event-life (integer(15:MAX)) [RFC3996] 8.1
15.2. Delivery Method and Additional Keyword Attribute Value Registrations for Existing Attributes
15.2. 既存の属性のための配信方法と追加のキーワード属性値登録
This section lists additional keyword attribute value registrations for use with existing attributes defined in other documents. These have been registered according to the procedures in [RFC2911], section 6.1. According to [RFC3995], section 24.7.3, Pull Delivery Method registrations are the keyword attribute value registrations for the "notify-pull-method" and "notify-pull-method-supported" attributes.
他のドキュメントで定義された既存の属性で使用するためにこのセクションで追加のキーワード属性値の登録。これらは、[RFC2911]の手順、セクション6.1に従って登録されています。 [RFC3995]、セクション24.7.3によると、配信方法の登録を引き、「通知プル方式」のキーワード属性値の登録であり、属性「通知プル方式でサポートされています」。
Attribute (attribute syntax)
Values Reference Section
----------------------- --------- -------
notify-pull-method (type2 keyword) [RFC3995] 5.3.2
notify-pull-method-supported (1setOf type2 keyword)
[RFC3995] 5.3.2.1
ippget [RFC3996] 9.1
The following table lists the enum attribute values defined in this document. These have been registered according to the procedures in [RFC2911], section 6.1.
次の表に、この文書で定義された列挙型の属性値を示しています。これらは、[RFC2911]の手順、セクション6.1に従って登録されています。
Attribute (attribute syntax)
Value Name Reference Section
------ ----------------------------- --------- -------
operations-supported (1setOf type2 enum) [RFC2911] 4.4.15
0x001C Get-Notifications [RFC3996] 9.2
The following table lists the operations defined in this document. This has been registered according to the procedures in RFC 2911 [RFC2911] section 6.4.
次の表に、この文書で定義された操作を示しています。これは、RFC 2911 [RFC2911]セクション6.4の手順に従って登録されています。
Operations: Reference Section
----------- --------- -------
Get-Notifications [RFC3996] 5
The following table lists the status codes defined in this document. This has been registered according to the procedures in [RFC2911], section 6.6.
次の表に、この文書で定義されたステータスコードを示しています。これは、[RFC2911]の手順、セクション6.6に従って登録されています。
Status codes: Reference Section
------------- --------- -------
successful-ok-events-complete (0x0007) [RFC3996] 10.1
The IPP Printer MUST localize the "notify-text" attribute as specified in section 14 of [RFC3995].
[RFC3995]のセクション14で指定されるようにIPPプリンタは、「通知テキスト」属性をローカライズしなければなりません。
In addition, when the client receives the Get-Notifications response, it is expected to localize the attributes that have the 'keyword' attribute syntax according to the charset and natural language requested in the Get-Notifications request.
クライアントがGET-通知応答を受信した場合に加えて、「キーワード」を持つ属性をローカライズすることが期待されている文字セットとGet-通知要求で要求された自然言語に応じた属性構文を。
The IPP Model and Semantics document [RFC2911, section 8] discusses high-level security requirements (Client Authentication, Server Authentication and Operation Privacy). The IPP Transport and Encoding document [RFC2910, section 8] discusses the security requirements for the IPP protocol. Client Authentication is the mechanism by which the client proves its identity to the server in a secure manner. Server Authentication is the mechanism by which the server proves its identity to the client in a secure manner. Operation Privacy is defined as a mechanism for protecting operations from eavesdropping.
IPPモデルと意味論の文書[RFC2911、セクション8]は、高レベルのセキュリティ要件（クライアント認証、サーバー認証と運用プライバシー）について説明します。 IPPトランスポート符号化文書[RFC2910、セクション8]はIPPプロトコルのためのセキュリティ要件を論じています。クライアント認証は、クライアントが安全な方法でサーバにその身元を証明するメカニズムです。サーバー認証は、サーバが安全な方法でクライアントにその身元を証明するメカニズムです。操作プライバシーを盗聴からの操作を保護するための機構として定義されます。
The 'ippget' Delivery Method with its Get-Notifications operations leverages the security mechanism that are used in IPP/1.1 [RFC2910 and RFC2911] without adding any additional security mechanisms in order to maintain the same security support as IPP/1.1.
その取得-通知操作と「ippget」発送方法はIPP / 1.1と同じセキュリティ・サポートを維持するために追加のセキュリティ機構を追加することなく、IPP / 1.1 [RFC2910及びRFC2911]で使用されるセキュリティメカニズムを活用します。
The access control model for the Get-Notifications operation defined in this document is the same as the access control model for the Get-Job-Attributes operation (see [RFC2911], section 3.2.6). The primary difference is that a Get-Notifications operation is directed at Subscription Objects rather than at Job objects, and a returned attribute group contains Event Notification attributes rather than Job object attributes.
この文書で定義されて取得し、通知動作のためのアクセス制御モデル（[RFC2911]、セクション3.2.6を参照）を取得し、ジョブ・属性動作のためのアクセス制御モデルと同じです。主な違いは、Get-通知操作がサブスクリプションのオブジェクトではなく、仕事のオブジェクトに向けて、返された属性グループは、イベント通知ではなく、ジョブオブジェクトの属性よりも属性が含まれていることです。
The Notification Recipient client MUST have the following access rights to the Subscription object(s) targeted by the Get-Notifications operation request:
通知の受信者のクライアントは、Get-通知を操作要求の対象となるサブスクリプションオブジェクト（複数可）に以下のアクセス権を持っている必要があります。
The authenticated user (see [RFC2911], section 8.3) performing this operation MUST be (1) the owner of each Subscription Object identified by the "notify-subscription-ids" operation attribute (see section 5.1.1), (2) an operator or administrator of the Printer (see [RFC2911], sections 1 and 8.5), or (3) otherwise authorized by the Printer's administrator-configured security policy to request Event Notifications from the target Subscription Object(s). Furthermore, the Printer's security policy MAY limit the attributes returned by the Get-Notifications operation, in a manner similar to that of the Get-Job-Attributes operation (see [RFC2911], end of section 3.3.4.2).
認証されたユーザは、（1）「通知サブスクリプション-ID」を操作属性によって識別される各サブスクリプション・オブジェクトの所有者は、（2）AN（セクション5.1.1を参照）である必要があり、この操作を実行する（[RFC2911]、セクション8.3を参照します）オペレータまたは管理者プリンタ（セクション1および8.5、[RFC2911]を参照されたい）、または（3）そうでなければターゲット・サブスクリプション・オブジェクト（複数可）からのイベント通知を要求するために、プリンタの管理者が設定したセキュリティポリシーによって許可。さらに、プリンタのセキュリティポリシーは、（、セクション3.3.4.2の終わりに[RFC2911]を参照）には、Get-ジョブ・属性の操作と同様に、取得・通知操作で返される属性を制限することがあります。
Because the Get-Notifications operation is sent in the same direction as are Job Creation operations, usually by the same client, this Event Notification Delivery Method poses no additional authentication, authorization, privacy, firewall, or port assignment issues above those for the IPP Get-Job-Attributes and Get-Printer-Attributes operations (see [RFC2911], sections 3.2.6 and 3.2.5).
通常、同じクライアントによって、雇用創出操作しているようには、Get-通知操作が同じ方向に送信されるため、このイベント通知の配信方法は、IPPのものの上に追加の認証、許可、プライバシー、ファイアウォール、またはポートの割り当ての問題を提起していない取得-job-属性およびGet-プリンタは、属性の操作（セクション3.2.6と3.2.5、[RFC2911]を参照）。
Unwanted Events Notifications (spam): Unlike Push Event Notification Delivery Methods in which the IPP Printer initiates the Event Notification, with the Pull Delivery Method defined in this document, the Notification Recipient is the client that initiates the Get-Notifications operation (see section 5). Therefore, with this method there is no chance of "spam" notifications.
不要なイベント通知（スパム）：この文書で定義されたプル配信方法とIPPプリンターは、イベント通知を開始するプッシュイベント通知配信方法とは異なり、通知の受信者が取得し、通知の操作を開始するクライアントである（セクション5を参照してください）。したがって、この方法では、「スパム」の通知の可能性はありません。
Note: When a client stays connected to a Printer by using the Event Wait Mode (see section 5.1.3) in order to receive Event Notifications as they occur, it can close down the IPP connection at any time and so can avoid future unwanted Event Notifications at any time.
注意：クライアントがイベントのウェイトモードを使用してプリンタに接続されたままと、それらが発生すると、それはいつでもIPP接続を閉鎖することができ、イベント通知を受信するために（セクション5.1.3を参照）ので、将来の不要なイベントを回避することができますいつでも通知。
It is true that the client has control over whether to ask for Event Notifications. However, if the client subscribes to an event and does a Get-Notifications request, it gets all events for the Subscription Object in the sequence number range (see section 5.1.2), not just those it wants. If a client subscribes to a Per-Printer Subscription job event, such as 'job-completed', and someone then starts and cancels thousands of jobs, the client would have to receive these events in addition to those it is interested in. A client can protect itself better by subscribing to its own jobs by using a Per-Job Subscription, rather than create a Per-Printer subscription whose Job events apply to all jobs.
クライアントがイベント通知を求めるかどうかを制御していることは事実です。クライアントがイベントをサブスクライブとは、Get-通知要求を行う場合は、それが望んでいるものをだけではなく、（セクション5.1.2を参照）、シーケンス番号の範囲内のサブスクリプションオブジェクトのすべてのイベントを取得します。クライアントは、このような「ジョブ完了」として、ペイ・パー・プリンタ・サブスクリプション・ジョブ・イベントをサブスクライブし、誰かが、その後起動し、ジョブの数千人をキャンセルした場合、クライアントは、それが興味を持っているものに加えて、これらのイベントを受信する必要があります。クライアントをその仕事のイベントはすべてのジョブに適用されるプリンタごとのサブスクリプションを作成するのではなく、ジョブごとのサブスクリプションを使用して、独自のジョブをサブスクライブすることによって、より良い自分自身を保護することができます。
For the Get-Notifications operation defined in this document, the same Printer conformance requirements apply for supporting and using Client Authentication, Server Authentication and Operation Privacy as stated in [RFC2910] section 8 for all IPP operations.
この文書で定義されます。Get-通知動作の場合、同じプリンタの適合性要件は、すべてのIPP操作のための[RFC2910]セクション8に記載されているようにサポートし、クライアント認証、サーバー認証と運用プライバシーを使用するために適用されます。
For the Get-Notifications operation defined in this document, the same client conformance requirements apply for supporting and using Client Authentication, Server Authentication, and Operation Privacy as stated in [RFC2910], section 8, for all IPP operations.
この文書で定義されます。Get-通知動作の場合、同じクライアントの適合性要件は、すべてのIPP操作のために、セクション8、[RFC2910]で述べたようにサポートし、クライアント認証、サーバー認証、および運用プライバシーを使用するために適用されます。
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]
以下のための構造とモデルとプロトコルのためのインターネット印刷プロトコル[RFC2567]原理の設計目標インターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/ 1.1：モデルと意味論[RFC2911]インターネット印刷プロトコル/ 1.1：コード化と輸送[RFC2910]インターネット印刷プロトコル/ 1.1：LPDとIPPプロトコル間のImplementerのガイド[RFC3196]のマッピング[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.
「インターネット印刷プロトコルの設計目標は、」分散印刷機能で幅広い見てみると、それはインターネットのための印刷プロトコルに含まれる必要な機能を明確に役立つ実際のシナリオを列挙します。エンドユーザー、オペレータ、および管理者：これは、ユーザーの3種類の要件を識別します。それはIPP / 1.0 [RFC2566、RFC2565]で満たされているエンドユーザ要件のサブセットを呼び出します。いくつかの任意のオペレータ操作がIPP / 1.1に追加されました。
"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 working group's major decisions.
「インターネット印刷プロトコルのための構造とモデルとプロトコルのための理論的根拠は、」IPPは、高レベルのビューから説明IPP仕様書の一式を形成する様々な文書のためのロードマップを定義し、IETFワーキンググループのための背景や根拠を与えます主要な決定。
"Internet Printing Protocol/1.1: Model and Semantics" describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport. It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It 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 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：コード化とTransportは、」HTTP / 1.1 [RFC2616]にモデル文書で定義された抽象操作と属性の正式なマッピングです。これは、「アプリケーション/ 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）実装の間のゲートウェイの実装にいくつかのアドバイスを提供します。
Carl Kugler and Harry Lewis contributed the basic idea of in-band "smart polling" coupled with multiple responses for a single operation on the same connection, with one response for each event as it occurs. Without their continual persuasion, we would not have arrived at this Delivery Method specification and would not have been able to agree on a single REQUIRED Delivery Method for IPP.
カール・クーグラーとハリー・ルイスは、それが発生すると、各イベントに1つの応答で、同じ接続上の単一の操作のために複数の応答と相まってインバンド「スマートポーリング」の基本的な考え方を貢献しました。彼らの継続的な説得がなければ、私たちは、この配送方法の仕様に到着しなかったであろうとIPPのための単一のREQUIRED配信方法に同意することはできなかったでしょう。
Carl Kugler IBM Corporation 6300 Diagonal Highway Boulder, CO 80301
カール・クーグラーIBMコーポレーション6300対角ハイウェイボルダー、CO 80301
EMail: kugler@us.ibm.com
メールアドレス：kugler@us.ibm.com
Authors' Addresses
著者のアドレス
Robert Herriot Global Workflow Solutions 706 Colorado Ave. Palo Alto, CA 94303
ロバート・ヘリオットグローバルワークフローソリューション706コロラドアベニュー。パロアルト、CA 94303
Phone: 650-324-4000 EMail: bob@herriot.com
電話：650-324-4000 Eメール：bob@herriot.com
Thomas N. Hastings Xerox Corporation 710 S Aviation Blvd. ESAE 242 El Segundo CA 90245
トーマスN.ヘイスティングスゼロックス社710 S航空ブルバードESAE 242エルセグンドーCA 90245
Phone: 310-333-6413 Fax: 310-333-6342 EMail: hastings@cp10.es.xerox.com
電話：310-333-6413ファックス：310-333-6342 Eメール：hastings@cp10.es.xerox.com
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 Eメール：harryl@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。