RFC2565 日本語訳
2565 Internet Printing Protocol/1.0: Encoding and Transport. R.Herriot, Ed., S. Butler, P. Moore, R. Turner. April 1999. (Format: TXT=80439 bytes) (Obsoleted by RFC2910) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Herriot, Ed.
Request for Comments: 2565 Xerox Corporation
Category: Experimental S. Butler
Hewlett-Packard
P. Moore
Microsoft
R. Turner
Sharp Labs
April 1999
ワーキンググループのR.エリオ、エドをネットワークでつないでください。コメントのために以下を要求してください。 2565年のゼロックス社のカテゴリ: 実験的な鋭いS.のP.ムーアマイクロソフトR.研究室バトラーヒューレット・パッカードターナー1999年4月
Internet Printing Protocol/1.0: Encoding and Transport
インターネット印刷プロトコル/1.0: コード化と輸送
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) [RFC 2246], to help determine how TLS may effectively be used as a security layer for IPP.
IESGはこのプロトコルによる実験を奨励します、特にTransport Layer Security(TLS)[RFC2246]と組み合わせて助けるのは、セキュリティにIPPのために層にされるときTLSがどのように事実上使用されるかもしれないかを決定します。
Herriot, et al. Experimental [Page 1] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[1ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
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 defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp".
このドキュメントは1セットのドキュメントの1つであり、どれが新しいインターネットPrintingプロトコル(IPP)の全面について一緒に説明しますか? IPPは分配された印刷にインターネット・ツールと技術を使用することで使用できるアプリケーションレベルプロトコルです。 このドキュメントはIPP操作をコード化するために規則を決めました、そして、「アプリケーション/ipp」と、新しいインターネットパントマイムメディアタイプへのIPP属性は呼びました。 また、このドキュメントは、HTTPの上でコンテントタイプが「アプリケーション/ipp」であるメッセージ本体を輸送するために規則を決めます。
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 [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport (this
document)
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
構造とモデルのためのインターネット印刷プロトコル[RFC2567]原理とインターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/1.0のためのプロトコルの目標を設計してください: モデルと意味論[RFC2566]インターネット印刷プロトコル/1.0: コード化とTransport(このドキュメント)インターネットPrintingプロトコル/1.0: LPDとIPPの間でプロトコルを写像するImplementerのガイド[ipp-iig][RFC2569]
The document, "Design Goals for an Internet Printing Protocol", 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. It 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 document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions.
「構造とモデルのための原理とインターネット印刷プロトコルのためのプロトコル」というドキュメントは、高い平らな視点からIPPについて説明して、IPP仕様のスイートを形成する様々なドキュメントのために道路地図を定義して、IETFワーキンググループの主たる決定のためにバックグラウンドと原理を与えます。
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport. It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
ドキュメント、「プロトコル/1.0に以下を印刷するインターネット」 「モデルとSemantics」と、簡易型のモデルは抽象的なオブジェクト、それらの属性、彼らのコード化から独立している操作、および輸送で説明します。 それはPrinterとJobオブジェクトを導入します。 Jobオブジェクトは任意に複数の1Jobあたりのドキュメントを支えます。 また、それはセキュリティ、国際化、およびディレクトリ問題を扱います。
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
このドキュメント「プロトコル/1.0に以下を印刷するインターネット」 「Implementerのガイド」はIPPクライアントとIPPオブジェクトのimplementersにアドバイスします。
Herriot, et al. Experimental [Page 2] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[2ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
The document "Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
「LPDとIPPの間でプロトコルを写像する」というドキュメントはIPPとLPD(線Printer Daemon)実装の間で何らかのアドバイスをゲートウェイのimplementersに与えます。
Table of Contents
目次
1. Introduction.....................................................4
2. Conformance Terminology..........................................4
3. Encoding of the Operation Layer.................................4
3.1 Picture of the Encoding.....................................5
3.2 Syntax of Encoding..........................................7
3.3 Version-number..............................................9
3.4 Operation-id................................................9
3.5 Status-code.................................................9
3.6 Request-id..................................................9
3.7 Tags.......................................................10
3.7.1 Delimiter Tags.........................................10
3.7.2 Value Tags.............................................11
3.8 Name-Length................................................13
3.9 (Attribute) Name...........................................13
3.10 Value Length...............................................16
3.11 (Attribute) Value..........................................16
3.12 Data.......................................................18
4. Encoding of Transport Layer.....................................18
5. Security Considerations.........................................19
5.1 Using IPP with SSL3........................................19
6. References......................................................20
7. Authors' Addresses..............................................22
8. Other Participants:.............................................24
9. Appendix A: Protocol Examples...................................25
9.1 Print-Job Request..........................................25
9.2 Print-Job Response (successful)............................26
9.3 Print-Job Response (failure)...............................27
9.4 Print-Job Response (success with attributes ignored).......28
9.5 Print-URI Request..........................................30
9.6 Create-Job Request.........................................31
9.7 Get-Jobs Request...........................................31
9.8 Get-Jobs Response..........................................32
10. Appendix C: Registration of MIME Media Type Information for
"application/ipp"..............................................35
11. Full Copyright Statement.......................................37
1. 序論…4 2. 順応用語…4 3. 操作がコード化されるのは層にされます…4 コード化の3.1画像…5 コード化の3.2構文…7 3.3バージョン番号…9 3.4操作イド…9 3.5 状態コード…9 3.6要求イド…9 3.7 タグ付けをします。10 3.7 .1 デリミタタグ…10 3.7 .2 タグを評価してください…11 3.8名前長さ…13 3.9 (結果と考えます) 命名します。13 3.10 長さを評価してください…16 3.11 (属性)値…16 3.12のデータ…18 4. 輸送がコード化されるのは層にされます…18 5. セキュリティ問題…19 5.1 SSL3とIPPを使用します…19 6. 参照…20 7. 作者のアドレス…22 8. 他の関係者: ……24 9. 付録A: 例について議定書の中で述べてください…25 9.1印刷仕事の要求…25 9.2 印刷仕事の応答(うまくいっている)…26 9.3 印刷仕事の応答(失敗)…27 9.4 印刷仕事のResponse(属性が無視されている成功)…28 9.5印刷URI要求…30 雇用を創り出している9.6要求…31 ジョブスを得ている9.7要求…31 9.8 ジョブスを得ている応答…32 10. 付録C: MIMEメディアの登録は「アプリケーション/ipp」のための情報をタイプします…35 11. 完全な著作権宣言文…37
Herriot, et al. Experimental [Page 3] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[3ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
1. Introduction
1. 序論
This document contains the rules for encoding IPP operations and describes two layers: the transport layer and the operation layer.
このドキュメントは、IPP操作をコード化するための規則を含んでいて、2つの層について説明します: トランスポート層と操作は層にされます。
The transport layer consists of an HTTP/1.1 request or response. RFC 2068 [RFC2068] describes HTTP/1.1. This document specifies the HTTP headers that an IPP implementation supports.
トランスポート層はHTTP/1.1要求か応答から成ります。 RFC2068[RFC2068]はHTTP/1.1について説明します。 このドキュメントはIPP実装がサポートするHTTPヘッダを指定します。
The operation layer consists of a message body in an HTTP request or response. The document "Internet Printing Protocol/1.0: Model and Semantics" [RFC2566] defines the semantics of such a message body and the supported values. This document specifies the encoding of an IPP operation. The aforementioned document [RFC2566] is henceforth referred to as the "IPP model document"
操作層はHTTP要求か応答でメッセージ本体から成ります。 ドキュメント「プロトコル/1.0に以下を印刷するインターネット」 「モデルとSemantics」[RFC2566]はそのようなメッセージ本体とサポートしている値の意味論を定義します。 このドキュメントはIPP操作のコード化を指定します。 前述のドキュメント[RFC2566]は今後は、「IPPモデルドキュメント」と呼ばれます。
2. Conformance Terminology
2. 順応用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Encoding of the Operation Layer
3. 操作層のコード化
The operation layer MUST contain a single operation request or operation response. Each request or response consists of a sequence of values and attribute groups. Attribute groups consist of a sequence of attributes each of which is a name and value. Names and values are ultimately sequences of octets
操作層はただ一つの操作要求か操作応答を含まなければなりません。 各要求か応答が値と属性グループの系列から成ります。 属性グループはそれのそれぞれが名前と値である属性の系列から成ります。 結局、名前と値は八重奏の系列です。
The encoding consists of octets as the most primitive type. There are several types built from octets, but three important types are integers, character strings and octet strings, on which most other data types are built. Every character string in this encoding MUST be a sequence of characters where the characters are associated with some charset and some natural language. A character string MUST be in "reading order" with the first character in the value (according to reading order) being the first character in the encoding. A character string whose associated charset is US-ASCII whose associated natural language is US English is henceforth called a US-ASCII-STRING. A character string whose associated charset and natural language are specified in a request or response as described in the model document is henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP model document order" with the first octet in the value (according to the IPP model document order) being the first octet in the encoding Every integer in this encoding MUST be encoded as a signed integer using two's-complement binary encoding with big-endian format (also known as "network order" and "most significant byte
コード化は最も原始のタイプとして八重奏から成ります。 3つの重要なタイプが、八重奏から造られたいくつかのタイプがありますが、整数と、文字列と八重奏ストリングです。(そこでは、他のほとんどのデータ型が組立しています)。 このコード化におけるあらゆる文字列がキャラクタがいくらかのcharsetと何らかの自然言語に関連しているキャラクタの系列であるに違いありません。 値(読み込み注文に従って)におけるコード化で最初のキャラクタである最初のキャラクタでの「オーダーを読みます」には文字列があるに違いありません。 関連charsetが関連自然言語が米国の英語である米国-ASCIIである文字列は今後は、米国ASCII STRINGと呼ばれます。 関連charsetと自然言語がモデルドキュメントで説明されるように要求か応答で指定される文字列は今後は、LOCALIZED-STRINGと呼ばれます。 八重奏ストリングがビッグエンディアン形式がある2補数の2進のコード化を使用して、値(IPPモデルドキュメント注文に従って)におけるコード化で最初の八重奏である最初の八重奏での「IPPモデルドキュメント注文」では署名している整数としてこのコード化におけるEvery整数をコード化しなければならないということであるに違いない、(また、「ネットワークオーダー」と「最も重要なバイト」として、知られています。
Herriot, et al. Experimental [Page 4] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[4ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
first"). The number of octets for an integer MUST be 1, 2 or 4, depending on usage in the protocol. Such one-octet integers, henceforth called SIGNED-BYTE, are used for the version-number and tag fields. Such two-byte integers, henceforth called SIGNED-SHORT are used for the operation-id, status-code and length fields. Four byte integers, henceforth called SIGNED-INTEGER, are used for values fields and the sequence number.
「1番目」) プロトコルの用法によって、整数のための八重奏の数は、1、2または4であるに違いありません。 そのような1八重奏の今後はSIGNED-BYTEと呼ばれた整数はバージョン番号とタグ・フィールドに使用されます。 そのような2バイトの整数であり、今後は呼ばれたSIGNED-SHORTは操作イド、ステータスコード、および長さの分野に使用されます。 今後はSIGNED-INTEGERと呼ばれた整数が使用される4バイトは分野と一連番号を評価します。
The following two sections present the operation layer in two ways
以下の2つのセクションが2つの方法で操作層を贈ります。
- informally through pictures and description
- formally through Augmented Backus-Naur Form (ABNF), as specified
by RFC 2234 [RFC2234]
- 非公式である、画像と記述で--、正式である、Augmented BN記法(ABNF)、RFC2234によって指定されます。[RFC2234]
3.1 Picture of the Encoding
3.1 コード化の画像
The encoding for an operation request or response consists of:
操作要求か応答のためのコード化は以下から成ります。
----------------------------------------------- | version-number | 2 bytes - required ----------------------------------------------- | operation-id (request) | | or | 2 bytes - required | status-code (response) | ----------------------------------------------- | request-id | 4 bytes - required ----------------------------------------------------------- | xxx-attributes-tag | 1 byte | ----------------------------------------------- |-0 or more | xxx-attribute-sequence | n bytes | ----------------------------------------------------------- | end-of-attributes-tag | 1 byte - required ----------------------------------------------- | data | q bytes - optional -----------------------------------------------
----------------------------------------------- | バージョン番号| 2バイト--必要です。----------------------------------------------- | 操作イド(要求)| | または| 2バイト--必要です。| ステータスコード(応答)| ----------------------------------------------- | 要求イド| 4バイト--必要です。----------------------------------------------------------- | xxx属性タグ| 1バイト| ----------------------------------------------- |-0以上| xxx属性系列| nバイト| ----------------------------------------------------------- | 属性タグの端| 1バイト--必要です。----------------------------------------------- | データ| qバイト--、任意-----------------------------------------------
The xxx-attributes-tag and xxx-attribute-sequence represents four different values of "xxx", namely, operation, job, printer and unsupported. The xxx-attributes-tag and an xxx-attribute-sequence represent attribute groups in the model document. The xxx- attributes-tag identifies the attribute group and the xxx-attribute- sequence contains the attributes.
xxx属性タグとxxx属性系列は"xxx"の4つの異価、操作、すなわち、プリンタの、そして、サポートされない仕事を表します。 xxx属性タグとxxx属性系列はモデルドキュメントの属性グループを代表します。 xxx属性タグは属性グループを特定します、そして、xxx-属性系列は属性を含んでいます。
The expected sequence of xxx-attributes-tag and xxx-attribute- sequence is specified in the IPP model document for each operation request and operation response.
xxx属性タグとxxx-属性系列の予想された系列はそれぞれの操作要求と操作応答のためのIPPモデルドキュメントで指定されます。
Herriot, et al. Experimental [Page 5] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[5ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
A request or response SHOULD contain each xxx-attributes-tag defined for that request or response even if there are no attributes except for the unsupported-attributes-tag which SHOULD be present only if the unsupported-attribute-sequence is non-empty. A receiver of a request MUST be able to process as equivalent empty attribute groups:
A要求か応答SHOULDがその要求のために定義されたそれぞれのxxx属性タグを含んでいるか、またはいいえがあっても、プレゼントが唯一であったなら、サポートされない属性系列が非空であるなら、サポートされない属性タグを除いて、応答はどのSHOULDを結果と考えるか。 要求の受信機は同等な空の属性グループとして処理できなければなりません:
a) an xxx-attributes-tag with an empty xxx-attribute-sequence,
b) an expected but missing xxx-attributes-tag.
a) 空のxxx属性系列があるxxx属性タグ、b) 予想されましたが、なくなったxxx属性タグ。
The data is omitted from some operations, but the end-of-attributes- tag is present even when the data is omitted. Note, the xxx- attributes-tags and end-of-attributes-tag are called 'delimiter- tags'. Note: the xxx-attribute-sequence, shown above may consist of 0 bytes, according to the rule below.
データがしかし、いくつかの操作、終わりから省略される、-、-データが省略さえされるとき、属性タグは現在です。 注意、xxx属性タグ、および属性タグの端は'デリミタタグ'と呼ばれます。 以下に注意してください。 以下の規則に従ってバイトが上で0から成るかもしれないのが示されたxxx属性系列。
An xxx-attributes-sequence consists of zero or more compound- attributes.
xxx属性系列がゼロから成るか、または以上は属性を合成します。
----------------------------------------------- | compound-attribute | s bytes - 0 or more -----------------------------------------------
----------------------------------------------- | 合成属性| sバイト--0以上-----------------------------------------------
A compound-attribute consists of an attribute with a single value followed by zero or more additional values.
合成属性は単一のゼロがあとに続いた値か以上追加している値で属性から成ります。
Note: a 'compound-attribute' represents a single attribute in the model document. The 'additional value' syntax is for attributes with 2 or more values.
以下に注意してください。 '合成属性'はモデルドキュメントのただ一つの属性を表します。 '加算値'構文は2つ以上の値がある属性のためのものです。
Each attribute consists of:
各属性は以下から成ります。
----------------------------------------------- | value-tag | 1 byte ----------------------------------------------- | name-length (value is u) | 2 bytes ----------------------------------------------- | name | u bytes ----------------------------------------------- | value-length (value is v) | 2 bytes ----------------------------------------------- | value | v bytes -----------------------------------------------
----------------------------------------------- | 値タグ| 1バイト----------------------------------------------- | 名前長さ(値はuです)| 2バイト----------------------------------------------- | 名前| uバイト----------------------------------------------- | 値長さ(値はvです)| 2バイト----------------------------------------------- | 値| バイトに対して-----------------------------------------------
Herriot, et al. Experimental [Page 6] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[6ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
An additional value consists of:
加算値は以下から成ります。
----------------------------------------------------------- | value-tag | 1 byte | ----------------------------------------------- | | name-length (value is 0x0000) | 2 bytes | ----------------------------------------------- |-0 or more | value-length (value is w) | 2 bytes | ----------------------------------------------- | | value | w bytes | -----------------------------------------------------------
----------------------------------------------------------- | 値タグ| 1バイト| ----------------------------------------------- | | 名前長さ(値は0×0000です)| 2バイト| ----------------------------------------------- |-0以上| 値長さ(値はwです)| 2バイト| ----------------------------------------------- | | 値| wバイト| -----------------------------------------------------------
Note: an additional value is like an attribute whose name-length is 0.
以下に注意してください。 加算値は名前長さが0である属性に似ています。
From the standpoint of a parsing loop, the encoding consists of:
構文解析輪の見地から、コード化は以下から成ります。
----------------------------------------------- | version-number | 2 bytes - required ----------------------------------------------- | operation-id (request) | | or | 2 bytes - required | status-code (response) | ----------------------------------------------- | request-id | 4 bytes - required ----------------------------------------------------------- | tag (delimiter-tag or value-tag) | 1 byte | ----------------------------------------------- |-0 or more | empty or rest of attribute | x bytes | ----------------------------------------------------------- | end-of-attributes-tag | 2 bytes - required ----------------------------------------------- | data | y bytes - optional -----------------------------------------------
----------------------------------------------- | バージョン番号| 2バイト--必要です。----------------------------------------------- | 操作イド(要求)| | または| 2バイト--必要です。| ステータスコード(応答)| ----------------------------------------------- | 要求イド| 4バイト--必要です。----------------------------------------------------------- | (デリミタタグか値タグ)にタグ付けをしてください。| 1バイト| ----------------------------------------------- |-0以上| 属性を空にするか、または休息させてください。| xバイト| ----------------------------------------------------------- | 属性タグの端| 2バイト--必要です。----------------------------------------------- | データ| yバイト--、任意-----------------------------------------------
The value of the tag determines whether the bytes following the tag are:
タグの値は、タグに続くバイトが以下の通りかどうか決定します。
- attributes
- data
- the remainder of a single attribute where the tag specifies the
type of the value.
- 属性--データ--タグが価値のタイプを指定するただ一つの属性の残り。
3.2 Syntax of Encoding
コード化の3.2構文
The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be case sensitive. For example 'a' means lower case 'a' and not upper case 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented as '%x' values which show their range of values.
以下の構文は'リテラルのストリング'を除いたABNF[RFC2234]が大文字と小文字を区別しているに違いないということです。 例えば、'a'は大文字'A'ではなく、下側のケース'a'を意味します。 'さらに、SIGNED-BYTEとSIGNED-SHORT分野はそれらの値の範囲を示している'%x'値として表されます。
Herriot, et al. Experimental [Page 7] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[7ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
ipp-message = ipp-request / ipp-response
ipp-request = version-number operation-id request-id
*(xxx-attributes-tag xxx-attribute-sequence)
end-of-attributes-tag data
ipp-response = version-number status-code request-id
*(xxx-attributes-tag xxx-attribute-sequence)
end-of-attributes-tag data
xxx-attribute-sequence = *compound-attribute
ipp-応答ipp-要求=バージョンipp-メッセージ=ipp-要求/番号操作イド要求イド*(xxx属性タグxxx属性系列)属性タグの端データipp-応答=バージョン番号ステータスコード要求イド*(xxx属性タグxxx属性系列)属性タグの端データxxx属性系列=*合成属性
xxx-attributes-tag = operation-attributes-tag / job-attributes-tag /
printer-attributes-tag / unsupported-attributes-tag
サポートされない属性プリンタ属性仕事の属性xxx属性タグ=操作属性タグ/タグ/タグ/タグ
version-number = major-version-number minor-version-number major-version-number = SIGNED-BYTE ; initially %d1 minor-version-number = SIGNED-BYTE ; initially %d0
メジャーバージョン番号マイナーバージョン番号バージョン番号=メジャーバージョン番号はSIGNED-BYTEと等しいです。 初めは、%d1マイナーバージョン番号=SIGNED-BYTE。 初めは、%d0
operation-id = SIGNED-SHORT ; mapping from model defined below status-code = SIGNED-SHORT ; mapping from model defined below request-id = SIGNED-INTEGER ; whose value is > 0
操作イドはSIGNED-SHORTと等しいです。 ステータスコードの下で定義されたモデルからのマッピングはSIGNED-SHORTと等しいです。 モデルからのマッピングは要求イド=の下でSIGNED-INTEGERを定義しました。 >0はだれの値ですか?
compound-attribute = attribute *additional-values attribute = value-tag name-length name value-length value additional-values = value-tag zero-name-length value-length value
合成属性=属性*加算値属性=値タグ名前長さ名前値長さ値加算値=値タグ無名の長さ値長さ価値
name-length = SIGNED-SHORT ; number of octets of 'name' name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) value-length = SIGNED-SHORT ; number of octets of 'value' value = OCTET-STRING
名前長さはSIGNED-SHORTと等しいです。 「'名の八重奏の数'がLALPHA*と=を命名する、(LALPHA / DIGIT /「-」/"_"/、」、」、)、値長さの=は-急に署名しました。 '値'価値の八重奏の数はOCTET-STRINGと等しいです。
data = OCTET-STRING
データはOCTET-STRINGと等しいです。
zero-name-length = %x00.00 ; name-length of 0 operation-attributes-tag = %x01 ; tag of 1 job-attributes-tag = %x02 ; tag of 2 printer-attributes-tag = %x04 ; tag of 4 unsupported-attributes-tag = %x05 ; tag of 5 end-of-attributes-tag = %x03 ; tag of 3 value-tag = %x10-FF
無名の長さ=%x00.00。 0操作属性タグの名前長さ=%x01。 1個の仕事の属性タグのタグ=%x02。 2プリンタ属性タグのタグ=%x04。 4のサポートされない属性タグのタグ=%x05。 属性タグの5端のタグ=%x03。 3値タグ=%x10-FFのタグ
SIGNED-BYTE = BYTE SIGNED-SHORT = 2BYTE SIGNED-INTEGER = 4BYTE DIGIT = %x30-39 ; "0" to "9" LALPHA = %x61-7A ; "a" to "z" BYTE = %x00-FF OCTET-STRING = *BYTE
署名しているバイト=バイトは、2バイトの=の署名している整数の=の4バイトのケタ=%がx30-39であると-急に署名しました。 「「9インチのLALPHAは%x61-7Aと等しいこと」への0インチ x00-ffが八重奏で結ぶ「z」バイトへの"a"=%は*バイトと等しいです。
Herriot, et al. Experimental [Page 8] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[8ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
The syntax allows an xxx-attributes-tag to be present when the xxx- attribute-sequence that follows is empty. The syntax is defined this way to allow for the response of Get-Jobs where no attributes are returned for some job-objects. Although it is RECOMMENDED that the sender not send an xxx-attributes-tag if there are no attributes (except in the Get-Jobs response just mentioned), the receiver MUST be able to decode such syntax.
従うxxx属性順序が空であるときに、構文は、xxx属性タグが現在であるのを許容します。 構文は、属性が全くいくつかの仕事オブジェクトのために返されないところでGet-ジョブスの応答を考慮するためにこの道と定義されます。 属性(ただ言及されたGet-ジョブス応答を除いた)が全くなければ送付者がxxx属性タグを送らないのが、RECOMMENDEDですが、受信機はそのような構文を解読できなければなりません。
3.3 Version-number
3.3 バージョン番号
The version-number MUST consist of a major and minor version-number, each of which MUST be represented by a SIGNED-BYTE. The protocol described in this document MUST have a major version-number of 1 (0x01) and a minor version-number of 0 (0x00). The ABNF for these two bytes MUST be %x01.00.
バージョン番号は主要で小さい方のバージョン番号から成らなければなりません。SIGNED-BYTEはそれぞれそれを表さなければなりません。 本書では説明されたプロトコルは主要なバージョン番号の1(0×01)と小さい方のバージョン番号の0(0×00)を持たなければなりません。 これらの2バイトABNFは%x01.00であるに違いありません。
3.4 Operation-id
3.4 操作イド
Operation-ids are defined as enums in the model document. An operation-ids enum value MUST be encoded as a SIGNED-SHORT.
操作イドはモデルドキュメントでenumsと定義されます。 SIGNED-SHORTとして操作イドenum価値をコード化しなければなりません。
Note: the values 0x4000 to 0xFFFF are reserved for private extensions.
以下に注意してください。 0xFFFFへの値0x4000は個人的な拡大のために予約されます。
3.5 Status-code
3.5 ステータスコード
Status-codes are defined as enums in the model document. A status- code enum value MUST be encoded as a SIGNED-SHORT.
ステータスコードはモデルドキュメントでenumsと定義されます。 SIGNED-SHORTとして状態コードenum価値をコード化しなければなりません。
The status-code is an operation attribute in the model document. In the protocol, the status-code is in a special position, outside of the operation attributes.
ステータスコードはモデルドキュメントの操作属性です。 プロトコルには、ステータスコードが操作属性の外に特別な位置にあります。
If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 (successful-ok). With any other HTTP Status-Code value, the HTTP response MUST NOT contain an IPP message-body, and thus no IPP status-code is returned.
IPPステータスコードを返すなら、HTTP Status-コードは200でなければなりません(うまくいって間違いない)。 いかなる他のHTTP Status-コード値でも、HTTP応答はIPPメッセージボディーを含んではいけません、そして、その結果、IPPステータスコードを全く返しません。
3.6 Request-id
3.6 要求イド
The request-id allows a client to match a response with a request. This mechanism is unnecessary in HTTP, but may be useful when application/ipp entity bodies are used in another context.
要求イドで、クライアントは要求に応答に合うことができます。 このメカニズムは、HTTPで不要ですが、アプリケーション/ipp実体ボディーが別の文脈で使用されるとき、役に立つかもしれません。
The request-id in a response MUST be the value of the request-id received in the corresponding request. A client can set the request-id in each request to a unique value or a constant value, such as 1, depending on what the client does with the request-id
応答における要求イドは対応する要求に受け取られた要求イドの値であるに違いありません。 クライアントはユニークな値か恒常価値への各要求に要求イドをはめ込むことができます、クライアントが要求イドですることによる1などのように
Herriot, et al. Experimental [Page 9] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[9ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
returned in the response. The value of the request-id MUST be greater than zero.
応答では、戻りました。 要求イドの値はゼロ以上でなければなりません。
3.7 Tags
3.7 タグ
There are two kinds of tags:
2種類のタグがあります:
- delimiter tags: delimit major sections of the protocol, namely
attributes and data
- value tags: specify the type of each attribute value
- デリミタタグ: 属性とデータ--プロトコルの主要なセクションを区切ってください、そして、すなわち、タグを評価してください: それぞれの属性値のタイプを指定してください。
3.7.1 Delimiter Tags
3.7.1 デリミタタグ
The following table specifies the values for the delimiter tags:
以下のテーブルはデリミタタグに値を指定します:
Tag Value (Hex) Delimiter
タグ値の(十六進法)デリミタ
0x00 reserved
0x01 operation-attributes-tag
0x02 job-attributes-tag
0x03 end-of-attributes-tag
0x04 printer-attributes-tag
0x05 unsupported-attributes-tag
0x06-0x0e reserved for future delimiters
0x0F reserved for future chunking-end-of-attributes-
tag
0×00 0×03 0×06 0×05のサポートされない属性タグ0x0eが将来のデリミタのために予約した属性タグの端の0×04プリンタ属性タグ0x0Fが未来に予約した操作属性タグ0×02仕事の属性タグの予約された0×01分魂化終わり、-、属性タグ
When an xxx-attributes-tag occurs in the protocol, it MUST mean that zero or more following attributes up to the next delimiter tag are attributes belonging to group xxx as defined in the model document, where xxx is operation, job, printer, unsupported.
xxx属性タグがプロトコルで現れると、次のデリミタタグまでのゼロか、より次の属性がxxxが操作であるモデルドキュメントで定義されるようにグループxxxに属す属性であることを意味しなければなりません、仕事、プリンタ、サポートされないです。
Doing substitution for xxx in the above paragraph, this means the following. When an operation-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are operation attributes as defined in the model document. When an job-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are job attributes or job template attributes as defined in the model document. When a printer-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are printer attributes as defined in the model document. When an unsupported-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are unsupported attributes as defined in the model document.
前の段落でxxxに代替して、これは以下を意味します。 操作属性タグがプロトコルで現れると、それは、次のデリミタタグまでのゼロか、より次の属性がモデルドキュメントで定義されるように操作属性であることを意味しなければなりません。 仕事の属性タグがプロトコルで現れると、それは、次のデリミタタグまでのゼロか、より次の属性がモデルドキュメントで定義されるように仕事の属性か仕事のテンプレート属性であることを意味しなければなりません。 プリンタ属性タグがプロトコルで現れると、それは、次のデリミタタグまでのゼロか、より次の属性がモデルドキュメントで定義されるようにプリンタ属性であることを意味しなければなりません。 サポートされない属性タグがプロトコルで現れると、それは、次のデリミタタグまでのゼロか、より次の属性がモデルドキュメントで定義されるようにサポートされない属性であることを意味しなければなりません。
Herriot, et al. Experimental [Page 10] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[10ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
The operation-attributes-tag and end-of-attributes-tag MUST each occur exactly once in an operation. The operation-attributes-tag MUST be the first tag delimiter, and the end-of-attributes-tag MUST be the last tag delimiter. If the operation has a document-content group, the document data in that group MUST follow the end-of-attributes- tag.
操作属性タグと属性タグの端はまさにそれぞれ稼働中であり一度現れなければなりません。 操作属性タグは最初のタグデリミタであるに違いありません、そして、属性タグの端は最後のタグデリミタであるに違いありません。 操作にドキュメント内容グループがあるなら、そのグループにおけるドキュメントデータが終わりに続かなければならない、-、属性タグについて。
Each of the other three xxx-attributes-tags defined above is OPTIONAL in an operation and each MUST occur at most once in an operation, except for job-attributes-tag in a Get-Jobs response which may occur zero or more times.
上で定義されたそれぞれの他の3個のxxx属性タグが、稼働中であるOPTIONALであり、それぞれ高々かつて起こるかもしれないGet-ジョブス応答における仕事の属性タグゼロ以外の操作か、より多くの回現れなければなりません。
The order and presence of delimiter tags for each operation request and each operation response MUST be that defined in the model document. For further details, see section 3.9 "(Attribute) Name" and section 9 "Appendix A: Protocol Examples".
それぞれの操作要求とそれぞれの操作応答のためのデリミタタグの注文と存在はモデルドキュメントでそんなに定義していなければなりません。 さらに詳しい明細については、「(属性)名」というセクション3.9と「付録A:」というセクション9を見てください。 「例について議定書の中で述べてください。」
A Printer MUST treat the reserved delimiter tags differently from reserved value tags so that the Printer knows that there is an entire attribute group that it doesn't understand as opposed to a single value that it doesn't understand.
Printerは、Printerが、それがそれが理解していないただ一つの値と対照的に理解していない全体の属性グループがあるのを知るように、予約されたデリミタタグを予約された値のタグと異なって扱わなければなりません。
3.7.2 Value Tags
3.7.2 値のタグ
The remaining tables show values for the value-tag, which is the first octet of an attribute. The value-tag specifies the type of the value of the attribute. The following table specifies the "out-of- band" values for the value-tag.
残っているテーブルは値タグのために値を示しています(属性の最初の八重奏です)。 値タグは属性の価値のタイプを指定します。 以下のテーブルが指定する、「外、-、-値タグのために」 値を括ってください。
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x10 unsupported
0x11 reserved for future 'default'
0x12 unknown
0x13 no-value
0×10 サポートされない0×11は将来の'デフォルト'0x12のためにどんな未知の0×13値も予約しませんでした。
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x14-0x1F reserved for future "out-of-band" values.
未来への「バンドの外で」予約された0×14 0x1F値。
The "unsupported" value MUST be used in the attribute-sequence of an error response for those attributes which the printer does not support. The "default" value is reserved for future use of setting value back to their default value. The "unknown" value is used for the value of a supported attribute when its value is temporarily unknown. The "no-value" value is used for a supported attribute to which
プリンタがサポートしないそれらの属性に誤り応答の属性系列に「サポートされない」値を使用しなければなりません。 「デフォルト」値はそれらのデフォルト値に値を遅らせることの今後の使用のために予約されます。 値が一時未知であるときに、「未知」の値はサポートしている属性の値に使用されます。 値が使用される「値がありません」aが属性をサポートした、どれ
Herriot, et al. Experimental [Page 11] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[11ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
no value has been assigned, e.g. "job-k-octets-supported" has no value if an implementation supports this attribute, but an administrator has not configured the printer to have a limit.
値は全く割り当てられていませんが、例えば、「八重奏がサポートした仕事k」には、実装がこの属性をサポートするなら、値が全くありませんが、管理者は、限界を持つためにプリンタを構成していません。
The following table specifies the integer values for the value-tag:
以下のテーブルは値タグに整数値を指定します:
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x20 reserved
0x21 integer
0x22 boolean
0x23 enum
0x24-0x2F reserved for future integer types
0×20 0×24 0x2Fが将来の整数型のために予約した予約された0×21整数0×22論理演算子0x23enum
NOTE: 0x20 is reserved for "generic integer" if it should ever be needed.
以下に注意してください。 0×20はそれであるなら「ジェネリック整数」のために予約されて、今までに必要とされるべきであるということです。
The following table specifies the octetString values for the value- tag:
以下のテーブルは値のタグにoctetString値を指定します:
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x30 octetString with an unspecified format
0x31 dateTime
0x32 resolution
0x33 rangeOfInteger
0x34 reserved for collection (in the future)
0x35 textWithLanguage
0x36 nameWithLanguage
0x37-0x3F reserved for future octetString types
0×30 不特定の形式0×31dateTime0x32解決で0×33rangeOfInteger0x34をoctetStringすると、収集(将来)0×35textWithLanguage0x36nameWithLanguageのために、将来のoctetStringタイプのために予約された0×37 0x3Fが予約されました。
The following table specifies the character-string values for the value-tag:
以下のテーブルは値タグに文字列値を指定します:
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x40 reserved
0x41 textWithoutLanguage
0x42 nameWithoutLanguage
0x43 reserved
0x44 keyword
0x45 uri
0x46 uriScheme
0x47 charset
0x48 naturalLanguage
0×40 予約された0×41textWithoutLanguage0x42nameWithoutLanguage0x43は0×44キーワード0x45uri0×46uriScheme0x47charset0×48naturalLanguageを予約しました。
Herriot, et al. Experimental [Page 12] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[12ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x49 mimeMediaType
0x4A-0x5F reserved for future character string types
0×49 将来の文字列タイプのために予約されたmimeMediaType 0x4A-0x5F
NOTE: 0x40 is reserved for "generic character-string" if it should ever be needed.
以下に注意してください。 0×40はそれであるなら「ジェネリック文字列」のために予約されて、今までに必要とされるべきであるということです。
NOTE: an attribute value always has a type, which is explicitly specified by its tag; one such tag value is "nameWithoutLanguage". An attribute's name has an implicit type, which is keyword.
以下に注意してください。 属性値には、タイプがいつもあります。(タイプはタグによって明らかに指定されます)。 そのような値のタグ1つは"nameWithoutLanguage"です。 属性の名前には、内在しているタイプがあります(キーワードです)。
The values 0x60-0xFF are reserved for future types. There are no values allocated for private extensions. A new type MUST be registered via the type 2 registration process [RFC2566].
0×60値の0xFFが将来のタイプのために予約されます。 個人的な拡大のために割り当てられた値が全くありません。 タイプ2登録手続[RFC2566]で新しいタイプを示さなければなりません。
The tag 0x7F is reserved for extending types beyond the 255 values available with a single byte. A tag value of 0x7F MUST signify that the first 4 bytes of the value field are interpreted as the tag value. Note, this future extension doesn't affect parsers that are unaware of this special tag. The tag is like any other unknown tag, and the value length specifies the length of a value which contains a value that the parser treats atomically. All these 4 byte tag values are currently unallocated except that the values 0x40000000- 0x7FFFFFFF are reserved for experimental use.
タグ0x7Fは、タイプを1バイトで利用可能な255の値を超えたところまで広げるために予約されます。 0x7Fのタグ値は、値の分野の最初の4バイトがタグ値として解釈されるのを意味しなければなりません。 この未来に拡大がこの特別なタグに気づかない状態でパーサに影響しないことに注意してください。 タグはいかなる他の未知のタグにも似ています、そして、値の長さはパーサが原子論的に扱う値を含む価値の長さを指定します。 値0x40000000の0x7FFFFFFFが実験用のために予約されるのを除いて、これらのすべての4バイトのタグ値が現在、「非-割り当て」られます。
3.8 Name-Length
3.8 名前長さ
The name-length field MUST consist of a SIGNED-SHORT. This field MUST specify the number of octets in the name field which follows the name-length field, excluding the two bytes of the name-length field.
名前長さの分野はSIGNED-SHORTから成らなければなりません。 この分野は名前長さの野原に続く名前欄の八重奏の数を指定しなければなりません、名前長さの分野の2バイトを除いて。
If a name-length field has a value of zero, the following name field MUST be empty, and the following value MUST be treated as an additional value for the preceding attribute. Within an attribute- sequence, if two attributes have the same name, the first occurrence MUST be ignored. The zero-length name is the only mechanism for multi-valued attributes.
名前長さの分野にゼロの値があるなら、以下の名前欄は人影がないに違いありません、そして、前の属性のために以下の値を加算値として扱わなければなりません。 属性系列の中では、同じ名前が2つの属性にあるなら、最初の発生を無視しなければなりません。 ゼロ・レングス名はマルチ評価された属性のための唯一のメカニズムです。
3.9 (Attribute) Name
3.9 (属性)名
Some operation elements are called parameters in the model document [RFC2566]. They MUST be encoded in a special position and they MUST NOT appear as an operation attributes. These parameters are:
いくつかの操作要素がモデルドキュメント[RFC2566]のパラメタと呼ばれます。 特別な位置でそれらをコード化しなければなりません、そして、彼らは操作属性として現れてはいけません。 これらのパラメタは以下の通りです。
- "version-number": The parameter named "version-number" in the
IPP model document MUST become the "version-number" field in the
operation layer request or response.
- 「バージョン番号」: IPPモデルドキュメントの「バージョン番号」というパラメタは操作層の要求か応答における「バージョン番号」分野にならなければなりません。
Herriot, et al. Experimental [Page 13] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[13ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
- "operation-id": The parameter named "operation-id" in the IPP
model document MUST become the "operation-id" field in the
operation layer request.
- "status-code": The parameter named "status-code" in the IPP
model document MUST become the "status-code" field in the
operation layer response.
- "request-id": The parameter named "request-id" in the IPP model
document MUST become the "request-id" field in the operation
layer request or response.
- 「操作イド」: IPPモデルドキュメントの「操作イド」というパラメタは操作層の要求における「操作イド」分野にならなければなりません。 - 「ステータスコード」: IPPモデルドキュメントの「ステータスコード」というパラメタは操作層の応答における「ステータスコード」分野にならなければなりません。 - 「要求イド」: IPPモデルドキュメントの「要求イド」というパラメタは操作層の要求か応答における「要求イド」分野にならなければなりません。
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. The notion of a URI is a useful concept, however, until the notion of URI is more stable (i.e., defined more completely and deployed more widely), it is expected that the URIs used for IPP objects will actually be URLs [RFC1738] [RFC1808]. Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.
Uniform Resource Identifier(URI)[RFC2396]によってすべてのPrinterとJobオブジェクトは、持続して明白にそれらに参照をつけることができるように特定されます。 URIの概念が役に立つ概念である、しかしながら、URIの概念が、より安定するまで(すなわち、より完全に定義されて、より広く配布されます)、IPPオブジェクトに使用されるURIが実際にURL[RFC1738][RFC1808]であると予想されます。 より多くの総称URIがこのドキュメントの残りの間中使用されますが、あらゆるURLがURIの専門化しているフォームであるので、用法がまた、URLの、より特定の概念をカバーすることを意図します。
Some operation elements are encoded twice, once as the request-URI on the HTTP Request-Line and a second time as a REQUIRED operation attribute in the application/ipp entity. These attributes are the target URI for the operation:
いくつかの操作要素が二度コード化されます、HTTP Request-線ともう一度のアプリケーション/ipp実体におけるREQUIRED操作属性としての要求URIとしての一度。 これらの属性は操作のための目標URIです:
- "printer-uri": When the target is a printer and the transport is
HTTP or HTTPS (for SSL3 [ssl]), the target printer-uri defined
in each operation in the IPP model document MUST be an operation
attribute called "printer-uri" and it MUST also be specified
outside of the operation layer as the request-URI on the
Request-Line at the HTTP level.
- "job-uri": When the target is a job and the transport is HTTP or
HTTPS (for SSL3), the target job-uri of each operation in the
IPP model document MUST be an operation attribute called "job-
uri" and it MUST also be specified outside of the operation
layer as the request-URI on the Request-Line at the HTTP level.
- 「プリンタ-uri」: 輸送が目標がプリンタであり、HTTPかHTTPS(SSL3[ssl]のための)であるときに、IPPモデルドキュメントにおける各操作で定義された目標プリンタ-uriは「プリンタ-uri」と呼ばれる操作属性であるに違いありません、そして、また、要求URIとしてHTTPレベルにおけるRequest-線の上で操作層の外でそれを指定しなければなりません。 - 「仕事-uri」: 輸送が目標が仕事であり、HTTPかHTTPS(SSL3のための)であるときに、IPPモデルドキュメントにおけるそれぞれの操作の目標仕事-uriは「仕事のuri」と呼ばれる操作属性であるに違いありません、そして、また、要求URIとしてHTTPレベルにおけるRequest-線の上で操作層の外でそれを指定しなければなりません。
Note: The target URI is included twice in an operation referencing the same IPP object, but the two URIs NEED NOT be literally identical. One can be a relative URI and the other can be an absolute URI. HTTP/1.1 allows clients to generate and send a relative URI rather than an absolute URI. A relative URI identifies a resource with the scope of the HTTP server, but does not include scheme, host or port. The following statements characterize how URLs should be used in the mapping of IPP onto HTTP/1.1:
以下に注意してください。 目標URIは同じIPPオブジェクトに参照をつける操作に二度含まれていますが、2つのURIが文字通り同じである必要はありません。 1つは相対的なURIであるかもしれません、そして、もう片方が絶対URIであるかもしれません。 HTTP/1.1は、クライアントに絶対URIよりむしろ相対的なURIを生成して、送らせます。 相対的なURIは、HTTPサーバの範囲とリソースを同一視しますが、体系、ホストまたはポートを含んでいません。 以下の声明はURLがIPPに関するマッピングでどうHTTP/1.1に使用されるべきであるかを特徴付けます:
Herriot, et al. Experimental [Page 14] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[14ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
1. Although potentially redundant, a client MUST supply the target
of the operation both as an operation attribute and as a URI at
the HTTP layer. The rationale for this decision is to maintain
a consistent set of rules for mapping application/ipp to
possibly many communication layers, even where URLs are not
used as the addressing mechanism in the transport layer.
2. Even though these two URLs might not be literally identical
(one being relative and the other being absolute), they MUST
both reference the same IPP object.
3. The URI in the HTTP layer is either relative or absolute and is
used by the HTTP server to route the HTTP request to the
correct resource relative to that HTTP server. The HTTP server
need not be aware of the URI within the operation request.
4. Once the HTTP server resource begins to process the HTTP
request, it might get the reference to the appropriate IPP
Printer object from either the HTTP URI (using to the context
of the HTTP server for relative URLs) or from the URI within
the operation request; the choice is up to the implementation.
5. HTTP URIs can be relative or absolute, but the target URI in
the operation MUST be an absolute URI.
1. 潜在的に余分ですが、クライアントは操作属性としてURIとしてHTTP層で操作の目標を供給しなければなりません。 この決定のための原理はことによると多くのコミュニケーション層にアプリケーション/ippを写像するための一貫したセットの規則を維持することです、URLがアドレシングメカニズムとしてトランスポート層の中で使用さえされないところで。 2. これらの2つのURLは文字通り同じでないかもしれませんが(ある存在親類と絶対であるもう片方)、それらはともに同じIPPオブジェクトに参照をつけなければなりません。 3. HTTP層のURIは、相対的であるか、または絶対であり、HTTPサーバによって使用されます。そのHTTPサーバに比例してHTTP要求を正しいリソースに発送して、HTTPサーバは操作要求の中でURIを意識している必要はありません。 4. HTTPサーバリソースがいったんHTTP要求を処理し始めると、HTTP URI(相対的なURLのためのHTTPサーバの文脈に使用する)か操作要求の中のURIから適切なIPP Printerオブジェクトの参照を得るかもしれません。 選択は実装まで達しています。 5. HTTP URIは、相対的であるか、または絶対である場合がありますが、操作における目標URIは絶対URIであるに違いありません。
The model document arranges the remaining attributes into groups for each operation request and response. Each such group MUST be represented in the protocol by an xxx-attribute-sequence preceded by the appropriate xxx-attributes-tag (See the table below and section 9 "Appendix A: Protocol Examples"). In addition, the order of these xxx-attributes-tags and xxx-attribute-sequences in the protocol MUST be the same as in the model document, but the order of attributes within each xxx-attribute-sequence MUST be unspecified. The table below maps the model document group name to xxx-attributes-sequence:
モデルドキュメントは各操作のためのグループへの属性が要求する残りと応答をアレンジします。 プロトコルで適切なxxx属性タグが先行したxxx属性系列でそのような各グループを代表しなければなりません(「付録A:プロトコルの例」という下のテーブルとセクション9を見てください)。 さらに、プロトコルにおける、これらのxxx属性タグとxxx属性系列の注文はモデルドキュメントと同じでなければなりませんが、それぞれのxxx属性系列の中の属性の注文は不特定であるに違いありません。 以下のテーブルはモデルドキュメントグループ名をxxx属性系列に写像します:
Model Document Group xxx-attributes-sequence
モデルDocument Group xxx属性系列
Operation Attributes operations-attributes-sequence
Job Template Attributes job-attributes-sequence
Job Object Attributes job-attributes-sequence
Unsupported Attributes unsupported-attributes-sequence
Requested Attributes job-attributes-sequence
Get-Job-Attributes)
Requested Attributes printer-attributes-sequence
Get-Printer-Attributes)
Document Content in a special position as described
above
操作Attributes属性が配列する操作Job Template Attributes仕事の属性系列Job Object Attributes仕事の属性系列Unsupported Attributesサポートされない属性系列Requested Attributes仕事の属性系列Get仕事の属性) 要求されたAttributesプリンタ属性系列Getプリンタ属性) 上で説明される特別な位置のドキュメントContent
If an operation contains attributes from more than one job object (e.g. Get-Jobs response), the attributes from each job object MUST be in a separate job-attribute-sequence, such that the attributes
操作が1個以上の仕事のオブジェクト(例えば、Get-ジョブス応答)からの属性を含んでいるなら、別々の仕事の属性系列にはそれぞれの仕事のオブジェクトからの属性があるに違いなくて、そのようなものがそれである、属性
Herriot, et al. Experimental [Page 15] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[15ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
from the ith job object are in the ith job-attribute-sequence. See Section 9 "Appendix A: Protocol Examples" for table showing the application of the rules above.
ith仕事のオブジェクトから、仕事の属性系列はithで来ています。 「付録A:」というセクション9を見てください。 上の規則の適用を示しているテーブルのための「プロトコルExamples。」
3.10 Value Length
3.10 値の長さ
Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST specify the number of octets in the value which follows this length, exclusive of the two bytes specifying the length.
SIGNED-SHORTは各属性値に先行しなければなりません、長さを指定する2バイトを除いて。(SIGNED-SHORTはこの長さに続く値における、八重奏の数を指定しなければなりません)。
For any of the types represented by binary signed integers, the sender MUST encode the value in exactly four octets.
整数であるのに調印されたバイナリーによって代理をされたタイプのいずれのためにも、送付者はまさに4つの八重奏における値をコード化しなければなりません。
For any of the types represented by character-strings, the sender MUST encode the value with all the characters of the string and without any padding characters.
文字列によって代理をされたタイプのいずれのためにも、送付者はストリングのすべてのキャラクタと少しも暫定記号なしで値をコード化しなければなりません。
If a value-tag contains an "out-of-band" value, such as "unsupported", the value-length MUST be 0 and the value empty. The value has no meaning when the value-tag has an "out-of-band" value. If a client receives a response with a nonzero value-length in this case, it MUST ignore the value field. If a printer receives a request with a nonzero value-length in this case, it MUST reject the request.
値タグが「サポートされない」ように「バンドの外」という値を含んでいるなら、0と値が空であったなら、値長さは含まなければなりません。 いいえが、いつ、値タグには「バンドの外」という値があるかを意味して、値はそうしました。 クライアントがこの場合非零値長さで応答を受けるなら、それは値の分野を無視しなければなりません。 プリンタがこの場合非零値長さで要求を受け取るなら、それは要求を拒絶しなければなりません。
3.11 (Attribute) Value
3.11 (属性)値
The syntax types and most of the details of their representation are defined in the IPP model document. The table below augments the information in the model document, and defines the syntax types from the model document in terms of the 5 basic types defined in section 3 "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING.
構文タイプと彼らの表現の詳細の大部分はIPPモデルドキュメントで定義されます。 以下のテーブルは、モデルドキュメントから「操作層のコード化」というセクション3で定義された5人の基本型で、モデルドキュメントの情報を増大させて、構文タイプを定義します。 5つのタイプが、米国ASCII STRINGと、LOCALIZED-STRINGと、SIGNED-INTEGERと、SIGNED-SHORTと、SIGNED-BYTEと、OCTET-STRINGです。
Syntax of Attribute Encoding Value
値をコード化する属性の構文
textWithoutLanguage, LOCALIZED-STRING. nameWithoutLanguage
ローカライズしているストリングtextWithoutLanguage、nameWithoutLanguage
textWithLanguage OCTET_STRING consisting of 4 fields:
a) a SIGNED-SHORT which is the number of octets
in the following field
b) a value of type natural-language,
c) a SIGNED-SHORT which is the number of octets
in the following field,
d) a value of type textWithoutLanguage.
4つの分野のtextWithLanguage OCTET_STRINGの成ること: 以下の分野b) aの八重奏の数であるa)a SIGNED-SHORTはタイプに自然言語を評価します、以下の分野の八重奏の数であるc)a SIGNED-SHORT、タイプtextWithoutLanguageのd)a価値。
Herriot, et al. Experimental [Page 16] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[16ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
The length of a textWithLanguage value MUST be 4
+ the value of field a + the value of field c.
textWithLanguage価値の長さは+ 4が分野a+の値であったならそうしなければなりません。分野cの値。
nameWithLanguage OCTET_STRING consisting of 4 fields:
a) a SIGNED-SHORT which is the number of octets
in the following field
b) a value of type natural-language,
c) a SIGNED-SHORT which is the number of octets
in the following field
d) a value of type nameWithoutLanguage.
4つの分野のnameWithLanguage OCTET_STRINGの成ること: 以下の分野b) aの八重奏の数であるa)a SIGNED-SHORTは自然言語(タイプnameWithoutLanguageの以下の分野d)a価値において、八重奏の数であるc)a SIGNED-SHORT)をタイプに評価します。
The length of a nameWithLanguage value MUST be 4
+ the value of field a + the value of field c.
nameWithLanguage価値の長さは+ 4が分野a+の値であったならそうしなければなりません。分野cの値。
charset, US-ASCII-STRING. naturalLanguage, mimeMediaType, keyword, uri, and uriScheme
charset、米国ASCII STRING. naturalLanguage、mimeMediaType、キーワード、uri、およびuriScheme
boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is
'true'.
0×00が'誤ってい'て、0×01が'本当である'論理演算子SIGNED-BYTE。
Syntax of Attribute Encoding Value
値をコード化する属性の構文
integer and enum a SIGNED-INTEGER.
整数とenum a SIGNED-INTEGER。
dateTime OCTET-STRING consisting of eleven octets whose
contents are defined by "DateAndTime" in RFC
2579 [RFC2579].
コンテンツがRFC2579[RFC2579]で"DateAndTime"によって定義される11の八重奏から成るdateTime OCTET-STRING。
resolution OCTET_STRING consisting of nine octets of 2
SIGNED-INTEGERs followed by a SIGNED-BYTE. The
first SIGNED-INTEGER contains the value of cross
feed direction resolution. The second SIGNED-
INTEGER contains the value of feed direction
resolution. The SIGNED-BYTE contains the units
value.
2SIGNED-INTEGERsの9つの八重奏の解決OCTET_STRINGの成ることはSIGNED-BYTEで続きました。 最初のSIGNED-INTEGERは交差している給送方向解決の値を含んでいます。 第2SIGNED- INTEGERは給送方向解決の値を含んでいます。 SIGNED-BYTEはユニット値を含んでいます。
rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs.
The first SIGNED-INTEGER contains the lower
bound and the second SIGNED-INTEGER contains the
upper bound.
2SIGNED-INTEGERsから成るrangeOfInteger Eight八重奏。 最初のSIGNED-INTEGERは下界を含んでいます、そして、第2SIGNED-INTEGERは上限を含んでいます。
Herriot, et al. Experimental [Page 17] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[17ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
1setOf X Encoding according to the rules for an attribute
with more than 1 value. Each value X is encoded
according to the rules for encoding its type.
1つ以上の値がある属性のための規則に従った1setOf X Encoding。 タイプをコード化するための規則に従って、各値Xはコード化されます。
octetString OCTET-STRING
octetString八重奏ストリング
The type of the value in the model document determines the encoding in the value and the value of the value-tag.
モデルドキュメントの価値のタイプは値タグの値と値におけるコード化を決定します。
3.12 Data
3.12 データ
The data part MUST include any data required by the operation
データ部分は操作で必要であるデータを含まなければなりません。
4. Encoding of Transport Layer
4. トランスポート層のコード化
HTTP/1.1 [RFC2068] is the transport layer for this protocol.
HTTP/1.1[RFC2068]はこのプロトコルのためのトランスポート層です。
The operation layer has been designed with the assumption that the transport layer contains the following information:
操作層はトランスポート層が以下の情報を含んでいるという仮定で設計されています:
- the URI of the target job or printer operation
- the total length of the data in the operation layer, either as a
single length or as a sequence of chunks each with a length.
- 目標仕事かプリンタ操作のURI--ただ一つの長さとした、または、それぞれ長さがある塊の系列とした操作層のデータの全長。
It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631 (the IPP default port), though a printer implementation may support HTTP over some other port as well. In addition, a printer may have to support another port for privacy (See Section 5 "Security Considerations").
IANAの上のプリンタ実装サポートHTTPがWell Known Port631(IPPデフォルトポート)を割り当てたのは、REQUIREDです、プリンタ実装がまた、ある他のポートの上でHTTPをサポートするかもしれませんが。 さらに、プリンタはプライバシーのために別のポートを支えなければならないかもしれません(「セキュリティ問題」というセクション5を見てください)。
Note: even though port 631 is the IPP default, port 80 remains the default for an HTTP URI. Thus a URI for a printer using port 631 MUST contain an explicit port, e.g. "http://forest:631/pinetree". An HTTP URI for IPP with no explicit port implicitly reference port 80, which is consistent with the rules for HTTP/1.1. Each HTTP operation MUST use the POST method where the request-URI is the object target of the operation, and where the "Content-Type" of the message-body in each request and response MUST be "application/ipp". The message-body MUST contain the operation layer and MUST have the syntax described in section 3.2 "Syntax of Encoding". A client implementation MUST adhere to the rules for a client described for HTTP1.1 [RFC2068]. A printer (server) implementation MUST adhere the rules for an origin server described for HTTP1.1 [RFC2068].
以下に注意してください。 ポート631はIPPデフォルトですが、ポート80はHTTP URIのためのデフォルトのままで残っています。 したがって、ポート631を使用するプリンタのためのURIは明白なポート、例えば、" http://forest:631/pinetree "を含まなければなりません。 明白なポートのないIPPのためのHTTP URIはそれとなくポート80に参照をつけます。(HTTP/1.1において、それは、規則と一致しています)。 それぞれのHTTP操作は要求URIが操作のオブジェクト目標であり、各要求と応答におけるメッセージ本体の「コンテントタイプ」が「アプリケーション/ipp」であるに違いないポストメソッドを使用しなければなりません。 メッセージ本体は、操作層を含まなければならなくて、「コード化の構文」というセクション3.2で説明された構文を持たなければなりません。 クライアント実装はHTTP1.1[RFC2068]のために説明されたクライアントのために規則を固く守らなければなりません。 プリンタ(サーバ)実装はHTTP1.1[RFC2068]のために説明された発生源サーバのための規則を付着させなければなりません。
An IPP server sends a response for each request that it receives. If an IPP server detects an error, it MAY send a response before it has read the entire request. If the HTTP layer of the IPP server completes processing the HTTP headers successfully, it MAY send an
IPPサーバは受信するという各要求のための応答を送ります。 IPPサーバが誤りを検出するなら、全体の要求を読む前にそれは応答を送るかもしれません。 IPPサーバのHTTP層が、首尾よくHTTPヘッダを処理するのを完了するなら、それは発信するかもしれません。
Herriot, et al. Experimental [Page 18] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[18ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
intermediate response, such as "100 Continue", with no IPP data before sending the IPP response. A client MUST expect such a variety of responses from an IPP server. For further information on HTTP/1.1, consult the HTTP documents [RFC2068].
IPP応答を送る前のIPPデータなしで「100は続くことなど」の中間的応答。 クライアントはIPPサーバからそのようなさまざまな応答を予想しなければなりません。HTTP/1.1の詳細に関して、HTTPドキュメント[RFC2068]を参照してください。
5. Security Considerations
5. セキュリティ問題
The IPP Model document defines an IPP implementation with "privacy" as one that implements Secure Socket Layer Version 3 (SSL3). Note: SSL3 is not an IETF standards track specification. SSL3 meets the requirements for IPP security with regards to features such as mutual authentication and privacy (via encryption). The IPP Model document also outlines IPP-specific security considerations and should be the primary reference for security implications with regards to the IPP protocol itself.
IPP Modelドキュメントは1としてのSecure Socket Layerバージョン3(SSL3)を実装する「プライバシー」でIPP実装を定義します。 以下に注意してください。 SSL3はIETF標準化過程仕様ではありません。 SSL3はIPPセキュリティのためにあいさつで互いの認証やプライバシー(暗号化を通した)などの特徴に条件を満たします。 IPP Modelドキュメントも、IPP特有のセキュリティ問題について概説して、あいさつでIPPプロトコル自体のセキュリティ含意のプライマリ参照であるべきです。
The IPP Model document defines an IPP implementation with "authentication" as one that implements the standard way for transporting IPP messages within HTTP 1.1. These include the security considerations outlined in the HTTP 1.1 standard document [RFC2068] and Digest Access Authentication extension [RFC2069].
IPP Modelドキュメントは1としてのHTTP1.1の中でIPPメッセージを輸送するための標準の方法を実装する「認証」でIPP実装を定義します。 これらはHTTP1.1の標準のドキュメント[RFC2068]とDigest Access Authentication拡張子[RFC2069]に概説されたセキュリティ問題を含んでいます。
The current HTTP infrastructure supports HTTP over TCP port 80. IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port.
TCPの上の現在のHTTPインフラ支援HTTPは80を移植します。 Well Known Port631(IPPデフォルトポート)が割り当てられたIANAの上でHTTPを使用して、IPPサーバ実装はサービスをIPPに提供しなければなりません。 IPPサーバ実装はこのポートに加えた他のポートを支えるかもしれません。
See further discussion of IPP security concepts in the model document [RFC2566].
モデルドキュメント[RFC2566]のIPPセキュリティ概念のさらなる議論を見てください。
5.1 Using IPP with SSL3
5.1 SSL3とIPPを使用すること。
An assumption is that the URI for a secure IPP Printer object has been found by means outside the IPP printing protocol, via a directory service, web site or other means.
仮定は安全なIPP PrinterオブジェクトのためのURIがIPP印刷プロトコルの外における手段によって見つけられたということです、ディレクトリサービス、ウェブサイトまたは他の手段で。
IPP provides a transparent connection to SSL by calling the corresponding URL (a https URI connects by default to port 443). However, the following functions can be provided to ease the integration of IPP with SSL during implementation:
IPPは、対応するURLを呼ぶことによって、わかりやすい接続をSSLに供給します(https URIは443を移植するためにデフォルトで接続します)。 しかしながら、実装の間、SSLとのIPPの統合を緩和するために以下の機能を提供できます:
connect (URI), returns a status
(URI)を接続して、状態を返します。
"connect" makes an https call and returns the immediate status
of the connection as returned by SSL to the user. The status
values are explained in section 5.4.2 of the SSL document
[ssl].
SSLによってユーザに返されるように、「接続してください」は、httpsを呼ばせて、接続の即座の状態を返します。 状態値は.2通のセクション5.4SSLドキュメント[ssl]で説明されます。
Herriot, et al. Experimental [Page 19] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[19ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
A session-id may also be retained to later resume a session.
The SSL handshake protocol may also require the cipher
specifications supported by the client, key length of the
ciphers, compression methods, certificates, etc. These should
be sent to the server and hence should be available to the IPP
client (although as part of administration features).
また、セッションイドは、後でセッションを再開するために保有されるかもしれません。 また、SSL握手プロトコルはクライアントによってサポートされた暗号仕様、暗号のキー長、圧縮方法、証明書などを必要とするかもしれません。 これらは、サーバに送られるべきであり、IPPクライアントにとって、したがって、利用可能であるべきです(管理機能の一部として)。
disconnect (session)
分離(セッション)
to disconnect a particular session.
特定のセッションから切断するために。
The session-id available from the "connect" could be used.
「接続」から利用可能なセッションイドを使用できました。
resume (session)
履歴書(セッション)
to reconnect using a previous session-id.
前のセッションイドを使用することで再接続するために。
The availability of this information as administration features are left for implementers, and need not be specified at this time.
管理機能があるとき、この情報の有用性は、implementersに向けて発って、このとき、指定される必要はありません。
6. References
6. 参照
[RFC2278] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2278, January 1998.
解放された[RFC2278]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2278、1998年1月。
[dpa] ISO/IEC 10175 Document Printing Application (DPA), June
1996.
[dpa]ISO/IEC10175は印刷アプリケーション(DPA)、1996年6月を記録します。
[iana] IANA Registry of Coded Character Sets:
ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
コード化文字集合の[iana]IANA登録: ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets 。
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.0:
Implementer's Guide", Work in Progress.
[ipp-iig] ヘイスティングズ、トム、他、「プロトコル/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プロトコルの間のマッピング」、RFC2569、1999年4月。
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2566] deBryとR.とヘイスティングズとT.とエリオとR.とイサクソンとS.とP.パウエル、「プロトコル/1.0に以下を印刷するインターネット」 「モデルと意味論」、RFC2566、4月1999日
[RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
Printing Protocol/1.0: Encoding and Transport", RFC 2565,
April 1999.
[RFC2565] エリオ、R.、バトラー、S.、ムーア、P.、チューナー、R.、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日
Herriot, et al. Experimental [Page 20] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[20ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
[RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RFC 2568,
April 1999.
[RFC2568]Zilles、S.、「インターネット印刷プロトコルのための構造、モデル、およびプロトコルのための原理」、RFC2568、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2567] ライト、D.、「インターネット印刷プロトコルのデザイン目標」、RFC2567、1999年4月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon
Protocol" RFC 1179, August 1990.
[RFC1179]マクラフリン、1990年8月のL.III、(エディタ)、「ラインプリンタデーモンプロトコル」RFC1179。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC2223] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] バーナーズ・リーとT.とMasinterとL.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[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行進。
[RFC1766] Alvestrand, H., " Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC1766]Alvestrand、H.、「言語の識別のためのタグ」、RFC1766、1995年3月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
1808, June 1995.
[RFC1808] フィールディング、R.、「相対的なUniform Resource Locator」、RFC1808、1995年6月。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2046] Freed, N. and N. Borenstein, Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
解放された[RFC2046]とN.とN.Borenstein、マルチパーパスインターネットメールエクステンション(MIME)は2を分けます: 「メディアタイプ」、RFC2046、1996年11月。
[RFC2048] Freed, N., Klensin J. and J. Postel. Multipurpose Internet
Mail Extension (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996.
解放された[RFC2048]、N.、Klensin J.、およびJ.ポステル。 マルチパーパスインターネットメールエクステンション(MIME)パートFour: 「登録手順」、BCP13、RFC2048、1996年11月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[RFC2068] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月」。
Herriot, et al. Experimental [Page 21] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 21] RFC 2565 IPP/1.0: Encoding and Transport April 1999
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E. and L. Stewart, "An Extension to
HTTP: Digest Access Authentication", RFC 2069, January
1997.
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2184, August 1997.
[RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234. November 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234. November 1997.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
7. Authors' Addresses
7. Authors' Addresses
Robert Herriot (Editor) Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
Robert Herriot (Editor) Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: rherriot@pahv.xerox.com
Phone: 650-813-7696 Fax: 650-813-6860 EMail: rherriot@pahv.xerox.com
Sylvan Butler Hewlett-Packard 11311 Chinden Blvd. Boise, ID 83714
Sylvan Butler Hewlett-Packard 11311 Chinden Blvd. Boise, ID 83714
Phone: 208-396-6000 Fax: 208-396-3457 EMail: sbutler@boi.hp.com
Phone: 208-396-6000 Fax: 208-396-3457 EMail: sbutler@boi.hp.com
Herriot, et al. Experimental [Page 22] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 22] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Paul Moore Microsoft One Microsoft Way Redmond, WA 98053
Paul Moore Microsoft One Microsoft Way Redmond, WA 98053
Phone: 425-936-0908 Fax: 425-93MS-FAX EMail: paulmo@microsoft.com
Phone: 425-936-0908 Fax: 425-93MS-FAX EMail: paulmo@microsoft.com
Randy Turner Sharp Laboratories 5750 NW Pacific Rim Blvd Camas, WA 98607
Randy Turner Sharp Laboratories 5750 NW Pacific Rim Blvd Camas, WA 98607
Phone: 360-817-8456 Fax: 360-817-8436 EMail: rturner@sharplabs.com
Phone: 360-817-8456 Fax: 360-817-8436 EMail: rturner@sharplabs.com
IPP Mailing List: ipp@pwg.org IPP Mailing List Subscription: ipp-request@pwg.org IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.org IPP Mailing List Subscription: ipp-request@pwg.org IPP Web Page: http://www.pwg.org/ipp/
Herriot, et al. Experimental [Page 23] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 23] RFC 2565 IPP/1.0: Encoding and Transport April 1999
8. Other Participants:
8. Other Participants:
Chuck Adams - Tektronix Harry Lewis - IBM
Ron Bergman - Dataproducts Tony Liao - Vivid Image
Keith Carter - IBM David Manchala - Xerox
Angelo Caruso - Xerox Carl-Uno Manros - Xerox
Jeff Copeland - QMS Jay Martin - Underscore
Roger deBry - IBM Larry Masinter - Xerox
Lee Farrell - Canon Ira McDonald - High North Inc.
Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard
Charles Gordon - Osicom Patrick Powell - Astart
Technologies
Brian Grimshaw - Apple Jeff Rackowitz - Intermec
Jerry Hadsell - IBM Xavier Riley - Xerox
Richard Hart - Digital Gary Roberts - Ricoh
Tom Hastings - Xerox Stuart Rowley - Kyocera
Stephen Holmstead Richard Schneider - Epson
Zhi-Hong Huang - Zenographics Shigern Ueda - Canon
Scott Isaacson - Novell Bob Von Andel - Allegro Software
Rich Lomicka - Digital William Wagner - Digital Products
David Kellerman - Northlake Jasper Wong - Xionics
Software
Robert Kline - TrueSpectra Don Wright - Lexmark
Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox
Takami Kurono - Brother Lloyd Young - Lexmark
Rich Landau - Digital Peter Zehler - Xerox
Greg LeClair - Epson Frank Zhao - Panasonic
Steve Zilles - Adobe
Chuck Adams - Tektronix Harry Lewis - IBM Ron Bergman - Dataproducts Tony Liao - Vivid Image Keith Carter - IBM David Manchala - Xerox Angelo Caruso - Xerox Carl-Uno Manros - Xerox Jeff Copeland - QMS Jay Martin - Underscore Roger deBry - IBM Larry Masinter - Xerox Lee Farrell - Canon Ira McDonald - High North Inc. Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard Charles Gordon - Osicom Patrick Powell - Astart Technologies Brian Grimshaw - Apple Jeff Rackowitz - Intermec Jerry Hadsell - IBM Xavier Riley - Xerox Richard Hart - Digital Gary Roberts - Ricoh Tom Hastings - Xerox Stuart Rowley - Kyocera Stephen Holmstead Richard Schneider - Epson Zhi-Hong Huang - Zenographics Shigern Ueda - Canon Scott Isaacson - Novell Bob Von Andel - Allegro Software Rich Lomicka - Digital William Wagner - Digital Products David Kellerman - Northlake Jasper Wong - Xionics Software Robert Kline - TrueSpectra Don Wright - Lexmark Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox Takami Kurono - Brother Lloyd Young - Lexmark Rich Landau - Digital Peter Zehler - Xerox Greg LeClair - Epson Frank Zhao - Panasonic Steve Zilles - Adobe
Herriot, et al. Experimental [Page 24] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 24] RFC 2565 IPP/1.0: Encoding and Transport April 1999
9. Appendix A: Protocol Examples
9. Appendix A: Protocol Examples
9.1 Print-Job Request
9.1 Print-Job Request
The following is an example of a Print-Job request with job-name, copies, and sides specified. The "ipp-attribute-fidelity" attribute is set to 'true' so that the print request will fail if the "copies" or the "sides" attribute are not supported or their values are not supported.
The following is an example of a Print-Job request with job-name, copies, and sides specified. The "ipp-attribute-fidelity" attribute is set to 'true' so that the print request will fail if the "copies" or the "sides" attribute are not supported or their values are not supported.
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0100 1.0 version-number 0x0002 Print-Job operation-id 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural- language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x001A value-length http://forest: printer pinetree value 631/pinetree 0x42 nameWithoutLanguage type value-tag 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x22 boolean type value-tag 0x16 name-length ipp-attribute- ipp-attribute-fidelity name fidelity 0x01 value-length 0x01 true value 0x02 start job-attributes job-attributes-tag 0x21 integer type value-tag
0x0100 1.0 version-number 0x0002 Print-Job operation-id 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural- language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x001A value-length http://forest: printer pinetree value 631/pinetree 0x42 nameWithoutLanguage type value-tag 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x22 boolean type value-tag 0x16 name-length ipp-attribute- ipp-attribute-fidelity name fidelity 0x01 value-length 0x01 true value 0x02 start job-attributes job-attributes-tag 0x21 integer type value-tag
Herriot, et al. Experimental [Page 25] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 25] RFC 2565 IPP/1.0: Encoding and Transport April 1999
0x0006 name-length copies copies name 0x0004 value-length 0x00000014 20 value 0x44 keyword type value-tag 0x0005 name-length sides sides name 0x0013 value-length two-sided- two-sided-long-edge value long-edge 0x03 end-of-attributes end-of-attributes-tag %!PS... <PostScript> data
0x0006 name-length copies copies name 0x0004 value-length 0x00000014 20 value 0x44 keyword type value-tag 0x0005 name-length sides sides name 0x0013 value-length two-sided- two-sided-long-edge value long-edge 0x03 end-of-attributes end-of-attributes-tag %!PS... <PostScript> data
9.2 Print-Job Response (successful)
9.2 Print-Job Response (successful)
Here is an example of a successful Print-Job response to the previous Print-Job request. The printer supported the "copies" and "sides" attributes and their supplied values. The status code returned is ' successful-ok'.
Here is an example of a successful Print-Job response to the previous Print-Job request. The printer supported the "copies" and "sides" attributes and their supplied values. The status code returned is ' successful-ok'.
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0100 1.0 version-number 0x0000 successful-ok status-code 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural- name natural-language language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000E name-length status-message status-message name 0x000D value-length successful-ok successful-ok value 0x02 start job-attributes job-attributes-tag 0x21 integer value-tag 0x0006 name-length
0x0100 1.0 version-number 0x0000 successful-ok status-code 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural- name natural-language language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000E name-length status-message status-message name 0x000D value-length successful-ok successful-ok value 0x02 start job-attributes job-attributes-tag 0x21 integer value-tag 0x0006 name-length
Herriot, et al. Experimental [Page 26] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 26] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
job-id job-id name 0x0004 value-length 147 147 value 0x45 uri type value-tag 0x0007 name-length job-uri job-uri name 0x001E value-length http://forest:63 job 123 on pinetree value 1/pinetree/123 0x42 nameWithoutLanguage type value-tag 0x0009 name-length job-state job-state name 0x0004 value-length 0x0003 pending value 0x03 end-of-attributes end-of-attributes-tag
job-id job-id name 0x0004 value-length 147 147 value 0x45 uri type value-tag 0x0007 name-length job-uri job-uri name 0x001E value-length http://forest:63 job 123 on pinetree value 1/pinetree/123 0x42 nameWithoutLanguage type value-tag 0x0009 name-length job-state job-state name 0x0004 value-length 0x0003 pending value 0x03 end-of-attributes end-of-attributes-tag
9.3 Print-Job Response (failure)
9.3 Print-Job Response (failure)
Here is an example of an unsuccessful Print-Job response to the previous Print-Job request. It fails because, in this case, the printer does not support the "sides" attribute and because the value '20' for the "copies" attribute is not supported. Therefore, no job is created, and neither a "job-id" nor a "job-uri" operation attribute is returned. The error code returned is 'client-error- attributes-or-values-not-supported' (0x040B).
Here is an example of an unsuccessful Print-Job response to the previous Print-Job request. It fails because, in this case, the printer does not support the "sides" attribute and because the value '20' for the "copies" attribute is not supported. Therefore, no job is created, and neither a "job-id" nor a "job-uri" operation attribute is returned. The error code returned is 'client-error- attributes-or-values-not-supported' (0x040B).
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x040B client-error-attributes-or- status-code
values-not-supported
0x00000001 1 request-id
0x01 start operation-attributes operation-attribute tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
0x0100 1.0 version-number 0x040B client-error-attributes-or- status-code values-not-supported 0x00000001 1 request-id 0x01 start operation-attributes operation-attribute tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural- language 0x0005 value-length
Herriot, et al. Experimental [Page 27] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 27] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000E name-length status- status-message name message 0x002F value-length client-error- client-error-attributes-or- value attributes- values-not-supported or-values- not-supported 0x05 start unsupported-attributes unsupported-attributes tag 0x21 integer type value-tag 0x0006 name-length copies copies name 0x0004 value-length 0x00000014 20 value 0x10 unsupported (type) value-tag 0x0005 name-length sides sides name 0x0000 value-length 0x03 end-of-attributes end-of-attributes-tag
en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000E name-length status- status-message name message 0x002F value-length client-error- client-error-attributes-or- value attributes- values-not-supported or-values- not-supported 0x05 start unsupported-attributes unsupported-attributes tag 0x21 integer type value-tag 0x0006 name-length copies copies name 0x0004 value-length 0x00000014 20 value 0x10 unsupported (type) value-tag 0x0005 name-length sides sides name 0x0000 value-length 0x03 end-of-attributes end-of-attributes-tag
9.4 Print-Job Response (success with attributes ignored)
9.4 Print-Job Response (success with attributes ignored)
Here is an example of a successful Print-Job response to a Print-Job request like the previous Print-Job request, except that the value of 'ipp-attribute-fidelity' is false. The print request succeeds, even though, in this case, the printer supports neither the "sides" attribute nor the value '20' for the "copies" attribute. Therefore, a job is created, and both a "job-id" and a "job-uri" operation attribute are returned. The unsupported attributes are also returned in an Unsupported Attributes Group. The error code returned is ' successful-ok-ignored-or-substituted-attributes' (0x0001).
Here is an example of a successful Print-Job response to a Print-Job request like the previous Print-Job request, except that the value of 'ipp-attribute-fidelity' is false. The print request succeeds, even though, in this case, the printer supports neither the "sides" attribute nor the value '20' for the "copies" attribute. Therefore, a job is created, and both a "job-id" and a "job-uri" operation attribute are returned. The unsupported attributes are also returned in an Unsupported Attributes Group. The error code returned is ' successful-ok-ignored-or-substituted-attributes' (0x0001).
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x0001 successful-ok-ignored-or- status-code
substituted-attributes
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
0x0100 1.0 version-number 0x0001 successful-ok-ignored-or- status-code substituted-attributes 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length
Herriot, et al. Experimental [Page 28] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 28] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural- name
natural-language language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x002F value-length
successful-ok- successful-ok-ignored-or- value
ignored-or- substituted-attributes
substituted-
attributes
0x05 start unsupported- unsupported-attributes
attributes tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x10 unsupported (type) value-tag
0x0005 name-length
sides sides name
0x0000 value-length
0x02 start job-attributes job-attributes-tag
0x21 integer value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
0x45 uri type value-tag
0x0007 name-length
job-uri job-uri name
0x001E value-length
http://forest:63 job 123 on pinetree value
1/pinetree/123
0x42 nameWithoutLanguage type value-tag
0x0009 name-length
job-state job-state name
0x0004 value-length
0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag
us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural- name natural-language language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000E name-length status-message status-message name 0x002F value-length successful-ok- successful-ok-ignored-or- value ignored-or- substituted-attributes substituted- attributes 0x05 start unsupported- unsupported-attributes attributes tag 0x21 integer type value-tag 0x0006 name-length copies copies name 0x0004 value-length 0x00000014 20 value 0x10 unsupported (type) value-tag 0x0005 name-length sides sides name 0x0000 value-length 0x02 start job-attributes job-attributes-tag 0x21 integer value-tag 0x0006 name-length job-id job-id name 0x0004 value-length 147 147 value 0x45 uri type value-tag 0x0007 name-length job-uri job-uri name 0x001E value-length http://forest:63 job 123 on pinetree value 1/pinetree/123 0x42 nameWithoutLanguage type value-tag 0x0009 name-length job-state job-state name 0x0004 value-length 0x0003 pending value 0x03 end-of-attributes end-of-attributes-tag
Herriot, et al. Experimental [Page 29] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 29] RFC 2565 IPP/1.0: Encoding and Transport April 1999
9.5 Print-URI Request
9.5 Print-URI Request
The following is an example of Print-URI request with copies and job-name parameters:
The following is an example of Print-URI request with copies and job-name parameters:
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x0100 1.0 version-number
Octets Symbolic Value Protocol field 0x0003 Print-URI operation-id 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural- language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x001A value-length http://forest printer pinetree value :631/pinetree 0x45 uri type value-tag 0x000C name-length document-uri document-uri name 0x11 value-length ftp://foo.com ftp://foo.com/foo value /foo 0x42 nameWithoutLanguage type value-tag 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x02 start job-attributes job-attributes-tag 0x21 integer type value-tag 0x0006 name-length copies copies name 0x0004 value-length
Octets Symbolic Value Protocol field 0x0003 Print-URI operation-id 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural- language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x001A value-length http://forest printer pinetree value :631/pinetree 0x45 uri type value-tag 0x000C name-length document-uri document-uri name 0x11 value-length ftp://foo.com ftp://foo.com/foo value /foo 0x42 nameWithoutLanguage type value-tag 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x02 start job-attributes job-attributes-tag 0x21 integer type value-tag 0x0006 name-length copies copies name 0x0004 value-length
Herriot, et al. Experimental [Page 30] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 30] RFC 2565 IPP/1.0: Encoding and Transport April 1999
0x00000001 1 value 0x03 end-of-attributes end-of-attributes-tag
0x00000001 1 value 0x03 end-of-attributes end-of-attributes-tag
9.6 Create-Job Request
9.6 Create-Job Request
The following is an example of Create-Job request with no parameters and no attributes:
The following is an example of Create-Job request with no parameters and no attributes:
Octets Symbolic Value Protocol field 0x0100 1.0 version-number 0x0005 Create-Job operation-id 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length
Octets Symbolic Value Protocol field 0x0100 1.0 version-number 0x0005 Create-Job operation-id 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag 0x0012 name-length
Octets Symbolic Value Protocol field attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural- language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x001A value-length http://forest: printer pinetree value 631/pinetree 0x03 end-of-attributes end-of-attributes-tag
Octets Symbolic Value Protocol field attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural- language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x001A value-length http://forest: printer pinetree value 631/pinetree 0x03 end-of-attributes end-of-attributes-tag
9.7 Get-Jobs Request
9.7 Get-Jobs Request
The following is an example of Get-Jobs request with parameters but no attributes:
The following is an example of Get-Jobs request with parameters but no attributes:
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0100 1.0 version-number 0x000A Get-Jobs operation-id 0x00000123 0x123 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag
0x0100 1.0 version-number 0x000A Get-Jobs operation-id 0x00000123 0x123 request-id 0x01 start operation-attributes operation-attributes-tag 0x47 charset type value-tag
Herriot, et al. Experimental [Page 31] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 31] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural- language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x001A value-length http://forest:6 printer pinetree value 31/pinetree 0x21 integer type value-tag 0x0005 name-length limit limit name 0x0004 value-length 0x00000032 50 value 0x44 keyword type value-tag 0x0014 name-length requested- requested-attributes name attributes 0x0006 value-length job-id job-id value 0x44 keyword type value-tag 0x0000 additional value name-length 0x0008 value-length job-name job-name value 0x44 keyword type value-tag 0x0000 additional value name-length 0x000F value-length document-format document-format value 0x03 end-of-attributes end-of-attributes-tag
0x0012 name-length attributes- attributes-charset name charset 0x0008 value-length us-ascii US-ASCII value 0x48 natural-language type value-tag 0x001B name-length attributes- attributes-natural-language name natural- language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x001A value-length http://forest:6 printer pinetree value 31/pinetree 0x21 integer type value-tag 0x0005 name-length limit limit name 0x0004 value-length 0x00000032 50 value 0x44 keyword type value-tag 0x0014 name-length requested- requested-attributes name attributes 0x0006 value-length job-id job-id value 0x44 keyword type value-tag 0x0000 additional value name-length 0x0008 value-length job-name job-name value 0x44 keyword type value-tag 0x0000 additional value name-length 0x000F value-length document-format document-format value 0x03 end-of-attributes end-of-attributes-tag
9.8 Get-Jobs Response
9.8 Get-Jobs Response
The following is an of Get-Jobs response from previous request with 3 jobs. The Printer returns no information about the second job (because of security reasons):
The following is an of Get-Jobs response from previous request with 3 jobs. The Printer returns no information about the second job (because of security reasons):
Herriot, et al. Experimental [Page 32] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Herriot, et al. Experimental [Page 32] RFC 2565 IPP/1.0: Encoding and Transport April 1999
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x0000 successful-ok status-code
0x00000123 0x123 request-id (echoed
back)
0x01 start operation-attributes operation-attribute-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x000A value-length
ISO-8859-1 ISO-8859-1 value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x000D value-length
successful-ok successful-ok value
0x02 start job-attributes (1st job-attributes-tag
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
0x36 nameWithLanguage value-tag
0x0008 name-length
job-name job-name name
0x000C value-length
0x0005 sub-value-length
fr-ca fr-CA value
0x0003 sub-value-length
fou fou name
0x02 start job-attributes (2nd job-attributes-tag
object)
0x02 start job-attributes (3rd job-attributes-tag
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
0×0100 1; 0バージョン番号0×0000うまくいっているOKステータスコード0x00000123 0×123要求イド(echo backである)0×01が0×47の操作属性操作属性タグcharsetタイプ値タグ0×0012名長さ属性属性-charset名前charset 0x000A値長さのISO-8859-1 ISO-8859-1値の0×48自然言語タイプ値タグ0x001B名長さ属性属性自然言語名義の自然な言語0x0005値長さを始める、アン、-、私たち、アン米国価値0x41のtextWithoutLanguageは値タグ0x000E名前長さをタイプします; ステータスメッセージステータスメッセージ名前0x000D値長さのうまくいっているOKうまくいっているOK値の0×02のスタート仕事属性(最初の仕事の属性タグオブジェクト)0×21整数型値タグ0×0006名前長さの仕事イド仕事イド名前0×0004値長さの147 147値の0×36nameWithLanguage値タグ0×0008名前長さのジョブ名ジョブ名名前0x000C値長さの0×0005サブ値の長さのfr-ca fr-カリフォルニア値の0×0003サブ値の長さのfou fou名0x02が仕事属性(2番目の仕事の属性タグオブジェクト)の0×02のスタート仕事属性を始める、(3番目の仕事の属性タグオブジェクト) 0×21整数型値タグ0×0006名前長さの仕事イド仕事イド名0x0004の値長さ
Herriot, et al. Experimental [Page 33] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[33ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
Octets Symbolic Value Protocol field
八重奏Symbolic Valueプロトコル分野
148 148 value 0x36 nameWithLanguage value-tag 0x0008 name-length job-name job-name name 0x0012 value-length 0x0005 sub-value-length de-CH de-CH value 0x0009 sub-value-length isch guet isch guet name 0x03 end-of-attributes end-of-attributes-tag
148 148値の0×36nameWithLanguage値タグ0×0008名前長さのジョブ名ジョブ名名0x0012の値長さの0×0005サブ値の長さの反-CH反-CHは属性タグの属性の0×0009サブ値の長さのisch guet isch guet名前0×03エンド端を評価します。
Herriot, et al. Experimental [Page 34] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[34ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
10. Appendix C: Registration of MIME Media Type Information for
"application/ipp"
10. 付録C: MIMEメディアの登録は「アプリケーション/ipp」のための情報をタイプします。
This appendix contains the information that IANA requires for registering a MIME media type. The information following this paragraph will be forwarded to IANA to register application/ipp whose contents are defined in Section 3 "Encoding of the Operation Layer" in this document:
この付録はIANAがMIMEメディアタイプを示すために必要とする情報を含んでいます。 コンテンツが「操作層のコード化」というセクション3で本書では定義されるアプリケーション/ippを登録するためにこのパラグラフに従う情報をIANAに転送するでしょう:
MIME type name: application
MIMEの種類名: アプリケーション
MIME subtype name: ipp
MIME「副-タイプ」は以下を命名します。 ipp
A Content-Type of "application/ipp" indicates an Internet Printing Protocol message body (request or response). Currently there is one version: IPP/1.0, whose syntax is described in Section 3 "Encoding of the Operation Layer" of [RFC2565], and whose semantics are described in [RFC2566].
「アプリケーション/ipp」のコンテントタイプはインターネットPrintingプロトコルメッセージボディー(要求か応答)を示します。 現在、1つのバージョンがあります: IPP/1.0。構文は「操作層のコード化」という[RFC2565]のセクション3で説明されて、その意味論は[RFC2566]で説明されます。
Required parameters: none
必要なパラメタ: なし
Optional parameters: none
任意のパラメタ: なし
Encoding considerations:
問題をコード化します:
IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths).
IPP/1.0プロトコル要求/応答は長い系列を含むかもしれません、そして、ALWAYSはバイナリ・データ(例えば、属性値の長さ)を含んでいます。
Security considerations:
セキュリティ問題:
IPP/1.0 protocol requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. Protocol mixed-version interworking rules in [RFC2566] as well as protocol encoding rules in [RFC2565] are complete and unambiguous.
IPP/1.0プロトコル要求/応答は基本的なトランスポート・プロトコルに既に固有でない少しのセキュリティ危険も導入しません。 [RFC2566]の規則を[RFC2565]のプロトコル符号化規則が完全であって、明白であるのと同じくらいよく織り込んで、複雑なバージョンについて議定書の中で述べてください。
Interoperability considerations:
相互運用性問題:
IPP/1.0 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [RFC2566] and [RFC2565]. Protocol encoding rules specified in [RFC2565] are comprehensive, so that interoperability between conforming implementations is guaranteed (although support for specific optional features is not ensured). Both the "charset" and "natural-language" of all IPP/1.0 attribute values which are a LOCALIZED-STRING are explicit within IPP protocol requests/responses (without recourse to any external information in HTTP, SMTP, or other message transport headers).
IPP/1.0要求(クライアントによって生成される)と応答(サーバで、生成される)は標準の仕様[RFC2566]と[RFC2565]で課されるすべての順応要件に応じなければなりません。 [RFC2565]で指定されたプロトコル符号化規則が包括的であるので、実装を従わせることの間のその相互運用性は保証されます(特定のオプション機能のサポートが確実にされませんが)。 ともに、LOCALIZED-STRINGであるすべてのIPP/1.0属性値の"charset"と「自然言語」はIPPプロトコル要求/応答(HTTP、SMTP、または他のメッセージ転送ヘッダーのどんな外部の情報への償還請求のないも)の中で明白です。
Herriot, et al. Experimental [Page 35] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[35ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
Published specification:
広められた仕様:
[RFC2566] Isaacson, S., deBry, R., Hastings, T., Herriot, R. and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics" RFC 2566, April 1999.
[RFC2566] イサクソンとS.とdeBryとR.とヘイスティングズとT.とエリオとR.とP.パウエル、「プロトコル/1.0に以下を印刷するインターネット」 1999年4月の「モデルと意味論」RFC2566。
[RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
Printing Protocol/1.0: Encoding and Transport", RFC 2565,
April 1999.
[RFC2565] エリオ、R.、バトラー、S.、ムーア、P.、チューナー、R.、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日
Applications which use this media type:
このメディアタイプを使用するアプリケーション:
Internet Printing Protocol (IPP) print clients and print servers, communicating using HTTP/1.1 (see [RFC2565]), SMTP/ESMTP, FTP, or other transport protocol. Messages of type "application/ipp" are self-contained and transport-independent, including "charset" and "natural-language" context for any LOCALIZED-STRING value.
HTTP/1.1([RFC2565]を見る)、SMTP/ESMTP、FTP、または他のトランスポート・プロトコルを使用することで交信して、インターネットPrintingプロトコル(IPP)はクライアントとプリント・サーバを印刷します。 どんなLOCALIZED-STRING値のための"charset"と「自然言語」文脈も含んでいて、タイプ「アプリケーション/ipp」のメッセージは、自己充足的であって、輸送から独立しています。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606
スコットA.イサクソンノベルInc.122のEの1700秒間のプロボ、ユタ 84606
Phone: 801-861-7366 Fax: 801-861-4025 Email: sisaacson@novell.com
以下に電話をしてください。 801-861-7366 Fax: 801-861-4025 メールしてください: sisaacson@novell.com
or
または
Robert Herriot (Editor) Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
ロバートエリオ(エディタ)ゼロックス社3400のHillview Ave、パロアルト、Bldg#1カリフォルニア 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: rherriot@pahv.xerox.com
以下に電話をしてください。 650-813-7696 Fax: 650-813-6860 メールしてください: rherriot@pahv.xerox.com
Herriot, et al. Experimental [Page 36] RFC 2565 IPP/1.0: Encoding and Transport April 1999
エリオ、他 実験的な[36ページ]RFC2565IPP/1.0: コード化と輸送1999年4月
11. Full Copyright Statement
11. 完全な著作権宣言文
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Herriot, et al. Experimental [Page 37]
エリオ、他 実験的[37ページ]
一覧
スポンサーリンク
