Network Working Group S. Zilles
Request for Comments: 2568 Adobe Systems Inc.
Category: Experimental April 1999
Rationale for the Structure of the Model and Protocol
for the Internet Printing Protocol
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
IESG Note
IESG注意
This document defines an Experimental protocol for the Internet community. The IESG expects that a revised version of this protocol will be published as Proposed Standard protocol. The Proposed Standard, when published, is expected to change from the protocol defined in this memo. In particular, it is expected that the standards-track version of the protocol will incorporate strong authentication and privacy features, and that an "ipp:" URL type will be defined which supports those security measures. Other changes to the protocol are also possible. Implementors are warned that future versions of this protocol may not interoperate with the version of IPP defined in this document, or if they do interoperate, that some protocol features may not be available.
この文書は、インターネットコミュニティのための実験プロトコルを定義します。 IESGはこのプロトコルの改訂版が提案されている標準的なプロトコルとして公開されることを期待しています。標準化提案は、公表されたときに、このメモで定義されたプロトコルから変更することが期待されています。 URLタイプは、これらのセキュリティ対策をサポートする定義されます。特に、プロトコルの標準トラックバージョンは強力な認証とプライバシー機能を組み込み、「IPP」ということが期待されます。プロトコルに対するその他の変更も可能です。実装者はこのプロトコルの将来のバージョンでは、この文書で定義されたIPPのバージョンとの相互運用性はありませかもしれないと警告している、またはそれらが相互運用しなければ、一部のプロトコル機能は利用できない可能性があること。
The IESG encourages experimentation with this protocol, especially in combination with Transport Layer Security (TLS) [RFC2246], to help determine how TLS may effectively be used as a security layer for IPP.
IESGは、TLSが有効IPPのセキュリティ層として使用することができる方法を決定するために役立つ、特にトランスポート層セキュリティ（TLS）[RFC2246]との組み合わせで、このプロトコルを用いて実験を奨励します。
ABSTRACT
抽象
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions.
この文書は、一緒に新しいインターネット印刷プロトコル（IPP）のすべての側面を記述した文書のセットの1つです。 IPPは、インターネットツールと技術を使用して、分散印刷のために使用することができるアプリケーションレベルのプロトコルです。この文書では、高レベルのビューからIPPを説明IPP仕様のスイートを構成する様々な文書のためのロードマップを定義し、IETFワーキンググループの主要な意思決定の背景と理論的根拠を提供します。
The full set of IPP documents includes:
IPPドキュメントのフルセットが含まれています：
Design Goals for an Internet Printing Protocol [RFC2567] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol (this document) Internet Printing Protocol/1.0: Model and Semantics [RFC2566] Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569]
モデルと意味論[RFC2566]インターネット印刷プロトコル/ 1.0：コード化と輸送[RFC2565インターネット印刷プロトコル（本書）インターネット印刷プロトコル/ 1.0のための構造とモデルとプロトコルのためのインターネット印刷プロトコル[RFC2567]原理の設計目標]インターネット印刷プロトコル/ 1.0：Implementerのガイド[IPP-IIG] LPDとIPPプロトコル[RFC2569間のマッピング]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to 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. The Design Goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
文書「インターネット印刷プロトコルの設計目標は、」分散印刷機能で幅広い見てみると、それはインターネットのための印刷プロトコルに含まれる必要な機能を明確にするために役立つ実際のシナリオを列挙します。エンドユーザー、オペレータ、および管理者：これは、ユーザーの3種類の要件を識別します。設計目標ドキュメントはIPP / 1.0で満たされているエンドユーザーの要求のサブセットを呼び出します。オペレータと管理者の要件は、バージョン1.0の範囲外です。
The "Internet Printing Protocol/1.0: Model and Semantics" document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. The model consists of a Printer and a Job object. The Job optionally supports multiple documents. This document also addresses security, internationalization, and directory issues.
「インターネット印刷プロトコル/ 1.0：モデルとセマンティクス」文書は、エンコードとトランスポートから独立して単純化された抽象オブジェクトで構成されるモデル、その属性、およびその動作を説明します。モデルは、プリンタとジョブオブジェクトで構成されています。仕事は、必要に応じて複数のドキュメントをサポートしています。この文書では、セキュリティ、国際化、およびディレクトリ問題に対処します。
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
「インターネット印刷プロトコル/ 1.0：コード化とTransport」文書がHTTP / 1.1にモデル文書で定義された抽象操作と属性の正式なマッピングです。これは、「アプリケーション/ IPP」と呼ばれる新しいインターネットメディアタイプのための符号化規則を定義します。
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 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.0：Implementerのガイド」ドキュメントはIPPクライアントとIPPオブジェクトの実装への洞察とアドバイスを提供します。彼らがIPP / 1.0とそのクライアントおよび/またはIPPオブジェクト実装のデザインでそれらを支援することが検討事項のいくつかを理解するためのものです。例えば、処理要求の典型的な順序は、エラー・チェックを含む、与えられます。仕様決定のいくつかのための動機も含まれています。
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
文書「LPDとIPPプロトコル間のマッピングは、」IPPとのLPD（Line Printer Daemon）実装の間のゲートウェイの実装にいくつかのアドバイスを提供します。
The Internet Printing Protocol (IPP) is an application level protocol that can be used for distributed printing on the Internet. This protocol defines interactions between a client and a server. The protocol allows a client to inquire about capabilities of a printer, to submit print jobs and to inquire about and cancel print jobs. The server for these requests is the Printer; the Printer is an abstraction of a generic document output device and/or a print service provider. Thus, the Printer could be a real printing device, such as a computer printer or fax output device, or it could be a service that interfaced with output devices.
インターネット印刷プロトコル（IPP）は、インターネット上の分散印刷のために使用することができるアプリケーションレベルのプロトコルです。このプロトコルは、クライアントとサーバー間の相互作用を定義します。プロトコルは、クライアントが、印刷ジョブを送信すると、印刷ジョブを問い合わせるとキャンセルし、プリンタの機能を問い合わせることができます。これらの要求のためのサーバがプリンタです。プリンタは、一般的なドキュメント出力デバイスおよび/または印刷サービスプロバイダを抽象化したものです。このように、プリンタは、コンピュータ、プリンタまたはFAX出力デバイスとして実際の印刷装置とすることができ、またはそれは、出力デバイスとインターフェイスのサービスである可能性があります。
The protocol is heavily influenced by the printing model introduced in the Document Printing Application (DPA) [ISO10175] standard. Although DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses only on end user functionality.
プロトコルは重く文書印刷アプリケーション（DPA）[ISO10175]規格に導入プリンティングモデルによって影響されます。 DPAは、エンドユーザと管理機能の両方を指定しますが、IPPバージョン1.0（IPP / 1.0）のみで、エンドユーザー機能に焦点を当てています。
The architecture for IPP defines (in the Model and Semantics document [RFC2566]) an abstract Model for the data which is used to control the printing process and to provide information about the process and the capabilities of the Printer. This abstract Model is hierarchical in nature and reflects the structure of the Printer and the Jobs that may be being processed by the Printer.
IPPのためのアーキテクチャは、（モデルおよびセマンティクス文書に[RFC2566]）印刷プロセスを制御するプロセスとプリンタの機能に関する情報を提供するために使用されるデータの抽象モデルを定義します。この抽象モデルは、本質的に階層的であるとプリンタによって処理されていることもプリンターやジョブの構造を反映しています。
The Internet provides a channel between the client and the server/Printer. Use of this channel requires flattening and sequencing the hierarchical Model data. Therefore, the IPP also defines (in the Encoding and Transport document [RFC2565]) an encoding of the data in the model for transfer between the client and server. This transfer of data may be either a request or the response to a request.
インターネットは、クライアントとサーバ/プリンタとの間のチャネルを提供します。このチャネルの使用は、平坦化と階層モデルのデータを配列決定することが必要です。したがって、IPPは、クライアントとサーバの間で転送するためのモデルのデータのエンコード（符号化及びトランスポート文書[RFC2565]で）定義します。このデータの転送は、要求または要求に対する応答のいずれであってもよいです。
Finally, the IPP defines (in the Encoding and Transport document [RFC2565]) a protocol for transferring the encoded request and response data between the client and the server/Printer.
最後に、IPPは（符号化およびトランスポート・ドキュメント[RFC2565]で）クライアントとサーバ/プリンタ間符号化要求と応答データを転送するためのプロトコルを定義します。
An example of a typical interaction would be a request from the client to create a print job. The client would assemble the Model data to be associated with that job, such as the name of the job, the media to use, the number of pages to place on each media instance, etc. This data would then be encoded according to the Protocol and would be transmitted according to the Protocol. The server/Printer would receive the encoded Model data, decode it into a form understood by the server/Printer and, based on that data, do one of two things: (1) accept the job or (2) reject the job. In either case, the server must construct a response in terms of the Model data, encode that response according to the Protocol and transmit that encoded Model data as the response to the request using the Protocol.
典型的な相互作用の例としては、印刷ジョブを作成するには、クライアントからのリクエストになります。モデルデータを組み立てるでしょう、クライアントは、このようなジョブの名前と、そのジョブに関連付けられていることを、使用するメディアは、各メディアインスタンスに配置するページの数は、など、このデータは、その後プロトコルに従って符号化されるだろうおよびプロトコルに従って送信されるだろう。 （1）ジョブを受け入れるか、または（2）ジョブを拒絶：サーバ/プリンタは2つのいずれかを実行し、そのデータに基づいて、符号化されたモデルデータを受信するサーバ/プリンタによって理解される形式にそれをデコードしてしまいます。いずれの場合も、サーバは、プロトコルに従って応答モデルデータ、エンコードの点で応答を構築しなければならず、プロトコルを使用して要求に対する応答として、その符号化されたモデルデータを送信します。
Another part of the IPP architecture is the Directory Schema described in the model document. The role of a Directory Schema is to provide a standard set of attributes which might be used to query a directory service for the URI of a Printer that is likely to meet the needs of the client. The IPP architecture also addresses security issues such as control of access to server/Printers and secure transmissions of requests, response and the data to be printed.
IPPアーキテクチャの別の部分は、モデルの文書に記述さDirectoryスキーマです。 Directoryスキーマの役割は、クライアントのニーズを満たす可能性があるプリンタのURIのためのディレクトリサービスを照会するために使用されるかもしれない属性の標準セットを提供することです。 IPPのアーキテクチャは、印刷するようなサーバ/プリンタと要求、応答、およびデータの安全な伝送へのアクセス制御などのセキュリティ問題に対処します。
Because the (abstract) server/Printer encompasses a wide range of implementations, it is necessary to make some assumptions about a minimal implementation. The most likely minimal implementation is one that is embedded in an output device running a specialized real time operating system and with limited processing, memory and storage capabilities. This printer will be connected to the Internet and will have at least a TCP/IP capability with (likely) SNMP [RFC1905, RFC1906] support for the Internet connection. In addition, it is likely the the Printer will be an HTML/HTTP server to allow direct user access to information about the printer.
（抽象）サーバー/プリンタは、実装の広い範囲を包含しているので、最小限の実装に関するいくつかの仮定を行う必要があります。最も可能性の高い最小限の実装では、専門的なリアルタイム・オペレーティング・システムを実行している出力デバイスで、限られた処理、メモリおよびストレージ機能が組み込まれているものです。このプリンタは、インターネットに接続され、インターネット接続のための（おそらく）SNMP [RFC1905、RFC1906]のサポートと、少なくともTCP / IP機能を備えています。また、プリンタは、プリンタに関する情報への直接のユーザアクセスを許可するようにHTML / HTTPサーバとなる可能性があります。
The Model [RFC2566] is defined independently of any encoding of the Model data both to support the likely uses of IPP and to be robust with respect to the possibility of alternate encoding.
モデル[RFC2566]はIPPのありそうな用途をサポートするために、代替符号化の可能性に対してロバストであることがモデルデータの両方のいずれかの符号化とは独立に定義されます。
It is expected that a client or server/Printer would represent the Model data in some data structure within the applications/servers that support IPP. Therefore, the Model was designed to make that representation straightforward. Typically a parser or formatter would be used to convert from or to the encoded data format. Once in an internal form suitable to a product, the data can be manipulated by the product. For example, the data sent with a Print Job can be used to control the processing of that Print Job.
クライアントまたはサーバ/プリンタは、IPPをサポートするアプリケーション/サーバ内の一部のデータ構造のモデルデータを表現することが期待されます。したがって、モデルはその表現は単純にするために設計されました。典型的には、パーサまたはフォーマッタから又は符号化されたデータフォーマットに変換するために使用されるであろう。一度製品に適した内部形式で、データは、製品によって操作することができます。例えば、印刷ジョブに送信されたデータは、その印刷ジョブの処理を制御するために使用することができます。
The semantics of IPP are attached to the (abstract) Model. Therefore, the application/server is not dependent on the encoding of the Model data, and it is possible to consider alternative mechanisms and formats by which the data could be transmitted from a client to a server; for example, a server could have a direct, client-less GUI interface that might be used to accept some kinds of Print Jobs. This independence would also allow a different encoding and/or transmission mechanism to be used if the ones adopted here were shown to be overly limiting in the future. Such a change could be migrated into new products as an alternate protocol stack/parser for the Model data.
IPPの意味は（抽象）モデルに添付されています。したがって、アプリケーション/サーバは、モデルデータのエンコーディングに依存しない、データがクライアントからサーバに送信することができたことにより、別のメカニズムとフォーマットを考慮することが可能です。例えば、サーバは、印刷ジョブの一部の種類を受け入れるために使用されるかもしれない、直接、クライアントレスGUIインターフェイスを持つことができます。この独立性はまた、ここで採用したものが過度将来的に制限されることが示された場合は、別のエンコードおよび/または伝達機構を使用することができるようになります。そのような変化は、モデルデータの代替プロトコルスタック/パーサとして新しい製品に移行することができます。
Having an abstract Model also allows the Model data to be aligned with the (abstract) model used in the Printer [RFC1759], Job and Host Resources MIBs. This provides consistency in interpretation of the data obtained independently of how the data is accessed, whether via IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job MIBs.
抽象モデルを持つことも、モデルデータをプリンタで使用される（抽象）モデル[RFC1759]と一致することを可能にする仕事とリソースのMIBをホストします。これは、IPPを介して、またはSNMP [RFC1905、RFC1906]とプリンタ/ジョブのMIBを介してかどうか、データがアクセスされる方法とは独立して得られたデータの解釈に一貫性を提供します。
There is one aspect of the Model that deserves some extra explanation. There are two ways for identifying a Job object: (a) with a Job URI and (b) using a combination of the Printer URI and a Job ID (a 32 bit positive integer). Allowing Job objects to have URIs allows for flexibility and scalability. For example a job could be moved from a printer with a large backlog to one with a smaller load and the job identification, the Job object URI, need not change. However, many existing printing systems have local models or interface constraints that force Job objects to be identified using only a 32-bit positive integer rather than a URI. This numeric Job ID is only unique within the context of the Printer object to which the create request was originally submitted. In order to allow both types of client access to Jobs (either by Job URI or by numeric Job ID), when the Printer object successfully processes a create request and creates a new Job, the Printer object generates both a Job URI and a Job ID for the new Job object. This requirement allows all clients to access Printer objects and Job objects independent of any local constraints imposed on the client implementation.
いくつかの余分な説明に値するモデルの一つの側面があります。ジョブオブジェクトを識別するための2つの方法がある：（a）にジョブURIとプリンタURIとJob ID（32ビットの正の整数）の組み合わせを用いて、（B）を有します。ジョブオブジェクトはURIを持つことができるようにすると、柔軟性と拡張性を可能にします。例えば、ジョブは、ジョブオブジェクトURI、小さな負荷とジョブ識別を有するものに大きいバックログを有するプリンタから移動することができ、変更する必要はありません。しかしながら、多くの既存の印刷システムは、32ビットの正の整数ではなく、URIを使用して識別されるジョブオブジェクトを強制ローカルモデルまたはインタフェースの制約を有しています。この数値ジョブIDは、作成要求が最初に提出された先のプリンタオブジェクトのコンテキスト内でのみ一意です。プリンタオブジェクトが正常に要求を作成して処理し、新しいジョブを作成するときにジョブ（ジョブURIによって、または数値ジョブIDのいずれかによって）へのクライアントアクセスの両方のタイプを可能にするために、Printerオブジェクトは、Job URIとジョブIDの両方を生成し、新しいジョブオブジェクトの。この要件は、すべてのクライアントがプリンタオブジェクトにアクセスすることを可能にすると、ジョブは、クライアントの実装に課せられた任意のローカルな制約の独立したオブジェクト。
There are two parts to the Protocol: (1) the encoding of the Model data and (2) the mechanism for transmitting the model data between client and server.
モデルデータの（1）符号化とクライアントとサーバとの間のモデルデータを送信する（2）メカニズム：プロトコルには2つの部分があります。
To make it simpler to develop embedded printers, a very simple binary encoding has been chosen. This encoding is adequate to represent the kinds of data that occur within the Model. It has a simple structure consisting of sequences of attributes. Each attribute has a name, prefixed by a name length, and a value. The names are strings constrained to characters from a subset of ASCII. The values are either scalars or a sequence of scalars. Each scalar value has a length specification and a value tag which indicates the type of the value. The value type has two parts: a major class part, such as integer or string, and a minor class part which distinguishes the usage of the major class, such as dateTime string. Tagging of the values with type information allows for introducing new value types at some future time.
それは単純に埋め込まれたプリンタを開発するようにするには、非常に単純なバイナリエンコードが選択されています。この符号化は、モデル内で発生するデータの種類を表現するのに十分です。これは、属性の配列からなる簡単な構造を有しています。各属性は、名前の長さで始まる名前、および値を持ちます。名前は、ASCIIのサブセットから文字に制限文字列です。値は、スカラーまたはスカラーの配列のいずれかです。各スカラー値は、長さ仕様と値の種類を示す値タグを有しています。主要なクラスの部分、例えば、整数または文字列、および主要なクラスの使用を区別するマイナークラスの一部として、そのような日時文字列として：値型は二つの部分を有しています。型情報を持つ値のタグ付けは、いくつかの将来の時点で、新たな価値のタイプを導入することができます。
A fully encoded request/response has a version number, an operation (for a request) or a status and optionally a status message (for a response), associated parameters and attributes which are encoded Model data and, optionally (for a request), print data following the Model data.
完全に符号化された要求/応答は、（要求用）バージョン番号、操作または（応答のための）ステータスおよび必要に応じてステータスメッセージ（要求に対して）必要に応じて、モデルデータを符号化されている関連するパラメータおよび属性を有していますモデルデータを、次の印刷データ。
The chosen mechanism for transmitting the encoded Model data is HTTP 1.1 Post (and associated response). No modifications to HTTP 1.1 are proposed or required. The sole role of the Transmission Mechanism is to provide a transfer of encoded Model data from/to the client to/from the server. This could be done using any data delivery mechanism. The key reasons why HTTP 1.1 Post is used are given below. The most important of these is the first. With perhaps this exception, these reasons could be satisfied by other mechanisms. There is no claim that this list uniquely determines a choice of mechanism.
符号化されたモデルデータを送信するための選択された機構は、HTTP 1.1ポスト（および関連する応答）です。 HTTP 1.1への改造は、提案されていないか、必要とされます。伝達機構の唯一の役割は、サーバーへ/からクライアントへの/からのエンコードされたモデルデータの転送を提供することです。これは、任意のデータ配信メカニズムを使用して行うことができます。 HTTP 1.1ポストが使用されている主な理由は以下の通りです。これらの中で最も重要なのは最初です。おそらく、この例外を除いて、これらの理由は、他のメカニズムによって満たすことができます。このリストは一意メカニズムの選択を決定ノークレームはありません。
1. HTTP 1.0 is already widely deployed and, based on the recent evidence, HTTP 1.1 is being widely deployed as the manufacturers release new products. The performance benefits of HTTP 1.1 have been shown and manufactures are reacting positively.
1. HTTP 1.0は、すでに広くメーカーが新製品をリリースするなど、最近の証拠に基づいて、HTTP 1.1は広く展開され、展開されています。 HTTP 1.1のパフォーマンス上の利点が示されており、積極的に反応している製造しています。
Wide deployment has meant that many of the problems of making a protocol work in a wide range of environments from local net to Intranet to Internet have been solved and will stay solved with HTTP 1.1 deployment.
ワイド展開は、インターネットへのローカルネットからイントラネットへの環境の広い範囲でのプロトコルの仕事を作るの問題の多くが解決されていると、HTTP 1.1の展開で解決したままになることを意味しています。
2. HTTP 1.1 solves most of the problems that might have required a new protocol to be developed. HTTP 1.1 allows persistent connections that make a multi-message protocol be more efficient; for example it is practical to have separate Create-Job and Send-Document messages. Chunking allows the transmission of large print files without having to pre-scan the file to determine the file length. The accept headers allow the client's protocol and localization desires to be transmitted with the IPP operations and data. If the Model were to provide for the redirection of Job requests, such as Cancel-Job, when a Job is moved, the HTTP redirect response allows a client to be informed when a Job he is interested in is moved to another server/Printer for any reason.
2. HTTP 1.1を開発するための新しいプロトコルを必要としている可能性のある問題のほとんどを解決します。 HTTP 1.1は、マルチメッセージプロトコルは、より効率的で作る永続的な接続を可能にします。例えば、別の、ジョブの作成と送信、文書メッセージを持つことが現実的です。チャンキングは、ファイルの長さを決定するために、ファイルを事前にスキャンすることなく、大規模な印刷ファイルの送信を可能にします。受け入れヘッダは、クライアントのプロトコルと局在がIPP操作とデータを送信することを希望することができます。モデルは、このようなキャンセル・ジョブとして、ジョブ要求のリダイレクトを提供した場合、ジョブが移動したとき、彼が興味を持っている仕事をするために別のサーバ/プリンタに移動すると、HTTPリダイレクト応答をクライアントに通知することができます何らかの理由。
3. Most network Printers will be implementing HTTP servers for reasons other than IPP. These network attached Printers want to provide information on how to use the printer, its current state, HELP information, etc. in HTML. This requires having an HTTP server which would be available to do IPP functions as well.
3.ほとんどのネットワークプリンターは、IPP以外の理由でHTTPサーバを実装します。これらのネットワーク接続されたプリンタは、HTMLでなど、プリンタ、現在の状態、HELP情報を、使用方法についての情報を提供したいです。これは、同様にIPP機能を行うために利用できるようになるHTTPサーバーを持つ必要があります。
4. Most of the complexity of HTTP 1.1 is concerned with the implementation of HTTP proxies and not the implementation of HTTP clients and/or servers. Work is proceeding in the HTTP Working Group to help identify what must be done by a server. As the Encoding and Transport document shows, that is not very much.
4. HTTP 1.1の複雑さのほとんどは、HTTPプロキシではなくHTTPクライアントおよび/またはサーバの実装の実装に関するものです。作業はサーバーによって行われなければならないものを識別しやすくするためにHTTPワーキンググループで進行されます。エンコードとトランスポート文書が示すように、それは非常に多くのではありません。
5. HTTP implementations provide support for handling URLs that would have to be provided if a new protocol were defined.
5. HTTPの実装は、新しいプロトコルが定義されている場合に提供されなければならないURLを処理するためのサポートを提供します。
6. An HTTP based solution fits well with the Internet security mechanisms that are currently deployed or being deployed. HTTP will run over SSL3. The digest access authentication mechanism of HTTP 1.1 provides an adequate level of access control. These solutions are deployed and in practical use; a new solution would require extensive use to have the same degree of confidence in its security. Note: SSL3 is not on the IETF standards track.
【請求項6】HTTPベースのソリューションは、現在配備されているか、展開されているインターネットのセキュリティメカニズムとよく合います。 HTTPは、SSL3上で実行されます。 HTTP 1.1のダイジェストアクセス認証メカニズムは、アクセス制御の十分なレベルを提供します。これらのソリューションは、展開され、実用化されています。新しいソリューションは、セキュリティに自信の同程度を持っている大規模な使用を必要とします。注意：SSL3は、IETF標準化過程の上ではありません。
7. HTTP provides an extensibility model that a new protocol would have to develop independently. In particular, the headers, intent-types (via Internet Media Types) and error codes have wide acceptance and a useful set of definitions and methods for extension.
7. HTTPは新しいプロトコルが独立して開発しなければならない拡張性モデルを提供します。具体的には、ヘッダ、（インターネットメディアタイプを経由して）意図-タイプとエラーコードが広く受け入れと定義し、拡張する方法の便利なセットを持っています。
8. Although not strictly a reason why IPP should use HTTP as the transmission protocol, it is extremely helpful that there are many prototyping tools that work with HTTP and that CGI scripts can be used to test and debug parts of the protocol.
8. IPPは、伝送プロトコルとしてHTTPを使用すべき理由はない厳密な理由は、それがHTTPで動作し、そのCGIスクリプトがプロトコルのデバッグパーツをテストするために使用することができ、多くのプロトタイピングツールがあることが非常に便利ですが。
9. Finally, the POST method was chosen to carry the print data because its usage for data transmission has been established, it works and the results are available via CGI scripts or servlets. Creating a new method would have better identified the intended use of the POSTed data, but a new method would be more difficult to deploy. Assigning a new default port for IPP provided the necessary identification with minimal impact to installed infrastructure, so was chosen instead.
データ伝送のためのその使用は、それが動作しますが、確立されたとの結果がCGIスクリプトやサーブレットを経由してご利用いただけますので9.最後に、POSTメソッドは、印刷データを運ぶために選ばれました。新しいメソッドを作成すると、より良いポストされたデータの使用目的を特定していますが、新しい方法が導入するのがより難しいだろう。 IPPの新しいデフォルトポートを割り当てることインストールインフラストラクチャへの影響を最小限に抑えながら、必要な識別情報を提供するので、代わりに選択しました。
Successful use of IPP depends on the client finding a suitable IPP
enabled Printer to which to send a IPP requests, such as print a
job. This task is simplified if there is a Directory Service which
can be queried for a suitable Printer. The purpose of the
Directory Schema is to have a standard description of Printer
attributes that can be associated the URI for the printer. These
attributes are a subset of the Model attributes and can be encoded
in the appropriate query syntax for the Directory Service being
used by the client.
Security is an area of active work on the Internet. Complete
solutions to a wide range of security concerns are not yet
available. Therefore, in the design of IPP, the focus has been on
identifying a set of security protocols/features that are
implemented (or currently implementable) and solve real problems
with distributed printing. The two areas that seem appropriate to
support are: (1) authorization to use a Printer and (2) secure
interaction with a printer. The chosen mechanisms are the digest
authentication mechanism of HTTP 1.1 and SSL3 [SSL] secure
communication mechanism.
[ipp-iig] Hastings, T. and C. Manros, "Internet Printing Protocol/1.0:Implementer's Guide", Work in Progress.
[IPP-IIG]ヘイスティングズ、T.とC. Manros、 "インターネット印刷プロトコル/ 1.0：Implementerのガイド" が進行中で働いています。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2569]エリオ、R.、ヘイスティングス、T.、ジェイコブズ、N.とJ.マーチン、 "LPDとIPPプロトコルとの間のマッピング"、RFC 2569、1999年4月。
[RFC2566] deBry, R., Isaacson, S., Hastings, T., Herriot, R. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2566] deBry、R.、Isaacson氏、S.、ヘイスティングズ、T.、エリオ、R.とP.パウエル、 "インターネット印刷プロトコル/ 1.0：モデルと意味論"、RFC 2566、1999年4月。
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565]エリオ、R.、バトラー、S.、ムーア、P.とR.チューナー、 "インターネット印刷プロトコル/ 1.0：コード化とTransport"、RFC 2565、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567]ライト、D.、 "インターネット印刷プロトコルの設計目標"、RFC 2567、1999年4月。
[ISO10175] ISO/IEC 10175 "Document Printing Application (DPA)", June 1996.
[ISO10175] ISO / IEC 10175 "のドキュメントの印刷アプリケーション（DPA）"、1996年6月。
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1759]スミス、R.、ライト、F.、ヘイスティングス、T.、Zilles、S.およびJ.およびGyllenskog、 "プリンタMIB"、RFC 1759、1995年3月。
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1905]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、1996年1月。
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1906]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、RFC 1906 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための交通マッピング"、1996年1月。
[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.
[SSL]ネットスケープ、SSLプロトコル、バージョン3、（テキストバージョン3.02）、1996年11月。
Stephen Zilles Adobe Systems Incorporated 345 Park Avenue MailStop W14 San Jose, CA 95110-2704
スティーブンZilles Adobe Systems Incorporated（アドビシステムズ社）345パークアベニューメールストップW14サンノゼ、CA 95110-2704
Phone: +1 408 536-4766 Fax: +1 408 537-4042 EMail: szilles@adobe.com
電話：+1 408 536-4766ファックス：+1 408 537-4042 Eメール：szilles@adobe.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。