RFC3997 日本語訳
3997 Internet Printing Protocol (IPP): Requirements for IPPNotifications. T. Hastings, Ed., R. K. deBry, H. Lewis. March 2005. (Format: TXT=38185 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hastings, Ed.
Request for Comments: 3997 Xerox Corporation
Category: Informational R. K. deBry
Utah Valley State College
H. Lewis
IBM Corporation
March 2005
エド、ワーキンググループのT.ヘイスティングズをネットワークでつないでください。コメントのために以下を要求してください。 3997年のゼロックス社のカテゴリ: 2005年の情報のR.の州立大学H.ルイスのIBMの社のK.deBryユタバレー行進
Internet Printing Protocol (IPP):
Requirements for IPP Notifications
インターネット印刷プロトコル(IPP): IPP通知のための要件
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service.
このドキュメントは1セットのそんなに一緒にいるドキュメントの1つがインターネットPrintingプロトコル(IPP)の全面について説明するということです。 IPPは分配された印刷にインターネットで使用できるアプリケーションレベルプロトコルです。 IPPへの複数の部品がありますが、第一の建築構成は、Modelと、プロトコルと、ディレクトリサービスへのインタフェースです。 このドキュメントはIPP Serviceの任意の部分として通知のための要件の声明を提供します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations for IPP Notifications Requirements. . 12
6. Internationalization Considerations . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References. . . . . . . . . . . . . . . . . . 14
8.2. Informative References. . . . . . . . . . . . . . . . . 14
9. Appendix A: Description of the Base IPP Documents . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 シナリオ. . . . . . . . . . . . . . . . . . . . . . . . . . 6 4。 要件。 . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IPP通知要件のためのセキュリティ問題。 . 12 6. 国際化問題. . . . . . . . . . . . . 13 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 13 8。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. 引用規格。 . . . . . . . . . . . . . . . . . 14 8.2. 有益な参照。 . . . . . . . . . . . . . . . . 14 9. 付録A: 基地のIPPドキュメント. . . . . . 15作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 16の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 17の記述
Hastings, et al. Informational [Page 1] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[1ページ]のRFC3997IPP: 通知要件2005年3月
1. Introduction
1. 序論
This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service. See section 10 for a description of the base IPP documents.
このドキュメントは1セットのそんなに一緒にいるドキュメントの1つがインターネットPrintingプロトコル(IPP)の全面について説明するということです。 IPPは分配された印刷にインターネットで使用できるアプリケーションレベルプロトコルです。 IPPへの複数の部品がありますが、第一の建築構成は、Modelと、プロトコルと、ディレクトリサービスへのインタフェースです。 このドキュメントはIPP Serviceの任意の部分として通知のための要件の声明を提供します。 ベースIPPドキュメントの記述に関してセクション10を見てください。
The scope of this requirements document covers functionality used by the following kinds of IPP Users: End Users, Print Administrators, and Operators. See [RFC3995] for the extensions to the Internet Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911], [RFC2910], and future versions.
この要件ドキュメントの範囲はIPP Usersの以下の種類によって使用される機能性をカバーしています: エンドユーザは管理者、およびオペレータを印刷してください。 拡大に関してインターネットPrintingプロトコル/1.0(IPP)[RFC2565]、[RFC2566]、IPP/1.1[RFC2911]、[RFC2910]、および将来のバージョンに[RFC3995]を見てください。
2. Terminology
2. 用語
It is necessary to define a set of terms to be able to clearly express the requirements for notification services in an IPP System.
明確にIPP Systemでの通知サービスのための要件を言い表すことができるように用語一式を定義するのが必要です。
2.1. Job-Submitting End User
2.1. 仕事を提出するエンドユーザ
A human end user who submits a print job to an IPP Printer. This person may or may not be within the same security domain as the Printer. This person may or may not be geographically near the printer.
印刷仕事をIPP Printerに提出する人間のエンドユーザ。 この人はPrinterと同じセキュリティー領域の中にいるかもしれません。 この人は地理的なプリンタの近くにいるかもしれません。
2.2. Administrator
2.2. 管理者
A human user who established policy for and configures the print system.
そして、方針を確立した人間のユーザ、印刷システムを構成します。
2.3. Operator
2.3. オペレータ
A human user who carries out the policy established by the Administrator and controls the day-to-day running of the print system.
政策を実行する人間のユーザはAdministratorとコントロールによる印刷システムのその日その日の走行を設立しました。
2.4. Job-Submitting Application
2.4. 仕事を提出するアプリケーション
An application (for example, a batch application), acting on behalf of a Job Submitting End User, that submits a print job to an IPP Printer. The application may or may not be within the same security domain as the Printer. This application may or may not be geographically near the printer.
アプリケーション(例えば、バッチアプリケーション)であり、Job Submittingエンドユーザを代表して行動して、それは印刷仕事をIPP Printerに提出します。 Printerと同じセキュリティー領域の中に利用があるかもしれません。 この利用は地理的なプリンタの近くにあるかもしれません。
Hastings, et al. Informational [Page 2] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[2ページ]のRFC3997IPP: 通知要件2005年3月
2.5. Security Domain
2.5. セキュリティー領域
For the purposes of this discussion, the set of network components that can communicate without going through a proxy or firewall. A security domain may be geographically very large; for example, anywhere within example.com.
この議論の目的、プロキシかファイアウォールに直面していなくて交信できるネットワーク要素のセットのために。 セキュリティー領域は地理的に非常に大きいかもしれません。 example.comの中で例えば、そして、どこでも。
2.6. IPP Client
2.6. IPPクライアント
The software component that sends IPP requests to an IPP Printer object and accepts IPP responses from an IPP Printer.
IPPを送るソフトウェアコンポーネントは、反対するようIPP Printerに要求して、IPP PrinterからIPP応答を受け入れます。
2.7. Job Recipient
2.7. 仕事の受取人
A human who is the ultimate consumer of the print job. In many cases this will be the same person as the Job-Submitting End User, but this need not always be the case. For example, if I use IPP to print a document on a printer in a business partner's office, I am the Job- Submitting End User, and the person whom I intend the document for in my business partner's office is the Job Recipient. Since one of the goals of IPP is to be able to print near the Job Recipient, we would normally expect that person to be in the same security domain as, and geographically near, the Printer. However, this may not always be the case. For example, I submit a print job across the Internet to a XYZ's print shop. I am both the Submitting End User and the Job Recipient, but I am neither near nor in the same security domain as the Printer.
印刷仕事の最終消費者である人間。 多くの場合、Jobを提出しているエンドユーザと同じ人になるでしょうが、これはいつもそうでなければならないというわけではありません。 例えば、ビジネスパートナーのオフィスのプリンタの上のドキュメントを印刷するのにIPPを使用するなら、私はJobの提出しているエンドユーザです、そして、私が私のビジネスパートナーのオフィスでドキュメントを意図する人はJob Recipientです。 IPPの目標の1つがJob Recipientの近くで印刷することであることができるので、通常、私たちは、その人が地理的にPrinterとPrinterの近くの同じセキュリティー領域にいると予想するでしょう。 しかしながら、これはいつもそうであるかもしれないというわけではありません。 例えば、私はインターネットの向こう側にXYZの印刷所に印刷仕事を提出します。 SubmittingエンドユーザとJob Recipientの両方ですが、私はどちらも両方です。セキュリティー領域の近くと、そして、Printerと同じセキュリティー領域で。
2.8. Job Recipient Proxy
2.8. 仕事の受取人プロキシ
A person acting on behalf of the Job Recipient. The Job Recipient Proxy physically picks up the printed document from the Printer if the Job Recipient cannot do so. The Proxy is by definition geographically near and in the same security domain as the printer. For example, I submit a print job from home to be printed on a printer at work. I'd like my secretary to pick up the print job and put it on my desk. In this case, I am acting as both a Job- Submitting End User and a Job Recipient. My secretary is acting as a Job Recipient Proxy.
Job Recipientを代表して行動している人。 Job Recipientがそうすることができないなら、Job Recipient ProxyはPrinterから印刷された記録を物理的に受信します。 定義上地理的に近く、プリンタと同じセキュリティー領域でProxy。 例えば、私は、仕事でプリンタに印刷されるために家から印刷仕事を提出します。 私は、私の秘書に印刷仕事を再開して、私の机にそれを置いて欲しいと思います。 この場合、私はエンドユーザを提出するJobとJob Recipientの両方として務めています。 私の秘書はJob Recipient Proxyとして務めています。
2.9. Notification Subscriber
2.9. 通知加入者
A client that requests the IPP Printer to send Event Notifications to one or more Notification Recipients. A Notification Subscriber may be a Job-Submitting End User or an End User, an Operator, or an Administrator that is not submitting a job.
1Notification RecipientsにEvent Notificationsを送るようIPP Printerに要求するクライアント。 Notification SubscriberはJobを提出しているエンドユーザ、エンドユーザ、Operator、または仕事を提出していないAdministratorであるかもしれません。
Hastings, et al. Informational [Page 3] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[3ページ]のRFC3997IPP: 通知要件2005年3月
2.10. Notification Source
2.10. 通知ソース
The entity that sends Event Notifications.
Event Notificationsを送る実体。
2.11. Notification Recipient
2.11. 通知受取人
The entity that receives IPP Notifications about Job and/or Printer events. A Notification Recipient may be a Job Submitting End User, a Job-Submitting Application, a Job Recipient, a Job Recipient Proxy, an Operator, an Administrator, etc., and his or her representative, log file, usage statistics-gathering application, or other active or passive entities.
Job、そして/または、Printer出来事に関してIPP Notificationsを受ける実体。 Notification RecipientはJob Submittingエンドユーザか、Job-提出Applicationか、Job Recipientか、Job Recipient Proxyか、Operatorか、Administratorか、などと、その人の代表か、ログファイルか、用法統計集会アプリケーションか、他の活発であるか受け身の実体であるかもしれません。
2.12. Notification Recipient Agent
2.12. 通知受取人エージェント
A program that receives Event Notifications on behalf of the Notification Recipient. The agent may take some action on behalf of the recipient, forward the notification to the recipient via some alternative means (for example, page the recipient), or queue the notification for later retrieval by the recipient.
Notification Recipientを代表してEvent Notificationsを受けるプログラム。 エージェントは、受取人を代表して何らかの行動を取るか、いくつかの代替の手段(例えば、受取人を呼び出す)で通知を受取人に転送するか、または受取人による後の検索のために通知を列に並ばせるかもしれません。
2.13. Event
2.13. 出来事
An Event is an occurrence (either expected or unexpected) within the printing system of a change of state, condition, or configuration of a Job or Printer object.
EventはJobかPrinter物の状態、状態、または構成の変化の印刷システムの中の(予想されているか、予期していません)の発生です。
2.14. Event Notification
2.14. イベント通知
When an event occurs, an Event Notification is generated that fully describes the event (what the event was, where it occurred, when it occurred, etc.). Event Notifications are delivered to all the Notification Recipients that are subscribed to that Event, if any. The Event Notification is delivered to the address of the Notification Recipient by using the notification delivery method defined in the subscription. However, an Event Notification is sent ONLY if there is a corresponding subscription.
出来事が起こるとき、出来事について完全に説明するEvent Notificationが発生する、(起こったのなどとき、起こったなら、出来事が何であるかということでした。 もしあればそのEventに申し込まれるすべてのNotification RecipientsにイベントNotificationsを渡します。 購読で定義された通知発送方法を使用することによって、Notification RecipientのアドレスにEvent Notificationを届けます。 しかしながら、対応する購読があるだけであれば、Event Notificationを送ります。
2.15. Notification Subscription
2.15. 通知購読
A Notification Subscription is a request by a Notification Subscriber to the IPP Printer to send Event Notifications to specified Notification Recipient(s) when an event occurs.
出来事が起こるとき、Notification Subscriptionは指定されたNotification Recipient(s)にEvent Notificationsを送るというIPP PrinterへのNotification Subscriberによる要求です。
Hastings, et al. Informational [Page 4] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[4ページ]のRFC3997IPP: 通知要件2005年3月
2.16. Notification Attributes
2.16. 通知属性
IPP Objects (for example, a print job) from which notification are being sent may have associated attributes. A user may want to have one or more of these returned along with a particular notification. In general, these may include any attribute associated with the object emitting the notification. Examples include the following:
通知がどれであるかから送られるIPP Objects(例えば、印刷仕事)は属性を関連づけたかもしれません。 ユーザは特定の通知と共にこれらの1つ以上を返して頂きたいかもしれません。 一般に、これらは通知を放つ物に関連しているどんな属性も含むかもしれません。 例は以下を含んでいます:
number-of-intervening jobs
job-k-octets
job-k-octets processed
job impressions
job-impressions-interpreted
job-impressions-completed
impressionsCompletedCurrentCopy (job MIB)
sheetCompletedCopyNumber (job MIB)
sheetsCompletedDocumentNumber (job MIB)
Copies-requested
Copy-type
Output-destination
Job-state-reasons
Job ID
Printer URI
Subscription ID (for job independent subscription)
コピーで要求された介入の数の仕事の解釈された仕事のk八重奏の仕事のk八重奏の処理仕事の印象仕事の印象印象が完了した仕事のimpressionsCompletedCurrentCopy(仕事のMIB)sheetCompletedCopyNumber(仕事のMIB)sheetsCompletedDocumentNumber(仕事のMIB)のJob ID Printer URI Subscription Copy-タイプOutput-目的地Job州の理由ID(仕事の独立している購読のための)
2.17. Notification Delivery Method (or Delivery Method for Short)
2.17. 通知発送方法(または、略して発送方法)
Event Notifications are delivered by using a Delivery Method. An example of a Delivery Method is email.
Delivery Methodを使用することによって、イベントNotificationsを届けます。 Delivery Methodに関する例はメールです。
2.18. Immediate Notification
2.18. 即座の通知
Notifications sent to the Notification Recipient or the Notification Recipient's agent in such a way that the notification arrives immediately, within the limits of common addressing, routing, network congestion, and quality of service.
通知は通知がすぐに到着するような方法でNotification RecipientかNotification Recipientのエージェントに発信しました、サービスの一般的なアドレシングの限界、ルーティング、ネットワークの混雑、および品質の中で。
2.19. Store-and-Forward Notification
2.19. 通知を格納して、転送してください。
Notifications that are not necessarily delivered to Notification Recipients immediately but are queued for delivery by an intermediate network application, for later retrieval. Email is an example of a store-and-forward notification delivery method.
通知は、すぐに、必ずNotification Recipientsに配送するというわけではありませんが、配送のために中間ネットワークアプリケーションで列に並ばせられます、後の検索のために。 メールは店とフォワード通知発送方法に関する例です。
Hastings, et al. Informational [Page 5] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[5ページ]のRFC3997IPP: 通知要件2005年3月
2.20. Reliable Delivery of Notifications
2.20. 通知の信頼できる配信
Notifications that are delivered by a reliable delivery of packets or character stream, with acknowledgement and retry, so that delivery of the notification is guaranteed within determinate time limits. For example, if the Notification Recipient has logged off and gone home for the day, an immediate notification cannot be guaranteed, even when sent over a reliable transport, because there is nothing there to catch it. Guaranteed delivery requires both store-and-forward notification and a reliable transport.
パケットかキャラクタの信頼できる配信で提供される通知は、承認で流れて、再試行されます、通知の配送が確定的なタイムリミットの中で保証されるように。 例えば、Notification Recipientがその1日にログオフして、家に帰ったなら、即座の通知を保証できません、信頼できる輸送の上に送ると、何もそれを捕らえるそこのものがないので。 保証された配送は店とフォワード通知と信頼できる輸送の両方を必要とします。
2.21. Notification over Unreliable Transport
2.21. 頼り無い輸送の上の通知
Notifications are delivered via the fundamental transport address and routing framework, but no acknowledgement or retry is required. Process-to-process communications, if involved, are unconstrained.
基本的な輸送アドレスとルーティング枠組みで通知を提供しますが、どんな承認も再試行も必要としません。 かかわるなら、プロセス間通信は自由です。
2.22. Human-Consumable Notification
2.22. 人間消費できる通知
Notifications intended to be consumed by human end users only. Email would be an example of a Human-Consumable Notification, though it could also contain Machine-Consumable Notification.
人間のエンドユーザだけによって消費されることを意図する通知。 また、Machine消費できるNotificationを含むかもしれませんが、メールはHuman消費できるNotificationに関する例でしょう。
2.23. Machine-Consumable Notification
2.23. マシン消費できる通知
Notifications that are intended for consumption by a program only, such as an IPP Client. Machine-Consumable Notifications may not contain human-readable information. Do we need both human and machine? Machine readable is intended for application-to-application only. The Notification Recipient could process the machine-readable Event Notification into human-readable format.
消費でIPP Clientなどのプログラムだけで意図する通知。 マシン消費できるNotificationsは人間が読める情報を含まないかもしれません。 私たちは人間とマシンの両方を必要としますか? マシン読み込み可能である、アプリケーションからアプリケーションだけのために、意図します。 Notification Recipientは機械可読なEvent Notificationを人間が読める形式に処理できました。
2.24. Mixed Notification
2.24. Mixed通知
A mixed notification contains both Human-Consumable and Machine- Consumable information.
複雑な通知はともにHuman消費できるのとMachineの消費できる情報を含んでいます。
3. Scenarios
3. シナリオ
1. Sitting in my office, I submit a print job to the printer down
the hall. I am in the same security domain as the printer and,
of course, geographically near. I want to know immediately when
my print job will be completed (or if there is a problem)
because the document I am working on is urgent. I submit the
print job with the following attributes:
1. 私のオフィスに座っていて、私はホールの下で印刷仕事をプリンタに提出します。 私は、プリンタと同じセキュリティー領域にいて、もちろん地理的に近いです。 私が取り組んでいるドキュメントが緊急であるので、すぐに、私の印刷仕事がいつ完了するかを(問題があれば)知りたいと思います。 私は以下の属性で印刷仕事を提出します:
Hastings, et al. Informational [Page 6] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[6ページ]のRFC3997IPP: 通知要件2005年3月
- Notification Recipient: Me
- Notification Events: All
- Notification Attributes: Job-state-reason
- Notification Type: Immediate
- 通知受取人: 私--通知イベント: すべて--通知属性: 仕事の州の理由--通知タイプ: 即座
2. Working from home, I submit a print job to the same printer as
in the previous example. However, I am not at work, I cannot
physically get the print file or do anything with it. It can
wait until I get to work this afternoon. However, I'd like my
secretary to pick up the output and put it on my desk so that it
doesn't get lost or misfiled. I'd also like a store-and-forward
notification sent to my email so that when I get to work I can
tell whether there was a problem with the print job. I submit a
print job with the following attributes:
2. 家から働いていて、私は前の例のように同じプリンタに印刷仕事を提出します。 しかしながら、仕事していなくて、私は、物理的に印刷ファイルを手に入れることができませんし、それで何もできません。 私が、今日の午後に働き始めるまで、それは待つことができます。 しかしながら、私が、私の秘書に出力を拾って、私の机にそれを置いて欲しいと思うので、失われているか、またはそれはmisfiledされません。 また、私は、働き始めるとき、私が、印刷仕事に関する問題があったかどうか言うことができるように店とフォワード通知を私のメールに送って欲しいと思います。 私は以下の属性で印刷仕事を提出します:
- Notification Recipient: My secretary
- Notification Events: Print complete
- Notification Type: Immediate
- 通知受取人: 私の秘書--通知Events: 完全な状態で印刷してください、--通知Type: 即座
- Notification Recipient: Me
- Notification Events: Print complete
- Notification Attributes: Impressions completed
- Notification Type: Store and forward
- 通知受取人: 私--通知イベント: 完全な状態で印刷してください、--通知Attributes: 終了する印象--通知Type: ストアとフォワード
3. Sitting in my office, I submit a print job to a client at an
engineering firm my company works with on a daily basis. The
engineering firm is in Belgium. I would like my client to know
when the print job is complete so that she can pick it up from
the printer in her building. It is important that she review it
right away and send her comments back to me. I submit the print
job with the following attributes:
3. 私のオフィスに座っていて、私は日課に私の会社と取り組む土建会社で印刷仕事をクライアントに提出します。 土建会社がベルギーにあります。 私は、私のクライアントに、彼女が彼女のビルのプリンタからそれを拾うことができるくらい印刷仕事がいつ完全であるかを知って欲しいと思います。 彼女がすぐ、それを見直して、コメントを私に送り返すのは、重要です。 私は以下の属性で印刷仕事を提出します:
- Notification Recipient: Client at engineering firm
- Notification Events: Print complete
- Notification Type: Immediate
- Notification Language: French
- 通知受取人: 土建会社のクライアント--通知Events: 完全な状態で印刷してください、--通知Type: 即座である、--通知言語: フランス語
4. From a hotel room, I send a print job to a Kinko's store in the
town I am working in, in order to get a printed report for the
meeting I am attending in the morning. As I'm going out to
dinner after I get this job submitted, an immediate notification
won't do me much good. However, I'd like to check in the
morning before I drive to the Kinko's store to see whether the
file has been printed. An email notification is sufficient for
this purpose. I submit the print job with the following
attributes:
4. ホテルの部屋から、私は印刷仕事を私が働いている町のキンコーズ店に送ります、私が朝出席するミーティングのための印刷されたレポートを得るために。 この仕事を提出させた後に私が外へ食事に出かける予定であるとき、即座の通知は私をあまり良くしないでしょう。 しかしながら、私が、ファイルが印刷されたかどうかを見るのをキンコーズ店に追い立てる前に朝、チェックしたいと思います。 メール通知はこのために十分です。 私は以下の属性で印刷仕事を提出します:
Hastings, et al. Informational [Page 7] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[7ページ]のRFC3997IPP: 通知要件2005年3月
- Notification Recipient: Me
- Notification Events: Print complete
- Notification Type: Store and forward
- 通知受取人: 私--通知イベント: 完全な状態で印刷してください、--通知Type: ストアとフォワード
5. I am printing a large, complex print file. I want to have some
immediate feedback on the progress of the print job as it
prints. I submit the print job with the following attributes:
5. 私は大きくて、複雑な印刷ファイルを印刷しています。 それが印刷するとき、私は、印刷仕事の進歩の何らかの即座のフィードバックが欲しいと思います。 私は以下の属性で印刷仕事を提出します:
- Notification Recipient: Me
- Notification Type: Immediate
- Notification Events: All state transitions
- Notification Attributes: Impression completed
- 通知受取人: 私--通知タイプ: 即座である、--通知イベント: すべての状態遷移--通知Attributes: 終了する印象
6. I am an operator and one of my duties is to keep the printer
running. I subscribe independently from a job submission so
that my subscription outlasts any particular job. I subscribe
with the following attributes:
6. 私はオペレータです、そして、私の義務の1つはプリンタを動かせ続けることです。 私がジョブ依頼から独自に申し込むので、私の購読はどんな特定の仕事よりも長持ちします。 私は以下の属性で申し込みます:
- Notification Recipient: Me
- Notification Type: Immediate
- Notification Events: All Printer state transitions
- Notification Attributes: Printer state, printer state
reasons, device powering up, device powering down
- 通知受取人: 私--通知タイプ: 即座である、--通知イベント: すべてのPrinter状態遷移--通知Attributes: プリンタ状態、プリンタ州の理由、装置がパワーダウンして、エネルギー消費量を上げる装置
7. I am a usage statistics gathering application. I subscribe
independently from a job submission so that my subscription
outlasts any particular job. My subscription may persist across
power cycles. I subscribe with the following attributes:
7. 私はアプリケーションを集める用法統計です。 私がジョブ依頼から独自に申し込むので、私の購読はどんな特定の仕事よりも長持ちします。 私の購読はパワーサイクルの向こう側に持続するかもしれません。 私は以下の属性で申し込みます:
- Notification Recipient: Me
- Notification Type: Immediate
- Notification Events: Job completion
- Notification Attributes: Impression completed, sheets
completed, time submitted, time started, time completed, job
owner, job size in octets, etc.
- 通知受取人: 私--通知タイプ: 即座である、--通知イベント: 仕事の完成--通知Attributes: 完成していて、シートが完成して、時間が提出されて、時間が始まったという印象、完成した時間、仕事の所有者、八重奏における仕事のサイズなど
8. I am a client application program that displays a list of jobs
currently queued for printing on a printer. I display the
"job-name", "job-state", "job-state-reasons", "page-count", and
"intervening-jobs", either for the user's jobs or for all jobs.
The window displaying the job list remains open for an
independent amount of time, and it is desired that it represent
the current state of the queue. It is desired that the
application only perform a slow poll in order to recover from
any missed notifications. So the event delivery mechanism
provides the means to update the screen on all needed changes,
including querying for some attributes that may not be delivered
in the Notification.
8. 私は現在プリンタに印刷するために列に並ばせられている仕事のリストを表示するクライアントアプリケーション・プログラムです。 私はユーザの仕事かすべての仕事のための「ジョブ名」、「仕事状態」、「仕事の州の理由」、「ページ数」、および「介入している仕事」を表示します。 ジョブリストを表示する窓は独立している時間、開いたままで残っています、そして、待ち行列の現状を表すことが望まれています。 アプリケーションがどんな逃された通知からも回復するために遅い投票を実行するだけであることが望まれています。 それで、イベント排紙機構はすべての必要な変化でスクリーンをアップデートする手段を提供します、Notificationで送られないかもしれないいくつかの属性のために質問するのを含んでいて。
Hastings, et al. Informational [Page 8] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[8ページ]のRFC3997IPP: 通知要件2005年3月
9. I am a client application program that displays a list of
printers. For each Printer, I display the current state and
configuration. The window displaying the printer list remains
open for an independent amount of time, and it is desired that
it represent the current state of each printer. It is desired
that the application only need to perform a slow poll in order
to recover from any missed notifications. So the event delivery
mechanism provides the means to update the screen on all needed
changes, including querying for some attributes that may not be
delivered in the Notification.
9. 私はプリンタのリストを表示するクライアントアプリケーション・プログラムです。 各Printerに関しては、私は現状と構成を表示します。 プリンタリストを表示する窓は独立している時間、開いたままで残っています、そして、それぞれのプリンタの現状を表すことが望まれています。 アプリケーションが、どんな逃された通知からも回復するために遅い投票を実行する必要であるだけであることが望まれています。 それで、イベント排紙機構はすべての必要な変化でスクリーンをアップデートする手段を提供します、Notificationで送られないかもしれないいくつかの属性のために質問するのを含んでいて。
10. I am an IPP Server that controls one or more devices and that
implements an IPP Printer object to represent each device. I
want to support IPP Notification for each of the IPP Printer
objects that I implement. Many of these devices do not support
notification (or IPP). So I need to support the IPP
Notification semantics specified for each IPP Printer object
myself on behalf of each of the devices that each of the IPP
Printer objects represents. When I accept an IPP job creation
requests, I convert it to what the device will accept. In some
cases, I must poll the devices in order to be informed of their
job and device state and state changes to be able to send IPP
Notifications to subscribed Notification Recipients.
10. 私は1台以上の装置を制御して、各装置を表すためにIPP Printer物を実行するIPP Serverです。 私が実行するそれぞれのIPP Printer物のためにIPP Notificationを支持したいと思います。 これらの装置の多くが通知(または、IPP)を支持しません。 それで、私は、自分でそれぞれのIPP Printer物が表すそれぞれの装置を代表してそれぞれのIPP Printer物に指定されたIPP Notification意味論を支持する必要があります。 IPPを受け入れるとき、雇用創出要求であり、私は装置が受け入れるものにそれを変換します。 いくつかの場合、私は、申し込まれたNotification RecipientsにIPP Notificationsを送ることができるように彼らの仕事、装置状態、および州の変化について知らされるために装置に投票しなければなりません。
11. I am an IPP Server that controls one or more devices and that
implements an IPP Printer object to represent each device. I
want to support IPP Notification for each of the IPP Printer
objects that I implement. These devices all support IPP,
including IPP Notification. I would like the design choice for
supporting IPP Notification for these objects either (1) by
forwarding the notification to the IPP Printers that I, alone,
control and have them send the notifications to the intended
Notification Recipients without my involvement, or (2) by
replacing the notification submitted with the Job to indicate me
as the Notification Recipient; in turn I will forward
Notifications to the Notification Recipients requested by my
clients. Most of the rest of the contents of the IPP Job I send
to the IPP Printers I control will be the same as those that I
receive from my IPP clients.
11. 私は1台以上の装置を制御して、各装置を表すためにIPP Printer物を実行するIPP Serverです。 私が実行するそれぞれのIPP Printer物のためにIPP Notificationを支持したいと思います。 これらの装置はすべて、IPP Notificationを含むIPPを支持します。 私は、単独の私が制御して、彼らに私のかかわり合いなしで意図しているNotification Recipientsに通知を送らせるというIPP Printersへの通知を転送するのによる(1)か通知を置き換えるのによる(2)のどちらかがNotification Recipientとして私を示すためにJobと共に提出したこれらの物のためにIPP Notificationを支持するためのデザイン選択が欲しいと思います。 順番に、私は私のクライアントによって要求されたNotification RecipientsにNotificationsを送るつもりです。 私が制御するIPP Printersに送るIPP Jobのコンテンツの残りの大部分は私がIPPクライアントから受けるものと同じになるでしょう。
12. I am an IPP Server that controls one or more devices and that
implements an IPP Printer object to represent each device. I
want to support IPP Notification for each of the IPP Printer
objects that I implement. These devices all support IPP,
including IPP Notification. Because these IPP Printers MAY also
be controlled by other servers (using IPP or other protocols), I
only want job events for the jobs that I send, but I do want
Printer events all the time, so that I can show proper Printer
12. 私は1台以上の装置を制御して、各装置を表すためにIPP Printer物を実行するIPP Serverです。 私が実行するそれぞれのIPP Printer物のためにIPP Notificationを支持したいと思います。 これらの装置はすべて、IPP Notificationを含むIPPを支持します。 また、これらのIPP Printersが他のサーバによって制御されるかもしれないので(IPPか他のプロトコルを使用して)、私が送る仕事のために仕事の出来事が欲しいと思うだけですが、私は、絶えずPrinter出来事が欲しいと思います、私が適切なPrinterを見せることができるように
Hastings, et al. Informational [Page 9] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[9ページ]のRFC3997IPP: 通知要件2005年3月
state to my clients. So I subscribe to these IPP Printers for
Printer events with a long-standing subscription, with myself as
the Notification Recipient. When I get a Job Creation request,
I decide to which IPP Printer to send the job. When I do so, I
also add a job subscription for Job events, with me as the
Notification Recipient to the job's job subscriptions supplied
by my clients (this usage is called "piggybacking"). These IPP
Printers automatically remove their job subscriptions when the
job finishes, as for all job subscriptions, so that I no longer
get Job events when my jobs are completed.
私のクライアントへの状態。 それで、私はPrinter出来事のために長年の購読、自分と共にNotification RecipientとしてこれらのIPP Printersに加入します。 Job Creation要求を得るとき、私は、仕事を送るとどのIPP Printerに決めるか。 また、私がそうすると、私は私と共にNotification Recipientとして私のクライアントによって供給された仕事の仕事の購読にJob出来事のための仕事の購読を加えます(この用法は「便乗」と呼ばれます)。 仕事が終わると、これらのIPP Printersは自動的に彼らの仕事の購読を取り除きます、すべての仕事の購読のように私の仕事であるときに、出来事は、私がもうJobを手に入れないように、終了しています。
4. Requirements
4. 要件
The following requirements are intended to be met by the IPP Notification specification (not the implementation). The following are true for the resulting IPP Notification Specification document:
IPP Notification仕様(実現でない)で以下の要件が会われることを意図します。 結果として起こるIPP Notification Specificationドキュメントに、以下は本当です:
1. It must indicate which of these requirements are REQUIRED and
which are OPTIONAL for a conforming implementation to support.
See [RFC2911], section 12.1, for the definition of these
important conformance terms.
1. それは支持する従う実現のためにこれらの要件のどれがREQUIREDであるか、そして、どれがOPTIONALであるかを示さなければなりません。 これらの重要な順応用語の定義に関して[RFC2911]、セクション12.1を見てください。
2. It must be designed so that an IPP Printer can transparently
support the IPP Notification semantics by using third-party
notification services that exist today or that may be
standardized in the future.
2. IPP Printerが今日、存在するか、または将来標準化されるかもしれない第三者通知サービスを利用することによって透明にIPP Notification意味論を支持できるように、それを設計しなければなりません。
3. It must define a means for a Job-Submitting End User to specify
zero or more Notification Recipients when submitting a print job.
A Submitter will not be able to prevent out-of-band subscriptions
from authorized persons, such as Operators.
3. それは印刷仕事を提出するときJobを提出しているエンドユーザがゼロか、より多くのNotification Recipientsを指定する手段を定義しなければなりません。 Submitterはバンドの外でOperatorsなどの権限保持者から購読を防ぐことができないでしょう。
4. It must define a means, when specifying a Notification Recipient,
for a Notification Subscriber to specify one or more notification
events for that Notification Recipient, subject to administrative
and security policy restrictions. Any of the following
constitute Job or Printer Events for which a Job Submitting End
User can specify that notifications be sent:
4. Notification Subscriberが管理を条件としたそのNotification Recipientのための1回以上の通知イベントと安全保障政策制限を指定するようにNotification Recipientを指定するとき、それは手段を定義しなければなりません。 以下のどれかはJob Submittingエンドユーザが、通知が送られると指定できるJobかPrinter Eventsを構成します:
- Any standard Printer MIB alert
- Job Received (transition from Unknown to Pending)
- Job Started (transition from Pending to Processing)
- Page Complete (page is stacked)
- Collated Copy Complete (last sheet of collated copy is
stacked)
- どんな標準のPrinter MIB警戒も--仕事のReceived(UnknownからPendingまでの変遷)--仕事のStarted(PendingからProcessingまでの変遷)(ページComplete(ページは積み重ねられる))はCopy Completeを照合しました。(照合されたコピーの最後のシートは積み重ねられます)
Hastings, et al. Informational [Page 10] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[10ページ]のRFC3997IPP: 通知要件2005年3月
- Job Complete (transition from Processing or Processing-stopped
to Completed)
- Job Aborted (transition from Pending, Pending-held,
- Processing, or Processing-stopped to Aborted)
- Job Canceled (transition from Pending, Pending-held,
- Processing, or Processing-held to Canceled)
- Other job state changes, such as paused, purged
- Device problems for which the job is destined
- Job (interpreter) issues
- 仕事のComplete(ProcessingかProcessingによって止まるのからCompletedまでの変遷)--仕事のAborted(処理しているか、Processingによって止まらされたPendingによって保持されたPendingからAbortedまでの変遷)--仕事のCanceled(処理しているか、Processingによって保持されたPendingによって保持されたPendingからCanceledまでの変遷)--掃除されて、ポーズされるような他の仕事の州の変化--仕事が運命づけられている装置問題--仕事の(インタプリタ)問題
5. It must define how an End User or Operator subscribes for
5. それはエンドユーザかOperatorがどう申し込むかを定義しなければなりません。
- any set of Job Events for a specific job, or
- any set of Printer Events while a specific job is not
complete.
- または、特定の仕事のためのJob Eventsのどんなセット、も--Printer Eventsのどんなセットも特定の仕事である間、完全ではありません。
6. It must define how an End User or Operator subscribes for the
following without having to submit a Job:
6. エンドユーザかOperatorが、↓これが提出する必要はなくてJobであることをどう予約するかをそれは定義しなければなりません:
- Any set of Printer Events for a defined period.
- Any set of Job Events for all jobs, with no control over
which jobs.
- 定義された期間のPrinter Eventsのどんなセット。 - すべての仕事のためのJob Eventsのどんなセット、終わっているコントロールのないどの仕事。
7. It must define how the Notification Subscriber is able to
specify either immediate or store-and-forward notification
independently for each Notification Recipient. The means may be
explicit, or implied by the method of delivery chosen by the Job
Submitting End User.
7. それは、各Notification Recipientのために独自に通知を即座の状態でNotification Subscriberがどう指定できるかを定義しなければならないか、格納して、または転送しなければなりません。 手段は、明白であり、Job Submittingエンドユーザによって選ばれた配送の方法で含意されるかもしれません。
8. It must define common delivery methods: e.g., email.
8. それは一般的な発送方法を定義しなければなりません: 例えば、メールしてください。
9. It must define how an IPP Printer validates its ability to
deliver an Event by using the specified delivery scheme. If it
does not support the specified scheme, or if the specified
scheme is invalid for some reason, then the IPP Printer accepts
and performs the request anyway and indicates the unsupported
attribute values. There is no requirement for the IPP Printer
receiving the print request to validate the identity of a
Notification Recipient, or the ability of the system to deliver
an event to that recipient as requested (for example, if the
Notification Recipient is not at work today).
9. それはIPP Printerがどう指定された配送計画を使用することによってEventを届ける性能を有効にするかを定義しなければなりません。 指定された計画を支持しないか、または指定された計画がある理由で無効であるなら、IPP Printerは受け入れて、とにかく要求を実行して、サポートされない属性値を示します。 要求された通り、Notification Recipientのアイデンティティ、または出来事を渡すシステムの能力を有効にするという印刷要求をその受取人に受け取るIPP Printerのための要件が全くありません(Notification Recipientが今日例えば仕事していないなら)。
10. It must define a class of IPP event notification delivery
methods that can flow through corporate firewalls. However, an
IPP printer need not test to guarantee delivery of the
notification through a firewall before accepting a print job.
10. それは法人のファイアウォールを通して流れることができるIPPイベント通知発送方法のクラスを定義しなければなりません。 しかしながら、IPPプリンタは、印刷仕事を受け入れる前にファイアウォールを通した通知の配送を保証するためにテストされる必要はありません。
Hastings, et al. Informational [Page 11] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[11ページ]のRFC3997IPP: 通知要件2005年3月
11. It may define a means to deliver a notification to the
submitting client when the delivery of an event notification to
a specified Notification Recipient fails. A fallback means of
subscribers to determine whether notifications have failed
(i.e., polling) may be provided.
11. 指定されたNotification Recipientへのイベント通知の配送が失敗すると、それは提出しているクライアントに通知を提供する手段を定義するかもしれません。 加入者が通知が失敗したかどうかと決心する後退手段(すなわち、世論調査)を提供するかもしれません。
12. It must define a mechanism for localizing Human-Consumable
Notifications by the Notification Source.
12. それは、Notification SourceでHuman消費できるNotificationsを局所化するようにメカニズムを定義しなければなりません。
13. It may define a way to specify whether event delivery requires
acknowledgement back to the Notification Source.
13. それはイベント配送がNotification Sourceに承認を必要として戻すかどうか指定する方法を定義するかもしれません。
14. There must be a mechanism defined so that job-independent
subscriptions do not become stale and do not require human
intervention to be removed. However, a subscription must not be
deemed stale only if it is unable to deliver an Event
Notification, as temporary Notification delivery problems must
be tolerated.
14. 定義されたメカニズムがあるに違いないので、仕事から独立している購読は、聞き古したであるならないで、また人間の介入が取り除かれるのを必要としません。 しかしながら、Event Notificationを届けることができない場合にだけ、聞き古したである購読を考えてはいけません、一時的なNotification配送問題を許容しなければならないとき。
15. A mechanism must be defined so that an Event Subscriber is able
to add an Event Subscription to a Job after the Job has been
submitted.
15. メカニズムを定義しなければならないので、Jobを提出した後に、Event SubscriberはJobにEvent Subscriptionを加えることができます。
16. A mechanism must be defined so that a client is able to cancel
an Event Subscription on a job or printer after the job has been
submitted.
16. メカニズムを定義しなければならないので、仕事を提出した後に、クライアントは仕事かプリンタの上のEvent Subscriptionを取り消すことができます。
17. A mechanism must be defined so that a client can obtain the set
of current Subscriptions.
17. クライアントが現在のSubscriptionsのセットを入手できるように、メカニズムを定義しなければなりません。
5. Security Considerations for IPP Notifications Requirements
5. IPP通知要件のためのセキュリティ問題
By far the biggest security concern is the abuse of notification:
sending unwanted notifications sent to third parties (i.e., spam).
The problem is made worse by notification addresses that may be
redistributed to multiple parties (e.g., mailing lists). Scenarios
exist in which third-party notification is required (see scenarios 2
and 3). The fully secure solution would require active agreement of
all recipients before anything is sent out. However, requirement 9
("There is no requirement for an IPP Printer receiving the print
request to validate the identity of an event recipient") argues
against this. Certain systems may decide to disallow third-party
notifications (a traditional fax model).
断然最も大きいセキュリティ関心は通知の乱用です: 送付の求められていない通知は第三者に発信しました(すなわち、ばらまいてください)。 複数のパーティー(例えば、メーリングリスト)に再配付されるかもしれない通知アドレスは問題をより悪くします。 どの第三者通知が必要であるかでシナリオは存在しています(シナリオ2と3を見てください)。 何でも出す前に完全に安全な解決策はすべての受取人の活発な協定を必要とするでしょう。 しかしながら、要件9(「イベント受取人のアイデンティティを有効にするという印刷要求を受け取るIPP Printerのための要件が全くない」)はこれについて反対の議論をします。 あるシステムは、第三者通知(伝統的なファックスモデル)を禁じると決めるかもしれません。
The same security issues are present when Clients submit notification requests to the IPP Printer as when they submit an IPP/1.1 print job request. The same mechanisms used by IPP/1.1 can therefore be used
ClientsがそれらがIPP/1.1印刷仕事の要求を提出する時として通知要求をIPP Printerに提出するとき、同じ安全保障問題は存在しています。 したがって、IPP/1.1によって使用された同じメカニズムは使用できます。
Hastings, et al. Informational [Page 12] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[12ページ]のRFC3997IPP: 通知要件2005年3月
by the client notification submission. Operations that require authentication can use the HTTP authentication. Operations that require privacy can use the HTTP/TLS privacy.
クライアント通知提案で。 認証を必要とする操作はHTTP認証を使用できます。 プライバシーを必要とする操作はHTTP/TLSプライバシーを使用できます。
The notification access control model should be similar to the IPP access control model. Creating a notification subscription is associated with a user. Only the creator or an operator can cancel the subscription. The system may limit the listing of items to items owned by the user. Some subscriptions (e.g., those that have a lifetime longer than a job) can be done only by privileged users (operators and/or administrators), if that is the authorization policy.
通知アクセス管理モデルはIPPアクセス管理モデルと同様であるべきです。 通知購読を作成するのはユーザに関連しています。 創造者かオペレータだけが購読を中止できます。 システムは項目のリストをユーザによって所有されていた項目に制限するかもしれません。 単に特権ユーザ(オペレータ、そして/または、管理者)はいくつかの購読(例えば、仕事より長い間生涯を持っているもの)ができます、それが認可方針であるなら。
The standard security concerns (delivery to the right user, privacy of content, tamper-proof content) apply to the notification delivery. IPP should use the security mechanism of the delivery method used. Some delivery mechanisms are more secure than others. Therefore, sensitive notifications should use the delivery method that has the strongest security.
標準の安全上の配慮(正しいユーザへの配送、満足していて、干渉防止している内容のプライバシー)は通知配送に適用されます。 IPPは方法が使用した配送のセキュリティー対策を使用するはずです。 いくつかの排紙機構が他のものより安全です。 したがって、機密の通知は最も強いセキュリティを持っている発送方法を使用するべきです。
6. Internationalization Considerations
6. 国際化問題
The Human-Consumable Notification must be localized to the natural language and charset that Notification Subscriber specifies within the choice of natural languages and charsets that the IPP Printer supports.
自然言語、Notification Subscriberが自然言語の選択の中で指定するcharset、およびIPP PrinterがサポートするcharsetsにHuman消費できるNotificationを局所化しなければなりません。
The Machine-Consumable Notification data uses the "application/ipp" MIME media type. It contains attributes whose text values are required to be in the natural language and charset that the Notification Subscriber specifies within the choice of natural languages and charsets that the IPP Printer supports. See [RFC2566].
Machine消費できるNotificationデータは「アプリケーション/ipp」MIMEメディアタイプを使用します。 それはテキスト値が自然言語にはあるのに必要である属性、Notification Subscriberが自然言語の選択の中で指定するcharset、およびIPP Printerが支持するcharsetsを含んでいます。 [RFC2566]を見てください。
7. IANA Considerations
7. IANA問題
Some notification delivery methods have been registered with IANA for use in URLs. These will be defined in other documents.
URLにおける使用のためにいくつかの通知発送方法をIANAに登録してあります。 これらは他のドキュメントで定義されるでしょう。
Hastings, et al. Informational [Page 13] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[13ページ]のRFC3997IPP: 通知要件2005年3月
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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を行進させます。
8.2. Informative References
8.2. 有益な参照
[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月。
[RFC2639] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
Holst, "Internet Printing Protocol/1.1: Implementor's
Guide", RFC 3196, November 2001.
[RFC2639] ヘイスティングズ、T.、Manros、C.、Zehler、P.、クーグラー、C.、およびH.ホルスト、「プロトコル/1.1に以下を印刷するインターネット」 「作成者のガイド」、RFC3196、2001年11月。
Hastings, et al. Informational [Page 14] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[14ページ]のRFC3997IPP: 通知要件2005年3月
9. Appendix A: Description of the Base IPP Documents
9. 付録A: 基地の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 [RFC2911], [RFC2910].
「インターネットPrintingプロトコルのためのデザインGoals」は分散印刷の機能性への広い一見を取ります、そして、それは印刷プロトコルに含まれる必要がある特徴をインターネットにはっきりさせるのを助ける現実のシナリオを列挙します。 それは3つのタイプのユーザのための要件を特定します: エンドユーザ、オペレータ、および管理者。 [RFC2565]、それはIPP/1.0[RFC2566]で満たされているエンドユーザ要件の部分集合を呼び出します。 [RFC2910]、いくつかのOPTIONALオペレータ操作がIPP/1.1[RFC2911]に加えられます。
"Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" describes IPP from a high-level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF IPP working group's major decisions.
「StructureとModelのための原理とインターネットPrintingプロトコルのためのプロトコル」は、ハイレベルの眺めからIPPについて説明して、IPP仕様ドキュメントのスイートを形成する様々なドキュメントのために道路地図を定義して、IETF IPPワーキンググループの主たる決定のためにバックグラウンドと原理を与えます。
"Internet Printing Protocol/1.1: Model and Semantics" describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses security, internationalization, and directory issues.
「インターネット印刷プロトコル/1.1:」 「モデルと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 also defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines the "ipp" scheme for identifying IPP printers and jobs.
「インターネット印刷プロトコル/1.1:」 「コード化とTransport」はモデルドキュメントでHTTP/1.1[RFC2616]と定義された抽象的な操作と属性の正式なマッピングです。 また、それはメディアタイプが「アプリケーション/ipp」と呼んだ新しいインターネットMIMEのために符号化規則を定義します。 また、このドキュメントは、HTTPの上でコンテントタイプが「アプリケーション/ipp」であるメッセージ本体を輸送するために規則を決めます。 このドキュメントはIPPプリンタと仕事を特定することの"ipp"計画を定義します。
"Internet Printing Protocol/1.1: Implementer's Guide" gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
「インターネット印刷プロトコル/1.1:」 「Implementerのガイド」はIPPクライアントとIPP物のimplementersに洞察とアドバイスを与えます。 彼らが彼らのクライアント、そして/または、IPP物の実現のデザインにそれらを助けるかもしれない問題のIPP/1.1といくつかを理解しているのを助けるのは意図しています。 例えば、誤りを含んでいるのがチェックして、処理要求の典型的な注文を与えます。 また、仕様決定のいくつかに関する動機は含まれています。
Hastings, et al. Informational [Page 15] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[15ページ]のRFC3997IPP: 通知要件2005年3月
"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に与えます。
Authors' Addresses
作者のアドレス
Tom Hastings (editor) Xerox Corporation 701 S Aviation Blvd, ESAE 242 El Segundo, CA 90245
701秒間のゼロックス社の航空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
Roger deBry Utah Valley State College
ロジャーdeBryユタバレー州立大学
Phone: (801) 863-8848 EMail: debryro@uvsc.edu
以下に電話をしてください。 (801) 863-8848 メールしてください: debryro@uvsc.edu
Harry Lewis IBM Corporation 6300 Diagonal Hwy Boulder, CO 80301
ハリールイスIBM社6300の対角線のHwyボウルダー、CO 80301
Phone: (303) 924-5337 EMail: harryl@us.ibm.com
以下に電話をしてください。 (303) 924-5337 メールしてください: harryl@us.ibm.com
Hastings, et al. Informational [Page 16] RFC 3997 IPP: Notification Requirements March 2005
ヘイスティングズ、他 情報[16ページ]のRFC3997IPP: 通知要件2005年3月
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機能のための基金は現在、インターネット協会によって提供されます。
Hastings, et al. Informational [Page 17]
ヘイスティングズ、他 情報[17ページ]
一覧
スポンサーリンク
