Network Working Group K. Holtman
Request for Comments: 2506 TUE
BCP: 31 A. Mutz
Category: Best Current Practice Hewlett-Packard
T. Hardie
Equinix
March 1999
Media Feature Tag Registration Procedure
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
ABSTRACT
抽象
Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved.
World Wide Webなどの最近のインターネットアプリケーションは、データ形式、クライアントとサーバープラットフォーム、および地域社会に大きな多様性を結びつけます。これは、当事者の能力や好みに情報の形式を識別し、調整するために、メディア機能の説明と交渉メカニズムの必要性を作成しました。
Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration.
拡張可能なメディア機能の識別と交渉メカニズムは正メディア機能を識別するために共通の語彙を必要とします。メディア機能のための登録プロセスと権限は、通信する当事者間でこの語彙を共有することを意図して定義されます。また、URIツリーは登録なしメディア機能の定義の共有を可能にするために定義されています。
This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary.
この文書では、メディア特徴ボキャブラリーのための中央レジストリとして、インターネット割り当て番号機関（IANA）を使用して登録手続きを定義します。
Please send comments to the CONNEG working group at <ietf-medfree@imc.org>. Discussions of the working group are archived at <URL: http://www.imc.org/ietf-medfree/>.
<ietf-medfree@imc.org>でCONNEGワーキンググループにコメントを送ってください。ワーキンググループの議論は、<：http://www.imc.org/ietf-medfree/ URL>でアーカイブされます。
TABLE OF CONTENTS
目次
1 Introduction ................................................. 2
2 Media feature tag definitions ................................ 3
2.1 Media feature tag purpose ................................. 3
2.2 Media feature tag syntax .................................. 4
2.3 Media feature tag values .................................. 4
2.4 ASN.1 identifiers for media feature tags ................. 5
3 Media feature tag registration ............................... 5
3.1 Registration trees ........................................ 6
3.1.1 IETF tree ............................................... 6
3.1.2 Global tree ............................................. 6
3.1.3 URL tree ................................................ 6
3.1.4 Additional registration trees ........................... 7
3.2 Location of registered media feature tag list ............. 7
3.3 IANA procedures for registering media feature tags ........ 7
3.4 Registration template ..................................... 7
4 Security Considerations ...................................... 10
5 Acknowledgments .............................................. 10
6 References ................................................... 10
7 Authors' Addresses ........................................... 11
8 Full Copyright Statement ..................................... 12
1 Introduction
1はじめに
Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved.
World Wide Webなどの最近のインターネットアプリケーションは、データ形式、クライアントとサーバープラットフォーム、および地域社会に大きな多様性を結びつけます。これは、当事者の能力や好みに情報の形式を識別し、調整するために、メディア機能の説明と交渉メカニズムの必要性を作成しました。
Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration.
拡張可能なメディア機能の識別と交渉メカニズムは正メディア機能を識別するために共通の語彙を必要とします。メディア機能のための登録プロセスと権限は、通信する当事者間でこの語彙を共有することを意図して定義されます。また、URIツリーは登録なしメディア機能の定義の共有を可能にするために定義されています。
This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary.
この文書では、メディア特徴ボキャブラリーのための中央レジストリとして、インターネット割り当て番号機関（IANA）を使用して登録手続きを定義します。
This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT and MAY according to usage described in [8].
この文書は、、および[8]に記載の使用状況に応じては限らないべきでSHOULD NOT MUST MUST用語を使用します。
2 Media feature tag definitions
2つのメディアフィーチャータグの定義
Media feature tags represent individual and simple characteristics related to media capabilities or properties associated with the resource to which they are applied. Examples of such features are:
メディア特徴タグは、それらが適用されるリソースに関連付けられたメディア機能や特性に関連個人や簡単な特性を表します。そのような特徴の例は以下のとおりです。
* the color depth of the screen on which something is to be displayed * the type of paper available in a printer * the support of the `floating 5 dimensional tables' feature * the fonts which are available to the recipient * the capability to display graphical content
*何かが表示される画面の色深度*プリンタで利用可能な用紙の種類* `フローティング5次元のテーブル機能のサポート*受信者*グラフィックを表示する機能が使用可能なフォントコンテンツ
Each media feature tag identifies a single characteristic. Values associated with a specific tag must use the data type defined for that tag. The list of allowed data types is presented below, in section 2.3.
各メディア特徴タグは、単一の特性を識別します。特定のタグに関連付けられた値は、そのタグに対して定義されたデータ型を使用する必要があります。許可されるデータ型のリストは、2.3節で、以下に示します。
Examples of media feature tags with values are:
値を持つメディア特徴タグの例は以下のとおりです。
* the width of a display in pixels per centimeter represented as an integer value. * a font available to a recipient, selected from an enumerated list. * the version of a protocol composed of integers "i.j.k", defined as either a value in an enumerated list or with a defined mapping to make the value isomorphic to a subset of integers (e.g. i*100 + j*10 +k, assuming j<=9 and k<=9).
*整数値として表さセンチメートルあたりのピクセルの表示の幅。 *列挙されたリストから選択された受信者に利用可能なフォント、。 *整数の部分集合と同型値を作るために列挙されたリストまたは定義されたマッピングとの値のいずれかとして定義された整数からなるプロトコルのバージョン「IJK」、（例えば、I * 100 + J * 10 + K、仮定J <= 9、K <= 9）。
Further examples of media feature tags are defined in detail elsewhere [4].
メディア特徴タグのさらなる例は、他の場所で詳細に定義されている[4]。
Feature collections may be composed using a number of individual feature tags [2]. Composition of feature collections is described elsewhere [2]. Examples of feature collections requiring multiple media feature tags are:
機能コレクションは、個々の特徴タグ[2]の番号を使用して構成されてもよいです。機能コレクションの組成物は、他の場所に記載されている[2]。複数のメディア特徴タグが必要な機能のコレクションの例は以下のとおりです。
* the set of all fonts used by a document * the width and height of a display * the combination of color depth and resolution a display can support
*文書で使用されるすべてのフォントの集合*ディスプレイの幅と高さ*色深度と分解能の組み合わせ表示をサポートすることができ
This registry presumes the availability of the MIME media type registry, and MIME media types MUST NOT be re-registered as media feature tags. Media feature tags which are currently in use by individual protocols or applications MAY be registered with this registry if they might be applied outside of their current domain.
このレジストリは、MIMEメディアタイプレジストリの可用性を前提とし、MIMEメディアタイプは、メディア特徴タグとして再登録してはなりません。彼らは現在のドメインの外に適用される可能性がある場合、個々のプロトコルまたはアプリケーションによって現在使用されているメディア特徴タグは、このレジストリに登録されるかもしれません。
The media feature tag namespace is not bound to a particular transport protocol or capability exchange mechanism. The registry is limited, however, to feature tags which express a capability or preference related to how content is presented. Feature tags related to other axes of negotiation are not appropriate for this registry. Capability exchange mechanisms may, of course, be used to express a variety of capabilities or preferences.
メディア特徴タグの名前空間は、特定のトランスポートプロトコルや能力交換メカニズムにバインドされていません。レジストリは、コンテンツが提示される方法に関連する能力や嗜好を表現する特徴タグに、しかし、制限されています。交渉の他の軸に関連する機能のタグは、このレジストリには適していません。能力交換メカニズムは、もちろん、能力または嗜好の多様を発現するために使用され得ます。
A media feature tag is a string consisting of one or more of the following US-ASCII characters: uppercase letters, lowercase letters, digits, colon (":"), slash ("/"), dot (".") percent ("%"), and dash ("-"). Feature tags are case-insensitive. Dots are understood to potentially imply hierarchy; a feature can be subtyped by describing it as tree.feature.subfeature and by indicating this in the registration. Tags should begin with an alphabetic character.
大文字、小文字、数字、コロン（「：」）メディア特徴タグは、次のUS-ASCII文字の一つ以上からなる文字列です（「」）、（「/」）スラッシュドットパーセント（ "％"）、およびダッシュ（ " - "）。フィーチャータグは大文字と小文字を区別しません。ドットは、潜在的に階層を意味すると理解されます。特徴はtree.feature.subfeatureとしてそれを記述することによって、登録中にこれを示すことによってサブタイプすることができます。タグは、英字で始める必要があります。
In ABNF [6], this may be represented as:
ABNF [6]、これはのように表すことができます。
Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" )
フィーチャータグ= ALPHA *（ALPHA / DIGIT / "：" / "/" / / " - " / "％" ""）
Registrants should take care to avoid creating tags which might conflict with the creation of new registration trees; in general this means avoiding tags which begin with an alphabetic character followed by a dot. The current registration trees are described in section 3 below.
登録者には、新規登録の木の作成と競合する可能性のあるタグを作成しないように注意する必要があります。一般的に、これはドットが続くアルファベットで始まるタグを避けることを意味します。現在の登録ツリーは以下のセクション3に記載されています。
The registry will initially support the use of the following data types as tag values:
レジストリは、最初にタグ値として以下のデータ型の使用をサポートします：
- signed integers - rational numbers - tokens, with equality relationship - tokens, with defined ordering relationship - strings, with standard (octet-by-octet) equality relationship - strings, with defined equality and/or comparison relationship
- 符号付き整数 - 有理数 - 平等の関係を持つトークン、 - 定義された順序関係を持つトークン、 - 文字列、定義された平等および/または比較関係に - 標準（オクテット・バイ・オクテット）平等な関係を持つ文字列を、
"Token" here means the token data type as defined by [7], which may be summarized as:
「トークン」は、ここでのように要約することができる[7]で定義されるようにトークンデータ型を意味します。
token = 1*<any CHAR except CTLs or tspecials>
トークン= 1 * <的CTLまたはtspecialsを除く任意のCHAR>
tspecials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> / "/" / "[" / "]" / "?" / "=" / "{" / "}" / SP / HT
tspecials = "（" / "）" / "<" / ">" / "@" / "" / ";" / "：" / "\" / < "> / "/"/ "["/ "]"/ ""/ "="/ "{"/ "}"/ SP / HT
At the time of registration, each tag must be associated with a single data type. If that data type implies a defined comparison or an ordering, the registrant must define the ordering or comparison. For ordered tokens, this may be by full enumeration of the tokens and their order or by reference to an ordering mechanism. For defined comparisons, a full description of the rules for comparison must be provided or included by reference.
登録時に、各タグは、単一のデータ・タイプに関連付けられなければなりません。そのデータ型が定義された比較や順序を意味している場合、登録者は、発注や比較を定義する必要があります。注文したトークンのために、これは完全なトークンを列挙し、その順序によって、または発注メカニズムへの参照によるものであってもよいです。定義比較のために、比較のための規則の完全な説明は、参照することにより提供または含まれていなければなりません。
Media feature tags related to spatial or temporal characteristics must be registered with a single canonical unit. It is strongly preferred that units be in the SI system; where current practice has defined units in other systems (such as pixels per inch), a conversion method to SI units must be provided. Conversion methods should include a defined rounding practice.
空間的または時間的特性に関連したメディア特徴タグは、単一の標準ユニットに登録する必要があります。ことを強く単位がSIシステムであることが好ましいです。現在の慣行は、（例えば、インチあたりのピクセルのような）他のシステム内のユニットを定義した場合、SI単位に変換する方法が提供されなければなりません。変換方法は、定義された丸め練習を含める必要があります。
Certain protocols use ASN.1 identifiers rather than human-readable representations for capability exchange. In order to allow both systems to interoperate, registrants may provide an ASN.1 identifier or ask that IANA assign an ASN.1 identifier during registration. These identifiers are not required for registration, but may provide assistance to those building gateways or other cross-protocol systems. Note that ASN.1 identifiers assigned by IANA will be treated as tokens, not as elements from which sub-delegated identifiers may be created or derived.
特定のプロトコルは、能力交換のためのASN.1識別子ではなく、人間が読める表現を使用しています。両方のシステムが相互運用することを可能にするために、登録はASN.1識別子を提供するか、IANAに登録時にASN.1識別子を割り当てることを求めることができます。これらの識別子は、登録のために必要とされないが、これらのビルディングゲートウェイまたは他のクロスプロトコルシステムに支援を提供することができます。 IANAによって割り当てられたASN.1識別子はトークンとしてではなく、サブ委任識別子が作成又は誘導され得る要素として扱われることに留意されたいです。
3 Media feature tag registration
3メディアフィーチャータグの登録
Media feature tags can be registered in several different registration trees, with different requirements as discussed below. The vocabulary for these requirements is taken from [5]. In general, a feature tag registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The feature tag is then registered if the proposal is accepted.
メディア特徴タグは、以下に説明するように異なる要件で、いくつかの異なった登録木に登録することができます。これらの要件のための語彙は、[5]から取得されます。一般的には、フィーチャータグ登録提案は循環され、関係ツリーへの適切な方法で検討しました。提案が受け入れられた場合の特徴タグは、登録されています。
Review of a feature tag in the URI tree is not required.
URIツリー内のフィーチャータグの見直しが必要とされていません。
The following subsections define registration "trees", distinguished by the use of faceted names (e.g., names of the form "tree.feature-name").
以下のサブセクションでは、ファセットの名前（例えば、フォームの名前は「tree.feature名」）の使用によって区別登録「木」を画定します。
The IETF tree is intended for media feature tags of general interest to the Internet Community, and proposals for these tags must meet the "IETF Consensus" policies described in [5].
IETFツリーは、インターネットコミュニティへの一般的な関心のメディア特徴タグのために意図されており、これらのタグのための提案は、[5]に記載されている「IETFコンセンサス」ポリシーを満たしている必要があります。
Registration in the IETF tree requires approval by the IESG and publication of the feature tag specification as an RFC. Submissions for feature tag registration in the IETF tree can originate in any WG of the IETF or as an individual submission to the IESG.
IETF木への登録は、IESGとRFCとして機能タグ仕様の公表による承認を必要とします。 IETF木での特徴タグ登録のための提出は、IETFのいずれかのWGやIESGへの個々の服従として発信することができます。
Feature tags in the IETF tree normally have names that are not explicitly faceted, i.e., do not contain period (".", full stop) characters.
IETFツリー内のフィーチャータグは、通常、すなわち、ピリオドが含まれていない、明示的に多面的でない名前を持つ（「」、フルストップ）の文字。
Tags in the global tree will be distinguished by the leading facet "g.". An organization may propose either a designation indicative of the feature, (e.g., "g.blinktags") or a faceted designation including the organization name (e.g., "g.organization.blinktags"). Organizations which have registered media types under the MIME vendor tree should use the same organizational name for media feature tags if they propose a faceted designation. The acceptance of the proposed designation is at the discretion of the IANA. If the IANA believes that a designation needs clarification it may request a new proposal from the proposing organization or otherwise coordinate the development of an appropriate designation.
グローバルツリー内のタグは、大手の面で区別される「グラム。」。組織を提案することができるいずれかの特徴を示す指示（例えば、「g.blinktags」）または組織名を含む多面的な名称（例えば、「g.organization.blinktags」）。彼らは多面的な指定を提案する場合はMIMEベンダーのツリーの下にメディアタイプを登録している組織は、メディア特徴タグの同じ組織名を使用する必要があります。提案された指定の受け入れはIANAの裁量です。 IANAは、指定が明確化が必要であると考えていた場合には、提案団体からの新しい提案を要求するか、そうでない場合には適切な名称の開発を調整することができます。
Registrations of feature tags in the global tree must meet the "Expert Review" policies described in [5]. In this case, a designated area expert will review the proposed tag, consulting with the members of a related mailing list. A registration may be proposed for the global tree by anyone who has the need to allow for communication on a particular capability or preference.
グローバルツリーでの特徴タグの登録は、[5]に記載の「エキスパートレビュー」ポリシーを満たしている必要があります。この場合、指定された領域の専門家は、関連するメーリングリストのメンバーと相談し、提案されたタグを確認します。登録は、特定の能力や好みの通信を可能にする必要性を持っている誰もが世界的な木のために提案することができます。
A feature tag may be defined as a URI using the restricted character set defined above. Feature tags in the URI tree are identified by the leading facet "u.". The leading facet u. is followed by a URI [9] which conforms to the character limitations specified in this document. The author of the URI is assumed to be registration authority regarding features defined and described by the content of the URI. These tags are considered unregistered for the purpose of this document.
特徴タグは、上記で定義された制限された文字セットを使用してURIとして定義することができます。 URIツリーでフィーチャータグは大手の面で識別されている「U。」。リード面U。 [9]この文書で指定された文字の制限に準拠したURIが続きます。 URIの作者はURIの内容によって定義されたと説明した機能についての登録権限を想定しています。これらのタグは、このドキュメントの目的のために登録されていないと考えられています。
From time to time and as required by the community, the IANA may, with the advice and consent of the IESG, create new top-level registration trees. These trees may be created for external registration and management by (for example) well-known permanent bodies, such as scientific societies for media feature types specific to the sciences they cover. Establishment of these new trees will be announced through RFC publication approved by the IESG.
時々、コミュニティの要求に応じて、IANAは、IESGの助言と同意を得て、新しいトップレベル登録木を作成することができます。これらの木は、それらがカバーする科学に特定のメディア機能タイプの学会として（例えば）周知の永久機関によって外部の登録および管理のために作成することができます。これらの新しい木の設立はIESGによって承認されたRFCの公表を通じて発表されます。
Feature tag registrations will be posted in the anonymous FTP directory: "ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/" and all registered feature tags will be listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC-1700]. The feature tag description and other supporting material may also be published as an Informational RFC by sending it to "rfc-editor@rfc-editor.org".
「ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/」と登録されているすべての機能タグが定期的に発行して表示されます：フィーチャータグの登録は、匿名FTPディレクトリに掲載されます"割り当てられた番号" RFC [現在STD 2、RFC-1700]。フィーチャータグの説明や他の支援材料はまた、「rfc-editor@rfc-editor.org」にそれを送信することにより、情報のRFCとして公開することができます。
The IANA will only register feature tags in the IETF tree in response to a communication from the IESG stating that a given registration has been approved.
IANAは、唯一与えられた登録が承認されたことを知らせるIESGからの通信に対応してIETF木での特徴タグを登録します。
Global tags will be registered by the IANA after review by a designated expert. That review will serve to ensure that the tag meets the technical requirements of this specification.
グローバルタグは、指定された専門家による審査の後にIANAによって登録されます。そのレビューは、タグは、この仕様の技術的要件を満たしていることを確認するのに役立つであろう。
To: media-feature-tags@apps.ietf.org (Media feature tags mailing list) Subject: Registration of media feature tag XXXX
To：media-feature-tags@apps.ietf.org（メディアフィーチャータグメーリングリスト）件名：メディア特徴タグXXXXの登録
| Instructions are preceded by `|'. Some fields are optional.
| |」命令は `が付いています。一部のフィールドはオプションです。
Media feature tag name:
メディアフィーチャータグ名：
ASN.1 identifier associated with feature tag: [optional]
特徴タグに関連付けられたASN.1識別子：[オプション]
| To have IANA assign an ASN.1 identifier, | use the value "New assignment by IANA" here.
| IANAは、ASN.1識別子を割り当てる持っています|ここでは、「IANAによって新しい割り当て」の値を使用します。
Summary of the media feature indicated by this feature tag:
この機能のタグで示されるメディアフィーチャーの概要：
| Include a short (no longer than 4 lines) description or summary | Examples: | `Use of the xyzzy feature is indicated by ...' | `Support of color display is indicated by ...' | `Number of colors in a palette which can be defined ...'
| |短い（もはや4行以上）の記述または要約を含みません例：| `XYZZY機能の使用はで示されています...」| `カラーディスプレイのサポートは、によって示され...」|定義することができ、パレットの色の数 `...」
Values appropriate for use with this feature tag:
この機能タグで使用するための適切な値：
[ ] 1. The feature tag is Boolean and may have values of TRUE or FALSE. A value of TRUE indicates an available capability. A value of FALSE indicates the capability is not available.
[] 1.特徴タグはブール値であり、TRUEまたはFALSEの値を有することができます。 TRUEの値は、利用可能な機能を示します。 FALSEの値は、機能が利用できないことを示します。
| If you wish to indicate two mutually exclusive possibilities | that cannot be expressed as the availability or lack of a | capability, use a two-token list, rather than a Boolean value.
|次の2つの相互に排他的な可能性を示したい場合|それはの可用性または不足のように表現することはできません|機能は、むしろブール値よりも、2-トークンリストを使用します。
[ ] 2. The feature has an associated numeric or enumerated value.
[] 2.機能は、関連する数値または列挙値を有しています。
For case 2: Indicate the data type of the value:
ケース2の場合：値のデータタイプを示します。
[ ] 2a. Signed Integer [ ] 2b. Rational number [ ] 2c. Token (equality relationship) [ ] 2d. Token (ordered) [ ] 2e. String (equality relationship) [ ] 2f. String (defined comparison)
[]図2a。符号付き整数[]図2b。有理数[] 2C。トークン（等価関係）[] 2D。トークン（注文）[] 2E。文字列（等号関係）[] 2F。文字列（定義の比較）
|IMPORTANT: You may only chose one of the above data types.
|重要：あなただけ上記のデータ・タイプのいずれかを選択できます。
(Only for case 2) Detailed description of the feature value meaning, and of the format and meaning of the feature tag values for the alternative results.
（唯一のケース2の場合）の詳細な特徴値の意味の説明、および代替結果に対する特徴タグ値のフォーマットと意味。
| If you have selected 2d you must provide the ordering mechanism | or a full and ordered enumeration of possible values. If you | have selected 2f, you must provide a definition of the comparison. | Definitions by included reference must be to stable and readily | available specifications: | | If the number of alternative results is small, you may | enumerate the identifiers of the different results and describe | their meaning. | | If there is a limited useful numeric range of result (2b, 2c),
|あなたは、2Dを選択した場合は、注文メカニズムを提供する必要があります|可能な値のまたは完全なと命じ列挙。あなたの場合| 2Fを選択している、あなたは比較の定義を提供しなければなりません。 |含まれる参照することによって定義が容易に安定してでなければなりません|利用可能な仕様：| |代替結果の数が少ない場合、あなたがかもしれません|異なる結果の識別子を列挙して説明|その意味。 | |結果の限定された有用な数値範囲がある場合（2B、2C）
| indicate the range. | | The identifiers of the alternative results could also be | described by referring to another IANA registry, for example | the paper sizes enumerated by the Printer MIB.
|範囲を示しています。 | |代替結果の識別子も可能性があり|例えば、別のIANAレジストリを参照して説明|用紙サイズは、プリンタのMIBによって列挙します。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: [optional]
フィーチャータグは、主に以下のアプリケーション、プロトコル、サービス、または交渉メカニズムにおける使用のために意図されています[オプション]
| For applications, also specify the number of the first version | which will use the tag, if applicable.
|アプリケーションでは、また、最初のバージョンの数を指定|これは該当する場合は、タグを使用します。
Examples of typical use: [optional]
典型的な使用例：[オプション]
Related standards or documents: [optional]
関連の規格や文書：[オプション]
Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms: [optional]
個々のアプリケーション、プロトコル、サービス、または交渉メカニズムで使用する特定の考慮事項：[オプション]
Interoperability considerations: [optional]
相互運用性に関する注意事項：[オプション]
Security considerations:
セキュリティの考慮事項：
Privacy concerns, related to exposure of personal information:
個人情報の暴露に関連するプライバシーの問題、：
Denial of service concerns related to consequences of specifying incorrect values:
不正な値を指定しての結果に関連したサービスの懸念の拒否：
Other:
その他：
Additional information: [optional]
追加情報：[オプション]
Keywords: [optional]
キーワード：[オプション]
Related feature tags: [optional]
関連機能タグ：[オプション]
Related media types or data formats: [optional]
関連メディアタイプやデータフォーマット：[オプション]
Related markup tags: [optional]
関連するマークアップタグ：[オプション]
Name(s) & email address(es) of person(s) to contact for further information:
詳細のために連絡する人（複数可）の名前（複数可）＆電子メールアドレス（複数可）：
Intended usage:
意図している用法：
| one of COMMON, LIMITED USE or OBSOLETE
| COMMON、限られた使用の1またはOBSOLETE
Author/Change controller:
著者/変更コントローラ：
Requested IANA publication delay: [optional]
要求されたIANA公開遅延：[オプション]
| A delay may only be requested for final placement in the global | or IETF trees, with a maximum of two months. Organizations | requesting a registration with a publication delay should note | that this delays only the official publication of the tag | and does not prevent information on it from being disseminated | by the members of the relevant mailing list.
|遅延は唯一のグローバルでの最終的な配置のために要求することができます| 2ヶ月の最大値を持つか、IETF木、。組織|遅延が注意すべき出版物への登録を要求します|これは、タグの唯一の公式発表を遅らせること|そして普及しているから、それについての情報を妨げるものではありません|関連のメーリングリストのメンバーによる。
Other information: [optional]
その他の情報：[オプション]
| Any other information that the author deems interesting may be | added here.
|その他の情報は、作者がおもしろいと考えるのかもしれ|ここで追加。
4 Security Considerations
4つのセキュリティの考慮事項
Negotiation mechanisms reveal information about one party to other parties. This may raise privacy concerns, and may allow a malicious party to make better guesses about the presence of specific security holes.
交渉メカニズムは、他の当事者に一方の当事者についての情報を明らかにしました。これはプライバシーの問題を提起することができ、悪意のある当事者が特定のセキュリティホールの存在についてのより良い推測を作ることを可能にします。
5 Acknowledgments
5つの謝辞
The details of the registration procedure in this document were directly adapted from [1]. Much of the text in section 3 was directly copied from this source.
この文書の登録手順の詳細は、直接、[1]から適合させました。セクション3のテキストの多くは、直接このソースからコピーされました。
The idea of creating a vocabulary of areas of media features, maintained in a central open registry, is due to discussions on extensible negotiation mechanisms [3] in the IETF HTTP working group.
中央開放レジストリ内に維持メディア機能の領域の語彙を作成するアイデアは、原因IETF HTTPワーキンググループ[3]拡張可能ネゴシエーションメカニズムに関する議論です。
The authors wish to thank Larry Masinter, Graham Klyne, Al Gilman, Dan Wing, Jacob Palme, and Martin Duerst for their contributions to discussions about media feature tag registration.
著者は、メディア特徴タグ登録に関する議論への貢献のためにラリーMasinter、グラハムKlyne、アルギルマン、ダン・ウィング、ヤコブパルメ、およびマーティンDuerstに感謝したいです。
6 References
6つの参考文献
[1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[1]解放され、N.、Klensin、J.およびJ.ポステル、 "多目的インターネットメール拡張（MIME）パート4：登録手順"、BCP 13、RFC 2048、1996年11月。
[2] Klyne, G., "An algebra for describing media feature sets", Work in Progress.
[2] Klyne、G.、「メディア機能セットを記述するための代数」、進行中で働いています。
[3] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP. RFC 2295, March 1998.
[3] Holtman、K.とA. MUTZ、HTTPでの「透明コンテントネゴシエーションを。RFC 2295、1998年3月。
[4] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "Media Features for Display, Print, and Fax", RFC 2534, March 1999.
[4] Masinter、L.、Holtman、K.、MUTZ、A.とD.翼、 "表示、印刷用メディアの機能、およびファックス"、RFC 2534、1999年3月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[6] Crocker, D., Ed., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[6]クロッカー、D.、エド、 "構文仕様のための増大しているBNF：ABNF"。、RFC 2234、1997年11月。
[7] Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[7]フィールディング、R.、ゲティス、J.、モーグル、J. Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC 1630, June 1994.
[9]バーナーズ=リー、T.、 "WWWにおけるユニバーサルリソース識別子、" RFC 1630、1994年6月。
7 Authors' Addresses
7本の著者のアドレス
Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven The Netherlands
技術の公園Holtmanアイントホーフェン大学私書箱513ルームHG 6時57分5600メガバイトアイントホーフェンオランダ
EMail: koen@win.tue.nl
メールアドレス：koen@win.tue.nl
Andrew H. Mutz Hewlett-Packard Company 11000 Wolfe Rd. 42UO Cupertino CA 95014 USA
アンドリューH. MUTZ米国Hewlett-Packard Company 11000ウルフRdを。 42UOクパチーノCA 95014 USA
Fax +1 408 447 4439 EMail: andy_mutz@hp.com
ファックス+1 408 447 4439 Eメール：andy_mutz@hp.com
Ted Hardie Equinix 901 Marshall Street Redwood City, CA 94063 USA
テッドハーディーエクイニクス901マーシャルストリートレッドウッドシティ、CA 94063 USA
EMail: hardie@equinix.com
メールアドレス：hardie@equinix.com
8 Full Copyright Statement
8フル著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。