RFC2910 日本語訳
2910 Internet Printing Protocol/1.1: Encoding and Transport. R.Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn. September 2000. (Format: TXT=100599 bytes) (Obsoletes RFC2565) (Updated by RFC3380, RFC3381, RFC3382, RFC3510, RFC3995) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Herriot, Editor
Request for Comments: 2910 Xerox Corporation
Obsoletes: 2565 S. Butler
Category: Standards Track Hewlett-Packard
P. Moore
Peerless Systems Networking
R. Turner
2wire.com
J. Wenn
Xerox Corporation
September 2000
ワーキンググループのR.エリオ、コメントを求めるエディタ要求をネットワークでつないでください: 2910 ゼロックス社は以下を時代遅れにします。 2565秒間バトラーCategory: J.Wennゼロックス社の2000年9月にR.ターナー2wire.comをネットワークでつなぐ標準化過程ヒューレット・パッカードのP.ムーアPeerlessのシステム
Internet Printing Protocol/1.1: Encoding and Transport
インターネット印刷プロトコル/1.1: コード化と輸送
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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 Hypertext Transfer Protocol (HTTP) a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
このドキュメントは1セットのドキュメントの1つであり、どれが新しいインターネットPrintingプロトコル(IPP)の全面について一緒に説明しますか? IPPは分配された印刷にインターネット・ツールと技術を使用することで使用できるアプリケーションレベルプロトコルです。 このドキュメントはIPP操作をコード化するために規則を決めました、そして、「アプリケーション/ipp」と、新しいインターネットパントマイムメディアタイプへのIPP属性は呼びました。 また、このドキュメントは、ハイパーテキストTransferプロトコル(HTTP)の上でコンテントタイプが「アプリケーション/ipp」であるメッセージ本体を輸送するために規則を決めます。 このドキュメントは、IPPプリンタと仕事を特定するために'ipp'という新しい体系を定義します。
Herriot, et al. Standards Track [Page 1] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[1ページ]: コード化と輸送2000年9月
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.1: Model and Semantics [RFC2911] Internet Printing Protocol/1.1: Encoding and Transport (this document) Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569]
構造とモデルのためのインターネット印刷プロトコル[RFC2567]原理とインターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/1.1のためのプロトコルの目標を設計してください: モデルと意味論[RFC2911]インターネット印刷プロトコル/1.1: コード化とTransport(このドキュメント)インターネットPrintingプロトコル/1.1: 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.1. A few OPTIONAL operator operations have been added to IPP/1.1.
「インターネット印刷プロトコルのデザイン目標」というドキュメントは分散印刷の機能性への広い一見を取ります、そして、それは印刷プロトコルに含まれる必要がある特徴をインターネットにはっきりさせるのを助ける現実のシナリオを列挙します。 それは3つのタイプのユーザのための要件を特定します: エンドユーザ、オペレータ、および管理者。 それはIPP/1.1で満たされているエンドユーザ要件の部分集合を呼び出します。 いくつかのOPTIONALオペレータ操作がIPP/1.1に加えられます。
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 specification documents, and gives background and rationale for the IETF working group's major decisions.
「構造とモデルのための原理とインターネット印刷プロトコルのためのプロトコル」というドキュメントは、高い平らな視点からIPPについて説明して、IPP仕様ドキュメントのスイートを形成する様々なドキュメントのために道路地図を定義して、IETFワーキンググループの主たる決定のためにバックグラウンドと原理を与えます。
The document, "Internet Printing Protocol/1.1: 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.1に以下を印刷するインターネット」 「モデルとSemantics」と、簡易型のモデルは抽象的なオブジェクト、それらの属性、彼らのコード化から独立している操作、および輸送で説明します。 それはPrinterとJobオブジェクトを導入します。 Jobオブジェクトは任意に複数の1Jobあたりのドキュメントを支えます。 また、それはセキュリティ、国際化、およびディレクトリ問題を扱います。
The document "Internet Printing Protocol/1.1: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
ドキュメント「プロトコル/1.1に以下を印刷するインターネット」 「Implementerのガイド」はIPPクライアントとIPPオブジェクトのimplementersにアドバイスします。
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に与えます。
Herriot, et al. Standards Track [Page 2] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[2ページ]: コード化と輸送2000年9月
Table of Contents
目次
1. Introduction ...................................................4
2. Conformance Terminology ........................................4
3. Encoding of the Operation Layer ...............................4
3.1 Picture of the Encoding ...................................6
3.1.1 Request and Response...................................6
3.1.2 Attribute Group........................................6
3.1.3 Attribute..............................................7
3.1.4 Picture of the Encoding of an Attribute-with-one-value.7
3.1.5 Additional-value.......................................8
3.1.6 Alternative Picture of the Encoding of a Request Or a
Response...............................................9
3.2 Syntax of Encoding ........................................9
3.3 Attribute-group ..........................................11
3.4 Required Parameters ......................................12
3.4.1 Version-number........................................12
3.4.2 Operation-id..........................................12
3.4.3 Status-code...........................................12
3.4.4 Request-id............................................13
3.5 Tags .....................................................13
3.5.1 Delimiter Tags........................................13
3.5.2 Value Tags............................................14
3.6 Name-Length ..............................................16
3.7 (Attribute) Name .........................................16
3.8 Value Length .............................................16
3.9 (Attribute) Value ........................................17
3.10 Data .....................................................18
4. Encoding of Transport Layer ...................................18
4.1 Printer-uri and job-uri ..................................19
5. IPP URL Scheme ................................................20
6. IANA Considerations ...........................................22
7. Internationalization Considerations ...........................23
8. Security Considerations .......................................23
8.1 Security Conformance Requirements ........................23
8.1.1 Digest Authentication.................................23
8.1.2 Transport Layer Security (TLS)........................24
8.2 Using IPP with TLS .......................................25
9. Interoperability with IPP/1.0 Implementations .................25
9.1 The "version-number" Parameter ...........................25
9.2 Security and URL Schemes .................................26
10. References ...................................................27
11. Authors' Addresses ...........................................29
12. Other Participants: ..........................................31
13. Appendix A: Protocol Examples ................................33
13.1 Print-Job Request ........................................33
13.2 Print-Job Response (successful) ..........................34
13.3 Print-Job Response (failure) .............................35
1. 序論…4 2. 順応用語…4 3. 操作がコード化されるのは層にされます…4 コード化の3.1画像…6 3.1 .1の要求と応答…6 3.1 .2 グループを結果と考えてください…6 3.1 .3 結果と考えます。7 3.1 1つの値がある属性のコード化の.4画像、.7 3.1 .5 追加値…8 3.1 要求か応答のコード化の.6の代替の画像…9 コード化の3.2構文…9 3.3 属性で分類してください…11 3.4 パラメタを必要とします…12 3.4 .1バージョン番号…12 3.4 .2操作イド…12 3.4 .3 状態コード…12 3.4 .4要求イド…13 3.5 タグ付けをします。13 3.5 .1 デリミタタグ…13 3.5 .2 タグを評価してください…14 3.6名前長さ…16 3.7 (結果と考えます) 命名します。16 3.8 長さを評価してください…16 3.9 (属性)値…17 3.10のデータ…18 4. 輸送がコード化されるのは層にされます…18 4.1のプリンタ-uriと仕事-uri…19 5. IPP URL体系…20 6. IANA問題…22 7. 国際化問題…23 8. セキュリティ問題…23 8.1 セキュリティ順応要件…23 8.1 .1 認証を読みこなしてください…23 8.1 .2 層のセキュリティ(TLS)を輸送してください…24 8.2 TLSとIPPを使用します…25 9. IPP/1.0実装がある相互運用性…25 9.1 「バージョン番号」パラメタ…25 9.2 セキュリティとURL体系…26 10. 参照…27 11. 作者のアドレス…29 12. 他の関係者: ..........................................31 13. 付録A: 例について議定書の中で述べてください…33 13.1印刷仕事の要求…33 13.2 印刷仕事の応答(うまくいっている)…34 13.3 印刷仕事の応答(失敗)…35
Herriot, et al. Standards Track [Page 3] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[3ページ]: コード化と輸送2000年9月
13.4 Print-Job Response (success with attributes ignored) .....36
13.5 Print-URI Request ........................................38
13.6 Create-Job Request .......................................39
13.7 Get-Jobs Request .........................................40
13.8 Get-Jobs Response ........................................41
14. Appendix B: Registration of MIME Media Type Information for
"application/ipp".............................................42
15. Appendix C: Changes from IPP/1.0 .............................44
16. Full Copyright Statement .....................................45
13.4 印刷仕事のResponse(属性が無視されている成功)…36 13.5印刷URI要求…雇用を創り出している38 13.6要求…ジョブスを得ている39 13.7要求…40 13.8 ジョブスを得ている応答…41 14. 付録B: MIMEメディアの登録は「アプリケーション/ipp」のための情報をタイプします…42 15. 付録C: IPP/1.0からの変化…44 16. 完全な著作権宣言文…45
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 2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP headers that an IPP implementation supports.
トランスポート層はHTTP/1.1要求か応答から成ります。 RFC2616[RFC2616]は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.1: Model and Semantics" [RFC2911] defines the semantics of such a message body and the supported values. This document specifies the encoding of an IPP operation. The aforementioned document [RFC2911] is henceforth referred to as the "IPP model document" or simply "model document".
操作層はHTTP要求か応答でメッセージ本体から成ります。 ドキュメント「プロトコル/1.1に以下を印刷するインターネット」 「モデルとSemantics」[RFC2911]はそのようなメッセージ本体とサポートしている値の意味論を定義します。 このドキュメントはIPP操作のコード化を指定します。 前述のドキュメント[RFC2911]は今後は、「IPPモデルドキュメント」か単に「モデルドキュメント」と呼ばれます。
Note: the version number of IPP (1.1) and HTTP (1.1) are not linked. They both just happen to be 1.1.
以下に注意してください。 IPP(1.1)とHTTP(1.1)のバージョン番号は繋がっていません。 それらの両方がちょうどたまたま1.1です。
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 is the message body part of the HTTP request or response and it MUST contain a single IPP operation request or IPP 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.
操作層はHTTP要求か応答のメッセージ身体の部分です、そして、それはただ一つのIPP操作要求かIPP操作応答を含まなければなりません。 各要求か応答が値と属性グループの系列から成ります。 属性グループはそれのそれぞれが名前と値である属性の系列から成ります。 結局、名前と値は八重奏の系列です。
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
コード化は最も原始のタイプとして八重奏から成ります。 3つの重要なタイプが、八重奏から造られたいくつかのタイプがありますが、整数と、文字列と八重奏ストリングです。(そこでは、他のほとんどのデータ型が組立しています)。 このコード化におけるあらゆる文字列がそうであるに違いありません。
Herriot, et al. Standards Track [Page 4] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[4ページ]: コード化と輸送2000年9月
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 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 value fields and the request-id.
キャラクタがいくらかのcharsetと何らかの自然言語に関連しているキャラクタの系列。 値(読み込み注文に従って)におけるコード化で最初のキャラクタである最初のキャラクタでの「オーダーを読みます」には文字列があるに違いありません。 関連charsetが関連自然言語が米国の英語である米国-ASCIIである文字列は今後は、米国ASCII STRINGと呼ばれます。 関連charsetと自然言語がモデルドキュメントで説明されるように要求か応答で指定される文字列は今後は、LOCALIZED-STRINGと呼ばれます。 コード化における最初の八重奏であり八重奏ストリングが値(IPPモデルドキュメント注文に従って)における最初の八重奏と共に「IPPモデルドキュメント注文」にあるに違いありません。 そして、ビッグエンディアン形式がある2補数の2進のコード化を使用して、署名している整数としてこのコード化におけるあらゆる整数をコード化しなければならない、(また、「ネットワークオーダー」として知られている、「最も重要なバイト、最初に」、) プロトコルの用法によって、整数のための八重奏の数は、1、2または4であるに違いありません。 そのような1八重奏の今後はSIGNED-BYTEと呼ばれた整数はバージョン番号とタグ・フィールドに使用されます。 そのような2バイトの整数であり、今後は呼ばれたSIGNED-SHORTは操作イド、ステータスコード、および長さの分野に使用されます。 4バイトの今後はSIGNED-INTEGERと呼ばれた整数は値の分野と要求イドに使用されます。
The following two sections present the encoding of 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]
An operation request or response MUST use the encoding described in these two sections.
操作要求か応答がこれらの2つのセクションで説明されたコード化を使用しなければなりません。
Herriot, et al. Standards Track [Page 5] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[5ページ]: コード化と輸送2000年9月
3.1 Picture of the Encoding
3.1 コード化の画像
3.1.1 Request and Response
3.1.1 要求と応答
An operation request or response is encoded as follows:
操作要求か応答が以下の通りコード化されます:
----------------------------------------------- | version-number | 2 bytes - required ----------------------------------------------- | operation-id (request) | | or | 2 bytes - required | status-code (response) | ----------------------------------------------- | request-id | 4 bytes - required ----------------------------------------------- | attribute-group | n bytes - 0 or more ----------------------------------------------- | end-of-attributes-tag | 1 byte - required ----------------------------------------------- | data | q bytes - optional -----------------------------------------------
----------------------------------------------- | バージョン番号| 2バイト--必要です。----------------------------------------------- | 操作イド(要求)| | または| 2バイト--必要です。| ステータスコード(応答)| ----------------------------------------------- | 要求イド| 4バイト--必要です。----------------------------------------------- | 属性グループ| nバイト--0以上----------------------------------------------- | 属性タグの端| 1バイト--必要です。----------------------------------------------- | データ| qバイト--、任意-----------------------------------------------
The first three fields in the above diagram contain the value of attributes described in section 3.1.1 of the Model document.
上のダイヤグラムの最初の3つの分野が.1通のセクション3.1Modelドキュメントで説明された属性の値を含んでいます。
The fourth field is the "attribute-group" field, and it occurs 0 or more times. Each "attribute-group" field represents a single group of attributes, such as an Operation Attributes group or a Job Attributes group (see the Model document). The IPP model document specifies the required attribute groups and their order for each operation request and response.
4番目の分野は「属性グループ」分野です、そして、それは0回以上起こります。 それぞれの「属性グループ」分野は属性のただ一つのグループを代表します、Operation AttributesグループやJob Attributesグループのように(Modelドキュメントを見てください)。 IPPモデルドキュメントは必要な属性グループと彼らのそれぞれの操作要求と応答の注文を指定します。
The "end-of-attributes-tag" field is always present, even when the "data" is not present. The Model document specifies for each operation request and response whether the "data" field is present or absent.
「データ」が存在してさえいないとき、「属性タグの端」分野はいつも存在しています。 Modelドキュメントは、「データ」分野に現在である、または欠けているかを各操作要求と応答に指定します。
3.1.2 Attribute Group
3.1.2 属性グループ
Each "attribute-group" field is encoded as follows:
それぞれの「属性グループ」分野は以下の通りコード化されます:
----------------------------------------------- | begin-attribute-group-tag | 1 byte ---------------------------------------------------------- | attribute | p bytes |- 0 or more ----------------------------------------------------------
----------------------------------------------- | 属性グループタグを始めてください。| 1バイト---------------------------------------------------------- | 属性| pバイト|- 0以上----------------------------------------------------------
Herriot, et al. Standards Track [Page 6] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[6ページ]: コード化と輸送2000年9月
The "begin-attribute-group-tag" field marks the beginning of an "attribute-group" field and its value identifies the type of attribute group, e.g. Operations Attributes group versus a Job Attributes group. The "begin-attribute-group-tag" field also marks the end of the previous attribute group except for the "begin- attribute-group-tag" field in the first "attribute-group" field of a request or response. The "begin-attribute-group-tag" field acts as an "attribute-group" terminator because an "attribute-group" field cannot nest inside another "attribute-group" field.
「属性グループタグを始めてください」という分野は「属性グループ」分野の始まりを示します、そして、値は属性グループのタイプを特定します、そして、例えば、Operations AttributesはJob Attributesグループに対して分類します。 また、「属性グループタグを始めてください」という分野は要求か応答の最初の「属性グループ」分野の「属性グループタグを始めてください」という分野以外の前の属性グループの終わりを示します。 「属性グループ」分野は別の「属性グループ」がさばく巣の内部を機能できないので、「属性グループタグを始めてください」という分野は「属性グループ」ターミネータとして機能します。
An "attribute-group" field contains zero or more "attribute" fields.
「属性グループ」分野はゼロか、より多くの「属性」分野を含んでいます。
Note, the values of the "begin-attribute-group-tag" field and the "end-of-attributes-tag" field are called "delimiter-tags".
注意、「属性グループタグを始めてください」という分野の値、および「属性タグの端」分野は「デリミタタグ」と呼ばれます。
3.1.3 Attribute
3.1.3 属性
An "attribute" field is encoded as follows:
「属性」分野は以下の通りコード化されます:
----------------------------------------------- | attribute-with-one-value | q bytes ---------------------------------------------------------- | additional-value | r bytes |- 0 or more ----------------------------------------------------------
----------------------------------------------- | 1つで、値を結果と考えてください。| qバイト---------------------------------------------------------- | 加算値| rバイト|- 0以上----------------------------------------------------------
When an attribute is single valued (e.g. "copies" with value of 10) or multi-valued with one value (e.g. "sides-supported" with just the value 'one-sided') it is encoded with just an "attribute-with-one- value" field. When an attribute is multi-valued with n values (e.g. "sides-supported" with the values 'one-sided' and 'two-sided-long- edge'), it is encoded with an "attribute-with-one-value" field followed by n-1 "additional-value" fields.
属性が評価(例えば、10の値がある「コピー」)にされるのであるかある値でマルチ評価されたシングル(例えば、正当で'一方的に'値を「側でサポートする」)であるときに、それが正当でコード化される、「属性、-、-」 分野を1つ評価してください。 属性がnでマルチ評価された値(例えば、「側でサポートされる」値が'一方的'、そして、'二面に長い縁'であることで)であるときに、n-1「加算値」分野が「1つの値がある属性」分野のあとに続いていて、それはコード化されます。
3.1.4 Picture of the Encoding of an Attribute-with-one-value
3.1.4 1つの値がある属性のコード化の画像
Each "attribute-with-one-value" field is encoded as follows:
それぞれの「1つの値がある属性」分野は以下の通りコード化されます:
----------------------------------------------- | 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. Standards Track [Page 7] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[7ページ]: コード化と輸送2000年9月
An "attribute-with-one-value" field is encoded with five subfields:
「1つの値がある属性」分野は5つの部分体でコード化されます:
The "value-tag" field specifies the attribute syntax, e.g. 0x44
for the attribute syntax 'keyword'.
「値タグ」分野は属性構文'キーワード'に属性構文、例えば0×44を指定します。
The "name-length" field specifies the length of the "name" field
in bytes, e.g. u in the above diagram or 15 for the name "sides-
supported".
「名前長さ」分野はバイト(例えば、「側は支えた」名前のための上のダイヤグラムか15におけるu)で表現される分野という「名前」の長さを指定します。
The "name" field contains the textual name of the attribute, e.g.
"sides-supported".
「名前」分野は例えば「側で、サポートされた」状態で属性の原文の名前を含んでいます。
The "value-length" field specifies the length of the "value" field
in bytes, e.g. v in the above diagram or 9 for the (keyword) value
'one-sided'.
「値長さ」分野はバイトで表現される「値」分野の長さ、例えば上のダイヤグラムか9におけるvを'一方的である'(キーワード)値に指定します。
The "value" field contains the value of the attribute, e.g. the
textual value 'one-sided'.
「値」分野は'一方的に'属性の値、例えば原文の値を含んでいます。
3.1.5 Additional-value
3.1.5 加算値
Each "additional-value" field is encoded as follows:
それぞれの「加算値」分野は以下の通りコード化されます:
----------------------------------------------- | value-tag | 1 byte ----------------------------------------------- | name-length (value is 0x0000) | 2 bytes ----------------------------------------------- | value-length (value is w) | 2 bytes ----------------------------------------------- | value | w bytes -----------------------------------------------
----------------------------------------------- | 値タグ| 1バイト----------------------------------------------- | 名前長さ(値は0×0000です)| 2バイト----------------------------------------------- | 値長さ(値はwです)| 2バイト----------------------------------------------- | 値| wバイト-----------------------------------------------
An "additional-value" is encoded with four subfields:
「加算値」は4つの部分体でコード化されます:
The "value-tag" field specifies the attribute syntax, e.g. 0x44
for the attribute syntax 'keyword'.
「値タグ」分野は属性構文'キーワード'に属性構文、例えば0×44を指定します。
The "name-length" field has the value of 0 in order to signify
that it is an "additional-value". The value of the "name-length"
field distinguishes an "additional-value" field ("name-length" is
0) from an "attribute-with-one-value" field ("name-length" is not
0).
「名前長さ」分野には、0の値が、それが「加算値」であると意味するようにあります。 「名前長さ」分野の値は「1つの値がある属性」分野と「加算値」分野(「名前長さ」は0である)を区別します(「名前長さ」は0ではありません)。
The "value-length" field specifies the length of the "value" field
in bytes, e.g. w in the above diagram or 19 for the (keyword)
value 'two-sided-long-edge'.
「値長さ」分野はバイトで表現される「値」分野の長さを指定します、例えば、上のダイヤグラムによるwか(キーワード)のための19は'二面の長い縁'を評価します。
Herriot, et al. Standards Track [Page 8] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[8ページ]: コード化と輸送2000年9月
The "value" field contains the value of the attribute, e.g. the
textual value 'two-sided-long-edge'.
「値」分野は属性の値を含んでいて、例えば、原文の値は'二面の長い縁'です。
3.1.6 Alternative Picture of the Encoding of a Request Or a Response
3.1.6 要求か応答のコード化の代替の画像
From the standpoint of a parser that performs an action based on a "tag" value, 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 | 1 byte - required ----------------------------------------------- | data | y bytes - optional -----------------------------------------------
----------------------------------------------- | バージョン番号| 2バイト--必要です。----------------------------------------------- | 操作イド(要求)| | または| 2バイト--必要です。| ステータスコード(応答)| ----------------------------------------------- | 要求イド| 4バイト--必要です。----------------------------------------------------------- | (デリミタタグか値タグ)にタグ付けをしてください。| 1バイト| ----------------------------------------------- |-0以上| 属性を空にするか、または休息させてください。| xバイト| ----------------------------------------------------------- | 属性タグの端| 1バイト--必要です。----------------------------------------------- | データ| yバイト--、任意-----------------------------------------------
The following show what fields the parser would expect after each type of "tag":
以下は、パーサがそれぞれのタイプの「タグ」の後にどんな分野を予想するかを示します:
- "begin-attribute-group-tag": expect zero or more "attribute"
fields
- "value-tag": expect the remainder of an "attribute-with-one-
value" or an "additional-value".
- "end-of-attributes-tag": expect that "attribute" fields are
complete and there is optional "data"
- 「属性グループタグを始めてください」: ゼロか以上が分野--「値タグ」を「結果と考える」と予想してください: 残りを期待する、「」 -1値による「加算値」を結果と考えます。 - 「属性タグの端」: 「属性」分野が完全であり、任意の「データ」があると予想してください。
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'値として表されます。
ipp-message = ipp-request / ipp-response
ipp-request = version-number operation-id request-id
*attribute-group end-of-attributes-tag data
ipp-response = version-number status-code request-id
*attribute-group end-of-attributes-tag data
ipp-応答ipp-要求=バージョン番号操作ipp-メッセージ=ipp-要求/イド要求イド*属性グループ属性タグの端のデータipp-応答はバージョン番号ステータスコード要求イド*属性グループ属性タグの端のデータと等しいです。
Herriot, et al. Standards Track [Page 9] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[9ページ]: コード化と輸送2000年9月
attribute-group = begin-attribute-group-tag *attribute
属性グループタグが始まっている=*属性グループ属性
version-number = major-version-number minor-version-number
major-version-number = SIGNED-BYTE
minor-version-number = SIGNED-BYTE
SIGNED-BYTEメジャーバージョン番号マイナーバージョン番号バージョン番号=メジャーバージョン番号=マイナーバージョン番号はSIGNED-BYTEと等しいです。
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はだれの値ですか?
attribute = attribute-with-one-value *additional-value
属性は1つの値がある属性*加算値と等しいです。
attribute-with-one-value = value-tag name-length name
value-length value
additional-value = value-tag zero-name-length value-length value
1つの値がある属性=値タグ名前長さ名前値長さ値加算値=値タグ無名の長さ値長さ価値
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
value-tag = %x10-FF ;see section 3.7.2
begin-attribute-group-tag = %x00-02 / %04-0F ; see section 3.7.1
end-of-attributes-tag = %x03 ; tag of 3
; see section 3.7.1
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
無名の長さ=%x00.00。 0値タグの名前長さ=%x10-FF; x00-02/%04-0Fを属性グループタグが始まっているセクション3.7.2=%見てください。 %x03は、属性タグのセクション3.7.1端が等しいのを見ます。 3のタグ。 BYTE SIGNED-SHORT=2BYTE SIGNED-INTEGER=4BYTE DIGIT=%x30-39は、セクション3.7.1SIGNED-BYTEが等しいのを見ます。 「「9インチのLALPHAは%x61-7Aと等しいこと」への0インチ x00-ffが八重奏で結ぶ「z」バイトへの"a"=%は*バイトと等しいです。
The syntax below defines additional terms that are referenced in this document. This syntax provides an alternate grouping of the delimiter tags.
以下の構文は本書では参照をつけられる追加用語を定義します。 この構文はデリミタタグの代替の組分けを提供します。
delimiter-tag = begin-attribute-group-tag / ; see section 3.7.1
end-of-attributes-tag
delimiter-tag = %x00-0F ; see section 3.7.1
属性グループタグが始まっている=/にデリミタでタグ付けをしてください。 セクション3.7.1属性タグの端のデリミタタグ=%をx00-0F見てください。 セクション3.7.1を見てください。
begin-attribute-group-tag = %x00 / operation-attributes-tag /
job-attributes-tag / printer-attributes-tag /
unsupported-attributes-tag / %x06-0F
operation-attributes-tag = %x01 ; tag of 1
属性グループタグが始まっている=%%x06-0F操作属性サポートされない属性プリンタ属性仕事の属性操作属性x00/タグ/タグ/タグ/タグ/タグ=%x01。 1のタグ
Herriot, et al. Standards Track [Page 10] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[10ページ]: コード化と輸送2000年9月
job-attributes-tag = %x02 ; tag of 2
printer-attributes-tag = %x04 ; tag of 4
unsupported-attributes-tag = %x05 ; tag of 5
仕事の属性タグ=%x02。 2プリンタ属性タグのタグ=%x04。 4のサポートされない属性タグのタグ=%x05。 5のタグ
3.3 Attribute-group
3.3 属性グループ
Each "attribute-group" field MUST be encoded with the "begin- attribute-group-tag" field followed by zero or more "attribute" sub- fields.
「属性グループタグを始めてください」というゼロがあとに続いている分野か、より多くの「属性」がサブ分野でそれぞれの「属性グループ」分野をコード化しなければなりません。
The table below maps the model document group name to value of the "begin-attribute-group-tag" field:
以下のテーブルは「属性グループタグを始めてください」という分野の値にモデルドキュメントグループ名を写像します:
Model Document Group "begin-attribute-group-tag" field
values
「属性グループタグを始めてください」というDocument Group分野値をモデル化してください。
Operation Attributes "operations-attributes-tag"
Job Template Attributes "job-attributes-tag"
Job Object Attributes "job-attributes-tag"
Unsupported Attributes "unsupported-attributes-tag"
Requested Attributes "job-attributes-tag"
(Get-Job-Attributes)
Requested Attributes "printer-attributes-tag"
(Get-Printer-Attributes)
Document Content in a special position as
described above
操作Attributes「属性がタグ付けをする操作」Job Template Attributes「仕事の属性タグ」Job Object Attributes「仕事の属性タグ」Unsupported Attributes「サポートされない属性タグ」Requested Attributes「仕事の属性タグ」(仕事の属性を得る)は上で説明される特別な位置でAttributes「プリンタ属性タグ」(プリンタ属性を得る)ドキュメントContentを要求しました。
For each operation request and response, the model document prescribes the required and optional attribute groups, along with their order. Within each attribute group, the model document prescribes the required and optional attributes, along with their order.
各操作要求と応答のために、モデルドキュメントは彼らのオーダーに伴う必要で任意の属性グループを定めます。 それぞれの属性グループの中では、モデルドキュメントは彼らのオーダーに伴う必要で任意の属性を定めます。
When the Model document requires an attribute group in a request or response and the attribute group contains zero attributes, a request or response SHOULD encode the attribute group with the "begin- attribute-group-tag" field followed by zero "attribute" fields. For example, if the client requests a single unsupported attribute with the Get-Printer-Attributes operation, the Printer MUST return no "attribute" fields, and it SHOULD return a "begin-attribute-group- tag" field for the Printer Attributes Group. The Unsupported Attributes group is not such an example. According to the model document, the Unsupported Attributes Group SHOULD be present only if the unsupported attributes group contains at least one attribute.
Modelドキュメントが要求か応答における属性グループを必要として、属性グループがSHOULDがコード化しないどんな属性も、要求または応答も含むと、ゼロが「属性グループタグを始めてください」という分野のあとに続いている属性グループは分野を「結果と考えます」。 例えば、クライアントがGetプリンタ属性操作でただ一つのサポートされない属性を要求するなら、PrinterはPrinter Attributes GroupのためにSHOULDのリターンのa「属性グループを始めているタグ」の野原を「属性」分野がなく、およびそれに返さなければなりません。 Unsupported Attributesグループはそのような例ではありません。 ドキュメントをモデル化してください、Unsupported Attributes Group SHOULD。サポートされない属性グループが少なくとも1つの属性を含む場合にだけ、存在してください。
A receiver of a request MUST be able to process the following as equivalent empty attribute groups:
要求の受信機は同等な空の属性グループとして以下を処理できなければなりません:
Herriot, et al. Standards Track [Page 11] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[11ページ]: コード化と輸送2000年9月
a) A "begin-attribute-group-tag" field with zero following
"attribute" fields.
a) 「属性グループタグを始めてください」というゼロがある「属性」野原に続く分野。
b) An expected but missing "begin-attribute-group-tag" field.
b) 「属性グループタグを始めてください」という予想されましたが、なくなった分野。
When the Model document requires a sequence of an unknown number of attribute groups, each of the same type, the encoding MUST contain one "begin-attribute-group-tag" field for each attribute group even when an "attribute-group" field contains zero "attribute" sub-fields. For example, for the Get-Jobs operation may return zero attributes for some jobs and not others. The "begin-attribute-group-tag" field followed by zero "attribute" fields tells the recipient that there is a job in queue for which no information is available except that it is in the queue.
Modelドキュメントが未知の数の属性グループ、同じタイプ各人の系列を必要とするとき、「属性グループ」分野が「属性」サブ分野を全く含まないときさえ、コード化は「属性グループタグを始めてください」というそれぞれの属性グループあたり1つの分野を含まなければなりません。 例えば、Get-ジョブス操作のために、リターンが他のものではなく、いくつかの仕事のための属性のゼロに合っていますように。 「属性グループタグを始めてください」というどんな「属性」分野もあとに続かなかった分野は、それが待ち行列中であるのを除いて、情報がないのが利用可能である待ち行列における仕事があると受取人に言います。
3.4 Required Parameters
3.4 必要なパラメタ
Some operation elements are called parameters in the model document [RFC2911]. They MUST be encoded in a special position and they MUST NOT appear as operation attributes. These parameters are described in the subsections below.
いくつかの操作要素がモデルドキュメント[RFC2911]のパラメタと呼ばれます。 特別な位置でそれらをコード化しなければなりません、そして、彼らは操作属性として現れてはいけません。 これらのパラメタは以下の小区分で説明されます。
3.4.1 Version-number
3.4.1 バージョン番号
The "version-number" field MUST consist of a major and minor version-number, each of which MUST be represented by a SIGNED-BYTE. The major version-number MUST be the first byte of the encoding and the minor version-number MUST be the second byte of the encoding. The protocol described in this document MUST have a major version-number of 1 (0x01) and a minor version-number of 1 (0x01). The ABNF for these two bytes MUST be %x01.01.
「バージョン番号」分野は主要で小さい方のバージョン番号から成らなければなりません。SIGNED-BYTEはそれぞれそれを表さなければなりません。 主要なバージョン番号はコード化の最初のバイトでなければなりません、そして、小さい方のバージョン番号はコード化の2番目のバイトでなければなりません。 本書では説明されたプロトコルは主要なバージョン番号の1(0×01)と小さい方のバージョン番号の1(0×01)を持たなければなりません。 これらの2バイトABNFは%x01.01であるに違いありません。
3.4.2 Operation-id
3.4.2 操作イド
The "operation-id" field MUST contain an operation-id value defined in the model document. The value MUST be encoded as a SIGNED-SHORT and it MUST be in the third and fourth bytes of the encoding of an operation request.
「操作イド」分野はモデルドキュメントで定義された操作イド値を含まなければなりません。 SIGNED-SHORTとそれがコード化の3番目と4番目のバイトであるに違いなくて、操作要求について値をコード化しなければなりません。
3.4.3 Status-code
3.4.3 ステータスコード
The "status-code" field MUST contain a status-code value defined in the model document. The value MUST be encoded as a SIGNED-SHORT and it MUST be in the third and fourth bytes of the encoding of an operation response.
「ステータスコード」分野はモデルドキュメントで定義されたステータスコード値を含まなければなりません。 SIGNED-SHORTとそれがコード化の3番目と4番目のバイトであるに違いなくて、操作応答について値をコード化しなければなりません。
Herriot, et al. Standards Track [Page 12] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[12ページ]: コード化と輸送2000年9月
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.4.4 Request-id
3.4.4 要求イド
The "request-id" field MUST contain a request-id value as defined in the model document. The value MUST be encoded as a SIGNED-INTEGER and it MUST be in the fifth through eighth bytes of the encoding.
「要求イド」分野はモデルドキュメントで定義されるように要求イド値を含まなければなりません。 SIGNED-INTEGERとして値をコード化しなければなりません、そして、コード化の5番目〜8番目のバイトにはそれがあるに違いありません。
3.5 Tags
3.5 タグ
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.5.1 Delimiter Tags
3.5.1 デリミタタグ
The following table specifies the values for the delimiter tags:
以下のテーブルはデリミタタグに値を指定します:
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x00 reserved for definition in a future IETF
standards track document
0x01 "operation-attributes-tag"
0x02 "job-attributes-tag"
0x03 "end-of-attributes-tag"
0x04 "printer-attributes-tag"
0x05 "unsupported-attributes-tag"
0x06-0x0f reserved for future delimiters in IETF
standards track documents
0×00は未来に定義のために「属性タグの端」0×04「プリンタ属性タグ」0×05「サポートされない属性タグ」の0×06 0x0fがIETF標準化過程ドキュメントの将来のデリミタのために予約したIETF標準化過程ドキュメント0x01「操作属性タグ」0×02「仕事の属性タグ」0×03を予約しました。
When a "begin-attribute-group-tag" field occurs in the protocol, it means that zero or more following attributes up to the next delimiter tag MUST be attributes belonging to the attribute group specified by the value of the "begin-attribute-group-tag". For example, if the value of "begin-attribute-group-tag" is 0x01, the following attributes MUST be members of the Operations Attributes group.
いつで「属性グループタグを始めてください」という分野がプロトコルで起こるか、そのゼロを意味するか、次のデリミタタグまでの、より多くの次の属性が値によって指定された属性グループに属す属性であるに違いないか、「属性グループタグを始めてください。」 例えば、「属性グループタグを始めてください」の値が0×01であるなら、以下の属性はOperations Attributesグループのメンバーであるに違いありません。
Herriot, et al. Standards Track [Page 13] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[13ページ]: コード化と輸送2000年9月
The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in an operation. It MUST be the last "delimiter-tag". If the operation has a document-content group, the document data in that group MUST follow the "end-of-attributes-tag".
「属性タグの端」(値0x03)はまさに一度稼働中であり起こらなければなりません。 それは最後の「デリミタタグ」であるに違いありません。 操作にドキュメント内容グループがあるなら、そのグループにおけるドキュメントデータは「属性タグの端」に続かなければなりません。
The order and presence of "attribute-group" fields (whose beginning is marked by the "begin-attribute-group-tag" subfield) for each operation request and each operation response MUST be that defined in the model document. For further details, see section 3.7 "(Attribute) Name" and 13 "Appendix A: Protocol Examples".
それぞれの操作要求とそれぞれの操作応答のための「属性グループ」分野(始めは「属性グループタグを始めてください」という部分体によって示される)の注文と存在はモデルドキュメントでそんなに定義していなければなりません。 さらに詳しい明細については、「(属性)名」と13「付録A:」というセクション3.7を見てください。 「例について議定書の中で述べてください。」
A Printer MUST treat a "delimiter-tag" (values from 0x00 through 0x0F) differently from a "value-tag" (values from 0x10 through 0xFF) 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が、それがそれが理解していないただ一つの値と対照的に理解していない全体の属性グループがあるのを知るように、「デリミタタグ」(0x0Fを通した0×00からの値)を「値タグ」(0xFFを通した0×10からの値)と異なって、扱わなければなりません。
3.5.2 Value Tags
3.5.2 値のタグ
The remaining tables show values for the "value-tag" field, which is the first octet of an attribute. The "value-tag" field specifies the type of the value of the attribute.
残っているテーブルは「値タグ」分野に値を案内しています。(それは、属性の最初の八重奏です)。 「値タグ」分野は属性の価値のタイプを指定します。
The following table specifies the "out-of-band" values for the "value-tag" field.
以下のテーブルは「値タグ」分野に「バンドの外」という値を指定します。
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x10 unsupported
0x11 reserved for 'default' for definition in a future
IETF standards track document
0x12 unknown
0x13 no-value
0x14-0x1F reserved for "out-of-band" values in future IETF
standards track documents.
サポートされない0×11が将来のIETF標準化過程ドキュメント0x12の値がない0×13の未知の0×14 0x1Fとの定義のための'デフォルト'のために予約した0×10は「バンドの外」のための将来のIETF標準化過程ドキュメントの値を予約しました。
The following table specifies the integer values for the "value-tag" field:
以下のテーブルは「値タグ」分野に整数値を指定します:
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x20 reserved for definition in a future IETF
standards track document
0x21 integer
0x22 boolean
0x23 enum
0x24-0x2F reserved for integer types for definition in
future IETF standards track documents
0×20は未来に定義のために0×24 0x2Fが将来のIETF標準化過程ドキュメントとの定義のための整数型のために予約したIETF標準化過程ドキュメント0×21整数0×22論理演算子0x23enumを予約しました。
Herriot, et al. Standards Track [Page 14] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[14ページ]: コード化と輸送2000年9月
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" field:
以下のテーブルは「値のタグ」分野にoctetString値を指定します:
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x30 octetString with an unspecified format
0x31 dateTime
0x32 resolution
0x33 rangeOfInteger
0x34 reserved for definition in a future IETF
standards track document
0x35 textWithLanguage
0x36 nameWithLanguage
0x37-0x3F reserved for octetString type definitions in
future IETF standards track documents
0×30 不特定の形式0×31dateTime0x32解決0x33rangeOfInteger0x34が未来との定義のために予約されている状態で、IETF標準化過程ドキュメント0x35textWithLanguage0x36nameWithLanguageこれからoctetString型定義のために予約された0×37 0x3F IETF標準化過程ドキュメントをoctetStringすること。
The following table specifies the character-string values for the "value-tag" field:
以下のテーブルは「値タグ」分野に文字列値を指定します:
Tag Value (Hex) Meaning
タグ値の(十六進法)意味
0x40 reserved for definition in a future IETF
standards track document
0x41 textWithoutLanguage
0x42 nameWithoutLanguage
0x43 reserved for definition in a future IETF
standards track document
0x44 keyword
0x45 uri
0x46 uriScheme
0x47 charset
0x48 naturalLanguage
0x49 mimeMediaType
0x4A-0x5F reserved for character string type definitions
in future IETF standards track documents
0×40は定義のために将来のIETF標準化過程ドキュメントでIETF標準化過程ドキュメント0×44キーワード0x45uri0×46uriScheme0x47charset0×48naturalLanguage0x49mimeMediaType 0x4A-0x5Fが将来のIETF標準化過程ドキュメントへの文字列型定義のために予約した未来との定義のために予約された0×41textWithoutLanguage0x42nameWithoutLanguage0x43を予約しました。
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 type definitions in IETF standards track documents.
0×60値の0xFFがIETF標準化過程ドキュメントへの今後の型定義のために予約されます。
Herriot, et al. Standards Track [Page 15] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[15ページ]: コード化と輸送2000年9月
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. Values from 0x00 to 0x37777777 are reserved for definition in future IETF standard track documents. The values 0x40000000 to 0x7FFFFFFF are reserved for vendor extensions.
タグ0x7Fは、タイプを1バイトで利用可能な255の値を超えたところまで広げるために予約されます。 0x7Fのタグ値は、値の分野の最初の4バイトがタグ値として解釈されるのを意味しなければなりません。 この未来に拡大がこの特別なタグに気づかない状態でパーサに影響しないことに注意してください。 タグはいかなる他の未知のタグにも似ています、そして、値の長さは価値の長さを指定します。(価値はパーサが原子論的に扱う値を含みます)。 0×00から0×37777777までの値は将来のIETF標準の道のドキュメントとの定義のために予約されます。 0x7FFFFFFFへの値0x40000000はベンダー拡大のために予約されます。
3.6 Name-Length
3.6 名前長さ
The "name-length" field MUST consist of a SIGNED-SHORT. This field MUST specify the number of octets in the immediately following "name" field. The value of this field excludes the two bytes of the "name- length" field. For example, if the "name" field contains "sides", the value of this field is 5.
「名前長さ」分野はSIGNED-SHORTから成らなければなりません。 この分野は分野というすぐに次の「名前」の八重奏の数を指定しなければなりません。 この分野の値は「名前の長さ」分野の2バイトを除きます。 例えば、「名前」分野が「側」を含んでいるなら、この分野の値は5です。
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 attribute encoded in the nearest preceding "attribute-with-one-value" field. Within an attribute group, if two or more attributes have the same name, the attribute group is mal- formed (see [RFC2911] section 3.1.3). The zero-length name is the only mechanism for multi-valued attributes.
「名前長さ」分野にゼロの値があるなら、以下の「名前」分野は人影がないに違いありません、そして、最も近い前の「1つの値がある属性」分野でコード化された属性のために以下の値を加算値として扱わなければなりません。 属性グループの中では、同じ名前が2つ以上の属性にあるなら、属性グループは悪-結成されます([RFC2911]セクション3.1.3を見てください)。 ゼロ・レングス名はマルチ評価された属性のための唯一のメカニズムです。
3.7 (Attribute) Name
3.7 (属性)名
The "name" field MUST contain the name of an attribute. The model document [RFC2911] specifies such names.
「名前」分野は属性の名前を含まなければなりません。 モデルドキュメント[RFC2911]はそのような名前を指定します。
3.8 Value Length
3.8 値の長さ
The "value-length" field MUST consist of a SIGNED-SHORT. This field MUST specify the number of octets in the immediately following "value" field. The value of this field excludes the two bytes of the "value-length" field. For example, if the "value" field contains the keyword (text) value 'one-sided', the value of this field is 9.
「値長さ」分野はSIGNED-SHORTから成らなければなりません。 この分野はすぐに次の「値」分野の八重奏の数を指定しなければなりません。 この分野の値は「値長さ」分野の2バイトを除きます。 例えば、「値」分野が'一方的に'キーワード(テキスト)値を含んでいるなら、この分野の値は9です。
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.
文字列によって代理をされたタイプのいずれのためにも、送付者はストリングのすべてのキャラクタと少しも暫定記号なしで値をコード化しなければなりません。
Herriot, et al. Standards Track [Page 16] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[16ページ]: コード化と輸送2000年9月
For "out-of-band" "value-tag" fields defined in this document, such as "unsupported", the "value-length" MUST be 0 and the "value" empty; the "value" has no meaning when the "value-tag" has one of these "out-of-band" values. For future "out-of-band" "value-tag" fields, the same rule holds unless the definition explicitly states that the "value-length" MAY be non-zero and the "value" non-empty.
「バンドの外」のための「値タグ」分野は「サポートされなく」本書ではそのようなものを定義して、0と「値」が空であったなら、「値長さ」はそうしなければなりません。 いいえが、いつ、「値タグ」には「バンドの外」というこれらの値の1つがあるかを意味して、「値」はそうしました。 将来の「バンドの外」という「値タグ」分野に、非ゼロと「値」が非空であったなら定義が明らかにその「値長さ」5月を述べない場合、同じ規則は成立します。
3.9 (Attribute) Value
3.9 (属性)値
The syntax types (specified by the "value-tag" field) and most of the details of the representation of attribute values 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.
The length of a textWithLanguage value MUST be
4 + the value of field a + the value of field c.
4つの分野のtextWithLanguage OCTET-STRINGの成ること: 以下の八重奏の数であるa SIGNED-SHORTはb.をさばきます。a. aはタイプに自然言語を評価します、以下の分野の八重奏の数であるc.a SIGNED-SHORT、タイプtextWithoutLanguageのd.a価値。 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.
The length of a nameWithLanguage value MUST be
4 + the value of field a + the value of field c.
4つの分野のnameWithLanguage OCTET-STRINGの成ること: 以下の八重奏の数であるa SIGNED-SHORTはb.をさばきます。a. aは自然言語(タイプnameWithoutLanguageの以下の分野d.a価値において、八重奏の数であるc.a SIGNED-SHORT)をタイプに評価します。 nameWithLanguage価値の長さは+ 4が分野a+の値であったならそうしなければなりません。分野cの値。
charset, US-ASCII-STRING. naturalLanguage, mimeMediaType, keyword, uri, and uriScheme
charset、米国ASCII STRING. naturalLanguage、mimeMediaType、キーワード、uri、およびuriScheme
Herriot, et al. Standards Track [Page 17] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[17ページ]: コード化と輸送2000年9月
Syntax of Attribute Encoding Value
値をコード化する属性の構文
boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is
'true'.
0×00が'誤ってい'て、0×01が'本当である'論理演算子SIGNED-BYTE。
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
1903 [RFC1903].
コンテンツがRFC1903[RFC1903]で"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
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は上限を含んでいます。
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 attribute syntax type of the value determines its encoding and the value of its "value-tag".
価値の属性構文タイプはコード化と「値タグ」の値を決定します。
3.10 Data
3.10 データ
The "data" field MUST include any data required by the operation
「データ」分野は操作で必要であるデータを含まなければなりません。
4. Encoding of Transport Layer
4. トランスポート層のコード化
HTTP/1.1 [RFC2616] is the transport layer for this protocol.
HTTP/1.1[RFC2616]はこのプロトコルのためのトランスポート層です。
The operation layer has been designed with the assumption that the transport layer contains the following information:
操作層はトランスポート層が以下の情報を含んでいるという仮定で設計されています:
Herriot, et al. Standards Track [Page 18] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[18ページ]: コード化と輸送2000年9月
- 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.
IANAの上のプリンタ実装サポートHTTPがWell Known Port631(IPPデフォルトポート)を割り当てたのは、REQUIREDです、プリンタ実装がまた、ある他のポートの上でHTTPをサポートするかもしれませんが。
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 [RFC2616]. A printer (server) implementation MUST adhere the rules for an origin server described for HTTP1.1 [RFC2616].
それぞれのHTTP操作は要求URIが操作のオブジェクト目標であり、各要求と応答におけるメッセージ本体の「コンテントタイプ」が「アプリケーション/ipp」であるに違いないポストメソッドを使用しなければなりません。 メッセージ本体は、操作層を含まなければならなくて、「コード化の構文」というセクション3.2で説明された構文を持たなければなりません。 クライアント実装はHTTP1.1[RFC2616]のために説明されたクライアントのために規則を固く守らなければなりません。 プリンタ(サーバ)実装はHTTP1.1[RFC2616]のために説明された発生源サーバのための規則を付着させなければなりません。
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 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 [RFC2616].
IPPサーバは受信するという各要求のための応答を送ります。 IPPサーバが誤りを検出するなら、全体の要求を読む前にそれは応答を送るかもしれません。 IPPサーバのHTTP層が、首尾よくHTTPヘッダを処理するのを完了するなら、中間的応答を送るかもしれません、「100は続きます」などのように、IPP応答を送る前のIPPデータなしで。 クライアントはIPPサーバからそのようなさまざまな応答を予想しなければなりません。HTTP/1.1の詳細に関して、HTTPドキュメント[RFC2616]を参照してください。
An HTTP server MUST support chunking for IPP requests, and an IPP client MUST support chunking for IPP responses according to HTTP/1.1 [RFC2616]. Note: this rule causes a conflict with non-compliant implementations of HTTP/1.1 that don't support chunking for POST methods, and this rule may cause a conflict with non-compliant implementations of HTTP/1.1 that don't support chunking for CGI scripts.
HTTPサーバはIPP要求のための分魂化をサポートしなければなりません、そして、HTTP/1.1[RFC2616]に従って、IPPクライアントはIPP応答のための分魂化をサポートしなければなりません。 以下に注意してください。 この規則はポストメソッドのための分魂化をサポートしないHTTP/1.1の不従順な実装との闘争を引き起こします、そして、この規則はCGIスクリプトのための分魂化をサポートしないHTTP/1.1の不従順な実装との闘争を引き起こすかもしれません。
4.1 Printer-uri and job-uri
4.1 プリンタ-uriと仕事-uri
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. 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がこのドキュメントの残りの間中使用されますが、あらゆるURLがURIの専門化しているフォームであるので、用法がまた、URLの、より特定の概念をカバーすることを意図します。
Herriot, et al. Standards Track [Page 19] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[19ページ]: コード化と輸送2000年9月
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 and are called printer-uri and job-uri. 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:
いくつかの操作要素が二度コード化されます、HTTP Request-線ともう一度のアプリケーション/ipp実体におけるREQUIRED操作属性としての要求URIとしての一度。 これらの属性は、操作のための目標URIであり、プリンタ-uriと仕事-uriと呼ばれます。 以下に注意してください。 目標URIは同じIPPオブジェクトに参照をつける操作に二度含まれていますが、2つのURIが文字通り同じである必要はありません。 1つは相対的なURIであるかもしれません、そして、もう片方が絶対URIであるかもしれません。 HTTP/1.1は、クライアントに絶対URIよりむしろ相対的なURIを生成して、送らせます。 相対的なURIは、HTTPサーバの範囲とリソースを同一視しますが、体系、ホストまたはポートを含んでいません。 以下の声明はURLがIPPに関するマッピングでどうHTTP/1.1に使用されるべきであるかを特徴付けます:
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. However, a Printer NEED NOT
verify that the two URLs reference the same IPP object, and
NEED NOT take any action if it determines the two URLs to be
different.
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オブジェクトに参照をつけなければなりません。 しかしながら、Printerは同じ2URL参照IPPが反対することを確かめる必要はなくて、2つのURLが異なっていることを決定するなら、少しの行動も取る必要はありません。 3. HTTP層のURIは、相対的であるか、または絶対であり、HTTPサーバによって使用されます。そのHTTPサーバに比例してHTTP要求を正しいリソースに発送して、HTTPサーバは操作要求の中でURIを意識している必要はありません。 4. HTTPサーバリソースがいったんHTTP要求を処理し始めると、HTTP URI(相対的なURLのためのHTTPサーバの文脈に使用する)か操作要求の中のURIから適切なIPP Printerオブジェクトの参照を得るかもしれません。 選択は実装まで達しています。 5. HTTP URIは、相対的であるか、または絶対である場合がありますが、操作における目標URIは絶対URIであるに違いありません。
5. IPP URL Scheme
5. IPP URL体系
The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL that identifies either an IPP printer object or an IPP job object. The IPP attributes using the 'ipp' scheme are specified below. Because the HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP headers. The mapping is simple because the 'ipp' scheme implies all of the same protocol semantics as that of the 'http' scheme
IPP/1.1ドキュメントはIPPプリンタオブジェクトかIPP仕事のオブジェクトのどちらかを特定する1つのURLの値と新しい体系'ipp'を定義します。 'ipp'体系を使用するIPP属性は以下で指定されます。 HTTP層が'ipp'体系をサポートしないので、クライアントは、'ipp'URLを'http'URLに写像しなければならなくて、次に、Request-線とHTTPヘッダを構成するためにHTTP[RFC2616][RFC2617]規則に従います。 'ipp'体系が'http'体系のものと同じプロトコル意味論のすべてを含意するので、マッピングは簡単です。
Herriot, et al. Standards Track [Page 20] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[20ページ]: コード化と輸送2000年9月
[RFC2616], except that it represents a print service and the implicit (default) port number that clients use to connect to a server is port 631.
[RFC2616]、印刷サービスと暗黙の(デフォルト)を表すのを除いて、クライアントがサーバに接続するのに使用するポートナンバーはポート631です。
In the remainder of this section the term 'ipp-URL' means a URL whose scheme is 'ipp' and whose implicit (default) port is 631. The term 'http-URL' means a URL whose scheme is 'http', and the term 'https- URL' means a URL whose scheme is 'https',
このセクションの残りでは、'ipp-URL'という用語は体系が'ipp'であり、内在している(デフォルト)ポートが631であるURLを意味します。 'http-URL'という用語は'http'がだれの体系であるかというURLを意味します、そして、'https URL'という用語は'https'がだれの体系であるかというURLを意味します。
A client and an IPP object (i.e. the server) MUST support the ipp-URL
value in the following IPP attributes.
job attributes:
job-uri
job-printer-uri
printer attributes:
printer-uri-supported
operation attributes:
job-uri
printer-uri
Each of the above attributes identifies a printer or job object. The
ipp-URL is intended as the value of the attributes in this list, and
for no other attributes. All of these attributes have a syntax type
of 'uri', but there are attributes with a syntax type of 'uri' that
do not use the 'ipp' scheme, e.g. 'job-more-info'.
(すなわち、サーバ)がipp-URLをサポートしなければならないクライアントとIPPオブジェクトは以下のIPP属性で. 仕事の属性を評価します: 仕事-uri仕事のプリンタuriプリンタ属性: uriが支えたプリンタ操作属性: 上の属性の仕事-uriプリンタ-uri Eachはプリンタか仕事のオブジェクトを特定します。 ipp-URLは他のどんな属性のためにもこのリストの属性の値として意図しません。 これらの属性のすべてには、'uri'の構文タイプがありますが、'ipp'体系を使用しない'uri'の構文タイプ、例えば、'仕事詳しい情報'がある属性があります。
If a printer registers its URL with a directory service, the printer MUST register an ipp-URL.
プリンタがディレクトリサービスにURLを登録するなら、プリンタはipp-URLを登録しなければなりません。
User interfaces are beyond the scope of this document. But if software exposes the ipp-URL values of any of the above five attributes to a human user, it is REQUIRED that the human see the ipp-URL as is.
ユーザインタフェースはこのドキュメントの範囲を超えています。 しかし、ソフトウェアが、ipp-URLが上の5つの属性のどれかの値であると人間のユーザに暴露するなら、人間が、ipp-URLがそのままであることを見るのは、REQUIREDです。
When a client sends a request, it MUST convert a target ipp-URL to a target http-URL for the HTTP layer according to the following rules:
クライアントが要求を送るとき、以下の規則に従って、HTTP層のために目標ipp-URLを目標http-URLに変換しなければなりません:
1. change the 'ipp' scheme to 'http'
2. add an explicit port 631 if the URL does not contain an
explicit port. Note: port 631 is the IANA assigned Well Known
Port for the 'ipp' scheme.
1. 'ipp'体系を'http'2に変えてください。URLが明白なポートを含まないなら、明白なポート631を加えてください。 以下に注意してください。 ポート631はWell Known Portが'ipp'体系のために割り当てられたIANAです。
The client MUST use the target http-URL in both the HTTP Request- Line and HTTP headers, as specified by HTTP [RFC2616] [RFC2617] . However, the client MUST use the target ipp-URL for the value of the "printer-uri" or "job-uri" operation attribute within the application/ipp body of the request. The server MUST use the ipp-URL
クライアントはHTTP[RFC2616][RFC2617]によるRequestが裏打ちするHTTPと指定されるとしてのHTTPヘッダの両方で目標http-URLを使用しなければなりません。しかしながら、クライアントは「プリンタ-uri」か「仕事-uri」操作属性の値に要求のアプリケーション/ippボディーの中で目標ipp-URLを使用しなければなりません。 サーバはipp-URLを使用しなければなりません。
Herriot, et al. Standards Track [Page 21] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[21ページ]: コード化と輸送2000年9月
for the value of the "printer-uri", "job-uri" or "printer-uri- supported" attributes within the application/ipp body of the response.
応答のアプリケーション/ippボディーの中の「プリンタ-uri」、「仕事-uri」または「プリンタ-uriによってサポートしている」属性の値のために。
For example, when an IPP client sends a request directly (i.e. no proxy) to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP connection to port 631 (the ipp implicit port) on the host "myhost.com" and sends the following data:
例えば、IPPクライアントが直接(すなわち、プロキシがない)「ipp://myhost.com/myprinter/myqueue」というipp-URLに要求を送るとき、631(ippの内在しているポート)をホスト"myhost.com"に移植するためにTCP接続を開いて、以下のデータを送ります:
POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body)
...
/myprinter/myqueue HTTP/1.1ホストを掲示してください: myhost.com: 631文書内容: ipp Transferをアプリケーション/コード化しています: chunkedしました… 「プリンタ-uri」「ipp://myhost.com/myprinter/myqueue」(アプリケーション/ippメッセージボディーでは、コード化されます)…
As another example, when an IPP client sends the same request as above via a proxy "myproxy.com", it opens a TCP connection to the proxy port 8080 on the proxy host "myproxy.com" and sends the following data:
別の例として、IPPクライアントがプロキシ"myproxy.com"を通して上記の同じ要求を送るとき、プロキシホスト"myproxy.com"のプロキシポート8080にTCP接続を開いて、以下のデータを送ります:
POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
Host: myhost.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body)
...
http://myhost.com:631/myprinter/myqueue HTTP/1.1ホストを掲示してください: myhost.com: 631文書内容: ipp Transferをアプリケーション/コード化しています: chunkedしました… 「プリンタ-uri」「ipp://myhost.com/myprinter/myqueue」(アプリケーション/ippメッセージボディーでは、コード化されます)…
The proxy then connects to the IPP origin server with headers that are the same as the "no-proxy" example above.
そして、上のヘッダーが「プロキシがありません」の例と同じ状態でプロキシはIPP発生源サーバに接続します。
6. IANA Considerations
6. IANA問題
This section describes the procedures for allocating encoding for the following IETF standards track extensions and vendor extensions to the IPP/1.1 Encoding and Transport document:
このセクションは以下のIETFのために標準化過程拡大をコード化して、ベンダー拡大をIPP/1.1EncodingとTransportドキュメントに割り当てるための手順について説明します:
1. attribute syntaxes - see [RFC2911] section 6.3
2. attribute groups - see [RFC2911] section 6.5
3. out-of-band attribute values - see [RFC2911] section 6.7
1. 構文を結果と考えてください--[RFC2911]セクション6.3 2つの属性グループ--3 バンドの外で[RFC2911]セクション6.5を見るのは値を結果と考えます--[RFC2911]セクション6.7を見るように確実にしてください。
Herriot, et al. Standards Track [Page 22] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[22ページ]: コード化と輸送2000年9月
These extensions follow the "type2" registration procedures defined in [RFC2911] section 6. Extensions registered for use with IPP/1.1 are OPTIONAL for client and IPP object conformance to the IPP/1.1 Encoding and Transport document.
これらの拡大は「[RFC2911]セクション6で定義されたtype2"登録手順」に続きます。 使用のためにIPP/1.1に示された拡張子は、IPP/1.1EncodingとTransportドキュメントへのクライアントのためのOPTIONALとIPPオブジェクト順応です。
These extension procedures are aligned with the guidelines as set forth by the IESG [IANA-CON]. The [RFC2911] Section 11 describes how to propose new registrations for consideration. IANA will reject registration proposals that leave out required information or do not follow the appropriate format described in [RFC2911] Section 11. The IPP/1.1 Encoding and Transport document may also be extended by an appropriate RFC that specifies any of the above extensions.
IESG[IANA-CON]によって詳しく説明されるようにこれらの拡張の手順はガイドラインに並べられます。 [RFC2911]セクション11は考慮のための新しい登録証明書を提案する方法を説明します。 IANAは必須情報を省く登録提案を拒絶するか、または[RFC2911]セクション11で説明された適切な形式に続きません。 また、IPP/1.1EncodingとTransportドキュメントは上の拡大のいずれも指定する適切なRFCによって広げられるかもしれません。
7. Internationalization Considerations
7. 国際化問題
See the section on "Internationalization Considerations" in the document "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] for information on internationalization. This document adds no additional issues.
「プロトコル/1.1に以下を印刷するインターネット」というドキュメントの「国際化問題」のセクションを見てください。 国際化の情報のための「モデルとSemantics」[RFC2911。] このドキュメントは追加設定を全く加えません。
8. Security Considerations
8. セキュリティ問題
The IPP Model and Semantics document [RFC2911] discusses high level security requirements (Client Authentication, Server Authentication and Operation Privacy). Client Authentication is the mechanism by which the client proves its identity to the server in a secure manner. Server Authentication is the mechanism by which the server proves its identity to the client in a secure manner. Operation Privacy is defined as a mechanism for protecting operations from eavesdropping.
高レベルセキュリティ要件(クライアントAuthentication、サーバー証明、およびOperation Privacy)について議論します[RFC2911]IPP ModelとSemanticsが、ドキュメントである。 クライアントAuthenticationはクライアントが安全な方法でサーバへのアイデンティティを立証するメカニズムです。 サーバー証明はサーバが安全な方法でクライアントへのアイデンティティを立証するメカニズムです。 操作Privacyは盗聴から操作を保護するためのメカニズムと定義されます。
8.1 Security Conformance Requirements
8.1 セキュリティ順応要件
This section defines the security requirements for IPP clients and IPP objects.
このセクションはIPPクライアントとIPPオブジェクトのためのセキュリティ要件を定義します。
8.1.1 Digest Authentication
8.1.1 ダイジェスト認証
IPP clients MUST support:
IPPクライアントは以下をサポートしなければなりません。
Digest Authentication [RFC2617].
認証[RFC2617]を読みこなしてください。
MD5 and MD5-sess MUST be implemented and supported.
MD5とMD5-sessを実装されて、サポートしなければなりません。
The Message Integrity feature NEED NOT be used.
Message Integrityの特徴は使用される必要はありません。
Herriot, et al. Standards Track [Page 23] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[23ページ]: コード化と輸送2000年9月
IPP Printers SHOULD support:
IPP Printers SHOULDサポート:
Digest Authentication [RFC2617].
認証[RFC2617]を読みこなしてください。
MD5 and MD5-sess MUST be implemented and supported.
MD5とMD5-sessを実装されて、サポートしなければなりません。
The Message Integrity feature NEED NOT be used.
Message Integrityの特徴は使用される必要はありません。
The reasons that IPP Printers SHOULD (rather than MUST) support Digest Authentication are:
そのIPP Printers SHOULDが推論する、(むしろ、)、サポートDigest Authenticationは以下の通りであるに違いありません。
1. While Client Authentication is important, there is a certain class
of printer devices where it does not make sense. Specifically, a
low-end device with limited ROM space and low paper throughput may
not need Client Authentication. This class of device typically
requires firmware designers to make trade-offs between protocols
and functionality to arrive at the lowest-cost solution possible.
Factored into the designer's decisions is not just the size of the
code, but also the testing, maintenance, usefulness, and time-to-
market impact for each feature delivered to the customer. Forcing
such low-end devices to provide security in order to claim IPP/1.1
conformance would not make business sense and could potentially
stall the adoption of the standard.
1. Client Authenticationは重要ですが、あるクラスのプリンタデバイスがそれが理解できないところにあります。 明確に、限られたROMスペースと少ない紙のスループットがあるローエンドデバイスはClient Authenticationを必要としないかもしれません。 このクラスのデバイスは、ファームウェアデザイナーが最も低い費用ソリューションに到着するプロトコルと機能性の間のトレードオフを可能にするのを通常必要とします。 デザイナーの決定が要因として考慮されているのは、コードのサイズだけではなく、テスト(顧客に提供された各特徴のためのメインテナンス、有用性、および時間から市場への影響)でもあります。 そのようなローエンドデバイスにIPP/1.1が順応であると主張するためにセキュリティを提供させると、ビジネスセンスが作られていなくて、規格の採用は潜在的に遅らせられるかもしれません。
2. Print devices that have high-volume throughput and have available
ROM space have a compelling argument to provide support for Client
Authentication that safeguards the device from unauthorized
access. These devices are prone to a high loss of consumables and
paper if unauthorized access should occur.
2. 大容量スループットを持っていて、利用可能なROMスペースが不正アクセスからデバイスを保護しているClient Authenticationのサポートを提供するいやとは言いにくい話を持っているデバイスを印刷してください。 これらのデバイスは消耗品の高い損失に傾向があります、そして、紙は不正アクセスであるなら現れるはずです。
8.1.2 Transport Layer Security (TLS)
8.1.2 トランスポート層セキュリティ(TLS)
IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for Server Authentication and Operation Privacy. IPP Printers MAY also support TLS for Client Authentication. If an IPP Printer supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL. An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 [RFC2617]) for Client Authentication if the channel is secure. TLS with the above mandated cipher suite can provide such a secure channel.
IPP Printers SHOULDはサーバー証明とOperation Privacyのために、Transport Layer Security(TLS)[RFC2246]をサポートします。 また、IPP PrintersはClient AuthenticationのためにTLSをサポートするかもしれません。 IPP PrinterがTLSをサポートするなら、RFC2246[RFC2246]によって強制されるようにそれはTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートを支えなければなりません。 他のすべての暗号スイートがOPTIONALです。 チャンネルが安全であるなら、IPP PrinterはClient Authenticationのために、Basic Authentication(HTTP/1.1[RFC2617]では、説明される)をサポートするかもしれません。 上の強制された暗号スイートがあるTLSはそのような安全なチャンネルを提供できます。
If a IPP client supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL.
IPPクライアントがTLSをサポートするなら、RFC2246[RFC2246]によって強制されるようにそれはTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートを支えなければなりません。 他のすべての暗号スイートがOPTIONALです。
Herriot, et al. Standards Track [Page 24] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[24ページ]: コード化と輸送2000年9月
The IPP Model and Semantics document defines two printer attributes
("uri-authentication-supported" and "uri-security-supported") that
the client can use to discover the security policy of a printer. That
document also outlines IPP-specific security considerations and
should be the primary reference for security implications with regard
to the IPP protocol itself. For backward compatibility with IPP
version 1.0, IPP clients and printers may also support SSL3 [ssl].
This is in addition to the security required in this document.
クライアントがプリンタの安全保障政策を発見するのに使用できる2つのプリンタ属性(「認証がサポートしたuri」と「セキュリティがサポートしたuri」)を定義しますIPP ModelとSemanticsが、ドキュメントである。 そのドキュメントも、IPP特有のセキュリティ問題について概説して、IPPプロトコル自体に関するセキュリティ含意のプライマリ参照であるべきです。 また、IPPバージョン1.0との後方の互換性のために、IPPクライアントとプリンタは、SSL3が[ssl]であるとサポートするかもしれません。 これは本書では必要であるセキュリティに加えています。
8.2 Using IPP with TLS
8.2 TLSとIPPを使用すること。
IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817]. An initial IPP request never uses TLS. The client requests a secure TLS connection by using the HTTP "Upgrade" header, while the server agrees in the HTTP response. The switch to TLS occurs either because the server grants the client's request to upgrade to TLS, or a server asks to switch to TLS in its response. Secure communication begins with a server's response to switch to TLS.
IPP/1.1は「HTTP/1.1インチのメカニズム[RFC2817]の中のTLSにアップグレードすること」を使用します。 初期のIPP要求はTLSを決して使用しません。 クライアントはHTTP「アップグレード」ヘッダーを使用することによって、安全なTLS接続を要求します、サーバはHTTP応答で同意しますが。 サーバがTLSにアップグレードするというクライアントの要求を承諾するので、TLSへのスイッチが現れるか、またはサーバは、応答でTLSに切り替わるように頼みます。 安全なコミュニケーションはサーバの応答でTLSに切り替わり始めます。
9. Interoperability with IPP/1.0 Implementations
9. IPP/1.0実装がある相互運用性
It is beyond the scope of this specification to mandate conformance with previous versions. IPP/1.1 was deliberately designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification (1999), we would expect IPP/1.1 Printer implementations to:
それは、旧バージョンがある順応を強制するためにこの仕様の範囲を超えています。 しかしながら、IPP/1.1は、旧バージョンをサポートするのを簡単にするように故意に設計されました。 この仕様(1999)を構成する時点でそれに注意する価値がある、私たちは以下のこととIPP/1.1Printer実装は予想するでしょう。
understand any valid request in the format of IPP/1.0, or 1.1;
IPP/1.0、または1.1の形式であらゆる有効な要求を理解してください。
respond appropriately with a response containing the same
"version-number" parameter value used by the client in the
request.
応答が要求でクライアントによって使用された同じ「バージョン番号」パラメタ価値を含んでいて、適切に応じてください。
And we would expect IPP/1.1 clients to:
そして、私たちは、以下のこととIPP/1.1クライアントは予想するでしょう。
understand any valid response in the format of IPP/1.0, or 1.1.
IPP/1.0、または1.1の形式であらゆる有効回答を理解してください。
9.1 The "version-number" Parameter
9.1 「バージョン番号」パラメタ
The following are rules regarding the "version-number" parameter (see section 3.3):
↓これは「バージョン番号」パラメタに関する規則(セクション3.3を見る)です:
1. Clients MUST send requests containing a "version-number"
parameter with a '1.1' value and SHOULD try supplying alternate
version numbers if they receive a 'server-error-version-not-
supported' error return in a response.
1. クライアントは'1.1'値がある「バージョン番号」パラメタを含む要求を送らなければなりません、そして、応答における'サーバ誤りバージョンでサポートしていない'誤りリターンを受けるなら、SHOULDは代替のバージョン番号を供給してみます。
Herriot, et al. Standards Track [Page 25] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[25ページ]: コード化と輸送2000年9月
2. IPP objects MUST accept requests containing a "version-number"
parameter with a '1.1' value (or reject the request for reasons
other than 'server-error-version-not-supported').
2. IPPオブジェクトは'1.1'値で「バージョン番号」パラメタを含む要求を受け入れなければなりません('誤りバージョンがサポートしなかったサーバ'を除いた理由に関する要求を拒絶してください)。
3. It is recommended that IPP objects accept any request with the
major version '1' (or reject the request for reasons other than
'server-error-version-not-supported'). See [RFC2911]
"versions" sub-section.
3. IPPオブジェクトが主要なバージョン'1'でどんな要求も受け入れるのは('誤りバージョンがサポートしなかったサーバ'を除いた理由に関する要求を拒絶してください)、お勧めです。 [RFC2911]「バージョン」小区分を見てください。
4. In any case, security MUST NOT be compromised when a client
supplies a lower "version-number" parameter in a request. For
example, if an IPP/1.1 conforming Printer object accepts
version '1.0' requests and is configured to enforce Digest
Authentication, it MUST do the same for a version '1.0'
request.
4. どのような場合でも、クライアントが要求における低い「バージョン番号」パラメタを提供するとき、セキュリティに感染してはいけません。 例えば、IPP/1.1の従っているPrinterオブジェクトがバージョン'1.0' 要求を受け入れて、Digest Authenticationを実施するために構成されるなら、それはバージョン'1.0'要求のために同じようにしなければなりません。
9.2 Security and URL Schemes
9.2 セキュリティとURL体系
The following are rules regarding security, the "version-number" parameter, and the URL scheme supplied in target attributes and responses:
↓これは、セキュリティに関する規則と、「バージョン番号」パラメタと、目標属性と応答で提供されたURL体系です:
1. When a client supplies a request, the "printer-uri" or "job-
uri" target operation attribute MUST have the same scheme as
that indicated in one of the values of the "printer-uri-
supported" Printer attribute.
1. クライアントが要求を提供するとき、「プリンタ-uri」か「仕事のuri」目標操作属性で、それが「プリンタ-uriによってサポートしている」Printer属性の値の1つで示したように同じくらいは計画されなければなりません。
2. When the server returns the "job-printer-uri" or "job-uri" Job
Description attributes, it SHOULD return the same scheme
('ipp', 'https', 'http', etc.) that the client supplied in the
"printer-uri" or "job-uri" target operation attributes in the
Get-Job-Attributes or Get-Jobs request, rather than the scheme
used when the job was created. However, when a client requests
job attributes using the Get-Job-Attributes or Get-Jobs
operations, the jobs and job attributes that the server returns
depends on: (1) the security in effect when the job was
created, (2) the security in effect in the query request, and
(3) the security policy in force.
2. サーバが「仕事のプリンタuri」か「仕事-uri」Job記述属性を返して、それがSHOULDリターンのクライアントが「プリンタ-uri」で供給した同じ体系('ipp'、'https'、'http'など)か「仕事-uri」であるという雇用が創り出されたとき使用される体系よりむしろGet仕事の属性かGet-仕事の要求における目標操作属性であるときに。 しかしながら、クライアントが仕事の属性を要求するとき、サーバが返すGet仕事の属性かGet-仕事の操作、仕事、および仕事の属性を使用するのは以下によります。 (1) 仕事であるなら有効なセキュリティは作成されました、事実上、(2) セキュリティが質問要求、および(3)の安全保障政策です。大挙して。
3. It is recommended that if a server registers a non-secure ipp-
URL with a directory service (see [RFC2911] "Generic Directory
Schema" Appendix), then it also register an http-URL for
interoperability with IPP/1.0 clients (see section 9).
3. また、サーバが非安全なipp URLをディレクトリサービスに登録するなら([RFC2911]「ジェネリックディレクトリ図式」Appendixを見てください)相互運用性のためにhttp-URLをIPP/1.0クライアントに登録するのは(セクション9を見てください)、お勧めです。
4. In any case, security MUST NOT be compromised when a client
supplies an 'http' or other non-secure URL scheme in the target
"printer-uri" and "job-uri" operation attributes in a request.
4. どのような場合でも、クライアントが要求における目標「プリンタ-uri」と「仕事-uri」操作属性における'http'か他の非安全なURL体系を供給するとき、セキュリティに感染してはいけません。
Herriot, et al. Standards Track [Page 26] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[26ページ]: コード化と輸送2000年9月
10. References
10. 参照
[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- はセットします。
[IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[IANA-まやかし] Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1:
Implementer's Guide", Work in Progress.
[ipp-iig] ヘイスティングズ、トム、他、「プロトコル/1.1に以下を印刷するインターネット」 「Implementerのガイド」、進行中で、働いてください。
[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, S., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October, 1989.
[RFC1123]ブレーデン、S.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月、1989
[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon
Protocol", RFC 1179, August 1990.
[RFC1179]マクラフリン、L.III、(エディタ)、「ラインプリンタデーモンプロトコル」、RFC1179、1990年8月。
[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月。
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Textual Conventions for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC1903] ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための原文のコンベンションは(SNMPv2)について議定書の中で述べます」、RFC1903、1996年1月。
[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月。
Herriot, et al. Standards Track [Page 27] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[27ページ]: コード化と輸送2000年9月
[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)は4を分けます」。 「登録手順」、BCP13、RFC2048、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2184, August 1997.
解放された[RFC2184]、N.、およびK.ムーア、「パラメタ値とコード化されたWord拡大をまねてください」 「文字コード、言語、および続刊」、RFC2184、8月1997日
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
全体的に見て[RFC2234]クロッカー、D.、およびP.、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246.
January 1999.
[RFC2246]DierksとT.とC.アレン、「TLSプロトコル」RFC2246。 1999年1月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.0: Encoding and Transport",
RFC 2565, April 1999.
[RFC2565] エリオとR.とバトラーとS.とムーアとP.とR.ターナー、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2566] deBryとR.とヘイスティングズとT.とエリオとR.とイサクソンとS.とP.パウエル、「プロトコル/1.0に以下を印刷するインターネット」 「モデルと意味論」、RFC2566、4月1999日
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC2567, April 1999.
[RFC2567]ライト、D.、「インターネット印刷プロトコルのデザイン目標」、RFC2567、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月。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2617] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
Herriot, et al. Standards Track [Page 28] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[28ページ]: コード化と輸送2000年9月
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[RFC2817]Khare、R.、およびS.ローレンス。
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC 2910, September 2000.
[RFC2910] エリオとR.とバトラーとS.とムーアとP.とターナーとR.とJ.Wenn、「プロトコル/1.1に以下を印刷するインターネット」 「コード化と輸送」、RFC2910、9月2000日
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC 2911, September 2000.
[RFC2911] ヘイスティングズとT.とエリオとR.とdeBryとR.とイサクソンとS.とP.パウエル、「プロトコル/1.1に以下を印刷するインターネット」 「モデルと意味論」、RFC2911、9月2000日
[SSL] Netscape, The SSL Protocol, Version 3, (Text version
3.02), November 1996.
[SSL]Netscape、SSLプロトコル、バージョン3、(テキストバージョン3.02)、1996年11月。
11. Authors' Addresses
11. 作者のアドレス
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: robert.herriot@pahv.xerox.com
以下に電話をしてください。 650-813-7696 Fax: 650-813-6860 メールしてください: robert.herriot@pahv.xerox.com
Sylvan Butler Hewlett-Packard 11311 Chinden Blvd. Boise, ID 83714
森のバトラーヒューレット・パッカード11311Chinden Blvd. ボイシ、ID 83714
Phone: 208-396-6000 Fax: 208-396-3457 EMail: sbutler@boi.hp.com
以下に電話をしてください。 208-396-6000 Fax: 208-396-3457 メールしてください: sbutler@boi.hp.com
Paul Moore Peerless Systems Networking 10900 NE 8th St #900 Bellevue, WA 98004
ポール・ムーア・無比のSystemsネットワーク10900のNeの第8通り#900ベルビュー、ワシントン 98004
Phone: 425-462-5852 EMail: pmoore@peerless.com
以下に電話をしてください。 425-462-5852 メールしてください: pmoore@peerless.com
Herriot, et al. Standards Track [Page 29] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[29ページ]: コード化と輸送2000年9月
Randy Turner 2Wire, Inc. 694 Tasman Dr. Milpitas, CA 95035
ミルピタス、ランディターナー2Wire Inc.694タスマン博士カリフォルニア 95035
Phone: 408-546-1273
以下に電話をしてください。 408-546-1273
John Wenn Xerox Corporation 737 Hawaii St El Segundo, CA 90245
ジョンWennゼロックス社737のハワイStエルセガンド、カリフォルニア 90245
Phone: 310-333-5764 Fax: 310-333-5514 EMail: jwenn@cp10.es.xerox.com
以下に電話をしてください。 310-333-5764 Fax: 310-333-5514 メールしてください: jwenn@cp10.es.xerox.com
IPP Web Page: http://www.pwg.org/ipp/ IPP Mailing List: ipp@pwg.org
IPPウェブページ: http://www.pwg.org/ipp/ IPPメーリングリスト: ipp@pwg.org
To subscribe to the ipp mailing list, send the following email:
1) send it to majordomo@pwg.org
2) leave the subject line blank
3) put the following two lines in the message body:
subscribe ipp
end
ippメーリングリストに加入するには、以下のメールを送ってください: 1) 2が)3が)以下の2つの系列をメッセージ本体に入れる件名空白を出る majordomo@pwg.org にそれを送ってください: ippエンドを申し込んでください。
Herriot, et al. Standards Track [Page 30] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[30ページ]: コード化と輸送2000年9月
12. Other Participants:
12. 他の関係者:
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Information Systems
チャック・アダムス--テクトロニクスのShivaunオルブライト--hpステファン・アンデション--枢軸ジェフ・バーネット--IBMのロンバーグマン・--日立工機のイメージデニス・カーニー--IBMシステムキース・カーター--IBMのアンジェロのカルーソ--ゼロックスのラジェッシュ・Chawla--ナンシー・チェンを計算するTR--Okidataソリューションジョッシュ・コーエン--マイクロソフトのジェフ・コープランド--QMSアンディ・ディヴィッドソン--テクトロニクスロジャーdeBry--IBMのMaulikデセイ--Aucoメイブリー・ドージア--QMSリー・ファレル--教会法情報Satoshi Fujitami--リコーシステムスティーブ・ゲーベルト(IBMのスー・グリーソン)Digitalのチャールズ・ゴードン--Osicom; ブライアン・グリムショー--アップルジェリーHadsell--IBMのリチャード・ハート--デジタルトム・ヘイスティングズ--ゼロックスHenrikホルスト--I-データスティーブン・Holmstead Zhi-Hongホアン--Zenographicsスコット・イサクソン--ノベルBabek Jahromi--マイクロソフトのSwenジョンソン--ゼロックスのデヴィッド・ケラーマン--Northlake; ロバート・クライン--TrueSpectraチャールズ・コン--ソフトウェアパナソニックのカール・クーグラー--IBMのデーヴ・Kuntz--ヒューレット・パッカード敬美Kurono--兄弟リック・ランドー(デジタルスコット・ローレンス)Agranot Systemsグレッグ・ルクレア--エプソンのドワイト・ルイス--Lexmarkハリー・ルイス--IBMのトニー・ライアo - 生き生きとしたイメージロイLomicka--デジタルピートLoya--hpレイ・ルッツ--Cognisysマイク・マッケイ--ノベルInc.デヴィッドManchala--ゼロックスカール-宇野Manros(ゼロックスのジェイ・マーチン)はスタン・マッコネールの下線を引きます--ゼロックスラリーMasinter--ゼロックスサンドラMatts--ヒューレットのパッカードのピーター・ミハウェック--Shinesoftイラ・マクドナルド--高い北の株式会社; マイクMoldovan--G3新星Tetsuya森田--リコーYuichi丹羽--リコーパットNogay--IBMロンノートン--Printronicsユーゴー・パラ、ノベルボブ五旬節(ヒューレット・パッカードパトリック・パウエル)AstartジェフRackowitz--Intermec技術エリック--無比のロブ・ローズ--無作為のインテルザビエルライリー--ゼロックスのゲーリー・ロバーツ--リコーのデヴィッド・ローチ--ユニシスのスチュアート・ローリー--京セラのYuji佐々木--日本のコンピュータリチャード・シュナイダー--エプソン産業クリスSchoff--hp Katsuaki Sekiguchi--教会法情報システム
Herriot, et al. Standards Track [Page 31] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[31ページ]: コード化と輸送2000年9月
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.
Systems
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Canon Information Lloyd Young - Lexmark
Systems
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang - Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon Information
Systems
ボブSetterbo--AdobeゲイルSonger--無比のHideki田中--大砲情報デボンテイラー--ノベルInc.システムマイクTimperman--Lexmark篤Uchino--エプソンのShigeru上田--教会法ボブフォンAndel--急速なソフトウェアウィリアム・ワグナー--NetSilicon/dpiジム・ウォーカー--研究室のトレバー・ウェルズを織り込むというヒューレットのパッカードのクレイグが削るDAZELクリスWellens--ロブが削る鋭い研究室--ノベルInc; 碧玉ウォン--Xionicsドン・ライト--Lexmarkマイケル・ウー--ハイデルベルグのデジタルリックYardumian--ゼロックスマイケルYeung--教会法情報ロイド・ヤング--Lexmarkシステムユキ・篤--京セラピーターZehler--ゼロックスのウィリアム・チャン--教会法情報フランク・チャオ--パナソニックシステムスティーブZilles--AdobeロブZirnstein--教会法情報システム
Herriot, et al. Standards Track [Page 32] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[32ページ]: コード化と輸送2000年9月
13. Appendix A: Protocol Examples
13. 付録A: プロトコルの例
13.1 Print-Job Request
13.1 印刷仕事の要求
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.
↓これは指定されたジョブ名によるPrint-仕事の要求、コピー、および側に関する例です。 「ipp属性信義」属性は、「コピー」か「側」属性がサポートされないか、またはそれらの値がサポートされないと印刷要求が失敗するように、'本当に'設定されます。
Octets Symbolic Value Protocol field
八重奏Symbolic Valueプロトコル分野
0x0101 1.1 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- name
natural- attributes-natural-language
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x0015 value-length
ipp://forest/ printer pinetree value
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
0x0016 name-length
ipp-attribute- ipp-attribute-fidelity name
fidelity
0x0001 value-length
0x01 true value
0x0101 1.1 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- name natural- attributes-natural-language language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000B name-length printer-uri printer-uri name 0x0015 value-length ipp://forest/ printer pinetree value 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 0x0016 name-length ipp-attribute- ipp-attribute-fidelity name fidelity 0x0001 value-length 0x01 true value
Herriot, et al. Standards Track [Page 33] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 33] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x02 start job-attributes job-attributes-tag 0x21 integer type value-tag 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
0x02 start job-attributes job-attributes-tag 0x21 integer type value-tag 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
13.2 Print-Job Response (successful)
13.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
0x0101 1.1 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
0x0101 1.1 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
Herriot, et al. Standards Track [Page 34] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 34] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
successful-ok successful-ok value
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
0x0019 value-length
ipp://forest/ job 123 on pinetree value
pinetree/123
0x23 enum 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
successful-ok successful-ok value 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 0x0019 value-length ipp://forest/ job 123 on pinetree value pinetree/123 0x23 enum 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
13.3 Print-Job Response (failure)
13.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).
0x0101 1.1 version-number
0x040B client-error-attributes-or- status-code
values-not-supported
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
0x0101 1.1 version-number 0x040B client-error-attributes-or- status-code values-not-supported 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
Herriot, et al. Standards Track [Page 35] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 35] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
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- status-message name message 0x002F value-length client-error- value attributes- values-not-supported or-values- client-error-attributes-or- 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
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- status-message name message 0x002F value-length client-error- value attributes- values-not-supported or-values- client-error-attributes-or- 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
13.4 Print-Job Response (success with attributes ignored)
13.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
0x0101 1.1 version-number 0x0001 successful-ok-ignored-or- status-code
0x0101 1.1 version-number 0x0001 successful-ok-ignored-or- status-code
Herriot, et al. Standards Track [Page 36] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 36] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
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
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
0x0019 value-length
ipp://forest/ job 123 on pinetree value
pinetree/123
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 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 0x0019 value-length ipp://forest/ job 123 on pinetree value pinetree/123
Herriot, et al. Standards Track [Page 37] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 37] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x23 enum 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
0x23 enum 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
13.5 Print-URI Request
13.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
0x0101 1.1 version-number
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
0x0015 value-length
ipp://forest/ printer pinetree value
pinetree
0x45 uri type value-tag
0x000C name-length
document-uri document-uri name
0x0011 value-length
ftp://foo.com ftp://foo.com/foo value
0x0101 1.1 version-number 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 0x0015 value-length ipp://forest/ printer pinetree value pinetree 0x45 uri type value-tag 0x000C name-length document-uri document-uri name 0x0011 value-length ftp://foo.com ftp://foo.com/foo value
Herriot, et al. Standards Track [Page 38] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 38] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
/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 0x00000001 1 value 0x03 end-of-attributes end-of-attributes-tag
/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 0x00000001 1 value 0x03 end-of-attributes end-of-attributes-tag
13.6 Create-Job Request
13.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
Octets Symbolic Value Protocol field
0x0101 1.1 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
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
0x0015 value-length
ipp://forest/ printer pinetree value
pinetree
0x0101 1.1 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 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 0x0015 value-length ipp://forest/ printer pinetree value pinetree
Herriot, et al. Standards Track [Page 39] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 39] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
inetree 0x03 end-of-attributes end-of-attributes-tag
inetree 0x03 end-of-attributes end-of-attributes-tag
13.7 Get-Jobs Request
13.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
0x0101 1.1 version-number 0x000A Get-Jobs operation-id 0x00000123 0x123 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 0x0015 value-length ipp://forest/ printer pinetree value 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
0x0101 1.1 version-number 0x000A Get-Jobs operation-id 0x00000123 0x123 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 0x0015 value-length ipp://forest/ printer pinetree value 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
Herriot, et al. Standards Track [Page 40] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 40] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
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
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
13.8 Get-Jobs Response
13.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):
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
0x0000 successful-ok status-code
0x00000123 0x123 request-id (echoed
back)
0x01 start operation-attributes operation-attributes-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
0x0101 1.1 version-number 0x0000 successful-ok status-code 0x00000123 0x123 request-id (echoed back) 0x01 start operation-attributes operation-attributes-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
Herriot, et al. Standards Track [Page 41] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 41] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
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
148 149 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
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 148 149 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
14. Appendix B: Registration of MIME Media Type Information for "application/ipp"
14. Appendix B: Registration of MIME Media Type Information for "application/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:
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:
MIME type name: application
MIME type name: application
MIME subtype name: ipp
MIME subtype name: ipp
Herriot, et al. Standards Track [Page 42] RFC 2910 IPP/1.1: Encoding and Transport September 2000
Herriot, et al. Standards Track [Page 42] RFC 2910 IPP/1.1: Encoding and Transport September 2000
A Content-Type of "application/ipp" indicates an Internet Printing Protocol message body (request or response). Currently there is one version: IPP/1.1, whose syntax is described in Section 3 "Encoding of the Operation Layer" of [RFC2910], and whose semantics are described in [RFC2911].
A Content-Type of "application/ipp" indicates an Internet Printing Protocol message body (request or response). Currently there is one version: IPP/1.1, whose syntax is described in Section 3 "Encoding of the Operation Layer" of [RFC2910], and whose semantics are described in [RFC2911].
Required parameters: none
Required parameters: none
Optional parameters: none
Optional parameters: none
Encoding considerations:
Encoding considerations:
IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths).
IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths).
Security considerations:
Security considerations:
IPP/1.1 protocol requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. Protocol mixed-version interworking rules in [RFC2911] as well as protocol encoding rules in [RFC2910] are complete and unambiguous.
IPP/1.1 protocol requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. Protocol mixed-version interworking rules in [RFC2911] as well as protocol encoding rules in [RFC2910] are complete and unambiguous.
Interoperability considerations:
Interoperability considerations:
IPP/1.1 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [RFC2911] and [RFC2910]. Protocol encoding rules specified in [RFC2910] 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.1 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.1 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [RFC2911] and [RFC2910]. Protocol encoding rules specified in [RFC2910] 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.1 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).
Published specifications:
Published specifications:
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC 2911, September 2000.
[RFC2911] ヘイスティングズとT.とエリオとR.とdeBryとR.とイサクソンとS.とP.パウエル、「プロトコル/1.1に以下を印刷するインターネット」 「モデルと意味論」、RFC2911、9月2000日
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC 2910, September 2000.
[RFC2910] エリオとR.とバトラーとS.とムーアとP.とターナーとR.とJ.Wenn、「プロトコル/1.1に以下を印刷するインターネット」 「コード化と輸送」、RFC2910、9月2000日
Herriot, et al. Standards Track [Page 43] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[43ページ]: コード化と輸送2000年9月
Applications which use this media type:
このメディアタイプを使用するアプリケーション:
Internet Printing Protocol (IPP) print clients and print servers, communicating using HTTP/1.1 (see [RFC2910]), 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([RFC2910]を見る)、SMTP/ESMTP、FTP、または他のトランスポート・プロトコルを使用することで交信して、インターネットPrintingプロトコル(IPP)はクライアントとプリント・サーバを印刷します。 どんなLOCALIZED-STRING値のための"charset"と「自然言語」文脈も含んでいて、タイプ「アプリケーション/ipp」のメッセージは、自己充足的であって、輸送から独立しています。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Tom Hastings Xerox Corporation 737 Hawaii St. ESAE-231 El Segundo, CA
トムヘイスティングズゼロックス社737のハワイ通りESAE-231エルセガンド(カリフォルニア)
Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com
以下に電話をしてください。 310-333-6413 Fax: 310-333-5514 メールしてください: hastings@cp10.es.xerox.com
or
または
Robert Herriot 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: robert.herriot@pahv.xerox.com
以下に電話をしてください。 650-813-7696 Fax: 650-813-6860 メールしてください: robert.herriot@pahv.xerox.com
Intended usage:
意図している用法:
COMMON
一般的
15. Appendix C: Changes from IPP/1.0
15. 付録C: IPP/1.0からの変化
IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes:
IPP/1.1は尾行変化でIPP/1.0[RFC2565]と同じです:
1. Attributes values that identify a printer or job object use a new
'ipp' scheme. The 'http' and 'https' schemes are supported only
for backward compatibility. See section 5.
1. プリンタか仕事のオブジェクトを特定する属性値が新しい'ipp'体系を使用します。 'http'と'https'体系は後方の互換性のためだけにサポートされます。 セクション5を見てください。
2. Clients MUST support of Digest Authentication, IPP Printers SHOULD
support Digest Authentication. See Section 8.1.1
2. クライアントはDigest Authentication、IPP Printers SHOULDサポートDigest Authenticationのサポートがそうしなければなりません。 セクション8.1.1を見てください。
3. TLS is recommended for channel security. In addition, SSL3 may be
supported for backward compatibility. See Section 8.1.2
3. TLSはチャンネルセキュリティのために推薦されます。 さらに、SSL3は後方の互換性のためにサポートされるかもしれません。 セクション8.1.2を見てください。
Herriot, et al. Standards Track [Page 44] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[44ページ]: コード化と輸送2000年9月
4. It is recommended that IPP/1.1 objects accept any request with
major version number '1'. See section 9.1.
4. IPP/1.1オブジェクトが主要なバージョン番号'1'でどんな要求も受け入れるのは、お勧めです。 セクション9.1を見てください。
5. IPP objects SHOULD return the URL scheme requested for "job-
printer-uri" and "job-uri" Job Attributes, rather than the URL
scheme used to create the job. See section 9.2.
5. IPPオブジェクトのURL体系が「仕事のプリンタ-uri」のために要求したSHOULDリターンとURL体系よりむしろ「仕事-uri」Job Attributesは雇用を創り出しました。 セクション9.2を見てください。
6. The IANA and Internationalization sections have been added. The
terms "private use" and "experimental" have been changed to
"vendor extension". The reserved allocations for attribute group
tags, attribute syntax tags, and out-of-band attribute values have
been clarified as to which are reserved to future IETF standards
track documents and which are reserved to vendor extension. Both
kinds of extensions use the type2 registration procedures as
defined in [RFC2911].
6. IANAとInternationalization部は加えられます。 「私用」という用語と「実験的」は「ベンダー拡大」に変わりました。 属性グループタグのための予約された配分、構文タグを結果と考えてください。そうすれば、記録とどれがベンダー拡大に予約されるかをどれが将来のIETF規格に予約されるかに追跡するとき、バンドの外では、属性値ははっきりさせられました。 両方の種類の拡大は[RFC2911]で定義されるようにtype2登録手順を用います。
7. Clarified that future "out-of-band" value definitions may use the
value field if additional information is needed.
7. その未来に「バンドの外で」はっきりさせられて、追加情報が必要であるなら、値の定義は値の分野を使用するかもしれません。
Herriot, et al. Standards Track [Page 45] RFC 2910 IPP/1.1: Encoding and Transport September 2000
エリオ、他 規格はRFC2910IPP/1.1を追跡します[45ページ]: コード化と輸送2000年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Herriot, et al. Standards Track [Page 46]
エリオ、他 標準化過程[46ページ]
一覧
スポンサーリンク
