RFC3996 日本語訳
3996 Internet Printing Protocol (IPP): The 'ippget' Delivery Methodfor Event Notifications. R. Herriot, T. Hastings, H. Lewis. March 2005. (Format: TXT=73638 bytes) (Updates RFC2911) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループR.エリオの要求をネットワークでつないでください: 3996のグローバルな作業フローソリューションアップデート: 2911年のT.ヘイスティングズカテゴリ: 2005年の標準化過程ゼロックスの社のH.ルイスのIBMの社の行進
Internet Printing Protocol (IPP):
The 'ippget' Delivery Method for Event Notifications
インターネット印刷プロトコル(IPP): イベント通知のための'ippget'発送方法
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはインターネットPrinting Protocol1.1に拡大について説明します: モデルと意味論(RFC2911、RFC2910)。 このドキュメントは「インターネット印刷は以下について議定書の中で述べ(IPP)」との使用に'ippget'Pull Delivery Methodを指定します。 「イベントNotificationsとSubscriptions」仕様(RFC3995)。 このIPPGET Delivery MethodはRFCが3995であるとサポートするすべてのクライアントとPrintersのためのREQUIREDです。 クライアントとして機能して、Notification Recipientは、本書では定義されたGet-通知操作を使用することによって、イベントNotificationsをとって来ます(引きます)。
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
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1。 順応用語. . . . . . . . . . . . . . . . 4 2.2。 他の用語. . . . . . . . . . . . . . . . . . . 4 3。 モデルと操作. . . . . . . . . . . . . . . . . . . . . 4 4。 総合案内. . . . . . . . . . . . . . . . . . . . . 5 5。 通知を得ている操作. . . . . . . . . . . . . . . . . 7 5.1。 通知を得ているRequest、.85.1、.1、購読イドに通知してください、(1setOf整数(1: MAX)8 5.1.2一連番号に通知している(1setOf整数(1: MAX))9
Herriot, et al. Standards Track [Page 1] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[1ページ]: 2005年の'ippget'発送方法行進
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
5.1.3. 待ちに通知している(論理演算子。). . . . . . . . . . . . . 10 5.2 通知を得ている応答。 . . . . . . . . . . . . . . 10 5.2 .1、通知、間隔を手に入れてください、(整数(0: MAX)。) . . . . . 13 5.2 .2 プリンタ動作可能時間(整数(1: MAX))。 . . . . . . . 14 6. 6.1 Subscription Template Attributes17に関して牽引力のメソッドに通知している追加情報(type2キーワード)。 . . . . . . . . . . 17 7. 購読記述属性. . . . . . . . . . . . . 18 8。 追加Printer記述Attributes. . . . . . . . . . 18 8.1ippgetイベントの寿命(整数(15: MAX)).189。 既存のプリンタ記述属性のための新しい値。 . . . 19 9.1 メソッドが支えた牽引力に通知している(1setOf type2キーワード).199.2は(1setOf type2 enum)を操作でサポートしました。 . . . . . . . 19 10. 新しいステータスコード。 . . . . . . . . . . . . . . . . . . . . . . 19 10.1. イベントが完成するうまくいっているOK(0×0007).20 11。 コード化と輸送。 . . . . . . . . . . . . . . . . . . . 20 12. 順応要件。 . . . . . . . . . . . . . . . . . . 21 12.1. IPPプリンタ. . . . . . . . . . . . . 21 12.2のための順応。 IPPクライアントのための順応。 . . . . . . . . . . . . . 22 13. 引用規格。 . . . . . . . . . . . . . . . . . . . . 23 14. 有益な参照。 . . . . . . . . . . . . . . . . . . . 23 15. IANA問題. . . . . . . . . . . . . . . . . . . . . 24 15.1。 登録証明書を結果と考えてください。 . . . . . . . . . . . . . . . 24 15.2. Existing Attributesのための配送MethodとAdditional Keyword Attribute Value登録証明書。 . . . . . . . . 24 15.3. 追加Enumは値. . . . . . . . . . . 25 15.4を結果と考えます。 操作登録証明書。 . . . . . . . . . . . . . . . 25 15.5. ステータスコード登録証明書。 . . . . . . . . . . . . . . 25 16. 国際化問題. . . . . . . . . . . . . 25 17。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 26 17.1。 通知受取人クライアントアクセス権。 . . . . . 26 17.2. プリンタ軍事的脅威. . . . . . . . . . . . . . . 27 17.3。 通知受取人軍事的脅威。 . . . . . . . 27 17.4. プリンタ. . . . . . . . . . 27 17.5のためのセキュリティ要件。 クライアントのためのセキュリティRequirements。 . . . . . . . . . . 28 18. 基地のIPPの記述は(有益)の.28 19を記録します。 貢献者。 . . . . . . . . . . . . . . . . . . . . . . . . 29人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 30の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 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
1を見送ってください。 発送方法に関する情報。 . . . . . . . . . 5 テーブル2。 そして、組み合わせ、「待ちに通知する、」、「ステータスコード」、「通知、間隔を手に入れてください、」 . . . . . . . . . . . . . . . . . 13 テーブル3。 イベント通知内容. . . . . . . . 15の属性は4を見送ります。 仕事のイベント. . . . . . . . . . . . . . . . . . . . . . . 16のためのイベント通知内容の追加属性
Herriot, et al. Standards Track [Page 2] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[2ページ]: 2005年の'ippget'発送方法行進
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
5を見送ってください。 EventsとSubscribed Eventsの組み合わせ、「仕事は」 .17Table6を印象で完成しました。 プリンタイベント. . . . . . . . . . . . . . . . . . . . . 17のためのイベント通知内容の追加属性は7を見送ります。 操作イド課題. . . . . . . . . . . . . . . . 19は8を見送ります。 「イベント通知属性タグ」値。 . . . . . 21
1. Introduction
1. 序論
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].
このドキュメントはPrintingプロトコル/1.1に拡大についてインターネットに説明します: そして、モデル、意味論[RFC2911]、[RFC2910。] このドキュメントは「インターネット印刷は以下について議定書の中で述べ(IPP)」との使用に'ippget'Pull Delivery Methodを指定します。 「イベントNotificationsとSubscriptions」仕様[RFC3995]。 このIPPGET Delivery Methodは[RFC3995]をサポートするすべてのクライアントとPrintersのためのREQUIREDです。 クライアントとして機能して、Notification Recipientは、本書では定義されたGet-通知操作を使用することによって、イベントNotificationsをとって来ます(引きます)。 ベースIPPドキュメントの記述に関しては、このドキュメントのセクション21を見てください。 IPP Event Notification Modelの記述に関しては、[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.
Eventが起こると、このPull Delivery Methodと共に、PrinterはしばらくEvent Lifeと呼ばれているEvent Notificationを取っておきます。 Notification Recipientは、Get-通知操作を使用することによって、Event Notificationsをとって来ます(引きます)。 この操作で、Printerは指定されたSubscriptionオブジェクトのために持たれていたすべてのEvent Notificationsを返します。 Notification Recipientが追加Event Notificationsを待つためにEvent Wait Modeオプションを選択したなら、Printerは、Eventsがトランザクションを使用することで起こるので非同期なGet-通知応答がNotification Recipientで起因したのでEvent NotificationsをNotification Recipientに返し続けるかもしれません。
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.
Notification Recipientが供することによってEvent Wait Mode(接続を終えることのない)を終えることができる、「待ちに通知する、」 その後のGet-通知要求における'誤った'値がある(論理演算子)属性。 -得てください。同様に、Printerが戻ることによってEvent Wait Mode(接続を終えることのない)を終えることができる、「通知、-」 (整数)操作がGet-通知応答でそれを結果と考える間隔は再試行する前に長く待つ方法をNotification Recipientに教えます。
2. Terminology
2. 用語
This section defines the following terms that are used throughout this document:
このセクションはこのドキュメント中で使用される次の用語を定義します:
Herriot, et al. Standards Track [Page 3] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[3ページ]: 2005年の'ippget'発送方法行進
2.1. Conformance Terminology
2.1. 順応用語
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.
用語を大文字で書く、OPTIONALには、NOT、REQUIRED、SHOULD、SHOULD NOT、5月はNOTを必要としなければならなくて、[RFC2119]と[RFC2911](セクション12.1)で定義されるように順応に関連する特別な意味がなければなりません。 実装が本書では定義された拡大をサポートするなら、これらの用語は当てはまります。 さもなければ、それらはそうしません。 これらの用語はこのドキュメントだけと順応を定義します。 それが別の方法で明らかに述べられない場合、それらは他のドキュメントに順応に影響しません。
2.2. Other terminology
2.2. 他の用語
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-通知RequestでNotification Recipientクライアントによって要求されていて、彼らが起こるときPrinterがEvent Notificationsの形のNotification Recipientへの操作応答をその後のGet-通知に送りますが、接続を開くように保つためにPrinterによって与えられたモード。
3. Model and Operation
3. モデルと操作
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"キーワード価値を持っているとき、Subscription Creation Operationでは、クライアントは、Printerが新しいSubscription Objectに関連しているEvent Notificationsに"ippget"Pull Delivery Methodを使用するよう要求しています。
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.
Eventが起こると、PrinterはEvent Notificationを生成しなければならなくて、Event Lifeをそれに割り当てなければなりません。 Printerは割り当てられたEvent LifeのためのEvent Notificationを持たなければなりません。
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
Notification RecipientがSubscriptionオブジェクトのためにEvent Notificationsを受け取りたがっているとき、それは、Subscriptionオブジェクトの購読イド(PrinterにそのSubscriptionオブジェクトのために持たれていたすべての満期になっていないEvent Notificationsを返させる)を供給しながら、Get-通知操作を実行します。 Notification Recipientが追加Event Notificationsを待つためにEvent Wait Modeオプションを選択したなら、Printerが、Eventを送り続けているのに従って、Get-通知要求への応答は無期限に続きます。
Herriot, et al. Standards Track [Page 4] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[4ページ]: 2005年の'ippget'発送方法行進
Notifications in the response as Events occur for that Subscription object.
Eventsとしての応答における通知はそのSubscriptionオブジェクトのために現れます。
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.
Notification RecipientがSubscription Creation操作を実行した後1秒以内にPer-仕事のSubscription ObjectsのためにEvent Notificationsを要求するとき、Notification RecipientはGet-通知操作を通常実行します。 Printerが少なくとも15秒間、Event Notificationsを取っておかなければならないので(セクション8.1を見てください)、Notification RecipientはSubscription CreationとGet-通知操作の間に起こるどんなEvent Notificationsもいなくて寂しそうにはありません。
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'Delivery Methodは主として(1) それが提出した仕事のために、Events(仕事のPer-仕事のSubscriptionオブジェクトからの)を手に入れたがっているクライアントと(2) Per-プリンタSubscriptionオブジェクトからすべての仕事かプリンタEventsを得たがっている特権があるクライアントのために設計されています。
4. General Information
4. 総合案内
If a Printer supports this Delivery Method, the following are its characteristics.
PrinterがこのDelivery Methodをサポートするなら、↓これはその特性です。
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'キーワード法Push Delivery MethodのためのURL体系名、またはPull Delivery Methodのためのキーワード名前メソッド名が何ですか?
2. Is the Delivery Method REQUIRED, REQUIRED
RECOMMENDED, or OPTIONAL for an IPP
Printer to support?
2. サポートにはIPP PrinterのためのDelivery Method REQUIRED、REQUIRED RECOMMENDED、またはOPTIONALがありますか?
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. Printerは、操作を提供するのに1つが新しいプロトコルIPPがそうするすべての輸送と配送を使用しますか? イベント通知内容。 すなわち、全体のネットワークスタックは何ですか?
4. Can several Event Notifications be Yes.
combined into a Compound Event
Notification?
4. 数個のEvent Notificationsがあることができる、はい. Compound Event Notificationに結合されていますか?
Herriot, et al. Standards Track [Page 5] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[5ページ]: 2005年の'ippget'発送方法行進
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. Delivery Methodは開始されます。(プッシュ?) This Delivery MethodはNotification Recipient(引く)であり、PrinterかPrinterによる牽引力のメソッドはプッシュメソッドの局面です、Printerが操作を開始しませんが。
6. Is the Event Notification content Machine Consumable.
Machine Consumable or Human
Consumable?
6. Event Notification内容はMachine Consumableですか? マシン消費できますか、人間消費できますか?
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に以下の質問に答えますか? Machine Consumable Event Notificationのために、[RFC3995]のセクション9.1で定義された値の表現とコード化は何です、そして、それの順応要件は何ですか? Human Consumable Event Notificationのために、それの[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. そして、IPPとしての潜在と信頼性のSameが何であるか、HTTPの基礎となる輸送と配送では、議定書を作ってください--輸送。
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としてのSameのセキュリティ局面はことです、そして、輸送と配送は議定書を作ります。 基本的なHTTP、それは輸送とファイアウォールで扱われます--例えば、どう同じ方向の、そして、したがって、新しくないファイアウォール問題
10. What are the content length None.
restrictions?
10. 何、Noneコンテンツの長さは制限ですか?
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 PrinterがEvent Notification内容を送るという情報の断片と順応要件が何ですか?
Herriot, et al. Standards Track [Page 6] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[6ページ]: 2005年の'ippget'発送方法行進
12. What are the additional Subscription None.
Template and/or Subscription
Description attributes and the
conformance requirements thereof?
12. 追加Subscription Noneは何ですか? テンプレート、そして/または、Subscription記述属性とそれの順応要件?
13. What are the additional Printer "ipp-event-life"
Description attributes and the (integer (15: MAX))
conformance requirements thereof?
13. 追加Printer「ippイベントの寿命」記述属性とそれの(整数(15: MAX))順応要件は何ですか?
5. Get-Notifications Operation
5. 通知を得ている操作
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オブジェクトのために持たれていたすべてのEvent Notificationsを返すようPrinterに要求するNotification Recipientの役割で行動しているクライアントによって発行されます。
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.
Printerはこの操作をサポートしなければならなくて、どんな状態([RFC2911]「プリンタ状態」と「プリンタ州の理由」属性を見る)でも要請を受け入れなければならなくて、同じ州に同じ「プリンタ州の理由」値で残らなければなりません。
When a Printer performs this operation, it MUST return all and only those Event Notifications
Printerがこの操作を実行するとき、それはそれらの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. 関連Subscription Objectの「購読イドに通知してください」Subscription記述属性は「購読イドに通知する」(1setOf整数(1: MAX))という操作属性ANDの値の1つと等しいですか?
2. whose associated Subscription Object contains the "notify-pull-
method" attribute and it has the 'ippget' keyword value, AND
2. だれの関連Subscription Objectが「牽引力に通知しているメソッド」の属性とそれを含むかに、'ippget'キーワード価値、ANDがあります。
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.、だれのもの、「一連番号に通知する、」、換算値より等しいか、またはすばらしい、「一連番号に通知する、」 ANDを供給するなら操作が結果と考える(1setOf整数(1: MAX))
4. whose Event Life has not yet expired AND
4. だれのEvent LifeはまだANDを吐き出していませんか?
5. where the Notification Recipient client has read-access rights to
the identified Subscription Object (see Access Rights paragraph
below).
5. Notification Recipientクライアントがアクセス権を特定に読み込んでいるSubscription Objectを持っている(以下のAccess Rightsパラグラフを見てください)ところ。
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
(a) 要求Event Wait Modeが供して、Notification Recipientクライアントがそうしなければならない、「待ちに通知する、」 a'本当'の値か(b)がある操作属性が省略することによってEvent Wait Modeを抑圧する、「」 操作属性か'誤った'値をそれに供給することによって、待ちに通知します。 次にEvent Wait Modeを終えるために、Notification Recipientクライアントは接続を終えなければなりません。 Event Wait Modeを終えるために、Printerがそうしなければならない、(a) 戻ってください、「通知、間隔を手に入れてください、」 操作
Herriot, et al. Standards Track [Page 7] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[7ページ]: 2005年の'ippget'発送方法行進
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.
(b) Get-通知応答(RECOMMENDEDの振舞い)か近くで接続を結果と考えてください。 「通知、間隔を手に入れてください、」 操作属性はその後のGet-通知要求を試みる前に長く待つ方法をNotification Recipientに教えます。
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).
アクセス権: (1) そうでなければ(2) Printer([RFC2911]を見てください、セクション1と8.5)、または(3)の操作属性(セクション5.1.1を見る)、オペレータまたは管理者が目標からEvent Notificationsを要求するのをPrinterの管理者によって構成された安全保障政策で認可した「購読イドに通知してください」によって特定されたそれぞれのSubscription Objectの所有者がSubscription Object(s)であったに違いないならこの操作を実行している認証されたユーザ([RFC2911]を見てください、セクション8.3)。 さもなければ、IPP Printerは操作を拒絶して、戻らなければなりません: 適宜'禁じられたクライアント誤り'、'誤りが認証しなかったクライアント'、または'誤りが権限を与えなかったクライアント'ステータスコード。 [RFC2911]を見てください、セクション3.3の端。その上、Printerの安全保障政策はGet-通知操作で返された属性を制限するかもしれません、Get仕事の属性操作のものと同様の方法で(.4 .2)。
5.1. Get-Notifications Request
5.1. 通知を得ている要求
The following groups of attributes are part of the Get-Notifications Request:
属性の以下のグループはGet-通知Requestの一部です:
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.
自然言語と文字コード: 「属性-charset」と「属性自然言語」属性[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]、セクション3.1.5で説明されるようにこの操作のための目標である「プリンタ-uri」(uri)操作属性。
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be
supplied by the client as described in [RFC2911], section 8.3.
ユーザ名を要求します: 「要求しているユーザ名」(名前(MAX))属性SHOULDが[RFC2911]で説明されるようにクライアントによって供給されて、8.3を区分してください。
5.1.1. notify-subscription-ids (1setOf integer(1:MAX))
5.1.1. 購読イドに通知してください。(1setOf整数(1: 最大))
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.
この属性はEventsが要求されている1個以上のSubscriptionオブジェクトを特定します。 クライアントは少なくとも1つの値をこの属性に供給しなければなりません。 Printerオブジェクトは複数の値でこの属性をサポートしなければなりません。
If no Subscription Object exists with the supplied identifier, or if the identified Subscription Object does not contain the "notify-
特定されたSubscription Objectが「通知」を含んでいないならどんなSubscription Objectも供給された識別子で存在していないなら
Herriot, et al. Standards Track [Page 8] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[8ページ]: 2005年の'ippget'発送方法行進
pull-method" attribute with the 'ippget' keyword value, the Printer MUST return the 'client-error-not-found' status code.
'ippget'キーワード価値がある「牽引力メソッド」属性、Printerは'誤りが当たらなかったクライアント'ステータスコードを返さなければなりません。
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.
以下に注意してください。 そして、両方の名前、「購読イドに通知してください」、「一連番号に通知する、」 それらがマルチ評価されているように's'に終わってください。 しかしながら、's'のないこれらの評価されていた状態でただ一つの属性名の他の発生があります。
5.1.2. notify-sequence-numbers (1setOf integer(1:MAX))
5.1.2. 一連番号に通知します。(1setOf整数(1: 最大))
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.
この属性は「購読イドに通知してください」という操作属性の換算値によって特定されたSubscriptionオブジェクトに最も低いEvent Notification一連番号値の1つ以上を指定します。 Notification Recipient SHOULDはこの属性、および値の数にSHOULDを供給します。「購読イドに通知してください」という属性のものと同じにしてください。 Printerは複数の値でこの属性をサポートしなければなりません。
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.
Printerは対応するSubscriptionオブジェクトのために下側の一連番号と共にNotification Eventsを返してはいけません。 したがって、この属性に固有値を供給することによって、Notification Recipientは、前のGet通知要求に返されたSubscriptionオブジェクトから同じEvent Notificationsを手に入れるのを防ぐことができます。 Notification Recipient SHOULDが最も高く覚えている、「一連番号に通知する、」 Subscriptionオブジェクトが要求したそれぞれのために返された値とSHOULDは次のGet-通知要求のときにそれぞれの要求されたSubscriptionオブジェクトのためにその値を通過します。
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.
Notification Recipientが、より少ない値をこの属性に供給するなら(この属性を省略するのを含んでいて)、Printerは各欠測値のために「購読イドに通知してください」という操作属性のために仮定するより'1'値を仮定します。 PrinterはそのSubscriptionオブジェクトのために'1'の値でどんな満期になっていないEvent Notificationも返します、'1'が可能な限り低い一連番号であるので。 Notification Recipientが「購読イドに通知してください」という操作属性にこの属性ための値の数より値を供給するなら、Printerは超過価値を無視します。
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-
以下に注意してください。 Notification Recipientが同じくらいで2つの連続したGet通知操作を実行するなら、「系列に通知している数」(または、属性を省略する)、1つの番目もののタイムスタンプ値には、Get-通知Responseがそれ以下であるかもしれない最初のGet-通知Responseにおける最後のEvent Notificationのタイムスタンプの秒にEvent Notificationを評価してください。 [RFC3995]、およびいくつかのEvent Notificationsで最初のGetから指定された注文に応じてPrinterが等しいか、より高い一連番号と共にすべての満期になっていないEvent Notificationsを送るので、これは起こります。
Herriot, et al. Standards Track [Page 9] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[9ページ]: 2005年の'ippget'発送方法行進
Notifications operation may not have expired by the time the second Get-Notifications operation occurs.
2番目のGet-通知操作が起こる時までに通知操作は期限が切れていないかもしれません。
5.1.3. notify-wait (boolean)
5.1.3. 待ちに通知します。(論理演算子)
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.
この値は、Notification RecipientがEvent Wait Modeが欲しいかどうかを示します。 クライアントはこの属性を供給するかもしれません。 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.
クライアントが'誤った'値を供給するか、またはこの属性を省略するなら、クライアントはEvent Wait Modeを要求していません。 値が'本当である'なら、クライアントはEvent Wait Modeを要求しています。 規則に関してEvent Wait Modeに関してセクション5.2の始まりを見てください。
5.2. Get-Notifications Response
5.2. 通知を得ている応答
The Printer has the following options for responding to a Get- Notifications Request:
Printerには、Get通知Requestに応じるための以下のオプションがあります:
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. Printerがこのときこの操作を受け入れることができないくらい忙しいなら、Printerは要求を拒絶して、'サーバ誤り忙しい'ステータスコードを返すことができます。 この場合Printerが戻らなければならない、「得る、間隔に通知してください、」 クライアントSHOULDが再試行するとき示す操作属性。
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. Notification RecipientがEvent Wait Mode('偽'と等しかった、または省略された「待ちモードに通知する」)を要求しなかったなら、Printerが現在要求されたSubscriptionオブジェクトでどんなEvent Notificationsも持ってもすぐに、戻らなければならなくて、戻らなければならない、「通知、間隔を手に入れてください、」 現在からの秒数がある操作属性。(その時、Notification Recipient SHOULDは、将来のEvent Notificationsを手に入れるためにGet-通知Requestを繰り返します)。
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. Notification RecipientがEvent Wait Modeを要求したなら(= '本当に'「待ちモードに通知してください」)、Printerは、現在要求されたSubscriptionオブジェクトでどんなEvent Notificationsも持ってもすぐに、戻らなければならなくて、すべての要求されたSubscription Objectsが取り消されるまで彼らが起こるのに従って、Event Notificationsを返し続けなければなりません。 Subscription Objectがキャンセル購読操作かPrinterによって取り消される、(Jobは完成して、もういないJob RetentionかJob歴史が位相を合わせる関連; 「ippgetイベントの寿命(整数(15: MAX))」が議論を結果と考えるのがわかると例えばSubscription Objectが取り消される、セクション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は、いつでもEvent Wait Mode、最初の応答での包含を終えると決めるかもしれません。 この場合
Herriot, et al. Standards Track [Page 10] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[10ページ]: 2005年の'ippget'発送方法行進
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.
プリンタが戻らなければならない、「通知、間隔を手に入れてください、」 操作属性。 この属性は、PrinterがNotification Recipient SHOULDが再びGet-通知操作を試みる未来にEvent Wait Modeと秒数を出たがっているのを示します。 Notification Recipientはこの応答を受け入れなければならなくて、切断しなければなりません。 Notification Recipientが切断しないなら、Printer SHOULDはそうします。
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.
Notification Recipientの視点から、応答は、データのイニシャル・バーストとしてPrinterが成立しているのをEvent Notification単位で現れさせます。(データはOperation Attributes Groupと1Event Notification Attributes Groupを含んでいます)。 データのイニシャル・バーストの後に、Notification Recipientが追加Event Notificationsを待つためにEvent Wait Modeオプションを選択したなら、Notification Recipientは時々のEvent Notification Attribute Groupsを受けます。 Proxyサーバは、起こるようにいくつかのEvent Notificationsか原因タイムアウトを遅らせるかもしれません。 タイムアウトが起こるとき、クライアントはもう一度Get-通知操作を実行する用意ができていなければなりません。
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-通知Responseの一部です:
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ステータスコードに加えて応答OPTIONALLYは「状態メッセージ」を含んでいます。(テキスト(255))、そして/または、説明されたコネ[RFC2911]、セクション13と3.1.6としての「詳細なステータスメッセージ」(テキスト(MAX))操作属性。
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:
Printerは[RFC2911]で定義されたどんなステータスコードも返すことができます。 ステータスコードが'うまくいっているxxx'でないなら、PrinterはどんなEvent Notification Attributeグループも返してはいけません。 ↓これは重要なステータスコードの記述です:
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: 応答は「購読イドに通知してください」という要求における操作属性で供給された指定された購読イドに関連しているすべてのEvent Notificationを含んでいます。 要求されたSubscription Objectsにどんな関連Event Notificationもないなら、応答はEvent Notificationsを全く含んではいけません。
Herriot, et al. Standards Track [Page 11] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[11ページ]: 2005年の'ippget'発送方法行進
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: このリターンがEvent Notificationsを返すか否かに関係なく、要求に合っているすべてのSubscriptionオブジェクトのための最後のリターンであるときに、示します。 (1) Subscription Objectがキャンセル購読操作で取り消されるか、(2) Per-プリンタSubscriptionリース時間が期限が切れるとき、Subscription Objectが削除されるか、または(3) '仕事で完成した'イベントがPer-仕事のSubscriptionのために起こるとNotification Recipientsが応答を待っていて、この状態はEvent Wait Modeのために現れます。 この状態は、また、仕事の後のa Notification Recipient造が終了するGet-通知要求のために起こりますが、Event Lifeの前で期限が切れます。 誤りが当たらなかったセクション10.1のクライアントを見てください: Printerが「購読イドに通知してください」という属性が操作属性が供給した「購読イドに通知してください」の値のいずれとも等しいSubscription Objectsを全く持っていないか、または特定されたSubscription Objectは'ippget'キーワード価値誤りが忙しくするサーバがある「牽引力に通知しているメソッド」の属性を含んでいません: Printerはこの操作を受け入れることができないくらい忙しいです。 Printer SHOULDが戻る、「通知、-、」 操作が応答のOperation Attributesで結果と考える間隔を得ます。 そして、Notification Recipient SHOULDは再びこの操作を実行する前に「間隔を得て、通知してください」操作属性によって指定された秒数を待っています。 「通知、間隔を手に入れてください、」 Operation Attributeが存在していない、Notification Recipient SHOULDは再びいつこの操作を実行するかを決定するのに正常なネットワーク下に後部アルゴリズムを使用します。
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes, as described in [RFC2911], section 3.1.4.2.
自然言語と文字コード: 「属性-charset」と「属性自然言語」属性[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.
そして、Printerが「-charsetに通知してください」の値を使用しなければならない、「自然言語に通知する、」 それぞれ、1から、Subscription Objectはこの応答でEvent Notificationsと交際しました。
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
そして、通常、ある取り組んでいるSubscription Object、または「-charsetに通知してください」の値しかない、「自然言語に通知する、」 属性はすべてのSubscription Objectsで同じです。 そうでなければ、Printerはこれらの属性の値を得る1Subscription Objectを選ばなければなりません。 Subscription Objectを選ぶためのアルゴリズムは実装に依存しています。 'テキスト'と'名前'値が「属性当然の言語」の操作属性をくつがえすことができるので、自然言語の選択は重要ではありません。 charsetのPrinterの選択
Herriot, et al. Standards Track [Page 12] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[12ページ]: 2005年の'ippget'発送方法行進
is critical because a bad choice may leave it unable to send
some 'text' and 'name' values accurately.
下手な選択が正確にいくつかの'テキスト'と'名前'値を送るのを残すかもしれないので、重要です。
5.2.1. notify-get-interval (integer(0:MAX))
5.2.1.、通知、間隔を手に入れてください。(整数(0: 最大))
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.
この操作属性の値は再びGet通知操作を試みる前にNotification Recipient SHOULDが待つ秒の数です。 (1) イベントを返すのが忙し過ぎるならPrinterがこの操作属性を返さなければならない、(2) Notification RecipientクライアントがEvent Wait Modeを要求しなかったか、またはさもなければ、(3) PrinterはEvent Wait Modeを終えています。 のあるなしにかかわらず、クライアントがこの属性を受け入れなければならなくて、SHOULDがGet-通知操作を再発行する、(「待ちに通知する、」 ='本当') 未来の秒の示された数では、より多くのEvent Notifications Thisを手に入れるために値が、クライアントが良いネットワーク国民であることを助けることを意図します。
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.
この属性の値はPrinterの「ippgetイベントの寿命」Printer記述属性のものと少なくとも同じくらい大きいに違いありません(セクション8.1を見てください)。 Printerは、より長い間隔がある、より大きい値と世論調査を考慮に入れるNotification Recipientsがイベントを逃さないで、PrinterがこのSubscriptionオブジェクトのためにEvent Lifeを増強すれば「ippgetイベントの寿命」Printer記述属性のものより大きい値を返すかもしれません。 以下に注意してください。 そのようなアルゴリズムを実装するのはSubscriptionオブジェクトのIMPLEMENTATION DEPENDENTであるいくつかの隠された属性を必要とします。
If the Printer wants to remain in Event Wait Mode, then the Printer MUST NOT return this attribute in the response.
PrinterがEvent Wait Modeに残りたいと思うなら、Printerは応答におけるこの属性を返してはいけません。
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):
組み合わせの完全なテーブルがここにある、「待ちに通知する、」、「状態コード」、「通知、間隔を手に入れてください、」 Get-通知のためのEvent Notification Attributes Groupsは応答とその後のEvent Wait Mode Responses(Event Wait Modeに滞在しているか、またはEvent Wait Modeを残すようNotification Recipientに要求するかもしれない)に頭文字をつけます(待ちにもかかわらず、Waitがありません):
Table 2. Combinations of "notify-wait", "status-code", and
"notify-get-interval"
2を見送ってください。 そして、組み合わせ、「待ちに通知する、」、「ステータスコード」、「通知、間隔を手に入れてください、」
Client sends: Printer returns: Printer Event
returns: Notification
"notify-wait" "status-code" "notify-get- Attribute
interval" Groups
クライアントは発信します: プリンタは戻ります: プリンタEventは戻ります: 通知、「待ちに通知する、」 「ステータスコード」、「通知、-、」 属性間隔Groupsを手に入れます。
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にNを返さなければなりません。 '見つけられなかった'*がそうしなければならない'誤ること'は3にそうしなければなりません。 '忙しいこと'がNを返さなければならない'誤った'*はそうしてはいけません。
Herriot, et al. Standards Track [Page 13] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[13ページ]: 2005年の'ippget'発送方法行進
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がそうしてはいけません。 '本当'の'うまくいっているOK'は多分7にNを返さなければなりません。 どんな8も、'本当に'と必須NOT必須であることを'見つけませんでした'。 '本当'は'忙しいこと'がNを返さなければならない9にそうしてはいけません。 '本当の'虚偽で'イベント'仕事は'完成する'か多分他の*を完成してはいけない''かクライアントが省略する、「待ちに通知する、」 属性
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: クライアントはEvent Wait Modeを要求しません。 5-9: クライアントはEvent Wait Modeを要求します。 2,7: 購読は、見つけられないで、反対したか、または、より早く中止されました。 クライアントは再試行するべきではありません。 3,8: サーバが、忙しくして、クライアントが後で試みると言う、。 クライアントはN秒以降に再試行するべきです。 4: 仕事の後に投票されたクライアントが'仕事で完成した'イベントを完成しましたが、吐き出して、Event Lifeの前得たので、クライアントはわざわざ再試行するべきではありません。 クライアントは後で再び試みるべきではありません。 5: プリンタは、1Event Notificationsを返して、Event Wait Modeに滞在するためにOKです。 クライアントは、より多くのEvent Notificationsが返されるのを待ちます。 6: Event Waitをモードに残すプリンタ必需品。 最初の応答(Event Notificationsのあるなしにかかわらず)のときに起こるか、またはその後の応答のときにEvent Notificationsのあるなしにかかわらず起こることができます。 クライアントSHOULDはN秒以降、再試行します。 9: (2) プリンタが'仕事で完成した'イベントを返す(1)かSubscription Objectのどちらかが更新されないで吐き出されたキャンセル仕事かPer-プリンタSubscriptionのどちらかによって取り消されました。 ケース(1)において、少なくとも1Event Notificationを返さなければなりません。 ケース(2)において、どんなEvent Notificationsも返すのがありそうもなく、クライアントは再試行するべきではありません。
5.2.2. printer-up-time (integer(1:MAX))
5.2.2. プリンタ動作可能時間(整数(1: 最大))
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.
Printerがこの応答を送るとき、この属性の値はPrinterの「プリンタ動作可能時間」属性です。 Printerはこの属性を返さなければなりません。 また、イベントが起こったとき各Event Notificationがこの属性の値を含んでいるので、この属性の値は、各Event Notificationがいつこの応答の時間に比例して起こったかをNotification Recipientに知らせます。
Herriot, et al. Standards Track [Page 14] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[14ページ]: 2005年の'ippget'発送方法行進
Group 2: Unsupported Attributes
See [RFC2911], section 3.1.7, for details on returning
Unsupported Attributes.
グループ2: サポートされないAttributes See[RFC2911]、戻っているUnsupported Attributesに関する詳細のためのセクション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.
3〜Nに分類してください: イベントNotification Attributes Printerは取り組んでいるEvent Notificationあたり1Event Notification Attributes Groupと共に応じます。 全体の応答は独身のCompound Event Notificationであると考えられます([RFC3995]を見てください)。 取り組んでいるEvent Notificationsは取り組んでいるSubscription Objectsに関連している満期になっていないEvent Notificationsであり、[RFC3995]セクション9で指定されたCompound Event Notificationの中のEvent Notificationsのための「イベント通知注文」要件に続かなければなりません。 言い換えれば、Subscriptionオブジェクトのタイムスタンプ(そして、一連番号)注文を昇って、PrinterはこれらのEvent Notificationグループを入るように命じなければなりません。 複数のSubscriptionオブジェクトのためのEvent Notificationsを返しているなら、次のために、Subscriptionがタイムスタンプオーダーを昇る際に続くのを反対させるNotification Eventsですなど。
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.
各Event Notification Groupは[RFC3995]のセクション9.1(「マシンの消費できるイベント通知の内容」)で指定された属性のすべてを含まなければなりません、例外が以下のテーブルのアスタリスクによって指示されている状態で。
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".
以下のテーブルは[RFC3995]のセクション9.1(「マシンの消費できるイベント通知の内容」)がそれらと同じです、「送付」コラムの各セルが“MUST"であるのを除いて。
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.
1Event Notificationを返していて、それぞれの状態が同じでないならPrinterがaを返さなければならない、「ステータスコードに通知する、」 それぞれのEvent Notification Attributesグループでは、異なった状態値を示すために、結果と考えます。
For an Event Notification for all Events, the Printer includes
the attributes shown in Table 3.
すべてのEventsのためのEvent Notificationに関しては、PrinterはTable3に示された属性を含んでいます。
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
購読イドに通知してください、(整数(1: マックス))プリンタuriに通知しているSubscription(uri)がそうしなければならない、Subscription、申し込まれたイベントに通知してください、(type2キーワード)(dateTime)がそうしなければならない*がそうしなければならないEvent Notificationプリンタ動作可能時間(整数(1: マックス))のPrinterプリンタ電流時間**プリンタでなければならない
Herriot, et al. Standards Track [Page 15] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[15ページ]: 2005年の'ippget'発送方法行進
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
一連番号に通知する、(整数(0: マックス))charsetに通知しているSubscription(charset)がそうしなければならない、自然言語に通知しているSubscription(naturalLanguage)がそうしなければならない、Subscription、利用者データに通知する、(octetString(63))がそうしなければならない、テキストに通知している(テキスト)がそうしなければならない***購読、Event Notification属性、「属性に通知する、」、****プリンタが属性を結果と考えなければならない、「属性に通知する、」、****仕事が属性を結果と考えなければならない、「属性に通知する、」、****購読は結果と考えなければなりません。
* 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で指定されるように、「プリンタ動作可能時間」属性の値は、各Event NotificationがEvent Notificationが送られた時ではなく、Eventが起こった時であるに違いないことを送りました。
** The Printer MUST send the "printer-current-time" attribute
if and only if it supports the "printer-current-time" attribute
on the Printer object.
** そして、Printerが「プリンタ電流時間」属性を送らなければならない、Printerで「プリンタ電流時間」属性をサポートする場合にだけ、反対してください。
*** If the associated Subscription Object does not contain a
"notify-user-data" attribute, the Printer MUST send an
octet-string of length 0.
*** 関連Subscription Objectがaを含んでいない、「利用者データに通知する、」 属性、Printerは長さ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.
**** 「属性に通知する、」 属性がSubscription Objectに存在している、Printerが属性が指定したすべてを送らなければならない、「属性に通知する、」 属性 以下に注意してください。 Printerがサポートしない、「属性に通知する、」 属性、それは関連Subscription Objectに存在していません。
For Event Notifications for Job Events, the Printer includes
the additional attributes shown in Table 4.
Job EventsのためのEvent Notificationsに関しては、PrinterはTable4に示された追加属性を含んでいます。
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
印象が完了した(1setOf type2キーワード)がそうしなければならない(type1 enum)がそうしなければならない(整数(1: マックス))がそうしなければならない仕事イドJob仕事州のJob仕事の州の理由Job仕事(整数(0: マックス))がそうしなければならない、*仕事
Herriot, et al. Standards Track [Page 16] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[16ページ]: 2005年の'ippget'発送方法行進
* 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.
* PrinterはTable5で見せられたEventsとSubscribed Eventsの組み合わせのためだけにEvent Notificationで「印象が完了した仕事」属性を送らなければなりません。
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.
Printer EventsのためのEvent Notificationに関しては、PrinterはTable6に示された追加属性を含んでいます。
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
プリンタが仕事を受け入れている(1setOf type2キーワード)がそうしなければならない(type1 enum)がそうしなければならないプリンタ州のPrinterプリンタ州の理由のPrinter(論理演算子)がそうしなければならない、Printer
6. Additional Information about Subscription Template Attributes
6. 購読テンプレート属性に関する追加情報
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'Delivery Methodはどんな追加Subscription Template属性も定義しないで、[RFC3995]で定義されたSubscription Template属性のための順応要件を持っています。 このセクションは[RFC3995]で定義されたSubscription Template属性に関する追加情報を定義します。
6.1. notify-pull-method (type2 keyword)
6.1. 牽引力のメソッドに通知してください。(type2キーワード)
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:
このSubscription Template属性は、Subscription Objectに使用されるためにPull Delivery Methodを特定します([RFC3995]を見てください)。 'ippget'が本書では定義されたPull Delivery Methodであるとサポートするために、Printerは以下のキーワード値でこの属性をサポートしなければなりません:
'ippget': Indicates that the 'ippget' Pull Delivery Method is to
be used for this Subscription Object.
'ippget': 'ippget'Pull Delivery MethodがこのSubscription Objectに使用されることになっているのを示します。
Herriot, et al. Standards Track [Page 17] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[17ページ]: 2005年の'ippget'発送方法行進
7. Subscription Description Attributes
7. 購読記述属性
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'Delivery Methodには、[RFC3995]で定義されたSubscription記述属性のための順応要件があります。 'ippget'Delivery Methodはどんな追加Subscription記述属性も定義しません。
8. Additional Printer Description Attributes
8. 追加プリンタ記述属性
This section defines additional Printer Description attributes for use with the 'ippget' Delivery Method.
このセクションは'ippget'Delivery Methodとの使用のために追加Printer記述属性を定義します。
8.1. ippget-event-life (integer(15:MAX))
8.1. ippgetイベントの寿命(整数(15: 最大))
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.
このPrinter記述属性はPrinterが各Eventに割り当てるEvent Life値を指定します。 すなわち、Eventの後のPrinterがEvent NotificationでGet-通知応答でそのEventを返す秒数は起こります。 Event LifeがEventのために期限が切れた後に、PrinterはそのEventのためにもうGet-通知応答でEvent Notificationを返さないかもしれません。
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'がDelivery Methodであるとサポートするなら、Printerはこの属性をサポートしなければなりません。 値は15以上でなければなりません(少なくとも15秒)、そして、60(秒)はPWG Job Monitoring MIB[RFC2707]jmGeneralJobPersistenceとjmGeneralAttributePersistenceオブジェクトに並べるRECOMMENDED値です。
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'Delivery Methodに関連づけられたSubscription Objectを作成するJob Creation操作を実行します。
2. An Event associated with the new Job occurs immediately after the
Subscription Object is created;
2. Subscription Objectが作成される直後新しいJobに関連しているEventは起こります。
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. 同じクライアントかある他のクライアントがGet-通知操作を実行するので、クライアントはJob Creation操作のN秒後に接されます。
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.
次に、Get-通知操作を実行しているクライアントは、Nがこの属性の値以下であるなら、少しのEvent-通知も逃さないと予想できます、Printerのメモリスペースの何らかの予期しない不足を除いて。 以下に注意してください。 クライアントがそのN秒の十分少ない時にネットワーク潜在を説明するためにGet通知を開始しなければならないので、N秒が経過する前に、それはPrinterに接続されます。
Herriot, et al. Standards Track [Page 18] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[18ページ]: 2005年の'ippget'発送方法行進
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.
この属性の値と少なくとも同じくらい長い間、Printerが、'ippget'がDelivery Methodであるとサポートするなら、それはJob Retention、そして/または、Job歴史フェーズで'完成した'か、'取り消された'か、'中止になっている'Jobオブジェクトを保たなければなりません。 5月が仕事より長い間保有するこれが評価するPrinter。 [RFC2911]、セクション4.3を見てください。.7 .1、および[RFC3995]('仕事で完成した'イベントに関する)での議論。 後者で、'完成される'か、'中止される'か、または'取り消される'仕事の他の情報を見つけるために'仕事で完成した'Event Notificationを受けた後にNotification RecipientがJobについて質問できるのがわかります。 しかしながら、この属性はキャンセル購読操作のときに効き目がありません。(それが「牽引力のメソッドに通知してください」という'ippget'キーワード価値がある属性を含んでいるか否かに関係なく、それは、すぐに、Subscriptionオブジェクトを削除します)。 その後すぐに、その後のGet-通知Responsesは取り消されたSubscriptionオブジェクトに関連しているEvent Notificationsを含んではいけません。
9. New Values for Existing Printer Description Attributes
9. 既存のプリンタ記述属性のための新しい値
This section defines additional values for existing Printer Description attributes as defined in [RFC3995].
このセクションは[RFC3995]で定義される既存のPrinter記述属性のために加算値を定義します。
9.1. notify-pull-method-supported (1setOf type2 keyword)
9.1. メソッドが支えた牽引力に通知してください。(1setOf type2キーワード)
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:
「サポートされた状態で牽引力のメソッドに通知してください」属性のための以下のキーワード価値は本書では定義された新しいDelivery Methodをサポートするために高められます:
'ippget': The IPP Notification Pull Delivery Method defined in
this document.
'ippget': 本書では定義されたIPP Notification Pull Delivery Method。
9.2. operations-supported (1setOf type2 enum)
9.2. 操作で、サポートされます。(1setOf type2 enum)
Table 7 lists the "operation-id" value defined in order to support the new Get-Notifications operation defined in this document.
テーブル7は新しいGet-通知が本書では定義された操作であるとサポートするために定義された「操作イド」値を記載します。
Table 7. Operation-id Assignments
7を見送ってください。 操作イド課題
Value Operation Name
値の操作名
0x001C Get-Notifications
0x001C、通知を得ます。
10. New Status Codes
10. 新しいステータスコード
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).
以下のステータスコードをこのDelivery Methodのための拡大と定義して、Get通知操作のステータスコードとしてGroup1かGroup3〜Nで返します(セクション5.2を見てください)。
Herriot, et al. Standards Track [Page 19] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[19ページ]: 2005年の'ippget'発送方法行進
10.1. successful-ok-events-complete (0x0007)
10.1. イベントが完成するうまくいっているOK(0×0007)
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.
PrinterはSubscriptionオブジェクトのためにいつこのGet-通知応答が最後の応答であるかを示すために'イベントが完成するうまくいっているOK'ステータスコードを返さなければなりません、返されるEvent Notificationsがあるか否かに関係なく。 (1) Subscription Objectがキャンセル購読操作で取り消されるか、(2) Per-プリンタSubscriptionリース時間が期限が切れるとき、Subscriptionオブジェクトが削除されるか、または(3) '仕事で完成した'イベントがPer-仕事のSubscriptionのために起こるとNotification Recipientsが応答を待っていて、この状態はEvent Wait Modeのために現れます。 この状態は、また、仕事の後のa Notification Recipient造が終了するGet-通知要求のために起こりますが、Event Lifeの前で期限が切れます。
11. Encoding and Transport
11. コード化と輸送
This section defines the encoding and transport considerations for this Delivery Method based on [RFC2910].
このセクションは[RFC2910]に基づくこのDelivery Methodのためにコード化と輸送問題を定義します。
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-通知Responseのコード化はGet-ジョブスResponseに倣われます([RFC2911]を見てください)。 Get-通知Responseでは、各Event Notification Attributes Groupが'終わりで'イベント通知属性タグ'([RFC3995]で「追加属性タグのEncodings」というセクションを見る)、および終わりから始まらなければならない、-、-、属性タグ、' さらに、Event Wait Modeに関して、マルチ部分か関連が、(時間内に)複数の応答単位でそれぞれの独身のGet-通知Requestに分離するのに使用されます。
The Printer returns Get-Notification Response as follows:
Printerは以下のGet-通知Responseを返します:
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. Notification RecipientクライアントがEvent Wait Modeを要求しなかった、(「待ちに通知する、」、'偽'と等しい、または省略される、)、Printerは'属性タグの端'による応答を終わらせます([RFC2911]を見てください、Get-ジョブスがコード化して)、どんな操作応答のようにも。
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. Notification RecipientクライアントがEvent Wait Modeを要求する、(「待ちに通知する、」 = '本当に')、要求を光栄に思うというPrinter願望、Printerはアプリケーション/ipp部分として複合の、または、関連するMIMEメディアタイプの中で応答を返さなければなりません。 1追加Eventsが起こると、Printerは、追加Event Notification Groupとして複合の、または、関連するタイプの下に別々のアプリケーション/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. クライアントがEvent Wait Modeを要求した、(「待ちに通知する、」 = '本当に')、Printerが初期の応答における要求を光栄に思うことを願わないで、Event Notificationsのために明らかにクライアントに投票して欲しく、Printerが戻らなければならない、「通知、間隔を手に入れてください、」 操作属性(セクション5.2.1を見ます)。 Printerは戻ります。
Herriot, et al. Standards Track [Page 20] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[20ページ]: 2005年の'ippget'発送方法行進
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.
マルチ部分の、または、関連するタイプの中にあるかもしれないアプリケーション/ipp部分としての応答。 クライアントがこの応答を受け入れて、将来値によって示されたGet-通知要求を再発行しなければならない、「通知、間隔を手に入れてください、」 値を結果と考えてください。
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. クライアントがEvent Wait Modeを要求した、(「待ちに通知する、」 = '本当に')、Printerが初めは、要求を光栄に思いますが、後でEvent Wait Modeを残したがっていて、Printerが戻らなければならない、「通知、-、」 操作が結果と考える(セクション5.2.1を見ます)間隔を得ます。 Printerは複合の、または、関連するタイプの中にあるに違いないアプリケーション/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.
以下に注意してください。 Notification Recipientが応答を受けないなら、それは再び同じEvent NotificationsをPrinterに求めることができます。 Notification Recipientはそれが1回目に受けるべきであったのと同じEvent Notificationsを受けるでしょう、差し当たり期限が切れているそれらのEvent Notificationsを除いて。
The Printer MAY chunk the responses, but this has no significance to the IPP semantics.
Printer5月の塊、しかし、応答、これはIPP意味論に意味を全く持っていません。
This notification delivery method uses the IPP transport and encoding [RFC2910] for the Get-Notifications operation with the following extension, allocated in [RFC3995]:
この通知発送方法はGet-通知操作に、[RFC3995]に割り当てられた以下の拡大でIPP輸送とコード化[RFC2910]を使用します:
Table 8. The "event-notification-attributes-tag" Value
8を見送ってください。 「イベント通知属性タグ」値
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x07 "event-notification-attributes-tag"
0×07 「属性がタグ付けをするイベント通知」
12. Conformance Requirements
12. 順応要件
This section lists the conformance requirements for clients and Printers.
このセクションはクライアントとPrintersのための順応要件をリストアップします。
12.1. Conformance for IPP Printers
12.1. IPPプリンタのための順応
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
それはPrinterが[RFC3995]で定義されるようにIPP NotificationsをサポートするOPTIONALです。 しかしながら、PrinterがIPP Notificationsをサポートするなら、Printerは、'ippget'がDelivery Methodであるとサポートしなければなりません、本書では定義されるように、Delivery Methodsの1つとして。 この仕様に従うIPP Printers
1. MUST meet the conformance requirements defined in [RFC3995] for a
Pull Delivery Method;
1. Pull Delivery Methodのために[RFC3995]で定義された順応必要条件を満たさなければなりません。
Herriot, et al. Standards Track [Page 21] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[21ページ]: 2005年の'ippget'発送方法行進
2. MUST support the Get-Notifications operation defined in section
5, including Event Wait Mode;
2. Event Wait Modeを含んでいて、操作がセクション5で定義したGet-通知をサポートしなければなりません。
3. MUST support the Subscription Template object attributes, as
defined in section 6;
3. セクション6で定義されるようにSubscription Templateオブジェクト属性をサポートしなければなりません。
4. MUST support the Subscription Description object attributes, as
defined in section 7;
4. セクション7で定義されるようにSubscription記述がオブジェクト属性であるとサポートしなければなりません。
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. 少なくとも同じくらい長い間Job Retention、そして/または、Job歴史フェーズに仕事を保有するのを含んでいて、値がPrinterの「ippgetイベントの寿命」で指定したようにセクション8.1で定義された「ippgetイベントの寿命」Printer記述属性をサポートしなければなりません。
6. MUST support the additional values for IPP/1.1 Printer
Description attributes defined in section 9;
6. セクション9で定義されたIPP/1.1Printer記述属性のために加算値をサポートしなければなりません。
7. MUST support the 'successful-ok-events-complete' status code, as
described in section 10.1;
7. セクション10.1で説明されるように'イベントが完成するうまくいっている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によって割り当てられたウェルノウンポート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. SHOULD NOTはいかなる他のポートに関するIPP Get-通知操作要求も聞こうとします、システム管理者かサイト方針で明らかに構成されない場合。 そして
10. MUST meet the security conformance requirements stated in section
18.4.
10. セクション18.4で述べられたセキュリティ順応必要条件を満たさなければなりません。
12.2. Conformance for IPP Clients
12.2. IPPクライアントのための順応
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:
それはIPP Clientが[RFC3995]で定義されるようにIPP NotificationsをサポートするOPTIONALです。 しかしながら、クライアントがIPP Notificationsをサポートするなら、クライアントは、本書ではDelivery Methodsの1つと定義されるように'ippget'がDelivery Methodであるとサポートしなければなりません。 この仕様に以下を従わせるIPP Clients
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に通知してください」という属性と対照的に)を含む操作要求をSubscription Creationに送ることによって、Subscription Objectsを作成しなければなりません。
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'URL(存在しているなら)かそうでなければ、IANAによって割り当てられたウェルノウンポート631で指定されたポートを通してIPP Get-通知操作要求(セクション5.1を見る)を送らなければなりません。
Herriot, et al. Standards Track [Page 22] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[22ページ]: 2005年の'ippget'発送方法行進
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. それらの対応する'http'URLフォームへのIPP Get通知操作における、セクション5の規則に従って「IPP URLは計画する」HTTP層、[RFC2910]における使用の使用のために関連'ipp'URLを変換しなければなりません。 そして
4. MUST meet the security conformance requirements stated in section
18.5.
4. セクション18.5で述べられたセキュリティ順応必要条件を満たさなければなりません。
13. Normative References
13. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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に以下を印刷するインターネット」 「コード化と輸送」、RFC2910、9月2000日
[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.、イサクソン、S.、およびP.パウエル、「プロトコル/1.1に以下を印刷するインターネット」 「モデルと意味論」、RFC2911、9月2000日
[RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol
(IPP): Event Notifications and Subscriptions", RFC 3995,
March 2005.
[RFC3995] エリオ、R.、およびT.ヘイスティングズ、「インターネット印刷は(IPP)について議定書の中で述べます」。 「イベント通知と購読」(RFC3995)は2005を行進させます。
14. Informative References
14. 有益な参照
[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に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日
[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.、イサクソン、S.、およびP.パウエル、「プロトコル/1.0に以下を印刷するインターネット」 「モデルと意味論」、RFC2566、4月1999日
[RFC2567] Wright, F., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2567] ライト、F.、「インターネット印刷プロトコルのデザイン目標」、RFC2567、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.、「インターネット印刷プロトコルのためのモデルとプロトコルの構造への原理」、RFC2568(1999年4月)。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569, April
1999.
[RFC2569] エリオとR.とヘイスティングズとT.とジェイコブズ、N.とJ.マーチン、「LPDとIPPプロトコルの間のマッピング」、RFC2569、1999年4月。
Herriot, et al. Standards Track [Page 23] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[23ページ]: 2005年の'ippget'発送方法行進
[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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、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.ルイス、「1999年11月にV1.0"、RFC MIB--2707をモニターする仕事。」
[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に以下を印刷するインターネット」 「作成者のガイド」、RFC3196、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通知のための要件」、RFC3997、2005年3月。
15. IANA Considerations
15. IANA問題
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.
このセクションは[RFC2911](セクション6)で定義された手順によると、IANAがIPP Registriesに加えたという正確な情報を含みます。 これらの登録証明書は http://www.iana.org/assignments/ipp-registrations 登録で発行されました。
15.1. Attribute Registrations
15.1. 属性登録証明書
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.
以下のテーブルは本書では定義された属性を記載します。 RFC2911[RFC2911]部6.2の手順によると、これを登録してあります。
Printer Description attributes: Reference Section ------------------------------- --------- ------- ippget-event-life (integer(15:MAX)) [RFC3996] 8.1
プリンタ記述属性: 参照部------------------------------- --------- ------- ippgetイベントの寿命(整数(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に従って、Pull Delivery Method登録証明書は「牽引力のメソッドに通知してください」と「メソッドが支えた牽引力に通知してください」属性のためのキーワード属性値登録証明書です。
Herriot, et al. Standards Track [Page 24] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[24ページ]: 2005年の'ippget'発送方法行進
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
属性(属性構文)はReferenceセクションを評価します。----------------------- --------- ------- 牽引力のメソッドに通知している(type2キーワード)[RFC3995]5.3.2メソッドが支えた牽引力に通知している(1setOf type2キーワード)[RFC3995]5.3.2.1ippget[RFC3996]9.1
15.3. Additional Enum Attribute Values
15.3. 追加Enum属性値
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.
以下のテーブルは本書では定義されたenum属性値を記載します。 手順によると、[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
属性(属性構文)値のName Referenceセクション------ ----------------------------- --------- ------- 操作でサポートしている(1setOf type2 enum)[RFC2911]4.4.15 0x001C Get-通知[RFC3996]9.2
15.4. Operation Registrations
15.4. 操作登録証明書
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.
以下のテーブルは本書では定義された操作を記載します。 RFC2911[RFC2911]部6.4の手順によると、これを登録してあります。
Operations: Reference Section ----------- --------- ------- Get-Notifications [RFC3996] 5
操作: 参照部----------- --------- ------- 通知を得ている[RFC3996]5
15.5. Status Code Registrations
15.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
ステータスコード: 参照部------------- --------- ------- イベントが完成するうまくいっているOK(0×0007)[RFC3996]10.1
16. Internationalization Considerations
16. 国際化問題
The IPP Printer MUST localize the "notify-text" attribute as specified in section 14 of [RFC3995].
IPP Printerがローカライズしなければならない、「テキストに通知する、」 [RFC3995]のセクション14で指定されるように、結果と考えます。
Herriot, et al. Standards Track [Page 25] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[25ページ]: 2005年の'ippget'発送方法行進
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-通知要求で要求されたcharsetと自然言語によると、'キーワード'属性構文を持っている属性をローカライズすると予想されます。
17. Security Considerations
17. セキュリティ問題
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.
ハイレベルのセキュリティ要件(クライアントAuthentication、サーバー証明、およびOperation Privacy)について議論しますIPP ModelとSemanticsが、ドキュメントである[RFC2911、セクション8]。 IPPプロトコルのためのセキュリティ要件について議論しますIPP TransportとEncodingが、ドキュメントである[RFC2910、セクション8]。 クライアントAuthenticationはクライアントが安全な方法でサーバへのアイデンティティを立証するメカニズムです。 サーバー証明はサーバが安全な方法でクライアントへのアイデンティティを立証するメカニズムです。 操作Privacyは盗聴から操作を保護するためのメカニズムと定義されます。
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.
IPP/1.1としてのGet-通知操作があるDelivery Methodがセキュリティー対策を利用する'ippget'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.
本書では定義されたGet-通知操作のためのアクセス制御モデルはGet仕事の属性操作のためのアクセス制御モデルと同じです([RFC2911]、セクション3.2.6を見てください)。 プライマリ違いはGet-通知操作がJobオブジェクトでというよりむしろSubscription Objectsで指示されて、返された属性グループがJobオブジェクト属性よりむしろEvent Notification属性を含むということです。
17.1. Notification Recipient Client Access Rights
17.1. 通知受取人クライアントアクセス権
The Notification Recipient client MUST have the following access rights to the Subscription object(s) targeted by the Get- Notifications operation request:
Notification RecipientクライアントはGet通知操作要求でSubscriptionオブジェクトへの以下のアクセス権を狙わせなければなりません:
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
(1) そうでなければ(2) Printer([RFC2911]を見てください、セクション1と8.5)、または(3)の操作属性(セクション5.1.1を見る)、オペレータまたは管理者が目標からEvent Notificationsを要求するのをPrinterの管理者によって構成された安全保障政策で認可した「購読イドに通知してください」によって特定されたそれぞれのSubscription Objectの所有者がSubscription Object(s)であったに違いないならこの操作を実行している認証されたユーザ([RFC2911]を見てください、セクション8.3)。 その上、Printerの安全保障政策は制限されるかもしれません。
Herriot, et al. Standards Track [Page 26] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[26ページ]: 2005年の'ippget'発送方法行進
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).
[RFC2911]を見てください、セクション3.3の端。Get-通知操作で属性は戻りました、Get仕事の属性操作のものと同様の方法で(.4 .2)。
17.2. Printer Security Threats
17.2. プリンタ軍事的脅威
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).
[RFC2911]、セクション3.2.6、および3.2を見てください。通常Job Creation操作のようにGet-通知操作を同じ方向に送る同じクライアントで、このEvent Notification Delivery Methodが追加認証、承認、プライバシー、ファイアウォールでない、またはどんなポート課題でないのにもIPP Get仕事の属性のためのそれらの上の問題を引き起こして、Get-プリンタ属性に操作を引き起こす、(.5)。
17.3. Notification Recipient Security Threats
17.3. 通知受取人軍事的脅威
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.
求められていないイベント通知(ばらまきます): Pull Delivery Methodが本書では定義されている状態でIPP PrinterがEvent Notificationを開始するPush Event Notification Delivery Methodsと異なって、Notification RecipientはGet通知操作を開始するクライアント(セクション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.
以下に注意してください。 クライアントが彼らが起こるときEvent Notificationsを受けるのに、Event Wait Mode(セクション5.1.3を見る)を使用することによってPrinterに接続されていたままであるなら、それは、いつでもIPP接続を閉鎖できるので、いつでも、将来の求められていないEvent Notificationsを避けることができます。
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.
クライアントにはEvent Notificationsを求めるかどうかのコントロールがあるのは、本当です。 しかしながら、クライアントがイベントに加入して、Get-通知要求をするなら、それはそれが欲しいものだけではなく、一連番号範囲(セクション5.1.2を見る)のSubscription Objectのためにすべてのイベントを得ます。 クライアントが'仕事で、完成している'ようにPer-プリンタSubscription仕事のイベントに加入して、だれかが次に、始まって、何千もの仕事を中止するなら、クライアントはそれらに加えたそれが興味を持っているこれらのイベントを受け取らなければならないでしょう。 クライアントは、Jobイベントがすべての仕事に適用されるPer-プリンタ購読を作成するよりむしろPer-仕事のSubscriptionを使用することによってそれ自身の仕事に加入することによって、それ自体をよりよく保護できます。
17.4. Security Requirements for Printers
17.4. プリンタのためのセキュリティ要件
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-通知Printerに関しては、順応要件は、すべてのIPP操作に[RFC2910]セクション8の述べられるとしてのClient Authentication、サーバー証明、およびOperation Privacyをサポートして、使用するために申し込まれます。
Herriot, et al. Standards Track [Page 27] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[27ページ]: 2005年の'ippget'発送方法行進
17.5. Security Requirements for Clients
17.5. クライアントのためのセキュリティ要件
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-通知操作のために、このドキュメントで定義されています、同じクライアント順応要件は[RFC2910]の述べられるとしてのClient Authentication、サーバー証明、およびOperation Privacyをサポートして、使用するために申し込まれます、セクション8、すべてのIPP操作のために。
18. Description of Base IPP Documents (Informative)
18. 基地のIPPドキュメントの記述(有益)です。
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.
「インターネットPrintingプロトコルのためのデザインGoals」は分散印刷の機能性への広い一見を取ります、そして、それは印刷プロトコルに含まれる必要がある特徴をインターネットにはっきりさせるのを助ける現実のシナリオを列挙します。 それは3つのタイプのユーザのための要件を特定します: エンドユーザ、オペレータ、および管理者。 それはIPP/1.0[RFC2566、RFC2565]で満たされているエンドユーザ要件の部分集合を呼び出します。 いくつかのOPTIONALオペレータ操作が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.
「StructureとModelのための原理とインターネットPrintingプロトコルのためのプロトコル」は、ハイレベルの眺めから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:」 「モデルとSemantics」は抽象的なオブジェクト、それらの属性、彼らのコード化から独立している操作、および輸送で簡易型のモデルについて説明します。 それはPrinterとJobオブジェクトを導入します。 Jobオブジェクトは任意に複数の1Jobあたりのドキュメントを支えます。 また、それはセキュリティ、国際化、およびディレクトリ問題を扱います。
"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のために符号化規則を定義します。 また、このドキュメントは、HTTPの上でコンテントタイプが「アプリケーション/ipp」であるメッセージ本体を輸送するために規則を決めます。 このドキュメントはIPPプリンタと仕事を特定することの'ipp'体系を定義します。
Herriot, et al. Standards Track [Page 28] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[28ページ]: 2005年の'ippget'発送方法行進
"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:」 「Implementerのガイド」はIPPクライアントとIPPオブジェクトのimplementersに洞察とアドバイスを与えます。 彼らが彼らのクライアント、そして/または、IPPオブジェクト実装のデザインにそれらを助けるかもしれない問題のIPP/1.1といくつかを理解しているのを助けるのは意図しています。 例えば、誤りを含んでいるのがチェックして、処理要求の典型的な注文を与えます。 また、仕様決定のいくつかに関する動機は含まれています。
"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(線Printer Daemon)実装の間で何らかのアドバイスをゲートウェイのimplementersに与えます。
19. Contributors
19. 貢献者
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つの応答との同じ関係のときにただ一つの操作のための複数の応答に結びつけられた「きびきびした世論調査」の基本的な考え方を寄付しました。 彼らの絶え間ない説得がなければ、私たちは、このDelivery Method仕様に到着していなくて、IPPのために独身のREQUIRED Delivery Methodに同意できなかったでしょう。
Carl Kugler IBM Corporation 6300 Diagonal Highway Boulder, CO 80301
カールクーグラーIBM社6300の対角線のハイウェイボウルダー、CO 80301
EMail: kugler@us.ibm.com
メール: kugler@us.ibm.com
Herriot, et al. Standards Track [Page 29] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[29ページ]: 2005年の'ippget'発送方法行進
Authors' Addresses
作者のアドレス
Robert Herriot Global Workflow Solutions 706 Colorado Ave. Palo Alto, CA 94303
ロバートエリオグローバルな作業フローソリューション706コロラドAve。 パロアルト、カリフォルニア 94303
Phone: 650-324-4000 EMail: bob@herriot.com
以下に電話をしてください。 650-324-4000 メールしてください: bob@herriot.com
Thomas N. Hastings Xerox Corporation 710 S Aviation Blvd. ESAE 242 El Segundo CA 90245
710秒間のトーマスN.ヘイスティングズゼロックス社の航空Blvd. ESAE242エルセガンドカリフォルニア 90245
Phone: 310-333-6413 Fax: 310-333-6342 EMail: hastings@cp10.es.xerox.com
以下に電話をしてください。 310-333-6413 Fax: 310-333-6342 メールしてください: hastings@cp10.es.xerox.com
Harry Lewis IBM Corporation 6300 Diagonal Hwy Boulder, CO 80301
ハリールイスIBM社6300の対角線のHwyボウルダー、CO 80301
Phone: (303) 924-5337 EMail: harryl@us.ibm.com
以下に電話をしてください。 (303) 924-5337 メールしてください: harryl@us.ibm.com
Herriot, et al. Standards Track [Page 30] RFC 3996 IPP: The 'ippget' Delivery Method March 2005
エリオ、他 規格はRFC3996IPPを追跡します[30ページ]: 2005年の'ippget'発送方法行進
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Herriot, et al. Standards Track [Page 31]
エリオ、他 標準化過程[31ページ]
一覧
スポンサーリンク
