RFC3382 日本語訳
3382 Internet Printing Protocol (IPP): The 'collection' attributesyntax. R. deBry, T. Hastings, R. Herriot, K. Ocke, P. Zehler. September 2002. (Format: TXT=78173 bytes) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. deBry
Request for Comments: 3382 Utah Valley State College
Updates: 2910, 2911 R. Herriot
Category: Standards Track Consultant
T. Hastings
K. Ocke
P. Zehler
Xerox Corporation
September 2002
deBryがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3382のユタバレー州立大学アップデート: 2910、2911R.エリオカテゴリ: 標準化過程コンサルタントT.ヘイスティングズK.Ocke P.Zehlerゼロックス社の2002年9月
Internet Printing Protocol (IPP):
The 'collection' attribute syntax
インターネット印刷プロトコル(IPP): '収集'属性構文
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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document specifies an OPTIONAL attribute syntax called 'collection' for use with the Internet Printing Protocol (IPP/1.0 and IPP/1.1). A 'collection' is a container holding one or more named values, which are called "member" attributes. A collection allows data to be grouped like a PostScript dictionary or a Java Map. This document also specifies the conformance requirements for a definition document that defines a collection attribute. Finally, this document gives some illustrative example collection attribute definitions that are not intended as actual attribute specifications.
このドキュメントはインターネットPrintingプロトコル(IPP/1.0とIPP/1.1)との使用に'収集'と呼ばれるOPTIONAL属性構文を指定します。 '収集'は、1つを保持するコンテナかもう少し命名された値です。(その値は「メンバー」属性と呼ばれます)。 収集は、データがポストスクリプト辞書やJava Mapのように分類されるのを許容します。 また、このドキュメントは収集属性を定義する定義ドキュメントのための順応要件を指定します。 最終的に、このドキュメントは実際として意図しないいくつかの説明に役立つ実例収集属性定義に属性仕様を与えます。
Table of Contents
目次
1 Introduction.....................................................3 1.1 Problem Statement..............................................3 1.2 Solution.......................................................3 2 Terminology......................................................4 2.1 Conformance Terminology........................................4 2.2 Other terminology..............................................5 3 Definition of a Collection Attribute.............................5 3.1 Information to Include.........................................5
1つの序論…3 1.1 問題声明…3 1.2ソリューション…3 2用語…4 2.1 順応用語…4 他の2.2用語…収集属性の5 3定義…5 含んでいる3.1情報…5
deBry, et. al. Standards Track [Page 1] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[1ページ]: '収集'属性構文2002年9月
3.2 Nested Collections.............................................9
4 Collection Attributes as Attributes in Operations................9
4.1 General Rules..................................................9
4.2 Unsupported Values.............................................9
5 Example definition of a collection attribute.....................9
5.1 media-col (collection)........................................10
5.1.1 media-color (type3 keyword | name(MAX)......................10
5.1.2 media-size (collection).....................................11
5.2 media-col-default (collection)................................11
5.3 media-col-ready (1setOf collection)...........................12
5.4 media-col-supported (1setOf type2 keyword)....................12
6 A Second Example Definition Of A Collection Attribute...........12
7 Encoding........................................................13
7.1 Additional tags defined for representing a collection
attribute value...............................................13
7.2 Example encoding: "media-col" (collection)....................14
8 Legacy issues...................................................20
9 IANA Considerations.............................................20
10 Internationalization Considerations............................20
11 Security Considerations........................................21
12 References.....................................................21
Appendix A: Encoding Example of a Simple Collection (Informative).22
Appendix B: Encoding Example of 1setOf Collection (Informative)...25
Appendix C: Encoding Example of Collection containing 1setOf XXX
attribute (Informative)...............................31
Appendix D: Description of the Base IPP Documents (Informative)...35
Authors' Addresses................................................36
Full Copyright Statement..........................................38
3.2 収集を入れ子にします…稼働中である属性としての9 4の収集属性…9 4.1一般は判決を下します…9 4.2 サポートされない値…収集属性の9 5例の定義…9 5.1 メディアあん部(収集)…10 5.1 .1メディア色、(type3キーワード| 名前(MAX)… .10 5.1 .2 メディアサイズ(収集)… .11 5.2 メディアあん部デフォルト(収集)… .11 5.3 あん部が準備するメディア(1setOf収集)… 12 5.4 あん部がサポートしたメディア(1setOf type2キーワード); .6 Second Example Definition Of A Collection Attribute… .12 7 Encoding… .13 7.1 収集属性値を表すために定義されたAdditionalタグ… .13 7.2 Exampleコード化; ppendix A: Encoding Example of a Simple Collection (Informative).22 Appendix B: Encoding Example of 1setOf Collection (Informative)...25 Appendix C: Encoding Example of Collection containing 1setOf XXX attribute (Informative)...............................31 Appendix D: Description of the Base IPP Documents (Informative)...35 Authors' Addresses................................................36 Full Copyright Statement..........................................38
Table of Tables
テーブルのテーブル
Table 1 - "media-col" member attributes...........................10
Table 2 - "media-size" collection member attributes...............11
Table 3 - Tags defined for encoding the 'collection' attribute
syntax .................................................13
Table 4 - Overview Encoding of "media-col" collection.............15
Table 5 - Example Encoding of "media-col" collection..............16
Table 6 - Overview Encoding of simple collection..................22
Table 7 - Example Encoding of simple collection...................22
Table 8 - Overview Encoding of 1setOf collection..................25
Table 9 - Example Encoding of 1setOf collection...................26
Table 10 - Overview Encoding of collection with 1setOf value......31
Table 11 - Example Encoding of collection with 1setOf value.......32
1を見送ってください--「メディアあん部」メンバー属性10 テーブル2--「メディアサイズ」収集メンバー属性…11 テーブル3--'収集'をコード化するために定義されたタグは構文を結果と考えます…13 テーブル4--「メディアあん部」収集の概要Encoding…15 テーブル5--「メディアあん部」収集の例のEncoding…16 テーブル6--簡単な収集の概要Encoding…22 テーブル7--簡単な収集の例のEncoding…22 テーブル8--1setOf収集の概要Encoding…25 テーブル9--1setOf収集の例のEncoding…26 テーブル10--1setOf値がある収集の概要Encoding…31 テーブル11--1setOf値がある収集の例のEncoding…32
deBry, et. al. Standards Track [Page 2] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[2ページ]: '収集'属性構文2002年9月
1 Introduction
1つの序論
This document is an OPTIONAL extension to IPP/1.0 [RFC2565, RFC2566] and IPP/1.1 [RFC2911, RFC2910]. For a description of the base IPP documents see Appendix D.
このドキュメントはIPP/1.0[RFC2565、RFC2566]とIPP/1.1[RFC2911、RFC2910]へのOPTIONAL拡張子です。 ベースIPPドキュメントの記述に関しては、Appendix Dを見てください。
1.1 Problem Statement
1.1 問題声明
The IPP Model and Semantics [RFC2911] supports most of the common data structures that are available in programming languages. It lacks a mechanism for grouping several attributes of different types. The Java language uses the Map to solve this problem and PostScript has a dictionary. The new mechanism for grouping attributes together (called 'collection' mechanism) must allow for optional members and the subsequent addition of new members.
[RFC2911]が最もサポートするプログラミング言語で利用可能な一般的なデータ構造のIPP ModelとSemantics。 それは異なったタイプのいくつかの属性を分類するためのメカニズムを欠いています。 ジャバ言語はこの問題を解決するのにMapを使用します、そして、ポストスクリプトには、辞書があります。 属性を分類する('収集'メカニズムと呼ばれる)ための新しいメカニズムは新しいメンバーの任意のメンバーとその後の追加を考慮しなければなりません。
The 'collection' mechanism must be encoded in a manner consistent with existing 1.0 and 1.1 parsing rules (see [RFC2910]). Current 1.0 and 1.1 parsers that don't support the 'collection' mechanism must not confuse collections or parts of a collection they receive with other attributes.
1.0と1.1の既存の構文解析規則と一致した方法で'収集'メカニズムをコード化しなければなりません([RFC2910]を見てください)。 '収集'メカニズムをサポートしない現在の1.0と1.1のパーサが収集か彼らが他の属性で受け取る収集の部分を混乱させてはいけません。
1.2 Solution
1.2 ソリューション
The new mechanism is a new IPP attribute syntax called a 'collection'. As such, each collection value is a value of an attribute whose attribute syntax type is defined to be a 'collection'. Such an attribute is called a collection attribute. The name of the collection attribute serves to identify the collection value in an operation request or response, as with any attribute value.
新しいメカニズムは'収集'と呼ばれる新しいIPP属性構文です。 そういうものとして、それぞれの収集値は属性構文タイプが'収集'になるように定義される属性の値です。 そのような属性は収集属性と呼ばれます。 収集属性の名前は、操作要求か応答における収集値を特定するのに役立ちます、どんな属性値のようにも。
The 'collection' attribute syntax is a container holding one or more named values (i.e., attributes), which are called member attributes. Each collection attribute definition document lists the mandatory and optional member attributes of each collection value. A collection value is similar to an IPP attribute group in a request or a response, such as the operation attributes group. They both consist of a set of attributes.
'収集'属性構文は、1つを保持するコンテナかもう少し命名された値(すなわち、属性)です。(その値はメンバー属性と呼ばれます)。 それぞれの収集属性定義ドキュメントはそれぞれの収集価値の義務的で任意のメンバー属性を記載します。 収集値は要求か応答におけるIPP属性グループと同様です、操作属性グループなどのように。 それらの両方が1セットの属性から成ります。
As with any attribute syntax, the document that defines a collection attribute specifies whether the attribute is single-valued (collection) or multi-valued (1setOf collection). If the attribute is multi-valued (1setOf collection), each collection value MUST be a separate instance of a single definition of a collection, i.e., it MUST have the same member attributes except for OPTIONAL member attributes. If we view each collection definition as a separate syntax type, this rule continues the IPP/1.1 notion that each
どんな属性構文のようにも、収集属性を定義するドキュメントは、属性が単一に評価(収集)にされますかそれともマルチ評価されているかを(1setOf収集)指定します。 属性がマルチ評価されているなら(1setOf収集)、それぞれの収集値が収集のただ一つの定義の別々のインスタンスでなければならない、すなわち、それには、OPTIONALメンバー属性以外の同じメンバー属性がなければなりません。 私たちがそれぞれの収集定義を別々の構文タイプを見るなら、この規則がIPP/1.1概念を続けている、そんなにそれぞれ。
deBry, et. al. Standards Track [Page 3] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[3ページ]: '収集'属性構文2002年9月
attribute has a single type or pattern (e.g., "keyword | name" is a pattern). Without this rule, the supported values would be more difficult to describe and the mechanism defined in item 4 of section 3.1 would not be sufficient.
属性に、単独のタイプかパターンがあります(例えば、「キーワード| 名前」はパターンです)。 この規則がなければ、サポートしている値は説明するのが、より難しいでしょう、そして、セクション3.1の項目4で定義されたメカニズムは十分でないでしょう。
The name of each member attribute MUST be unique for a collection attribute, but MAY be the same as the name of a member attribute in another collection attribute and/or MAY be the same as the name of an attribute that is not a member of a collection. The rules for naming member attributes are given in section 3.1.
収集属性に、それぞれのメンバー属性の名前はユニークであるに違いありません、別の収集属性におけるメンバー属性の名前と同じであるかもしれない、そして/または、収集のメンバーでない属性の名前と同じであるかもしれないのを除いて。 セクション3.1でメンバー属性を命名するための規則を与えます。
Each member attribute can have any attribute syntax type, including 'collection', and can be either single-valued or multi-valued. The length of a collection value is not limited. However, the length of each member attribute MUST NOT exceed the limit of its attribute syntax.
それぞれのメンバー属性がどんな属性構文タイプも持つことができて、'収集'を含んで、単一に評価するかマルチ評価できます。 収集価値の長さは限られていません。 しかしながら、それぞれのメンバー属性の長さは属性構文の限界を超えてはいけません。
The member attributes in a collection MAY be in any order in a request or response. When a client sends a collection attribute to the Printer, the order that the Printer stores the member attributes of the collection value and the order returned in a response MAY be different from the order sent by the client.
収集におけるメンバー属性は要求か応答で順不同であるかもしれません。 クライアントが収集属性をPrinterに送るとき、収集のメンバー属性が評価するPrinter店と注文が応答で返したオーダーはクライアントによって送られた注文と異なっているかもしれません。
A collection value MUST NOT contain two or more member attributes with the same attribute name. Such a collection is mal-formed. Clients MUST NOT submit such malformed requests and Printers MUST NOT return such malformed responses. If such a malformed request is submitted to a Printer, the Printer MUST (depending on implementation) either (1) reject the request with the 'client- error-bad-request' status code (see [RFC2911] section 13.1.4.1), or (2) accept the request and use only one of each duplicate member attributes.
収集値は同じ属性名がある2つ以上のメンバー属性を含んではいけません。 そのような収集は悪-形成されます。 クライアントはそのような奇形の要求を提出してはいけません、そして、Printersはそのような奇形の応答を返してはいけません。 (実装によります)(1)は'クライアントの誤りの悪い要求'ステータスコードで要求を拒絶しなければなりません。そのような奇形の要求をPrinter、Printerに提出する、([RFC2911]セクション13.1.4の.1)、または(2)が要請を受け入れて、それぞれの写しメンバーのひとりだけに属性を使用するのを見てください。
2 Terminology
2 用語
This section defines terminology used throughout this document.
このセクションはこのドキュメント中で使用される用語を定義します。
2.1 Conformance Terminology
2.1 順応用語
Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance as defined in BCP 14, RFC 2119 [RFC2119] and [RFC2911], section 12.1. If an implementation supports the extension defined in this document, then these terms apply; otherwise, they do not. These terms define conformance to this document only; they do not affect conformance to other documents, unless explicitly stated otherwise.
大文字で書かれた用語と、そのようなもの、OPTIONAL、NOT、REQUIRED、SHOULD、SHOULD NOT、5月はNOTを必要としなければならなくて、BCP14とRFC2119[RFC2119]と[RFC2911](セクション12.1)で定義されるように順応に関連する特別な意味を持たなければならなくなってください。 実装が本書では定義された拡大をサポートするなら、これらの用語は当てはまります。 さもなければ、それらはそうしません。 これらの用語はこのドキュメントだけと順応を定義します。 別の方法で明らかに述べられない場合、それらは他のドキュメントに順応に影響しません。
deBry, et. al. Standards Track [Page 4] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[4ページ]: '収集'属性構文2002年9月
2.2 Other terminology
2.2 他の用語
This document uses terms such as Job object (or Job), IPP Printer object (or Printer), "operation", "request", response", "attributes", "keywords", and "support". These terms have special meaning and are defined in the model terminology [RFC2911] section 12.2. The following additional terms are introduced in this document:
「このドキュメントはJobオブジェクト(または、Job)などの用語を使用します、とIPP Printerオブジェクト(または、Printer)、「操作」は「要求します」、応答」、「属性」、「キーワード」、および「サポート。」 これらの用語は、特別な意味を持って、モデル用語[RFC2911]部12.2で定義されます。 次の追加用語は本書では紹介されます:
collection: an attribute syntax in which each attribute value is a
set of attributes, called member attributes.
収集: 各属性値がメンバー属性と呼ばれる1セットの属性である属性構文。
member attribute: an attribute that is defined to be used as one
of the attributes in a collection.
メンバー属性: 収集における属性の1つとして使用されるために定義される属性。
collection attribute: an attribute whose definition specifies the
'collection' attribute syntax and each of the member attributes
that MAY occur in a collection attribute value.
収集属性: 定義が'収集'属性構文を指定する属性と収集属性値で起こるかもしれないそれぞれのメンバー属性。
3 Definition of a Collection Attribute
3 収集属性の定義
This section describes the requirements for any collection attribute definition.
このセクションはどんな収集属性定義のための要件についても説明します。
3.1 Information to Include
3.1 含んでいる情報
When a specification document defines an "xxx" collection attribute,
i.e., an attribute whose attribute syntax type is 'collection' or
'1setOf collection'; the definition document MUST include the
following aspects of the attribute semantics. Suppose the "xxx"
collection attribute contains N member attributes named "aaa1",
"aaa2", ..., "aaaN" ("aaaI" represents any one of these N member
attributes).
仕様ドキュメントはいつ"xxx"収集属性、すなわち、属性構文タイプが'収集'である属性を定義するか、そして、'1setOf収集'。 定義ドキュメントは属性意味論の以下の局面を含まなければなりません。 "xxx"収集属性が属性が任命したNメンバーを含むと仮定してください、「aaa1"、「aaa2"、…」, "aaaN"("aaaI"はこれらのNメンバー属性のどれかを表します)。
1. The name of the collection attribute MUST be specified (e.g.,
"xxx"). The selection of the name "xxx" MUST follow the same
rules for uniqueness as for attributes of any other syntax type,
(as defined by IPP/1.1) unless "xxx" is a member attribute of
another collection. Then the selection of the name "xxx" MUST
follow the rules for uniqueness defined in item 5a) of this list.
1. 収集属性の名前を指定しなければなりません(例えば、"xxx")。 "xxx"という名前の選択がいかなる他の構文タイプの属性のようにもユニークさのための同じ規則に従わなければならない、(IPP/1.1によって定義されるように) "xxx"が別の収集のメンバー属性でないなら。 "xxx"という名前の選択はこのリストの項目5a)で定義されたユニークさのために約束を守らなければなりません。
2. The collection attribute syntax MUST be of type 'collection' or
'1setOf collection'.
2. 収集属性構文はタイプ'収集'か'1setOf収集'のものであるに違いありません。
3. The context of the collection attribute MUST be specified, i.e.,
whether the attribute is an operation attribute, a Job Template
attribute, a Job Description attribute, a Printer Description
attribute, a member attribute of a particular collection
attribute, etc.
3. 収集属性の文脈を指定しなければなりません、すなわち、属性が操作属性、Job Template属性、Job記述属性、Printer記述属性、特定の収集属性のメンバー属性などであるか否かに関係なく
deBry, et. al. Standards Track [Page 5] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[5ページ]: '収集'属性構文2002年9月
4. An "xxx-supported" attribute MUST be specified and it has one of
the following two forms:
4. 「xxxによってサポートしている」属性を指定しなければなりません、そして、それには、以下の2つのフォームの1つがあります:
a) "xxx-supported" is a "1setOf collection", which enumerates all
of the supported collection values of "xxx". If a collection
of this form contains a nested collection, it MUST be of the
same form.
a) 「xxxによってサポートされる」は"xxx"のサポートしている収集値のすべてを列挙する「1setOf収集」です。 この形式の収集が入れ子にされた収集を含んでいるなら、それは同じフォームのものであるに違いありません。
For example, "media-size-supported" might have the values {{x-
dimension:210, y-dimension:297},{x-dimension:297, y-
dimension:420}} to show that it supports two values of "media
size": A4 (210x297) and A3 (297x420). It does not support
other combinations of "x-dimension" and "y-dimension" member
attributes, such as 210x420 or 297x297, and it does not support
non-enumerated values, such as 420x595.
例えば、「サイズがサポートしたメディア」には値があるかもしれない、y-寸法: x寸法: 210、297、y寸法: x-寸法: 297、420、それを示しているために、「メディアサイズ」の2つの値をサポートします: A4(210×297)とA3(297×420)。 それは「x-寸法」と「y-寸法」メンバー属性の他の組み合わせをサポートしません、210×420や297×297のように、そして、非列挙された値をサポートしません、420×595などのように。
b) "xxx-supported" is a "1setOf type2 keyword", which enumerates
the names of all of the member attributes of "xxx": "aaa1",
"aaa2", ..., "aaaN". If a collection of this form contains a
nested collection, it MAY be of either form. See item 5f)
below for details on supported values of member attributes.
b) 「xxxによってサポートされる」は「1setOf type2キーワード」です:(それは、"xxx"のメンバー属性のすべての名前を列挙します)。 「aaa1"、「aaa2"、…」, "aaaN"。 この形式の収集が入れ子にされた収集を含んでいるなら、それはどちらのまたフォームについてものであるかもしれません。 メンバー属性のサポートしている値に関する詳細における、以下の項目5fを見てください。
For example, "media-col-supported" might have the keyword
values: "media-size" and "media-color".
例えば、「あん部がサポートしたメディア」には、キーワード値があるかもしれません: 「メディアサイズ」と「メディア色。」
5. The member attributes MUST be defined. For each member attribute,
the definition document MUST provide the following information:
5. メンバー属性を定義しなければなりません。 それぞれのメンバー属性のために、定義ドキュメントは以下の情報を提供しなければなりません:
a) The member attribute's name (e.g., "aaa") MUST be unique within
the collection being defined and MUST either:
a) メンバー属性の名前(例えば、"aaa") 定義される収集の中でユニークでなければならなく、ユニークでなければなりません:
i) reuse the attribute name of another attribute (that is
unique across the entire IPP attribute name space) and
have the same syntax and semantics as the reused attribute
(if the condition of item 4b) above is met). For example,
a member attribute definition could reuse the IPP/1.1
"media" attribute.
i) 別の属性の属性名を再利用してください、そして、(それはスペースという全体のIPP属性名の向こう側にユニークです)再利用された属性として同じ構文と意味論を持ってください(項目4bの状態) 上が会われるなら)。 例えば、メンバー属性定義はIPP/1.1「メディア」属性を再利用するかもしれません。
ii) potentially occur elsewhere in the entire IPP attribute
name space. (if the condition of item 4a) above is met).
For example, a member attribute could be "x-dimension",
which could potentially occur in another collection or as
an attribute outside of a collection.
ii) スペースという全体のIPP属性名におけるほかの場所に潜在的に起こってください。 (項目4a)の状態です。 上が会われる、) 例えば、メンバー属性は収集の外の別の収集か属性として潜在的に起こることができた「x-寸法」であるかもしれません。
iii) be unique across the entire IPP attribute name space (if
the condition of item 4b) above is met). For example, a
member attribute could be "media-color" which must be
unique across the entire IPP attribute name space.
iii) スペースという全体のIPP属性名の向こう側にユニークであってください(項目4bの状態) 上が会われるなら)。 例えば、メンバー属性はスペースという全体のIPP属性名の向こう側にユニークであるに違いない「メディア色」であるかもしれません。
deBry, et. al. Standards Track [Page 6] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[6ページ]: '収集'属性構文2002年9月
b) Whether the member attribute is REQUIRED or OPTIONAL for the
Printer to support.
b) メンバー属性は、サポートへのPrinterのためのREQUIREDかそれともOPTIONALですか?
c) Whether the member attribute is REQUIRED or OPTIONAL for the
client to supply in a request.
c) メンバー属性は、要求で供給するクライアントのためのREQUIREDかそれともOPTIONALですか?
d) The member attribute's syntax type, which can be any attribute
syntax, including '1setOf X', 'collection', and '1setOf
collection'. If this attribute name reuses the name of another
attribute (case of item a1 above), it MUST have the same
attribute syntax, including cardinality (whether or not
1setOf).
d) メンバー属性の構文タイプ、どれが何か属性構文であるかもしれませんか、'1setOf X'を含んでいる、'収集'、および'1setOf収集'。 この属性名が別の属性(上の項目a1に関するケース)の名前を再利用するなら、それには、同じ属性構文がなければなりません、基数を含んでいて(1setOf)
e) The semantics of the "aaa" member attribute. The semantic
definition MUST include a description of any constraint or
boundary conditions the member attribute places on the
associated attribute, especially if the attribute reuses the
name of another attribute (case of item a1 above).
e) "aaa"メンバー属性の意味論。 意味定義はメンバー属性が関連属性に置くどんな規制や境界状態の記述も含まなければなりません、特に属性が別の属性(上の項目a1に関するケース)の名前を再利用するなら。
f) The supported values for each "aaaI" member attribute (of the
member attributes "aaa1", "aaa2", ..., "aaaN") is specified by
one of two mechanisms.
f) それぞれの"aaaI"メンバーのためのサポートしている値が結果と考える、(メンバー属性、「aaa1"、「aaa2"、…」, "aaaN") 2つのメカニズムの1つで、指定されます。
i) If "xxx-supported" is a "1setOf collection" (see item 4a)
above), the value for each "aaaI" is specified in each
collection value of "xxx-supported", in the context of
other member attributes. That is, "xxx-supported"
enumerates all supported values of "xxx".
i) 「xxxによってサポートされる」が「1setOf収集」(項目4a)が上であることを見る)であるなら、各"aaaI"のための値は「xxxによってサポートされること」のそれぞれの収集値で指定されます、他のメンバー属性の文脈で。 すなわち、「xxxによってサポートされること」は"xxx"の値であるとサポートされたすべてを列挙します。
ii) If the value of "xxx-supported" is a "1setOf type2
keyword" (see item 4b) above), the supported values of
"aaaI" are the values specified by either i) the "aaaI-
supported" attribute or ii) the definition of the member
attribute "aaaI" within the document defining the "xxx"
attribute. The values of each member attribute "aaaI" are
specified independently of other member attributes, though
a Printer is not required to support all combinations of
supported values.
ii) 「xxxによってサポートされること」の値が「1setOf type2キーワード」(項目4b) 上を見る)であるなら、"aaaI"のサポートしている値はi) 「サポートされたaaaI」属性かii) "xxx"属性を定義するドキュメントの中のメンバー属性"aaaI"の定義のどちらかで指定された値です。 それぞれのメンバー属性"aaaI"の値は他のメンバー属性の如何にかかわらず指定されます、Printerがサポートしている値のすべての組み合わせをサポートするのに必要ではありませんが。
For example, "media-col-supported" might have the keyword
values: "media-size" and "media-color". Using the first
method for defining supported values (an "aaaI-supported"
attribute), the collection values of "media-col" are
combinations of values of "media-size-supported" and
"media-color-supported". If "media-size-supported" has
the values of '210x297' and '297x420' and "media-color-
supported" has the values of 'white' and 'pink', the
例えば、「あん部がサポートしたメディア」には、キーワード値があるかもしれません: 「メディアサイズ」と「メディア色。」 値(「aaaIによってサポートしている」属性)であるとサポートされた定義に最初のメソッドを使用して、「メディアあん部」の収集値は「サイズがサポートしたメディア」と「色がサポートしたメディア」の値の組み合わせです。 「サイズがサポートしたメディア」で'210×297'と'297×420'の値があるか、そして、「メディア色でサポートされること」で、'白'と'ピンク'の値があります。
deBry, et. al. Standards Track [Page 7] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[7ページ]: '収集'属性構文2002年9月
Printer might support only the combinations 'white-
210x297', 'pink-210x297' and 'white-297x420', and not
'pink-297x420'.
プリンタは、唯一の組み合わせが'ピンク-297×420'ではなく'白い210×297'、'ピンク-210×297'と'白-297×420'であるとサポートするかもしれません。
If a collection contains a member "aaaI", whose syntax
type is "text", the supported values would probably be
defined by the definition of "xxx" rather than by the
attribute "aaaI-supported".
収集がメンバー"aaaI"(構文タイプは「テキスト」である)を含んでいるなら、サポートしている値はたぶん属性でというよりむしろ"xxx"の定義で「aaaIによってサポートされた」状態で定義されるでしょう。
g) the default value of each "aaaI" member attribute if it is
OPTIONAL for a client to supply the "aaa" member attribute in a
request. The default value is specified by the attribute's
definition within a document and MUST be one of the following:
g) それであるなら、それぞれの"aaaI"メンバー属性のデフォルト値はクライアントが要求における"aaa"メンバー属性を供給するOPTIONALです。 デフォルト値は、ドキュメントの中に属性の定義で指定されて、以下の1つであるに違いありません:
i) a fixed default
i) 固定デフォルト
ii) a mechanism by which the Printer determines default
ii) Printerがデフォルトを決定するメカニズム
iii) an indefinite default that is left to the implementation.
iii) 実装に残される無期デフォルト。
iv) an attribute that the Printer uses to determine the
default
iv) Printerがデフォルトを決定するのに使用する属性
6. The default value of "xxx", if a client does not supply it. The
default value is specified by the attribute's definition within a
document and MUST be one of the following:
6. "xxx"のデフォルト値クライアントがそれを供給しないなら。 デフォルト値は、ドキュメントの中に属性の定義で指定されて、以下の1つであるに違いありません:
a) a fixed default
a) 固定デフォルト
b) a mechanism by which the Printer determines default
b) Printerがデフォルトを決定するメカニズム
c) an indefinite default that is left to the implementation
c) 実装に残される無期デフォルト
d) a Printer attribute "xxx-default" which is a collection with
the same member attributes as "xxx". If optional member
attributes are absent, the Printer uses the defaulting rules of
item 5g) above.
d) "xxx"と同じメンバー属性がある収集であるPrinter属性「xxx-デフォルト。」 任意のメンバー属性が欠けるなら、Printerは上の項目5g)のデフォルト規則を使用します。
7. The "xxx-ready (1setOf collection)" attribute, if human
intervention is required to make many of the supported values
available. For example, "media-col" is an attribute which has a
"ready" attribute. Most attributes do not have a "ready"
attribute.
7. 「xxx準備ができ(1setOf収集)」属性人間の介入がサポートしている値の多くを利用可能にするのに必要であるなら。 例えば、「メディアあん部」は「準備ができる」属性がある属性です。 ほとんどの属性に、「準備ができる」属性がありません。
deBry, et. al. Standards Track [Page 8] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[8ページ]: '収集'属性構文2002年9月
3.2 Nested Collections
3.2 入れ子にされた収集
A member attribute may have a syntax type of 'collection' or '1setOf collection', in which case it is called a nested collection attribute. The rules for a nested collection attribute are the same as for a collection attribute as specified in section 3.1.
メンバー属性に、'収集'か'1setOf収集'の構文タイプがあるかもしれません、その場合、それは入れ子にされた収集属性と呼ばれます。 入れ子にされた収集属性のための規則はセクション3.1の指定されるとしての収集属性のように同じです。
4 Collection Attributes as Attributes in Operations
4 稼働中である属性としての収集属性
4.1 General Rules
4.1 一般規則
A collection value is like any other IPP/1.1 value, except that it is structured. The rules for attributes with collection values are the same as for attributes of any other syntax type (see IPP/1.1), be they in any group of a request of a response.
それが構造化されるのを除いて、収集値はいかなる他のIPP/1.1値にも似ています。 収集値がある属性のための規則はいかなる他の構文タイプの属性のようにも同じです(IPP/1.1を見てください)、いずれかのそれらが応答の要求のグループであったなら。
4.2 Unsupported Values
4.2 サポートされない値
The rules for returning an unsupported collection attribute are an extension to the current rules:
サポートされない収集属性を返すための規則は現在の規則への拡大です:
1. If the entire collection attribute is unsupported, then the
Printer returns just the collection attribute name with the
'unsupported' out-of-band value (see the beginning of [RFC2911]
section 4.1) in the Unsupported Attributes Group.
1. 全体の収集属性がサポートされないなら、PrinterはUnsupported Attributes Groupでまさしくバンドの外の'サポートされなさ'の収集属性名に値を返します([RFC2911]セクション4.1の始まりを見ます)。
2. If a collection contains unrecognized, unsupported member
attributes and/or conflicting values, the attribute returned in
the Unsupported Group is a collection containing the unrecognized,
unsupported member attributes, and/or conflicting values. The
unrecognized member attributes have an out-of-band value of
'unsupported' (see the beginning of [RFC2911] section 4.1). The
unsupported member attributes and conflicting values have their
unsupported or conflicting values.
2. 収集が認識されていなくて、サポートされないメンバー属性、そして/または、闘争している値を含んでいるなら、Unsupported Groupで返された属性は、認識されていなくて、サポートされないメンバー属性を含む収集、そして/または、闘争値です。 認識されていないメンバー属性に、'サポートされないこと'のバンドで出ている値があります([RFC2911]セクション4.1の始まりを見てください)。 サポートされないメンバー属性と闘争している値には、それらのサポートされないか闘争している値があります。
5 Example definition of a collection attribute
5 収集属性の例の定義
In some printing environments, it is desirable to allow the client to select the media by its properties, e.g., weight, color, size, etc., instead of by name. In IPP/1.1 (see [RFC2911]), the "media (type3 keyword | name) Job Template attribute allows selection by name. It is tempting to extend the "media" attribute syntax to include "collection", but then existing clients could not understand default or supported media values that use the collection value. To preserve interoperability, a new attribute MUST BE added, e.g., "media-col (collection)". The following subsections contain a sample definition of a simplified "media-col" attribute. The definition follows the rules in section 3.
いくつかの印刷環境で、クライアントが特性、例えば、重さ、色、サイズなどでメディアを選択するのを許容するのは望ましいです、名前の代わりに。 IPP/1.1([RFC2911]を見る)、「メディア(type3キーワード| 名前)仕事のTemplate属性は名前で選択を許すところ」で。 それが「収集」を含むように「メディア」属性構文を広げるのに誘惑していますが、既存のクライアントは、デフォルトを理解できませんでしたし、メディアが収集値を使用する値であるとサポートもしました。 相互運用性を保存するために、例えば新しい属性を加えなければなりません。「メディアあん部(収集)。」 以下の小区分は簡易型の「メディアあん部」属性のサンプル定義を含んでいます。 定義はセクション3で約束を守ります。
deBry, et. al. Standards Track [Page 9] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[9ページ]: '収集'属性構文2002年9月
All of the example attribute definitions in this document are illustrative examples, rather than actual definitions. These examples are intended to illustrate how to define collection attributes. Other documents MUST define collection attributes for use in actual interchange. Such definitions may be very similar to the examples in this document, since we attempted to pick useful examples.
例の属性定義のすべてが本書では実際の定義よりむしろ説明に役立つ実例です。 これらの例が収集属性を定義する方法を例証することを意図します。 他のドキュメントは実際の置き換えにおける使用のために収集属性を定義しなければなりません。 私たちが、有用な例を選ぶのを試みたので、そのような定義は本書では例と非常に同様であるかもしれません。
Note: we picked the name "media-col" because the name "media" is already in use. Ordinarily the collection attribute would have a name like any other attribute and would not end in "col".
以下に注意してください。 名前「メディア」が既に使用中であるので、私たちは名前「メディアあん部」を選びました。 通常、収集属性は、いかなる他の属性のような名前も持って、「あん部」に終わらないでしょう。
The member attributes of "media-col" attribute ("media-color (type 3
keyword)" and "media-size (collection)") both follow the naming rules
of item 4a3 of section 3, i.e., the names are unique across the
entire IPP attribute name space. The member attributes of the
"media-size (collection)" member attribute ("x-dimension
(integer(0:MAX))" and "y-dimension (integer(0:MAX))") both follow the
naming rules of item 4a2 of section 3, i.e., they potentially occur
elsewhere in the IPP attribute name space.
「メディアあん部」属性(「メディア色(3キーワードをタイプする)」と「メディアサイズ(収集)」)のメンバー属性はともにセクション3の項目4a3の命名規則に従います、すなわち、名前がスペースという全体のIPP属性名の向こう側にユニークです。 「メディアサイズ(収集)」メンバー属性(「x-寸法(整数(0: MAX))」と「y-寸法(整数(0: MAX))」)のメンバー属性はセクション3の項目4a2の命名規則に従います、すなわち、それらがスペースというIPP属性名におけるほかの場所に潜在的に起こります。
5.1 media-col (collection)
5.1 メディアあん部(収集)
The "media-col" (collection) attribute augments the IPP/1.1 [RFC2911] "media" attribute. This collection attribute enables a client end user to submit a list of media characteristics to the Printer. When the client specifies media using the "media-col" collection attribute, the Printer object MUST match the requested media exactly. The 'collection' consists of the following member attributes:
「メディアあん部」(収集)属性はIPP/1.1[RFC2911]「メディア」属性を増大させます。 この収集属性は、クライアントエンドユーザがメディアの特性のリストをPrinterに提出するのを可能にします。 クライアントが「メディアあん部」収集属性を使用することでメディアを指定するとき、Printerオブジェクトはまさに要求されたメディアに合わなければなりません。 '収集'は以下のメンバー属性から成ります:
Table 1 - "media-col" member attributes
テーブル1--「メディアあん部」メンバー属性
Attribute name attribute syntax request Printer
Support
属性名前属性構文要求Printer Support
media-color type3 keyword | name (MAX) MAY MUST
メディア色のtype3キーワード| 名前(マックス)5月はそうしなければなりません。
media-size collection MUST MUST
収集がそうしなければならないメディアサイズはそうしなければなりません。
The definitions for the member attributes is given in the following sub-sections:
以下の小区分でメンバー属性のための定義を与えます:
5.1.1 media-color (type3 keyword | name(MAX)
5.1.1 メディア色、(type3キーワード| 名前(マックス)
This member attribute identifies the color of the media. Valid values are 'red', 'white' and 'blue'.
このメンバー属性はメディアの色を特定します。 有効値は、'赤く'、'白く''青いです'。
deBry, et. al. Standards Track [Page 10] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[10ページ]: '収集'属性構文2002年9月
The "media-color-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of this "media-color" member attribute that the Printer supports, i.e., the colors supported.
「色がサポートしたメディア」(1setOf(type3キーワード| 名前(MAX)))プリンタ属性はPrinterがサポートするこの「メディア色」メンバー属性の値を特定します、すなわち、サポートされた色。
If the client omits this member attribute, the Printer determines the value in an implementation dependent manner.
クライアントがこのメンバー属性を省略するなら、Printerは実装に依存する方法で値を決定します。
5.1.2 media-size (collection)
5.1.2 メディアサイズ(収集)
This member attribute identifies the size of the media. The 'collection' consists of the member attributes shown in Table 2:
このメンバー属性はメディアのサイズを特定します。 '収集'はTable2に示されたメンバー属性から成ります:
Table 2 - "media-size" collection member attributes
テーブル2--「メディアサイズ」収集メンバー属性
Attribute name attribute syntax request Printer
Support
属性名前属性構文要求Printer Support
x-dimension integer (0:MAX) MUST MUST
整数(0: マックス)がそうしなければならないx-寸法はそうしなければなりません。
y-dimension integer (0:MAX) MUST MUST
整数(0: マックス)がそうしなければならないy-寸法はそうしなければなりません。
The definitions for the member attributes are given in the following sub-sections:
以下の小区分でメンバー属性のための定義を与えます:
5.1.2.1 x-dimension (integer(0:MAX))
5.1.2.1 x-寸法(整数(0: 最大))
This attribute identifies the width of the media in inch units along the X axis.
この属性はX軸に沿ってインチ単位のメディアの幅を特定します。
5.1.2.2 y-dimension (integer(0:MAX))
5.1.2.2 y-寸法(整数(0: 最大))
This attribute identifies the height of the media in inch units along the Y axis.
この属性はY軸に沿ってインチ単位のメディアの高さを特定します。
The "media-size-supported" (1setOf collection) Printer attribute identifies the values of this "media-size" member attribute that the Printer supports, i.e., the size combinations supported. The names of the member attributes are the same as the member attributes of the "media-size" collection attribute, namely "x-dimension", and "y- dimension", since they have the same attribute syntax and the same semantics.
「サイズがサポートしたメディア」(1setOf収集)プリンタ属性はPrinterがサポートするこの「メディアサイズ」メンバー属性の値を特定します、すなわち、組み合わせがサポートしたサイズ。 メンバー属性の名前は「メディアサイズ」収集属性、すなわち、「x-寸法」、および「y寸法」のメンバー属性と同じです、それらには同じ属性構文と同じ意味論があるので。
5.2 media-col-default (collection)
5.2 メディアあん部デフォルト(収集)
The "media-col-default" Printer attribute specifies the media that the Printer uses, if any, if the client omits the "media-col" and "media". Job Template attributes in the Job Creation operation and the PDL do not include a media specification. The member attributes
「メディアあん部デフォルト」Printer属性はPrinterが使用するメディアを指定します、もしあれば、クライアントが「メディアあん部」と「メディア」を省略するなら。 Job Creation操作とPDLの仕事のTemplate属性はメディア仕様を含んでいません。 メンバー属性
deBry, et. al. Standards Track [Page 11] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[11ページ]: '収集'属性構文2002年9月
are defined in Table 1. A Printer MUST support the same member attributes for this default collection attribute as it supports for the corresponding "media-col" Job Template attribute.
Table1では、定義されます。 Job Templateが属性であると対応する「メディアあん部」にサポートするとき、Printerはこのデフォルト収集属性のために同じメンバー属性をサポートしなければなりません。
5.3 media-col-ready (1setOf collection)
5.3 あん部が準備するメディア(1setOf収集)
The "media-col-ready" Printer attribute identifies the media that are available for use without human intervention, i.e., the media that are ready to be used without human intervention. The collection value MUST have all of the member attributes that are supported in Table 1.
「あん部が準備するメディア」Printer属性は人間の介入(すなわち、人間の介入なしで使用される準備ができているメディア)なしで使用に利用可能なメディアを特定します。 収集値には、Table1でサポートされるメンバー属性のすべてがなければなりません。
5.4 media-col-supported (1setOf type2 keyword)
5.4 あん部がサポートしたメディア(1setOf type2キーワード)
The "media-col-supported" Printer attribute identifies the keyword names of the member attributes supported in the "media-col" collection Job Template attribute, i.e., the keyword names of the member attributes in Table 1 that the Printer supports.
「あん部がサポートしたメディア」Printer属性は「メディアあん部」収集Job Template属性(すなわち、PrinterがサポートするTable1のメンバー属性のキーワード名)でサポートされたメンバー属性のキーワード名を特定します。
6 A Second Example Definition Of A Collection Attribute
6 収集属性の第2の例の定義
All of the example attribute definitions in this document are illustrative examples, rather than actual definitions. These examples are intended to illustrate how to define collection attributes. Other documents MUST define collection attributes for use in actual interchange. Such definitions may be very similar to the examples in this document, since we attempted to pick useful examples.
例の属性定義のすべてが本書では実際の定義よりむしろ説明に役立つ実例です。 これらの例が収集属性を定義する方法を例証することを意図します。 他のドキュメントは実際の置き換えにおける使用のために収集属性を定義しなければなりません。 私たちが、有用な例を選ぶのを試みたので、そのような定義は本書では例と非常に同様であるかもしれません。
In some printing environments, it is desirable to allow the client to select the media for the job start sheet. The reason for not adding the 'collection' attribute syntax to the existing "job-sheets" Job Template attribute is the same as for "media". Instead, a new Job Template attribute is introduced, e.g., "job-sheet-col (collection)".
いくつかの印刷環境で、クライアントが仕事のスタートシートのためにメディアを選択するのを許容するのは望ましいです。 Job Templateが結果と考える「仕事シート」という'収集'属性構文を存在に加えない理由は「メディア」のように同じです。 代わりに、例えば新しいJob Template属性を導入します。「仕事のシートあん部(収集)。」
The member attributes of "job-sheet-col" attribute ("job-sheets (type
3 keyword)" and "media (type3 keyword | name)") both follow the
naming rules of item 4a1 of section 3, i.e., they reuse existing IPP
attributes. According to the rules, their supported values come from
the existing IPP attributes: "job-sheets-supported" and "media-
supported". However, their default values do not come from "job-
sheets-default" and "media-default", respectively. Rather, the
definition of "job-sheet-col" says that "job-sheets (type 3 keyword)"
is required and if "media (type3 keyword | name)" is absent, the
Printer uses the same media as the rest of the job uses.
「仕事のシートあん部」属性(「仕事シート(3キーワードをタイプする)」と「メディア(type3キーワード| 名前)」)のメンバー属性はセクション3の項目4a1の命名規則に従います、すなわち、それらが既存のIPP属性を再利用します。 規則に従って、それらのサポートしている値は既存のIPP属性から来ます: 「シートがサポートした仕事」と「サポートされたメディア。」 しかしながら、それらのデフォルト値は「仕事のシートデフォルト」と「メディアデフォルト」からそれぞれ来ません。 むしろ、「仕事のシートあん部」の定義は、「仕事シート(3キーワードをタイプする)」が必要であると言います、そして、「メディア(type3キーワード| 名前)」が休むなら、Printerは仕事の用途の残りと同じメディアを使用します。
deBry, et. al. Standards Track [Page 12] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[12ページ]: '収集'属性構文2002年9月
If "job-sheet-col" attribute was defined to contain the member attribute "job-sheet-media (type3 keyword | name)" instead of "media (type3 keyword | name)", then the definition would also have to specify a "job-sheet-media-supported (1setOf (type3 keyword | name))" whose values would be independent of "media-supported (1setOf (type3 keyword | name))" and would be set separately by a System Administrator.
「仕事のシートあん部」属性がメンバーを含むように定義されたなら、「メディア(type3キーワード| 名前)」の代わりに「仕事のシートメディア(type3キーワード| 名前)」を結果と考えてください、また値が「メディアによってサポート1setOf(type3キーワード| 名前)()にされること」から独立していて、別々にSystem Administratorによって設定される「メディアが支えた仕事のシート(1setOf(type3キーワード| 名前))」を指定するために定義にはあるその時。
The actual text for the definition of the attribute is left as an exercise for the reader.
属性の定義のための実際のテキストは読者のための運動として残されます。
7 Encoding
7 コード化
This section defines the additional encoding tags used according to [RFC2910] and gives an example of their use. The encoding tags defined in this document MUST be used by all collection attributes defined in other documents. However, the example of their use is illustrative only.
このセクションは、[RFC2910]に従ってタグが使用した追加コード化を定義して、彼らの使用に関する例を出します。 他のドキュメントで定義されたすべての収集属性で本書ではタグが定義したコード化を使用しなければなりません。 しかしながら、彼らの使用の例は説明に役立っています。単に。
7.1 Additional tags defined for representing a collection attribute
value
7.1 収集属性値を表すために定義された追加タグ
The 'collection' attribute syntax uses the tags defined in Table 3.
'収集'属性構文はTable3で定義されたタグを使用します。
Table 3 - Tags defined for encoding the 'collection' attribute syntax
テーブル3--'収集'属性構文をコード化するために定義されたタグ
Tag name Tag
value Meaning
タグ名前Tag値のMeaning
begCollection 0x34 Begin the collection attribute value.
begCollection0x34Begin、収集属性値。
endCollection 0x37 End the collection attribute value.
endCollection0x37End、収集属性値。
memberAttrName 0x4A The value is the name of the
collection member attribute
memberAttrName 0x4A、値は収集メンバー属性の名前です。
When encoding a collection attribute "xxx" that contains an attribute "aaa" and is not inside another collection, the encoding follows these rules:
属性"aaa"を含んでいて、別の収集にはない収集属性"xxx"をコード化するとき、コード化はこれらの規則に従います:
1. The beginning of the collection is indicated with a value tag that
MUST be syntax type 'begCollection' (0x34) with a name length and
Name field that represent the name of the collection attribute
("xxx") as with any attribute, followed by a value. The Printer
MAY ignore the value and its length MAY be 0. In the future,
however, this field MAY contain useful information, such as the
collection name (cf. the name of a C struct).
1. 収集の始まりは値があとに続いたどんな属性のようにも収集属性("xxx")の名前を表す名前の長さとName分野がある構文タイプ'begCollection'(0×34)であるに違いない値のタグで示されます。 Printerは値を無視するかもしれません、そして、長さは0であるかもしれません。 しかしながら、将来、この分野は役に立つ情報を含むかもしれません、収集名(Cf C structの名前)などのように。
deBry, et. al. Standards Track [Page 13] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[13ページ]: '収集'属性構文2002年9月
2. Each member attribute is encoded as a sequence of two or more
values that appear to be part of a single multi-valued attribute,
i.e., 1setOf. The first value after the 'begCollection' value has
the attribute syntax, 'memberAttrName' (0x4A), and its value holds
the name of the first member attribute (e.g., "aaa"). The second
value holds the first member's attribute value, which can be of
any attribute syntax, except 'memberAttrName' or 'endCollection'.
If the first member's attribute value is multi-valued, the third
value holds the second value of the first member's value.
Otherwise, the third value holds the name of second member
attribute (e.g., "bbb"), and its attribute syntax is
'memberAttrName'. In this case, the fourth member's value is the
value of "bbb".
2. それぞれのメンバー属性はただ一つのマルチ評価された属性(すなわち、1setOf)の一部であるように見える2つ以上の値の系列としてコード化されます。 次々と'begCollection'の最初の値には、属性構文があります、'memberAttrName'(0x4A)、そして、値は最初のメンバー属性(例えば、"aaa")の名前を保持します。 'memberAttrName'か'endCollection'を除いて、2番目の値は第1代メンバーの属性値を保持します。(それは、どんな属性構文のものであることができます)。 第1代メンバーの属性値がマルチ評価されているなら、3番目の値は第1代メンバーの価値の2番目の値を保持します。 さもなければ、3番目の値は2番目のメンバー属性(例えば、"bbb")の名前を保持します、そして、属性構文は'memberAttrName'です。 この場合、第4代メンバーの値は"bbb"の値です。
Note that the technique of encoding a 'collection' as a '1setOf'
makes it easy for a Printer that doesn't support a particular
collection attribute (or the collection attribute syntax at all)
to simply skip over the entire collection value.
'1setOf'として'収集'をコード化するテクニックで単に全体の収集値を飛ばすのが特定の収集属性(または、全く収集属性構文)をサポートしないPrinterに簡単になることに注意してください。
3. The end of the collection is indicated with a value tag that MUST
be syntax type 'endCollection' (e.g., 0x37) and MAY have a zero
name length and a zero value length. In the future, this field
MAY contain useful information, such as the collection name that
matches the one in the 'begCollection' .
3. 収集の終わりは示されて、'endCollection'(例えば、0×37)と5月にはある構文タイプであるに違いない値のタグでゼロが長さを命名して、ゼロが長さを評価するということです。 将来、この分野は役に立つ情報を含むかもしれません、'begCollection'のものに合っている収集名などのように。
4. It is valid to have a member attribute that is itself, a
collection attribute, i.e., collections can be nested within
collections. This is represented by the occurrence of a member
attribute that is of attribute syntax type 'begCollection'. Such
a collection is terminated by a matching 'endCollection'. The
name of such a member attribute is in the immediately preceding
value, whose syntax type is 'memberAttrName'.
4. それ自体、収集属性、収集の中ですなわち、収集を入れ子にすることができるということであるメンバー属性を持っているのは有効です。 これは属性構文タイプ'begCollection'にはあるメンバー属性の発生によって表されます。 そのような収集は合っている'endCollection'によって終えられます。 構文タイプが'memberAttrName'であるすぐに前の値にはそのようなメンバー属性の名前があります。
5. It is valid for a collection attribute to be multi-valued, i.e.,
have more than one collection value. If the next attribute
immediately following the 'endCollection' has a zero name length
and a tag of 'begCollection', then the collection attribute is a
multi-valued collection, as with any attribute. This statement
applies to collections within collections and collections that are
not in collections.
5. 収集属性がマルチ評価されているのが、有効であり、すなわち、1つ以上の収集値を持ってください。 すぐに'endCollection'に続く次の属性がそうしたなら、ゼロは長さを命名します、そして、'begCollection'のタグであり、次に、収集属性はマルチ評価された収集です、どんな属性のようにも。 この声明は収集にない収集と収集の中の収集に適用されます。
7.2 Example encoding: "media-col" (collection)
7.2 例のコード化: 「メディアあん部」(収集)
The collection specified in section 5 is used for the encoding example shown in Table 5. The example also shows nested collections, since the "media-size" member attribute is a 'collection. The encoding example represents a blue 4x6-index card and takes 216 octets. The Appendices contain more complex examples.
セクション5で指定された収集はTable5に示されたコード化の例に使用されます。 また、例は、「メディアサイズ」メンバー属性が'収集'であるのに入れ子にされた収集を示しています。 コード化の例は、青い4×6インデクスカードを表して、216の八重奏を取ります。 Appendicesは、より複雑な例を含んでいます。
deBry, et. al. Standards Track [Page 14] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[14ページ]: '収集'属性構文2002年9月
Additional examples have been included in the appendices.
追加例は付録に含まれています。
The overall structure of the two collection values can be pictorially represented as:
以下として絵入りで2つの収集値の全体的な構造を表すことができます。
"media-col" =
{ "media-color" = 'blue';
"media-size" =
{ "x-dimension" = 6;
"y-dimension" = 4
}
},
「メディアあん部」は「x-寸法」=6 ; 「y-寸法」「メディア色」='青';「メディアサイズ」==4と等しいです。
The full encoding is in table 5. A simplified view of the encoding looks like this:
完全なコード化がテーブル5にあります。 コード化の簡易型の視点はこれに似ています:
Table 4 - Overview Encoding of "media-col" collection
テーブル4--「メディアあん部」収集の概要Encoding
Tag Value Name Value
タグ値の名前価値
begCollection media-col ""
begCollectionメディアあん部、「」
memberAttrName "" media-color
memberAttrName、「「メディア色」
keyword "" blue
キーワード、「「青」
memberAttrName "" media-size
memberAttrName、「「メディアサイズ」
begCollection "" ""
begCollection、「「「」」
memberAttrName "" x-dimension
memberAttrName、「「x-寸法」
integer "" 6
整数、「「6」
memberAttrName "" y-dimension
memberAttrName、「「y-寸法」
integer "" 4
整数、「「4」
endCollection "" ""
endCollection、「「「」」
endCollection "" ""
endCollection、「「「」」
deBry, et. al. Standards Track [Page 15] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[15ページ]: '収集'属性構文2002年9月
Table 5 - Example Encoding of "media-col" collection
テーブル5--「メディアあん部」収集の例のEncoding
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x34 begCollection value-tag beginning of the "media-
col" collection attribute
「メディアあん部」収集属性の0×34begCollection値タグ始まり
0x0009 name- length of (collection)
length attribute name
0×0009 (収集)長さ属性名の名前の長さ
media-col media-col name name of (collection)
attribute
(収集)属性のメディアあん部メディアあん部名前名
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
0x4A memberAttrName value-tag starts a new member
attribute: "media-color"
0x4A memberAttrName値タグは新しいメンバー属性を始めます: 「メディア色」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x000B value- length of "media-color"
length keyword
0x000B値「メディア色」長さのキーワードの長さ
media-color media-color value value is name of 1st
member attribute
メディア色のメディア色の値の価値は最初のメンバー属性の名前です。
0x44 keyword type value-tag keyword type
0×44 キーワードタイプ値タグキーワードタイプ
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
deBry, et. al. Standards Track [Page 16] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[16ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x0004 value-
length
0×0004 値の長さ
blue blue value value of 1st member
attribute
最初のメンバー属性の青い青い値の値
0x4A memberAttrName value-tag starts a new member
attribute: "media-size"
0x4A memberAttrName値タグは新しいメンバー属性を始めます: 「メディアサイズ」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x000A value- length of "media-size"
length keyword
0x000A値「メディアサイズ」長さのキーワードの長さ
media-size media-size value Name of 2nd member
attribute
2番目のメンバー属性のメディアサイズメディアサイズ値のName
0x34 begCollection value-tag Beginning of the "media-
size" collection attribute
which is a sub-collection
0×34 サブ収集である「メディアサイズ」収集属性のbegCollection値タグBeginning
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0000 value- collection attribute names
length have no value
値の収集属性が長さと命名する0×0000は値を全く持っていません。
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
0x4A memberAttrName value-tag starts a new member
attribute: "x-dimension"
0x4A memberAttrName値タグは新しいメンバー属性を始めます: 「x-寸法」
deBry, et. al. Standards Track [Page 17] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[17ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x000B value- length of "x-dimension"
length keyword
0x000B値「x-寸法」長さのキーワードの長さ
x-dimension x-dimension value name of 1st sub-
collection member
attribute
最初のサブ収集メンバー属性のx-寸法x-寸法値の名
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
0x0006 value value of 1st sub-
collection member
attribute
0×0006 最初のサブ収集メンバー属性の値の値
0x4A memberAttrName value-tag starts a new member
attribute: "y-dimension"
0x4A memberAttrName値タグは新しいメンバー属性を始めます: 「y-寸法」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x000B value- length of the "y-
length dimension" keyword
0x000B値「y長さの寸法」キーワードの長さ
deBry, et. al. Standards Track [Page 18] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[18ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
y-dimension y-dimension value name of 2nd sub-
collection member
attribute
2番目のサブ収集メンバー属性のy-寸法y-寸法値の名
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
0x0004 value value of 2nd sub-
collection member
attribute
0×0004 2番目のサブ収集メンバー属性の値の値
0x37 endCollection value-tag end of the sub-collection
0×37サブ収集のendCollection値最後尾
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
0x37 endCollection value-tag end of the 1st collection
value in 1setOf
0×37 1setOfにおける最初の収集価値のendCollection値最後尾
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
deBry, et. al. Standards Track [Page 19] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[19ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
8 Legacy issues
8 レガシー問題
IPP 1.x Printers and Clients will gracefully ignore collections and its member attributes if it does not understand the collection. The begCollection and endCollection elements each look like an attribute with an attribute syntax that the recipient doesn't support and so should ignore the entire attribute. The individual member attributes and their values will look like a 1setOf values of the collection attribute, so that the Printer simply ignores the entire attribute and all of its values. Returning unsupported attributes is also simple, since only the name of the collection attribute is returned with the 'unsupported' out-of-band value (see section 4.2).
収集を理解していないと、IPP 1.x PrintersとClientsは優雅に収集とそのメンバー属性を無視するでしょう。 それぞれbegCollectionとendCollection要素は、受取人がサポートしない属性構文がある属性に似ているので、全体の属性を無視するはずです。 個人会員属性とそれらの値は収集属性の1setOf値に似るでしょう、Printerが単に値の全体の属性とすべてを無視するように。 また、サポートされない属性を返すのも簡単です、バンドで出ている'サポートされない'値と共に収集属性の名前だけを返すので(セクション4.2を見てください)。
9 IANA Considerations
9 IANA問題
The following table provides registration for the 'collection' attribute syntax defined in this document. This is to be registered according to the procedures in RFC 2911 [RFC2911] section 6.3.
以下のテーブルは本書では定義された'収集'属性構文のための登録を提供します。 RFC2911[RFC2911]部6.3の手順によると、これは登録されることになっています。
Tag value: Attribute Syntaxes: Ref. Section:
collection RFC 3382 3
0x34 begCollection RFC 3382 7.1
0x37 endCollection RFC 3382 7.1
0x4A memberAttrName RFC 3382 7.1
値にタグ付けをしてください: 構文を結果と考えてください: 審判。 セクション: 収集RFC3382 3 0×34begCollection RFC3382 7.1 0×37endCollection RFC3382 7.1 0x4A memberAttrName RFC3382 7.1
The resulting attribute syntax registration will be published in the http://www.iana.org/assignments/ipp-registrations registry.
結果として起こる属性構文登録は http://www.iana.org/assignments/ipp-registrations 登録で発行されるでしょう。
10 Internationalization Considerations
10 国際化問題
This attribute syntax by itself has no impact on internationalization. However, the member attributes that are subsequently defined for use in a collection may have internationalization considerations, as may any attribute, according to [RFC2911].
それ自体でこの属性構文は国際化に影響力を全く持っていません。 しかしながら、次に収集における使用のために定義されるメンバー属性は国際化問題を持っているかもしれません、どんな属性であるかもしれないことのようにも、[RFC2911]に従って。
deBry, et. al. Standards Track [Page 20] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[20ページ]: '収集'属性構文2002年9月
11 Security Considerations
11 セキュリティ問題
This attribute syntax causes no more security concerns than any other attribute syntax. It is only the attributes that are subsequently defined, to use this or any other attribute syntax, that may have security concerns, depending on the semantics of the attribute, according to [RFC2911].
この属性構文はいかなる他の属性構文が安全上の配慮でないことのようなどんな安全上の配慮も引き起こしません。 唯一のそれは次に、これかいかなる他の属性構文も使用するために定義されて、安全上の配慮を持っているかもしれない属性です、属性の意味論によって、[RFC2911]に従って。
12 References
12の参照箇所
12.1 Normative References
12.1 標準の参照
[RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
Printing Protocol/1.1: Encoding and Transport", RFC 2910,
September 2000.
[RFC2910] エリオとR.とバトラーとS.とムーアとP.とR.ターナー、「プロトコル/1.1に以下を印刷するインターネット」 「コード化と輸送」、RFC2910、9月2000日
[RFC2911] Isaacson, S., deBry, R., Hastings, T., Herriot, R. and P.
Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC 2911, September 2000.
[RFC2911] イサクソンとS.とdeBryとR.とヘイスティングズとT.とエリオとR.とP.パウエル、「プロトコル/1.1に以下を印刷するインターネット」 「モデルと意味論」、RFC2911、9月2000日
12.2 Informative References
12.2 有益な参照
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
Printing Protocol/1.0: Encoding and Transport", RFC 2565,
April 1999.
[RFC2565] エリオとR.とバトラーとS.とムーアとP.とR.チューナー、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日
[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", RFC 2567, 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月」。
[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C. and H.
Holst, "Internet Printing Protocol/1.1: Implementor's
Guide", RFC 3196, November 2001.
[RFC3196] ヘイスティングズとT.とManrosとC.とZehlerとP.とクーグラーとC.とH.ホルスト、「プロトコル/1.1に以下を印刷するインターネット」 「作成者のガイド」、RFC3196、2001年11月。
deBry, et. al. Standards Track [Page 21] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[21ページ]: '収集'属性構文2002年9月
Appendix A: Encoding Example of a Simple Collection (Informative)
付録A: 簡単な収集に関する例をコード化します。(有益)です。
The overall structure of the collection value can be pictorially represented as:
以下として絵入りで収集価値の全体的な構造を表すことができます。
"media-size" =
{ "x-dimension" = 6;
"y-dimension" = 4
}
「メディアサイズ」=「x-寸法」=6 ; 「y-寸法」=4
A simplified view of the encoding would look like this:
コード化の簡易型の視点はこれに似ているでしょう:
Table 6 - Overview Encoding of simple collection
テーブル6--簡単な収集の概要Encoding
Tag Value Name Value
タグ値の名前価値
begCollection media-size ""
begCollectionメディアサイズ、「」
memberAttrName "" x-dimension
memberAttrName、「「x-寸法」
integer "" 6
整数、「「6」
memberAttrName "" y-dimension
memberAttrName、「「y-寸法」
integer "" 4
整数、「「4」
endCollection "" ""
endCollection、「「「」」
Note: "" represents a name or value whose length is 0.
以下に注意してください。 「「長さが0である名前か値を表します」。
Table 7 - Example Encoding of simple collection
テーブル7--簡単な収集の例のEncoding
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x34 begCollection value-tag beginning of the "media-
size" collection attribute
「メディアサイズ」収集属性の0×34begCollection値タグ始まり
0x000A name- length of (collection)
length attribute name
0x000A名(収集)長さ属性名の長さ
media-size media-size name name of (collection)
attribute
(収集)属性のメディアサイズメディアサイズ名前名
deBry, et. al. Standards Track [Page 22] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[22ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
0x4A memberAttrName value-tag starts member attribute:
"x-dimension"
0x4A memberAttrName値タグはメンバー属性を始めます: 「x-寸法」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x000B value- length of "x-dimension"
length keyword
0x000B値「x-寸法」長さのキーワードの長さ
x-dimension x-dimension value name of 1st collection
member attribute
最初の収集メンバー属性のx-寸法x-寸法値の名
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
0x0006 value value of 1st collection
member attribute
0×0006 最初の収集メンバー属性の値の値
0x4A memberAttrName value-tag starts a new member
attribute: "y-dimension"
0x4A memberAttrName値タグは新しいメンバー属性を始めます: 「y-寸法」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
deBry, et. al. Standards Track [Page 23] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[23ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x000B value- length of the "y-
length dimension" keyword
0x000B値「y長さの寸法」キーワードの長さ
y-dimension y-dimension value name of 2nd collection
member attribute
2番目の収集メンバー属性のy-寸法y-寸法値の名
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf for
length media-size
0×0000 名前0は長さのメディアサイズのために1setOfを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
0x0004 value value of 2nd collection
member attribute
0×0004 2番目の収集メンバー属性の値の値
0x37 endCollection value-tag end of the collection
0×37収集のendCollection値最後尾
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
deBry, et. al. Standards Track [Page 24] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[24ページ]: '収集'属性構文2002年9月
Appendix B: Encoding Example of 1setOf Collection (Informative)
付録B: 1setOf収集に関する例をコード化します。(有益)です。
The overall structure of the collection value can be pictorially represented as:
以下として絵入りで収集価値の全体的な構造を表すことができます。
"media-size-supported" =
{ "x-dimension" = 6;
"y-dimension" = 4
},
{ "x-dimension" = 3;
"y-dimension" = 5
};
「サイズがサポートしたメディア」が「x-寸法」=6 ; 「y-寸法」=4と等しい、「x-寸法」=3 ; 「y-寸法」=5。
A simplified view of the encoding would look like this:
コード化の簡易型の視点はこれに似ているでしょう:
Table 8 - Overview Encoding of 1setOf collection
テーブル8--1setOf収集の概要Encoding
Tag Value Name Value
タグ値の名前価値
begCollection media-size- ""
supported
begCollectionメディアサイズ、-、「「サポートされます」。
memberAttrName "" x-dimension
memberAttrName、「「x-寸法」
integer "" 6
整数、「「6」
memberAttrName "" y-dimension
memberAttrName、「「y-寸法」
integer "" 4
整数、「「4」
endCollection "" ""
endCollection、「「「」」
begCollection "" ""
begCollection、「「「」」
memberAttrName "" x-dimension
memberAttrName、「「x-寸法」
integer "" 3
整数、「「3」
memberAttrName "" y-dimension
memberAttrName、「「y-寸法」
integer "" 5
整数、「「5」
endCollection "" ""
endCollection、「「「」」
deBry, et. al. Standards Track [Page 25] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[25ページ]: '収集'属性構文2002年9月
Table 9 - Example Encoding of 1setOf collection
テーブル9--1setOf収集の例のEncoding
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x34 begCollection value-tag beginning of the "media-
size-supported (1setOf
collection" attribute
0×34begCollection値タグ始め、「メディアがサイズでサポートした、(1setOf収集、」 属性
0x00014 name- length of (collection)
length attribute name
0×00014 (収集)長さ属性名の名前の長さ
media-size- media-size- name name of (collection)
supported supported attribute
(収集)の名前がサポートしたメディアサイズメディアサイズ名は属性をサポートしました。
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
0x4A memberAttrName value-tag starts member attribute:
"x-dimension"
0x4A memberAttrName値タグはメンバー属性を始めます: 「x-寸法」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x000B value- length of "x-dimension"
length keyword
0x000B値「x-寸法」長さのキーワードの長さ
x-dimension x-dimension value name of 1st collection
member attribute
最初の収集メンバー属性のx-寸法x-寸法値の名
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
deBry, et. al. Standards Track [Page 26] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[26ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
0x0006 value value of 1st collection
member attribute
0×0006 最初の収集メンバー属性の値の値
0x4A memberAttrName value-tag starts member attribute:
"y-dimension"
0x4A memberAttrName値タグはメンバー属性を始めます: 「y-寸法」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x000B value- length of the "y-
length dimension" keyword
0x000B値「y長さの寸法」キーワードの長さ
y-dimension y-dimension value name of 2nd collection
member attribute
2番目の収集メンバー属性のy-寸法y-寸法値の名
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
0x0004 value value of 2nd collection
member attribute
0×0004 2番目の収集メンバー属性の値の値
0x37 endCollection value-tag end of the collection
0×37収集のendCollection値最後尾
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
deBry, et. al. Standards Track [Page 27] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[27ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
0x34 begCollection value-tag beginning of the 2nd
member of the 1setOf
"sizes-avail " collection
attribute
第2代「サイズで役に立ってください」という1setOf収集属性のメンバーの0×34begCollection値タグ始まり
0x0000 name- Zero length name indicates
length this is member of previous
attribute
0×0000名前ゼロ・レングス名が長さを示す、前の属性のメンバー
name no name (since name-length
was 0)
名前を全く挙げないでください。(名前長さが0であったので)
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
0x4A memberAttrName value-tag starts member attribute:
"x-dimension"
0x4A memberAttrName値タグはメンバー属性を始めます: 「x-寸法」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x000B value- length of "x-dimension"
length keyword
0x000B値「x-寸法」長さのキーワードの長さ
x-dimension x-dimension value name of 1st collection
member attribute
最初の収集メンバー属性のx-寸法x-寸法値の名
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
deBry, et. al. Standards Track [Page 28] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[28ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
0x0003 value value of 1st collection
member attribute
0×0003 最初の収集メンバー属性の値の値
0x4A memberAttrName value-tag starts member attribute:
"y-dimension"
0x4A memberAttrName値タグはメンバー属性を始めます: 「y-寸法」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x000B value- length of the "y-
length dimension" keyword
0x000B値「y長さの寸法」キーワードの長さ
y-dimension y-dimension value name of 2nd collection
member attribute
2番目の収集メンバー属性のy-寸法y-寸法値の名
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
0x0005 value value of 2nd collection
member attribute
0×0005 2番目の収集メンバー属性の値の値
deBry, et. al. Standards Track [Page 29] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[29ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x37 endCollection value-tag end of the 1setOf
collection value
0×37 1setOf収集価値のendCollection値最後尾
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
deBry, et. al. Standards Track [Page 30] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[30ページ]: '収集'属性構文2002年9月
Appendix C: Encoding Example of Collection containing 1setOf XXX
attribute (Informative)
付録C: 1setOf XXX属性を含むCollectionのExampleをコード化します。(有益)です。
The overall structure of the collection value can be pictorially represented as:
以下として絵入りで収集価値の全体的な構造を表すことができます。
"wagons" =
{ "colors" = red, blue;
"sizes" = 4, 6, 8
}
「ワゴン」={「色」は赤、青と等しいです; 4、6、「サイズ」=8}
A simplified view of the encoding would look like this:
コード化の簡易型の視点はこれに似ているでしょう:
Table 10 - Overview Encoding of collection with 1setOf value
テーブル10--1setOf値がある収集の概要Encoding
Tag Value Name Value
タグ値の名前価値
begCollection wagons ""
begCollectionワゴン、「」
memberAttrName "" colors
memberAttrName、「「色」
keyword "" red
キーワード、「「赤」
keyword "" blue
キーワード、「「青」
memberAttrName "" sizes
memberAttrName、「「サイズ」
integer "" 4
整数、「「4」
integer "" 6
整数、「「6」
integer "" 8
整数、「「8」
endCollection "" ""
endCollection、「「「」」
deBry, et. al. Standards Track [Page 31] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[31ページ]: '収集'属性構文2002年9月
Table 11 - Example Encoding of collection with 1setOf value
テーブル11--1setOf値がある収集の例のEncoding
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x34 begCollection value-tag beginning of the "wagons"
collection attribute
「ワゴン」収集属性の0×34begCollection値タグ始まり
0x0005 name- length of (collection)
length attribute name
0×0005 (収集)長さ属性名の名前の長さ
wagons wagons name name of (collection)
attribute
ワゴンワゴンは(収集)の名前を属性に挙げます。
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
0x4A memberAttrName value-tag starts a new member
attribute: "colors"
0x4A memberAttrName値タグは新しいメンバー属性を始めます: 「色」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0006 value- length of "colors" keyword
length
0×0006 「色」キーワードの長さの値の長さ
colors colors value value is name of 1st
member attribute
色の色の値の価値は最初のメンバー属性の名前です。
0x44 keyword type value-tag keyword type
0×44 キーワードタイプ値タグキーワードタイプ
0x0000 name- 0 indicates 1setOf wagons
length
0×0000 名前0は1setOfワゴンの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value-
length
0×0004 値の長さ
deBry, et. al. Standards Track [Page 32] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[32ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
blue blue value value of 1st member
attribute
最初のメンバー属性の青い青い値の値
0x44 keyword type value-tag keyword type
0×44 キーワードタイプ値タグキーワードタイプ
0x0000 name- 0 indicates 1setOf wagons
length
0×0000 名前0は1setOfワゴンの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0003 value-
length
0×0003 値の長さ
red red value value of 1st member
attribute
最初のメンバー属性の赤い赤い値の値
0x4A memberAttrName value-tag starts a new member
attribute: "sizes"
0x4A memberAttrName値タグは新しいメンバー属性を始めます: 「サイズ」
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0005 value- length of "length-avail"
length keyword
0×0005 「長さ利益」長さのキーワードの値の長さ
sizes sizes value Name of 2nd member
attribute
2番目のメンバー属性のサイズサイズ値のName
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf wagons
length
0×0000 名前0は1setOfワゴンの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
deBry, et. al. Standards Track [Page 33] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[33ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
0x0004 value 1st value for 1setOf
integer attribute
0×0004は1setOf整数属性のために最初の値を評価します。
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value-
length length of an integer = 4
0×0004 整数=4の値の長さの長さ
0x0006 value 2nd value for 1setOf
integer attribute
0×0006は1setOf整数属性のために2番目の値を評価します。
0x21 integer type value-tag attribute type
0×21 整数型値タグ属性タイプ
0x0000 name- 0 indicates 1setOf
length
0×0000 名前0は1setOfの長さを示します。
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0004 value- length of an integer = 4
length
0×0004 整数の値の長さは4の長さと等しいです。
0x0008 value 3rd value for 1setOf
integer attribute
0×0008は1setOf整数属性のために3番目の値を評価します。
0x37 endCollection value-tag end of the collection
0×37収集のendCollection値最後尾
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
この長さのタイプのための0であるので離れるために定義された0×0000名(1setOf)
no name (since name-length
was 0)
名前がありません。(名前長さが0であったので)
0x0000 value- defined to be 0 for this
length type
0×0000 この長さのタイプのための0になるように定義された値
deBry, et. al. Standards Track [Page 34] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[34ページ]: '収集'属性構文2002年9月
Octets Symbolic Value Protocol comments
field
コメントがさばく八重奏Symbolic Valueプロトコル
no value (since value-
length was 0)
値がありません。(値の長さが0であったので)
Appendix D: Description of the Base IPP Documents (Informative)
付録D: 基地のIPPドキュメントの記述(有益)です。
The base 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 [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
Mapping between LPD and IPP Protocols [RFC2569]
構造とモデルのためのインターネット印刷プロトコル[RFC2567]原理とインターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/1.1のためのプロトコルの目標を設計してください: モデルと意味論[RFC2911]インターネット印刷プロトコル/1.1: コード化と輸送[RFC2910]インターネット印刷プロトコル/1.1: LPDとIPPの間でプロトコルを写像するImplementerのガイド[RFC3196][RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator operations have been added to IPP/1.1 [RFC2911, RFC2910].
「インターネット印刷プロトコルのデザイン目標」ドキュメントは分散印刷の機能性への広い一見を取ります、そして、それは印刷プロトコルに含まれる必要がある特徴をインターネットにはっきりさせるのを助ける現実のシナリオを列挙します。 それは3つのタイプのユーザのための要件を特定します: エンドユーザ、オペレータ、および管理者。 それはIPP/1.0[RFC2566、RFC2565]で満たされているエンドユーザ要件の部分集合を呼び出します。 いくつかのOPTIONALオペレータ操作がIPP/1.1[RFC2911、RFC2910]に加えられます。
The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document 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 IPP working group's major decisions.
「構造とモデルのための原理とインターネット印刷プロトコルのためのプロトコル」ドキュメントは、高い平らな視点からIPPについて説明して、IPP仕様ドキュメントのスイートを形成する様々なドキュメントのために道路地図を定義して、IETF IPPワーキンググループの主たる決定のためにバックグラウンドと原理を与えます。
The "Internet Printing Protocol/1.1: Model and Semantics" document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
「プロトコル/1.1に以下を印刷するインターネット」 「モデルとSemantics」というドキュメントは抽象的な物、それらの属性、および彼らの操作で簡易型のモデルについて説明します。 モデルはPrinterとJobを導入します。 Jobは複数の1Jobあたりのドキュメントを支えます。 また、モデルドキュメントはセキュリティ、国際化、およびディレクトリ問題がどう記述されるかを記述します。
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It also defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines the 'ipp' scheme for identifying IPP printers and jobs.
「プロトコル/1.1に以下を印刷するインターネット」 「コード化とTransport」というドキュメントはモデルドキュメントでHTTP/1.1[RFC2616]と定義された抽象的な操作と属性の正式なマッピングです。 また、それはメディアタイプが「アプリケーション/ipp」と呼んだ新しいインターネットMIMEのために符号化規則を定義します。 また、このドキュメントは、HTTPの上でコンテントタイプが「アプリケーション/ipp」であるメッセージ本体を輸送するために規則を決めます。 このドキュメントはIPPプリンタと仕事を特定することの'ipp'計画を定義します。
deBry, et. al. Standards Track [Page 35] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[35ページ]: '収集'属性構文2002年9月
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
「プロトコル/1.1に以下を印刷するインターネット」 」 ドキュメントが洞察とアドバイスを与える「のImplementerガイドはIPPクライアントとIPPのimplementersに反対します。 彼らが彼らのクライアント、そして/または、IPP物の実現のデザインにそれらを助けるかもしれない問題のIPP/1.1といくつかを理解しているのを助けるのは意図しています。 例えば、誤りを含んでいるのがチェックして、処理要求の典型的な注文を与えます。 また、仕様決定のいくつかに関する動機は含まれています。
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
「LPDとIPPの間でプロトコルを写像します」ドキュメントはIPPとLPD(線Printer Daemon)実現の間で何らかのアドバイスをゲートウェイのimplementersに与えます。
Authors' Addresses
作者のアドレス
Roger deBry Utah Valley State College Orem, UT 84058
ロジャー・deBryユタバレー州立大学オレーム、ユタ 84058
Phone: (801) 222-8000 EMail: debryro@uvsc.edu
以下に電話をしてください。 (801) 222-8000 メールしてください: debryro@uvsc.edu
Tom Hastings Xerox Corporation 737 Hawaii St. ESAE 231 El Segundo, CA 90245
エルセガンド、トムヘイスティングズゼロックス社737のハワイ通りESAE231カリフォルニア 90245
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
Robert Herriot Consultant 706 Colorado Ave Palo Alto, CA 94303
Aveパロアルト、ロバートエリオコンサルタント706Coloradoカリフォルニア 94303
Phone: 650-327-4466 Fax: 650-327-4466 EMail: bob@herriot.com
以下に電話をしてください。 650-327-4466 Fax: 650-327-4466 メールしてください: bob@herriot.com
deBry, et. al. Standards Track [Page 36] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[36ページ]: '収集'属性構文2002年9月
Kirk Ocke Xerox Corp. 800 Phillips Rd M/S 128-30E Webster, NY 14580
カークOckeゼロックス社800のフィリップスM/第S128-30Eウェブスター、ニューヨーク 14580
Phone: (585) 442-4832 EMail: KOcke@crt.xerox.com
以下に電話をしてください。 (585) 442-4832 メールしてください: KOcke@crt.xerox.com
Peter Zehler Xerox Corp. 800 Phillips Rd M/S 128-30E Webster, NY 14580
ピーターZehlerゼロックス社800のフィリップスM/第S128-30Eウェブスター、ニューヨーク 14580
Phone: (585) 265-8755 EMail: PZehler@crt.xerox.com
以下に電話をしてください。 (585) 265-8755 メールしてください: PZehler@crt.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:
ippメーリングリストに加入するには、以下のメールを送ってください:
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
1) 2が)3が)以下の2つの線をメッセージ本体に入れる件名空白を出る majordomo@pwg.org にそれを送ってください: ippエンドを申し込んでください。
Implementers of this specification document are encouraged to join the IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values. In order to reduce spam the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the mailing list.
この仕様ドキュメントのImplementersが明確化問題のどんな議論と追加属性と値のための登録提案のレビューにも参加するためにIPP Mailing Listを接合するよう奨励されます。 メーリングリスト廃棄物が非加入者から郵送するスパムを減少させて、したがって、あなたは、質問やご意見をメーリングリストに送るためにメーリングリストに加入しなければなりません。
deBry, et. al. Standards Track [Page 37] RFC 3382 IPP: The 'collection' attribute syntax September 2002
et deBry、アル。 規格はRFC3382IPPを追跡します[37ページ]: '収集'属性構文2002年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。
deBry, et. al. Standards Track [Page 38]
et deBry、アル。 標準化過程[38ページ]
一覧
スポンサーリンク
