RFC2506 日本語訳
2506 Media Feature Tag Registration Procedure. K. Holtman, A. Mutz, T.Hardie. March 1999. (Format: TXT=24892 bytes) (Also BCP0031) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
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
Holtmanがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2506 火曜日のBCP: 31A.Mutzカテゴリ: 1999年の最も良い現在の練習ヒューレット・パッカードのT.ハーディーEquinix行進
Media Feature Tag Registration Procedure
メディアはタグ登録手順を特徴とします。
Status of this Memo
この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.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
WWWなどの最近のインターネットアプリケーションはデータ形式、クライアント、サーバプラットホーム、および共同体でかなりの多様性を結びつけます。 これは、かかわったパーティーの能力と好みに情報のフォームを特定して、和解させるためにメディア特徴記述と交渉メカニズムの必要性を作成しました。
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.
このドキュメントはメディア特徴ボキャブラリーに、中央の登録としてインターネットAssigned民数記Authority(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ワーキンググループにコメントを送ってください、gt。 ワーキンググループの議論は<URLに格納されます: http://www.imc.org/ietf-medfree/ >。
Holtman, et. al. Best Current Practice [Page 1] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[1ページ]
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つの序論… 2 2のメディアがタグ定義を特徴とします… 3 2.1のメディアがタグ目的を特徴とします… 3 2.2のメディアがタグ構文を特徴とします… 4 2.3のメディアがタグ値を特徴とします… 4 2.4 メディアのためのASN.1識別子はタグを特集します… 5 3のメディアがタグ登録を特徴とします… 5 3.1 登録木… 6 3.1 .1IETF木… 6 3.1 .2のグローバルな木… 6 3.1 .3URL木… 6 3.1 .4 追加登録木… 7 3.2 登録されたメディアの位置はタグリストを特徴とします… 7 3.3 メディアを登録するためのIANA手順はタグを特集します… 7 3.4登録テンプレート… 7 4のセキュリティ問題… 10 5つの承認… 10 6つの参照箇所… 10 7人の作者のアドレス… 11 8 完全な著作権宣言文… 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.
WWWなどの最近のインターネットアプリケーションはデータ形式、クライアント、サーバプラットホーム、および共同体でかなりの多様性を結びつけます。 これは、かかわったパーティーの能力と好みに情報のフォームを特定して、和解させるためにメディア特徴記述と交渉メカニズムの必要性を作成しました。
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.
このドキュメントはメディア特徴ボキャブラリーに、中央の登録としてインターネットAssigned民数記Authority(IANA)を使用する登録手順を定義します。
This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT and MAY according to usage described in [8].
これが用語が記録しなければならない用途を記録する、[8]で慣例によって説明されたNOT、SHOULD、SHOULD NOT、および5月はそうしなければなりません。
Holtman, et. al. Best Current Practice [Page 2] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[2ページ]
2 Media feature tag definitions
2つのメディアがタグ定義を特徴とします。
2.1 Media feature tag purpose
2.1のメディアがタグ目的を特徴とします。
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).
* 1整数値として表されたセンチメートルあたりの画素の表示の幅。 * 受取人にとって利用可能で、列挙されたリストから選択された字体。 * プロトコルのバージョンは、値を整数の部分集合に同型にするように列挙されたリストか定義されたマッピングで値と定義された整数「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メディアの有用性を推定します。 メディアが現在個々のプロトコルで使用中のタグを特集するか、またはそれらがそれらの現在のドメインの外に適用されるかもしれないなら、アプリケーションはこの登録に登録されるかもしれません。
Holtman, et. al. Best Current Practice [Page 3] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[3ページ]
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.
メディア特徴タグ名前空間は特定のトランスポート・プロトコルか能力交換メカニズムに縛られません。 しかしながら、登録が能力を言い表すタグを特集するために制限されたか、または好みは内容がどう提示されるかに関連しました。 この登録には、交渉の他の軸に関連する特徴タグは適切ではありません。 能力交換メカニズムは、さまざまな能力か好みを言い表すのにもちろん使用されるかもしれません。
2.2 Media feature tag syntax
2.2のメディアがタグ構文を特徴とします。
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.
メディア特徴タグは以下の米国-ASCII文字のより多くのひとりから成るストリングです: 大文字、小文字、ケタ、コロン、(「:」、)、(「/」)、ドットをなでぎりしてください、(「」、)、パーセント(「%」)、およびダッシュ(「-」)。 特徴タグは大文字と小文字を区別しないです。 ドットが潜在的に階層構造を含意するのが理解されています。 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で説明されます。
2.3 Media feature tag values
2.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](以下としてまとめられるかもしれない)によって定義されるように象徴データ型を意味します。
Holtman, et. al. Best Current Practice [Page 4] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[4ページ]
token = 1*<any CHAR except CTLs or tspecials>
象徴=1*<はCTLsか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単位系への変換法を提供しなければなりません。 変換法は定義された一周習慣を含むべきです。
2.4 ASN.1 identifiers for media feature tags
2.4 メディアのためのASN.1識別子はタグを特集します。
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木での特徴タグのレビューは必要ではありません。
Holtman, et. al. Best Current Practice [Page 5] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[5ページ]
3.1 Registration trees
3.1 登録木
The following subsections define registration "trees", distinguished by the use of faceted names (e.g., names of the form "tree.feature- name").
以下の小区分はfaceted名前(例えば、「tree.featureは命名する」フォームの名前)の使用で区別された登録「木」を定義します。
3.1.1 IETF tree
3.1.1 IETF木
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木での登録はRFCとして特徴タグ仕様のIESGと公表で承認を必要とします。 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が木に追い上げる特徴タグが明らかにfacetedされない名前を持って、すなわち、期間を含まないでください、(「」、終止符) キャラクタ。
3.1.2 Global tree
3.1.2 グローバルな木
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」)を含むfaceted名称のどちらかを提案するかもしれません。 faceted名称を提案するなら、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]で説明された「専門のレビュー」方針を満たさなければなりません。 この場合、指定地域の専門家は提案されたタグを見直すでしょう、関連するメーリングリストのメンバーと相談して。 登録はグローバルな木のために特定の能力か優先に関するコミュニケーションを考慮する必要性を持っているだれによっても提案されるかもしれません。
3.1.3 URI tree
3.1.3 URI木
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.」によって特定されます。 これで指定されたキャラクタ制限に従うURI[9]は主な一面u.のあとに続いています。
Holtman, et. al. Best Current Practice [Page 6] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[6ページ]
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の内容によって定義されて、説明された特徴に関する登録局であると思われます。 これらのタグはこのドキュメントの目的のために登録されていないと考えられます。
3.1.4 Additional registration trees
3.1.4 追加登録木
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.
時々、必要に応じて、IESGの助言と同意で、共同体のそばでは、IANAが新しいトップレベル登録木を作成するかもしれません。 これらの木は外部の登録のために作成されるかもしれません、そして、(例えば、)メディアのための科学的社会などの周知の永久的なボディーによる経営者側はそれらがカバーする科学に特定のタイプを特集します。これらの新しい木の設立はIESGによって承認されたRFC公表を通して示されるでしょう。
3.2 Location of registered feature tag list
3.2 登録された特徴タグリストの位置
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- 特徴タグ/」とすべての登録された特徴タグが定期的に発行された「規定番号」RFC[現在のSTD2、RFC1700]に記載されるでしょう。 また、特徴タグ記述と他のサポートの材料は、Informational RFCとして「rfc editor@rfc-editor.org 」にそれを送ることによって、発行されるかもしれません。
3.3 IANA procedures for registering feature tags
3.3 特徴タグを登録するためのIANA手順
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はIETF木に与えられた登録が承認されたと述べるIESGからのコミュニケーションに対応して特徴タグを登録するだけでしょう。
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によって登録されるでしょう。 そのレビューは、タグがこの仕様に関する技術的要求事項を満たすのを保証するのに役立つでしょう。
3.4 Registration template
3.4 登録テンプレート
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 (メディア機能はメーリングリストにタグ付けをする)Subject: メディア機能タグ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による新しい課題。」
Holtman, et. al. Best Current Practice [Page 7] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[7ページ]
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 ...'
| インクルードaショート、(もう、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つの互いに唯一の可能性を示すことを願ってください。| aの有用性か不足としてそれを言い表すことができません。| 能力、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.
| 重要: あなたは選ぶことができます。上記のデータ型の1つを選ぶだけでした。
(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)があれば
Holtman, et. al. Best Current Practice [Page 8] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[8ページ]
| 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登録について言及することによって、説明されます。| 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:
人の(s)とEメールアドレス(es)を詳細のために連絡する(s)と命名してください:
Intended usage:
意図している用法:
| one of COMMON, LIMITED USE or OBSOLETE
| COMMON、LIMITED USEまたはOBSOLETEの1つ
Holtman, et. al. Best Current Practice [Page 9] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[9ページ]
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.
交渉メカニズムは相手への情報およそ1パーティーを明らかにします。 これは、プライバシーの問題を提起して、悪意があるパーティーが特定のセキュリティの存在に関する、より良い推測を穴にするのを許容するかもしれません。
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.
作者は、メディアについての議論への彼らの貢献のためのDuerstがタグ登録を特徴とするのをラリーMasinter、グラハムKlyne、アル・ギルマン、ダンWing、ヤコブ・パルメ、およびマーチンに感謝したがっています。
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を分けます」。 「登録手順」、BCP13、RFC2048、1996年11月。
[2] Klyne, G., "An algebra for describing media feature sets", Work
in Progress.
[2]Klyne、G.、「特徴が設定するメディアを説明するための代数」、ProgressのWork。
[3] Holtman, K. and A. Mutz, "Transparent Content Negotiation in
HTTP. RFC 2295, March 1998.
[3]HoltmanとK.とA.Mutz、「HTTPにおけるわかりやすい満足している交渉。」 1998年3月のRFC2295。
Holtman, et. al. Best Current Practice [Page 10] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[10ページ]
[4] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "Media Features
for Display, Print, and Fax", RFC 2534, March 1999.
Masinter、L.、Holtman、K.、Mutz、A.、およびD.が翼をつけさせる[4]、「表示、印刷、およびファックスのためのメディア機能」、RFC2534(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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[6] Crocker, D., Ed., "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997.
[6] クロッカー、D.、エド、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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.、Gettys、J.、ムガール人、J.Frystyk、H.、およびT.Bernersリー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月。」
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC
1630, June 1994.
[9] バーナーズ・リー、T.、「WWWの普遍的なリソース識別子」、RFC1630、1994年6月。
7 Authors' Addresses
7人の作者のアドレス
Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven The Netherlands
クンHoltman Technische UniversiteitアイントホーフェンPostbus513のKamer HGの6.57 5600MBのアイントホーフェンオランダ
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ヒューレット・パッカード社11000のウルフ通り 42UOカルパチーノカリフォルニア95014米国
Fax +1 408 447 4439 EMail: andy_mutz@hp.com
ファックスで、+1に、4439がメールする408 447を送ってください: andy_mutz@hp.com
Ted Hardie Equinix 901 Marshall Street Redwood City, CA 94063 USA
レッドウッドシティー、テッドハーディーEquinix901カリフォルニア94063米国マーシャル・ストリート
EMail: hardie@equinix.com
メール: hardie@equinix.com
Holtman, et. al. Best Current Practice [Page 11] RFC 2506 Media Feature Tag Registration Procedure March 1999
et Holtman、アル。 RFC2506メディアが1999年のタグ登録手順行進のときに特集する中で最も良い現在の習慣[11ページ]
8 Full Copyright Statement
8 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Holtman, et. al. Best Current Practice [Page 12]
et Holtman、アル。 最も良い現在の習慣[12ページ]
一覧
スポンサーリンク
