[要約] RFC 2506は、メディア機能タグの登録手順に関する規格であり、メディアタイプの識別と相互運用性を向上させることを目的としています。
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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>のコネグワーキンググループにコメントを送信してください。ワーキンググループの議論は、<url：http://www.imc.org/ietf-medfree/>でアーカイブされています。
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]で説明されている使用法に従って、用語が使用されなければならない、そうでなければ、そうでなければ、そうでなければ、そうでなければ、そうでなければ、そうでなければ、そうでなければ、そうでなければ、そうでなければ、そうでなければならないか、そうでなければならない。
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).
* ピクセル単位のディスプレイの幅は、整数値として表されました。*受信者が使用できるフォント、列挙されたリストから選択されています。*整数「I.J.K」で構成されるプロトコルのバージョンは、列挙されたリストの値として定義されているか、整数のサブセットに値を同型にするための定義されたマッピングを使用して定義されています（例：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.
メディア機能タグは、次の1つ以上のUS-ASCII文字で構成される文字列です。大文字、小文字、数字、コロン（ "："）、slash（ "/"）、dot（ "。"）パーセント（ "）パーセント（"/"）"％"）、およびdash（ " - "）。特徴タグはケース非感受性です。ドットは潜在的に階層を暗示すると理解されています。機能は、tree.feature.subfeatureとして説明し、登録でこれを示すことにより、サブタイプ化できます。タグは、アルファベット文字から始める必要があります。
In ABNF [6], this may be represented as:
ABNF [6]では、これは次のように表される場合があります。
Feature-tag = 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>
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-name」の名前）の使用によって区別される登録「ツリー」を定義します。
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」によって区別されます。組織は、機能を示す指定（「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
機能タグは、上記で定義された制限文字セットを使用してURIとして定義できます。URIツリーの機能タグは、先頭のファセット「u」によって識別されます。主要なファセットu。続いて、これで指定されたキャラクターの制限に適合するURI [9]が続きます
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の内容によって定義および記述された機能に関する登録機関であると想定されています。これらのタグは、このドキュメントの目的のために未登録と見なされます。
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://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/」に投稿され、すべての登録機能タグは定期的に発行された定期的にリストされます。「割り当てられた番号」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
宛先：MediaFeature-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 ...'
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の値がある場合があります。真の値は、利用可能な機能を示します。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. 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)
|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),
| 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.
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:
詳細については、連絡先の人の名前とメールアドレス（es）：
Intended usage:
意図された使用法：
| one of COMMON, LIMITED USE or OBSOLETE
|一般的な、限られた使用または時代遅れの1つ
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.
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.
著者は、メディア機能タグの登録に関する議論への貢献について、ラリー・マシンター、グラハム・クライネ、アル・ギルマン、ダン・ウィング、ジェイコブ・パルメ、マーティン・デュエストに感謝します。
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] Freed、N.、Klensin、J。and J. Postel、「多目的インターネットメールエクステンション（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。RFC2295の透明なコンテンツ交渉、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。and D. Wing、「ディスプレイ、印刷、FAXのメディア機能」、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] Crocker、D.、ed。、「構文仕様のための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] Fielding、R.、Gettys、J.、Mogul、J。Frystyk、H。およびT. Berners-Lee、「HyperText Transfer Protocol-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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC 1630, June 1994.
[9] Berners-Lee、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
Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer Hg 6.57 5600 MB Eindhoven the Netherlands
EMail: koen@win.tue.nl
Andrew H. Mutz Hewlett-Packard Company 11000 Wolfe Rd. 42UO Cupertino CA 95014 USA
Andrew H. Mutz Hewlett-Packard Company 11000 Wolfe Rd。42Uo Cupertino CA 95014 USA
Fax +1 408 447 4439 EMail: andy_mutz@hp.com
FAX 1 408 447 4439メール：andy_mutz@hp.com
Ted Hardie Equinix 901 Marshall Street Redwood City, CA 94063 USA
テッドハーディエクイニックス901マーシャルストリートレッドウッドシティ、カリフォルニア94063 USA
EMail: hardie@equinix.com
8 Full Copyright Statement
8完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。