RFC2568 日本語訳

Network Working Group                                          S. Zilles
Request for Comments: 2568                            Adobe Systems Inc.
Category: Experimental                                        April 1999

Zillesがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2568年のアドビ・システムズ株式会社カテゴリ: 実験的な1999年4月

         Rationale for the Structure of the Model and Protocol
                   for the Internet Printing Protocol

インターネット印刷プロトコルのためのモデルとプロトコルの構造への原理

Status of this Memo

この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.

Copyright(C)インターネット協会(1999)。 All rights reserved。

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.

このドキュメントはインターネットコミュニティのためにExperimentalプロトコルを定義します。 IESGは、Proposed Standardが議定書を作るときこのプロトコルの改訂版が発行されると予想します。 発行されると、Proposed Standardがこのメモで定義されたプロトコルから変化すると予想されます。 特に、プロトコルの標準化過程バージョンが強い認証、プライバシー機能、およびそれを取り入れると予想される、「ipp:」 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はこのプロトコルによる実験を奨励します、特にTransport Layer Security(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セットのドキュメントの1つであり、どれが新しいインターネットPrintingプロトコル(IPP)の全面について一緒に説明しますか? IPPは分配された印刷にインターネット・ツールと技術を使用することで使用できるアプリケーションレベルプロトコルです。 このドキュメントは、高い平らな視点からIPPについて説明して、IPP仕様のスイートを形成する様々なドキュメントのために道路地図を定義して、IETFワーキンググループの主たる決定のためにバックグラウンドと原理を与えます。

Zilles                        Experimental                      [Page 1]

RFC 2568                   Rationale for IPP                  April 1999

IPP1999年4月のためのZillesの実験的な[1ページ]RFC2568原理

   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]

StructureとModelのためのインターネットPrintingプロトコル[RFC2567]原理とインターネットPrintingプロトコル(このドキュメント)インターネットPrintingのためのプロトコルのためにプロトコル/1.0にGoalsを設計してください: モデルと意味論[RFC2566]インターネット印刷プロトコル/1.0: コード化と輸送[RFC2565]インターネット印刷プロトコル/1.0: LPDとIPPの間でプロトコルを写像するImplementerのガイド[ipp-iig][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つのタイプのユーザのための要件を特定します: エンドユーザ、オペレータ、および管理者。 Design Goalsドキュメントは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に以下を印刷するインターネット」 「モデルとSemantics」というドキュメントは抽象的なオブジェクト、それらの属性、および彼らの操作のコード化と輸送から独立している簡易型のモデルの成ることについて説明します。 モデルはPrinterとJobオブジェクトから成ります。 Jobは任意に複数のドキュメントを支えます。 また、このドキュメントはセキュリティ、国際化、およびディレクトリ問題を扱います。

   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のimplementersに反対します。 彼らが彼らのクライアント、そして/または、IPPオブジェクト実装のデザインにそれらを助けるかもしれない問題のIPP/1.0といくつかを理解しているのを助けるのは意図しています。 例えば、誤りを含んでいるのがチェックして、処理要求の典型的な注文を与えます。 また、仕様決定のいくつかに関する動機は含まれています。

   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(線Printer Daemon)実装の間で何らかのアドバイスをゲートウェイのimplementersに与えます。

1.   ARCHITECTURAL OVERVIEW

1. 建築概要

   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

インターネットPrintingプロトコル(IPP)は分配された印刷にインターネットで使用できるアプリケーションレベルプロトコルです。 このプロトコルはクライアントとサーバとの相互作用を定義します。

Zilles                        Experimental                      [Page 2]

RFC 2568                   Rationale for IPP                  April 1999

IPP1999年4月のためのZillesの実験的な[2ページ]RFC2568原理

   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.

プロトコルで、クライアントは、印刷仕事をプリンタの能力について問い合わせをして、印刷仕事を提出して、問い合わせをして、中止します。 これらの要求のためのサーバはPrinterです。 Printerはジェネリックドキュメント出力装置、そして/または、印刷サービスプロバイダーの抽象化です。 したがって、Printerはラインプリンタかファックス出力装置などの実際の印刷デバイスであるかもしれませんかそれが出力装置に接続したサービスであるかもしれません。

   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.

プロトコルはDocument Printing Application(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のためのアーキテクチャは印画法を制御して、プロセスの情報とPrinterの能力を提供するのに使用されるデータのために抽象的なModelを定義します(ModelとSemanticsドキュメント[RFC2566]で)。 この抽象的なModelは現実に階層的であり、Printerによって処理されているかもしれないPrinterとジョブスの構造を反映します。

   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.

インターネットはクライアントとサーバ/プリンタの間にチャンネルを供給します。 このチャンネルの使用は、階層的なModelデータを平らにして、配列するのを必要とします。 したがって、また、IPPはクライアントとサーバの間の転送のためにモデルにおける、データのコード化を定義します(EncodingとTransportドキュメント[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は、クライアントとサーバ/プリンタの間にコード化された要求と応答データを移すためにプロトコルを定義します(EncodingとTransportドキュメント[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.

典型的な相互作用に関する例は、印刷雇用を創り出すためにはクライアントからの要求でしょう。 クライアントはその仕事に関連しているようにModelデータを組み立てるでしょう、仕事の名前などのように、使用するメディア、それぞれのメディアインスタンスなどに置くページ数 このデータは、次に、プロトコルによってコード化されて、プロトコルに応じて、送られるでしょう。 そのデータに基づいて、サーバ/プリンタは、コード化されたModelデータを受け取って、サーバ/プリンタに解釈されたフォームにそれを解読して、2つのものの1つをするでしょう: (1) (2) 仕事を受け入れるか、または仕事を拒絶してください。 どちらの場合ではも、サーバは、プロトコルを使用することでModelデータに関して応答を構成して、プロトコルによってその応答をコード化して、要求への応答としてそのコード化されたModelデータを送らなければなりません。

   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

IPPアーキテクチャの別の部分はモデルドキュメントで説明されたディレクトリSchemaです。 ディレクトリSchemaの役割はaについて質問するのに使用されるかもしれない属性の標準セットを提供することです。

Zilles                        Experimental                      [Page 3]

RFC 2568                   Rationale for IPP                  April 1999

IPP1999年4月のためのZillesの実験的な[3ページ]RFC2568原理

   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.

クライアントの需要を満たしそうなPrinterのURIのためのディレクトリサービス。 また、IPPアーキテクチャは、セキュリティが印刷されるべきサーバ/プリンタへのアクセスのコントロールと要求の安全な送信や、応答やデータなどの問題であると扱います。

2. THE PRINTER

2. プリンタ

   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能力を持つでしょう。 さらに、Printerがプリンタの周りにダイレクトユーザ情報入手を許容するためにHTML/HTTPサーバになるのは、ありそうです。

3. RATIONALE FOR THE MODEL

3. モデルのための原理

   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.

Model[RFC2566]は、Modelデータのどんなコード化の如何にかかわらずともに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をサポートするアプリケーション/サーバの中に何らかのデータ構造におけるModelデータを表すと予想されます。 したがって、Modelは、その表現を簡単にするように設計されました。 通常、パーサかフォーマッタが、データの形式、または、コード化されたデータの形式に変換するのに使用されるでしょう。 製品に適した内部のフォームの一度、製品はデータを操ることができます。 例えば、そのPrint Jobの処理を制御するのにPrint Jobと共に送られたデータは使用できます。

   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の意味論は(抽象的)のモデルに愛着しています。 したがって、アプリケーション/サーバはModelデータのコード化であることに依存していません、そして、クライアントからサーバまでデータを送ることができた代替のメカニズムと形式を考えるのは可能です。 例えば、サーバには、数種類のPrintジョブスを受け入れるのに使用されるかもしれないダイレクトで、クライアントなしのGUIインタフェースがあるかもしれません。 また、ここに採用されたのが将来ひどく制限するために示されるなら、この独立は、異なったコード化、そして/または、効果波及経路が使用されるのを許容するでしょうに。 そのような変化は移行して、補欠としての新製品がModelデータのためにスタック/パーサについて議定書の中で述べるということであるかもしれません。

Zilles                        Experimental                      [Page 4]

RFC 2568                   Rationale for IPP                  April 1999

IPP1999年4月のためのZillesの実験的な[4ページ]RFC2568原理

   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.

また、抽象的なModelを持っているのに、ModelデータはPrinter[RFC1759]、Job、およびHost Resources MIBsで使用される(抽象的)のモデルに並びます。 これはどうアクセスされているかの如何にかかわらず得られたデータの解釈に一貫性を提供します、IPPを通して、または、SNMP[RFC1905、RFC1906]とPrinter/仕事の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.

何らかの付加的な説明に値するModelの1つの局面があります。 Jobオブジェクトを特定するための2つの方法があります: (a) Job URIと(b)がPrinter URIとJob ID(32ビットの正の整数)の組み合わせを使用していて。 JobオブジェクトにはURIがあるのを許容するのが柔軟性とスケーラビリティを考慮します。 大きい予備があるプリンタから1まで例えば仕事をよりわずかな負荷に動かすことができました、そして、職務識別(JobオブジェクトURI)は変化する必要はありません。 しかしながら、多くの既存の印刷システムには、JobオブジェクトがURIよりむしろ32ビットの正の整数だけを使用することでやむを得ず特定されるローカルのモデルかインタフェース規制があります。 要求を作成してください。この数値Job IDがPrinterオブジェクトの文脈の中でユニークであるだけである、どれ、元々、提出したか。 両方を許容するために、Printerオブジェクトが首尾よくaを処理するときのジョブス(Job URIか数値Job IDのそばの)へのクライアントアクセスのタイプは、要求を作成して、新しいJobを作成して、Printerオブジェクトは、新しいJobオブジェクトのために両方がJob URIとJob IDであると生成します。 この要件で、すべてのクライアントがクライアント実装に課されたどんな地方の規制の如何にかかわらずPrinterオブジェクトとJobオブジェクトにアクセスできます。

4. RATIONALE FOR THE PROTOCOL

4. プロトコルのための原理

   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) クライアントとサーバの間にモデルデータを送るためのModelデータとメカニズムのコード化。

4.1 The Encoding

4.1 コード化

   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.

埋め込まれたプリンタ、非常に簡単なバイナリーを開発するのをより簡単にするように、コード化は選ばれました。 このコード化は、Modelの中に現れるデータの種類を表すために適切です。 それには、属性の系列から成る単純構造があります。 各属性に、名前の長さ、および値によって前に置かれた名前があります。 名前はASCIIの部分集合からキャラクタに抑制されたストリングです。 値は、スカラのスカラか系列のどちらかです。 それぞれのスカラの値には、長さの仕様と価値のタイプを示す値のタグがあります。 値のタイプには、2つの部品があります: 主要なクラスは離れています、整数やストリングや、主要なクラスの使用法を区別する小さい方のクラス部分などのように、dateTimeストリングなどのように。 タイプ情報がある値のタグ付けは、何らかの将来の時間に新しい値のタイプを導入すると考慮します。

Zilles                        Experimental                      [Page 5]

RFC 2568                   Rationale for IPP                  April 1999

IPP1999年4月のためのZillesの実験的な[5ページ]RFC2568原理

   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.

完全にコード化された要求/応答には、バージョン番号、操作(要求のための)または状態が任意にいます。コード化されたModelデータであり、Modelデータに従って、任意に(要求のために)データを印刷するステータスメッセージ(応答のための)、関連パラメタ、および属性。

4.2 The Transmission Mechanism

4.2 効果波及経路

   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.

コード化されたModelデータを送るための選ばれたメカニズムはHTTP1.1ポスト(そして、関連応答)です。 HTTP1.1への変更は、全く提案もされませんし、必要になりもしません。 Transmission Mechanismの唯一の役割はコード化されたModelデータの/からクライアントまでの転送をサーバからの/に供給することです。これはどんなデータ排紙機構も使用し終わることができました。 HTTP1.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. HTTP1.0は既に広く配布されます、そして、最近の証拠に基づいて、メーカーが新製品を発表するとき、HTTP1.1は広く配布されています。 HTTP1.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. HTTP1.1は新しいプロトコルが開発されるのを必要としたかもしれない問題の大部分を解決します。 HTTP1.1はマルチメッセージプロトコルが、より効率的にするパーシステントコネクションを許容します。 例えば、別々のCreate-仕事とSendドキュメントメッセージを持っているのは実用的です。 分魂化で、大きな活字の本ファイルのファイルをあらかじめスキャンする必要はなくて伝達はファイルの長さを測定できます。 受け入れてください。ヘッダーは、クライアントのプロトコルとローカライズ願望がIPP操作とデータで伝えられるのを許容します。 Jobが動かされるとき、どんな理由でも、Modelがキャンセル仕事などのJob要求のリダイレクションに備えるつもりであったなら、再直接の応答がJobであるときに、知らされて、彼が中で興味を持っているということであることをクライアントを許容する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. ほとんどのネットワークPrintersが、IPP以外の理由でHTTPがサーバであると実装するでしょう。 これらのネットワークの付属PrintersはHTMLにどうプリンタ、現状、ヘルプ情報などを使用するかの情報を提供したがっています。 これは、IPPに機能するようにまた、利用可能なHTTPサーバを持っているのを必要とします。

Zilles                        Experimental                      [Page 6]

RFC 2568                   Rationale for IPP                  April 1999

IPP1999年4月のためのZillesの実験的な[6ページ]RFC2568原理

      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. HTTP1.1の複雑さの大部分はHTTPクライアント、そして/または、サーバの実装ではなく、HTTPプロキシの実装に関係があります。 仕事は、HTTP作業部会でサーバでしなければならないことを特定するのを助けかけます。EncodingとTransportがショーを記録するとき、それはそれほど多くはありません。

      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をひくでしょう。 HTTP1.1のダイジェストアクセス認証機構は適切なアクセスのレベルコントロールを提供します。 配布されて実用にはこれらのソリューションがあります。 新しいソリューションは、大規模な使用にはセキュリティにおける、同じ度合いの信用があるのを必要とするでしょう。 以下に注意してください。 IETF標準化過程の上にSSL3がありません。

      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は新しいプロトコルが独自に開発しなければならない伸展性モデルを提供します。 ヘッダー、熱心なタイプ(インターネットメディア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スクリプトかサーブレットで利用可能であるので、ポストメソッドは印刷データを運ぶために選ばれました。 新しいメソッドを作成すると、POSTedデータの意図している使用は、よりよく特定されたでしょうが、新しいメソッドは配布するのが、より難しいでしょう。 IPPのために新しいデフォルトポートを割り当てるのは、インストールされたインフラストラクチャへの最小量の影響を必要な識別に提供するので、代わりに選ばれました。

5. RATIONALE FOR THE DIRECTORY SCHEMA

5. ディレクトリ図式のための原理

      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を送るのが印刷などのように仕事を要求するPrinterを有効にしたのがわかっているクライアントに頼っています。 適当なPrinterのために質問できるディレクトリサービスがあれば、このタスクは簡易型です。 ディレクトリSchemaの目的は関連する場合があるPrinter属性の標準の記述を持つことです。プリンタのためのURI。 クライアントによって使用されながら、これらの属性は、Model属性の部分集合であり、ディレクトリサービスのための適切な質問構文でコード化できます。

Zilles                        Experimental                      [Page 7]

RFC 2568                   Rationale for IPP                  April 1999

IPP1999年4月のためのZillesの実験的な[7ページ]RFC2568原理

6. SECURITY CONSIDERATIONS - RATIONALE FOR SECURITY

6. セキュリティ問題--セキュリティのための原理

      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のデザインには、焦点が実装されて(または、現在、実装可能します)、分配された印刷の実際の問題を解決する1セットのセキュリティプロトコル/機能を特定するところにありました。 サポートするのが適切に見える2つの領域は以下の通りです。 (1) Printerを使用する承認と(2)はプリンタとの相互作用を機密保護します。 選ばれたメカニズムはHTTP1.1とSSL3[SSL]の安全なコミュニケーションメカニズムのダイジェスト認証機構です。

7. REFERENCES

7. 参照

   [ipp-iig]  Hastings, T. and C. Manros, "Internet Printing
              Protocol/1.0:Implementer's Guide", Work in Progress.

[ipp-iig] 「インターネット印刷プロトコル/1.0: Implementerのガイド」というヘイスティングズ、T.、およびC.Manrosは進行中で働いています。

   [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月。

   [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.とイサクソンとS.とヘイスティングズとT.とエリオとR.とP.パウエル、「プロトコル/1.0に以下を印刷するインターネット」 「モデルと意味論」、RFC2566、4月1999日

   [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に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日

   [RFC2567]  Wright, D., "Design Goals for an Internet Printing
              Protocol", RFC 2567, April 1999.

[RFC2567] ライト、D.、「インターネット印刷プロトコルのデザイン目標」、RFC2567、1999年4月。

   [ISO10175] ISO/IEC 10175 "Document Printing Application (DPA)", June
              1996.

1996年6月の[ISO10175]IEC10175ISO/「ドキュメント印刷アプリケーション(DPA)。」

   [RFC1759]  Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
              Gyllenskog, "Printer MIB", RFC 1759, March 1995.

[RFC1759] スミスとR.とライトとF.とヘイスティングズとT.とZillesとS.と1995年のJ.Gyllenskog、「プリンタMIB」、RFC1759行進。

   [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)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、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)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。

Zilles                        Experimental                      [Page 8]

RFC 2568                   Rationale for IPP                  April 1999

IPP1999年4月のためのZillesの実験的な[8ページ]RFC2568原理

   [SSL]      Netscape, The SSL Protocol, Version 3, (Text version
              3.02), November 1996.

[SSL]Netscape、SSLプロトコル、バージョン3、(テキストバージョン3.02)、1996年11月。

8. AUTHOR'S ADDRESS

8. 作者のアドレス

   Stephen Zilles
   Adobe Systems Incorporated
   345 Park Avenue
   MailStop W14
   San Jose, CA 95110-2704

パーク・アベニューMailStop W14サンノゼ、スティーブンZillesアドビ・システムズ株式会社345カリフォルニア95110-2704

   Phone: +1 408 536-4766
   Fax:   +1 408 537-4042
   EMail: szilles@adobe.com

以下に電話をしてください。 +1 408 536-4766Fax: +1 408 537-4042 メールしてください: szilles@adobe.com

Zilles                        Experimental                      [Page 9]

RFC 2568                   Rationale for IPP                  April 1999

IPP1999年4月のためのZillesの実験的な[9ページ]RFC2568原理

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Zilles                        Experimental                     [Page 10]

Zilles実験的です。[10ページ]