[要約] RFC 2568は、インターネット印刷プロトコル（IPP）のモデルとプロトコルの構造に関する理論的根拠を提供しています。このRFCの目的は、IPPの設計と実装における意思決定の基礎を提供し、効果的な印刷サービスの提供を支援することです。
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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は、このプロトコルの改訂版が提案された標準プロトコルとして公開されることを期待しています。提案された標準は、公開された場合、このメモで定義されているプロトコルから変更されると予想されます。特に、プロトコルの標準トラックバージョンには、強力な認証とプライバシーの機能が組み込まれ、「IPP：」URLタイプがこれらのセキュリティ対策をサポートする「URLタイプ」が定義されることが予想されます。プロトコルの他の変更も可能です。実装者は、このプロトコルの将来のバージョンが、このドキュメントで定義されている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）[RFC2246]と組み合わせて、IPPのセキュリティ層としてTLSを効果的に使用する方法を判断するのに役立ちます。
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.
このドキュメントは一連のドキュメントの1つであり、新しいインターネット印刷プロトコル（IPP）のすべての側面を一緒に説明しています。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]
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：エンコードとトランスポート」ドキュメントは、モデルドキュメントで定義されている抽象操作とhttp/1.1に定義されている属性の正式なマッピングです。「Application/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：実装者ガイド」ドキュメントは、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.
典型的な相互作用の例は、印刷ジョブを作成するためのクライアントからのリクエストです。クライアントは、ジョブの名前、使用するメディア、各メディアインスタンスに配置するページ数など、そのジョブに関連付けられるモデルデータを組み立てます。このデータは、プロトコルに従ってエンコードされます。プロトコルに従って送信されます。サーバー/プリンターは、エンコードされたモデルデータを受信し、サーバー/プリンターによって理解されるフォームにデコードし、そのデータに基づいて、2つのことのいずれかを実行します。（1）ジョブを受け入れるか、（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アーキテクチャの別の部分は、モデルドキュメントで説明されているディレクトリスキーマです。ディレクトリスキーマの役割は、クライアントのニーズを満たす可能性が高いプリンターの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]で使用した（要約）モデル、ジョブおよびホストリソースMIBSと一致させることができます。これにより、IPPまたはSNMP [RFC1905、RFC1906]およびプリンター/ジョブMIBSを介して、データのアクセス方法とは独立して得られたデータの解釈の一貫性が提供されます。
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.
モデルには、いくつかの追加の説明に値する1つの側面があります。ジョブオブジェクトを識別するには、2つの方法があります。（a）URIと（b）プリンターURIとジョブID（32ビットの正の整数）の組み合わせを使用しています。ジョブオブジェクトがurisを持つことを許可すると、柔軟性とスケーラビリティが可能になります。たとえば、ジョブは、大きなバックログを備えたプリンターから、負荷が小さく、ジョブの識別であるジョブオブジェクトURIが変更する必要はありません。ただし、多くの既存の印刷システムには、URIではなく32ビットの正の整数のみを使用してジョブオブジェクトを識別するように強制するローカルモデルまたはインターフェイス制約があります。この数値ジョブIDは、作成リクエストが元々送信されたプリンターオブジェクトのコンテキスト内でのみ一意です。ジョブへの両方のタイプのクライアントアクセスを（ジョブURIまたは数値ジョブIDによる）許可するために、プリンターオブジェクトが作成リクエストを正常に処理して新しいジョブを作成する場合、プリンターオブジェクトはジョブ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.
プロトコルには2つの部分があります。（1）モデルデータのエンコードと（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のサブセットの文字に制約されている文字列です。値は、スカラーまたはスカラーのシーケンスのいずれかです。各スカラー値には、長さの仕様と値のタイプを示す値タグがあります。値タイプには、整数や文字列などの主要なクラスの部分と、DateTime文字列などの主要なクラスの使用を区別するマイナーなクラスの部分の2つの部分があります。タイプ情報を使用した値のタグ付けにより、将来の時期に新しい値タイプを導入できます。
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は、マルチメッサージプロトコルをより効率的にする永続的な接続を可能にします。たとえば、個別のcreate-jobとsend-documentメッセージがあることが実用的です。チャンキングにより、ファイルの長さを決定するためにファイルを事前に事前にすることなく、大きな印刷ファイルを送信できます。受け入れヘッダーは、クライアントのプロトコルとローカリゼーションの希望を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でプリンター、その現在の状態、ヘルプ情報などの使用方法に関する情報を提供したいと考えています。これには、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のDigest Access認証メカニズムは、適切なレベルのアクセス制御を提供します。これらのソリューションは展開され、実際に使用されています。新しいソリューションでは、セキュリティに同じ程度の自信を持つために広範な使用が必要です。注：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は、新しいプロトコルが独立して開発する必要がある拡張性モデルを提供します。特に、ヘッダー、Intent-Types（インターネットメディアタイプを介して）、およびエラーコードには、幅広い受け入れと、拡張のための有用な定義と方法があります。
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.
9. 最後に、データ送信の使用が確立され、機能し、結果はCGIスクリプトまたはサーブレットを介して使用できるため、印刷データを携帯するために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.
IPPの使用の成功は、クライアントが適切なIPP有効なプリンターを見つけ、IPPリクエストを印刷するなどのIPPリクエストを送信することに依存します。このタスクは、適切なプリンターを照会できるディレクトリサービスがある場合、簡素化されます。ディレクトリスキーマの目的は、プリンターのURIを関連付けることができるプリンター属性の標準的な説明を持つことです。これらの属性は、モデル属性のサブセットであり、クライアントが使用するディレクトリサービスの適切なクエリ構文でエンコードできます。
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の設計において、焦点は、実装されている（または現在実装可能）一連のセキュリティプロトコル/機能を特定し、分散印刷で実際の問題を解決することにありました。サポートが適切であると思われる2つの領域は次のとおりです。（1）プリンターを使用する許可と（2）プリンターとの安全な相互作用。選択されたメカニズムは、HTTP 1.1およびSSL3 [SSL]安全な通信メカニズムのダイジェスト認証メカニズムです。
[ipp-iig] Hastings, T. and C. Manros, "Internet Printing Protocol/1.0:Implementer's Guide", Work in Progress.
[IPP-IIG] Hastings、T。およびC. Manros、「インターネット印刷プロトコル/1.0：実装ガイド」、進行中の作業。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2569] Herriot、R.、Hastings、T.、Jacobs、N。およびJ. Martin、「LPDとIPPプロトコルのマッピング」、RFC 2569、1999年4月。
[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.、Hastings、T.、Herriot、R。、およびP. Powell、「インターネット印刷プロトコル/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] Herriot、R。、Butler、S.、Moore、P。and R. Tuner、「インターネット印刷プロトコル/1.0：エンコーディングとトランスポート」、RFC 2565、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567] Wright、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMPV2）のバージョン2のプロトコル操作」、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMPV2）のバージョン2の輸送マッピング」、RFC 1906、1996年1月。
[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.
[SSL] Netscape、The SSLプロトコル、バージョン3、（テキストバージョン3.02）、1996年11月。
Stephen Zilles Adobe Systems Incorporated 345 Park Avenue MailStop W14 San Jose, CA 95110-2704
Stephen Zilles Adobe Systems Incorporated 345 Park Avenue Mailstop W14 San Jose、CA 95110-2704
Phone: +1 408 536-4766
Fax: +1 408 537-4042
EMail: szilles@adobe.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。