[要約] RFC 6839は、メディアタイプの構造化構文の接尾辞に関する追加情報を提供しています。その目的は、メディアタイプの拡張性と柔軟性を向上させることです。
Internet Engineering Task Force (IETF) T. Hansen
Request for Comments: 6839 AT&T Laboratories
Updates: 3023 A. Melnikov
Category: Informational Isode Ltd
ISSN: 2070-1721 January 2013
Additional Media Type Structured Syntax Suffixes
追加のメディアタイプの構造化構文のサフィックス
Abstract
概要
A content media type name sometimes includes partitioned meta-information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix.
コンテンツメディアタイプの名前には、構造化された構文で区別されるパーティション化されたメタ情報が含まれ、メディアの属性を名前のサフィックスとして示すことができます。このドキュメントでは、メディアタイプ登録で使用するためのいくつかの構造化構文サフィックスを定義します。特に、「+ json」、「+ ber」、「+ der」、「+ fastinfoset」、「+ wbxml」、「+ zip」の構造化構文サフィックスを定義および登録し、メディアタイプの構造化構文サフィックス登録を提供します「+ xml」構造化構文サフィックスの形式。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6839.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6839で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. When to Use These Structured Syntax Suffixes . . . . . . . . . 3
3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 4
3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 4
3.2. The +ber Structured Syntax Suffix . . . . . . . . . . . . 5
3.3. The +der Structured Syntax Suffix . . . . . . . . . . . . 6
3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 7
3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 9
3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
4.1. The +xml Structured Syntax Suffix . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
[RFC3023] created the +xml suffix convention that can be used when defining names for media types whose representation uses XML underneath. That is, they could have been successfully parsed as if the media type had been application/xml in addition to their being parsed as their media type that is using the +xml suffix. [RFC6838] defines the media type "Structured Syntax Suffix Registry" to be used for such structured syntax suffixes.
[RFC3023]は、表現がその下でXMLを使用するメディアタイプの名前を定義するときに使用できる+ xmlサフィックス規則を作成しました。つまり、+ xmlサフィックスを使用するメディアタイプとして解析されることに加えて、メディアタイプがapplication / xmlであるかのように正常に解析された可能性があります。 [RFC6838]は、このような構造化構文のサフィックスに使用されるメディアタイプ「構造化構文のサフィックスレジストリ」を定義しています。
A variety of structured syntax suffixes have already been used in some media type registrations, in particular "+json", "+der", "+fastinfoset", and "+wbxml". This document defines and registers these structured syntax suffixes in the Structured Syntax Suffix Registry, along with "+ber" and "+zip". In addition, this document updates [RFC3023] to formally register the "+xml" structured syntax suffix according to the procedure defined in [RFC6838].
一部のメディアタイプ登録では、さまざまな構造化構文のサフィックスがすでに使用されています。特に「+ json」、「+ der」、「+ fastinfoset」、「+ wbxml」などです。このドキュメントでは、「+ ber」および「+ zip」とともに、これらの構造化構文サフィックスを定義し、構造化構文サフィックスレジストリに登録します。さらに、このドキュメントでは、[RFC6838]で定義されている手順に従って、「+ xml」構造化構文のサフィックスを正式に登録するために[RFC3023]を更新しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Each of the structured syntax suffixes defined in this document is appropriate for use when the media type identifies the semantics of the protocol payload. That is, knowing the semantics of the specific media type provides for more specific processing of the content than that afforded by generic processing of the underlying representation.
このドキュメントで定義されている各構造化構文のサフィックスは、メディアタイプがプロトコルペイロードのセマンティクスを識別するときに使用するのに適しています。つまり、特定のメディアタイプのセマンティクスを知ることで、基礎となる表現の一般的な処理よりも具体的なコンテンツの処理が提供されます。
At the same time, using the suffix allows receivers of the media types to do generic processing of the underlying representation in cases where
同時に、サフィックスを使用すると、メディアタイプのレシーバーが、
they do not need to perform special handling of the particular semantics of the exact media type, and
正確なメディアタイプの特定のセマンティクスの特別な処理を実行する必要がない。
there is no special knowledge needed by such a generic processor in order to parse that underlying representation other than what would be needed to parse any example of that underlying representation.
そのような基本的な表現の例を解析するために必要なもの以外に、そのような基本的な表現を解析するためにそのような汎用プロセッサが必要とする特別な知識はありません。
[RFC4627] defines the "application/json" media type. The suffix "+json" MAY be used with any media type whose representation follows that established for "application/json". The media type structured syntax suffix registration form follows. See [RFC6838] for definitions of each of the registration form headings.
[RFC4627]は、「application / json」メディアタイプを定義します。接尾辞「+ json」は、「application / json」用に確立されたものに従う表現に従う任意のメディアタイプで使用できます。メディアタイプの構造化構文のサフィックス登録フォームは次のとおりです。登録フォームの各見出しの定義については、[RFC6838]を参照してください。
Name: JavaScript Object Notation (JSON)
名前：JavaScript Object Notation（JSON）
+suffix: +json
References: [RFC4627]
参照：[RFC4627]
Encoding considerations:
エンコードに関する考慮事項：
Per [RFC4627], JSON is allowed to be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, JSON is binary ([RFC2045]).
[RFC4627]に従い、JSONはUTF-8、UTF-16、またはUTF-32を使用して表現できます。 JSONがUTF-8で記述されている場合、JSONは8ビット互換です（[RFC2045]）。 JSONがUTF-16またはUTF-32で記述されている場合、JSONはバイナリー（[RFC2045]）です。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
The syntax and semantics of fragment identifiers specified for +json SHOULD be as specified for "application/json". (At publication of this document, there is no fragment identification syntax defined for "application/json".)
+ jsonに指定されたフラグメント識別子の構文とセマンティクスは、「application / json」に指定されたとおりである必要があります（SHOULD）。 （このドキュメントの公開時には、「application / json」に対して定義されたフラグメント識別構文はありません。）
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+json" SHOULD be processed as follows:
特定の「xxx / yyy + json」のフラグメント識別子の構文とセマンティクスは、次のように処理する必要があります。
For cases defined in +json, where the fragment identifier resolves per the +json rules, then process as specified in +json.
+ jsonで定義されているケースの場合、フラグメント識別子は+ jsonルールに従って解決され、+ jsonで指定されているように処理されます。
For cases defined in +json, where the fragment identifier does not resolve per the +json rules, then process as specified in "xxx/yyy+json".
+ jsonで定義されているケースで、フラグメント識別子が+ jsonルールに従って解決されない場合は、「xxx / yyy + json」で指定されているように処理します。
For cases not defined in +json, then process as specified in "xxx/yyy+json".
+ jsonで定義されていない場合は、「xxx / yyy + json」で指定されているように処理します。
Interoperability considerations: n/a
相互運用性に関する考慮事項：なし
Security considerations: See [RFC4627]
セキュリティに関する考慮事項：[RFC4627]を参照してください
Contact: Apps Area Working Group (apps-discuss@ietf.org) Author/Change controller:
連絡先：Apps Area Working Group（apps-discuss@ietf.org）著者/変更コントローラ：
The Apps Area Working Group. IESG has change control over this registration.
アプリ領域作業グループ。 IESGは、この登録を変更管理します。
The ITU defined the Basic Encoding Rules (BER) transfer syntax in [ITU.X690.2008]. The suffix "+ber" MAY be used with any media type whose representation follows the BER transfer syntax. (The Expert Reviewer for media type structured syntax suffix registrations ought to be aware of the relationship between BER and DER to aid in selecting the proper suffix.) The media type structured syntax suffix registration form for +ber follows:
ITUは[ITU.X690.2008]でBasic Encoding Rules（BER）転送構文を定義しました。接尾辞「+ ber」は、BER転送構文に従う表現を持つすべてのメディアタイプで使用できます。 （メディアタイプの構造化構文のサフィックス登録のエキスパートレビューアーは、適切なサフィックスの選択を支援するために、BERとDERの関係を認識する必要があります。）+ berのメディアタイプの構造化構文のサフィックス登録フォームは次のとおりです。
Name: Basic Encoding Rules (BER) transfer syntax
名前：Basic Encoding Rules（BER）transfer syntax
+suffix: +ber
References: [ITU.X690.2008]
参照：[ITU.X690.2008]
Encoding considerations: BER is a binary encoding.
エンコーディングに関する考慮事項：BERはバイナリエンコーディングです。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
At publication of this document, there is no fragment identification syntax defined for +ber.
このドキュメントの公開時には、+ berに対して定義されたフラグメント識別構文はありません。
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+ber" SHOULD be processed as follows:
特定の「xxx / yyy + ber」のフラグメント識別子の構文とセマンティクスは、次のように処理する必要があります。
For cases defined in +ber, where the fragment identifier resolves per the +ber rules, then process as specified in +ber.
+ berで定義されたケースの場合、フラグメント識別子は+ berルールに従って解決され、+ berで指定されたとおりに処理されます。
For cases defined in +ber, where the fragment identifier does not resolve per the +ber rules, then process as specified in "xxx/yyy+ber".
+ berで定義されているケースで、フラグメント識別子が+ berルールに従って解決されない場合は、「xxx / yyy + ber」で指定されているように処理します。
For cases not defined in +ber, then process as specified in "xxx/yyy+ber".
+ berで定義されていないケースの場合は、「xxx / yyy + ber」で指定されているように処理します。
Interoperability considerations: n/a
相互運用性に関する考慮事項：なし
Security considerations:
セキュリティに関する考慮事項：
Each individual media type registered with a +ber suffix can have additional security considerations.
+ berサフィックスで登録された各メディアタイプには、セキュリティに関する追加の考慮事項があります。
BER has a type-length-value structure, and it is easy to construct malicious content with invalid length fields that can cause buffer overrun conditions.
BERにはタイプ長さ値構造があり、バッファオーバーラン状態を引き起こす可能性のある無効な長さフィールドを持つ悪意のあるコンテンツを簡単に構築できます。
BER allows for arbitrary levels of nesting, which may make it possible to construct malicious content that will cause a stack overflow.
BERは、任意のレベルのネストを可能にします。これにより、スタックオーバーフローを引き起こす悪意のあるコンテンツを構築できる可能性があります。
Interpreters of the BER structures should be aware of these issues and should take appropriate measures to guard against buffer overflows and stack overruns in particular and malicious content in general.
BER構造のインタープリターはこれらの問題を認識している必要があり、特にバッファーオーバーフローやスタックオーバーラン、特に悪意のあるコンテンツ全般を防ぐために適切な対策を講じる必要があります。
Contact: Apps Area Working Group (apps-discuss@ietf.org)
連絡先：Apps Area Working Group（apps-discuss@ietf.org）
Author/Change controller:
著者/変更コントローラ：
The Apps Area Working Group. IESG has change control over this registration.
アプリ領域作業グループ。 IESGは、この登録を変更管理します。
The ITU defined the Distinguished Encoding Rules (DER) transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used with any media type whose representation follows the DER transfer syntax. (The Expert Reviewer for media type structured syntax suffix registrations ought to be aware of the relationship between BER and DER to aid in selecting the proper suffix.) The media type structured syntax suffix registration form for +der follows:
ITUは、[ITU.X690.2008]でDistinguished Encoding Rules（DER）転送構文を定義しました。接尾辞「+ der」は、表現がDER転送構文に従う任意のメディアタイプで使用できます。 （メディアタイプの構造化構文のサフィックス登録のエキスパートレビューアーは、適切なサフィックスの選択を支援するために、BERとDERの関係を認識している必要があります。）+ derのメディアタイプの構造化構文のサフィックス登録フォームは次のとおりです。
Name: Distinguished Encoding Rules (DER) transfer syntax
名前：Distinguished Encoding Rules（DER）転送構文
+suffix: +der
References: [ITU.X690.2008]
参照：[ITU.X690.2008]
Encoding considerations: DER is a binary encoding.
エンコーディングに関する考慮事項：DERはバイナリエンコーディングです。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
At publication of this document, there is no fragment identification syntax defined for +der.
このドキュメントの公開時には、+ derに対して定義されたフラグメント識別構文はありません。
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+der" SHOULD be processed as follows:
特定の「xxx / yyy + der」のフラグメント識別子の構文とセマンティクスは、次のように処理する必要があります。
For cases defined in +der, where the fragment identifier resolves per the +der rules, then process as specified in +der.
+ derで定義されたケースの場合、フラグメント識別子は+ derルールに従って解決され、+ derで指定されたとおりに処理されます。
For cases defined in +der, where the fragment identifier does not resolve per the +der rules, then process as specified in "xxx/yyy+der".
+ derで定義されているケースで、フラグメント識別子が+ derルールに従って解決されない場合は、「xxx / yyy + der」で指定されているように処理します。
For cases not defined in +der, then process as specified in "xxx/yyy+der".
+ derで定義されていないケースの場合は、「xxx / yyy + der」で指定されているように処理します。
Interoperability considerations: n/a
相互運用性に関する考慮事項：なし
Security considerations:
セキュリティに関する考慮事項：
Each individual media type registered with a +der suffix can have additional security considerations.
+ derサフィックスで登録された個々のメディアタイプには、セキュリティに関する追加の考慮事項があります。
DER has a type-length-value structure, and it is easy to construct malicious content with invalid length fields that can cause buffer overrun conditions.
DERにはtype-length-value構造があり、バッファオーバーラン状態を引き起こす可能性がある無効な長さフィールドを持つ悪意のあるコンテンツを簡単に構築できます。
DER allows for arbitrary levels of nesting, which may make it possible to construct malicious content that will cause a stack overflow.
DERは、任意のレベルのネストを可能にします。これにより、スタックオーバーフローを引き起こす悪意のあるコンテンツを構築できる可能性があります。
Interpreters of the DER structures should be aware of these issues and should take appropriate measures to guard against buffer overflows and stack overruns in particular and malicious content in general.
DER構造のインタープリターはこれらの問題を認識している必要があり、特定のバッファーオーバーフローやスタックオーバーラン、そして一般的には悪意のあるコンテンツに対して保護するための適切な対策を講じる必要があります。
Contact: Apps Area Working Group (apps-discuss@ietf.org)
連絡先：Apps Area Working Group（apps-discuss@ietf.org）
Author/Change controller:
著者/変更コントローラ：
The Apps Area Working Group. IESG has change control over this registration.
アプリ領域作業グループ。 IESGは、この登録を変更管理します。
The ITU defined the Fast Infoset document format as a binary representation of the XML Information Set in [ITU.X891.2005]. These documents further define the "application/fastinfoset" media type. The suffix "+fastinfoset" MAY be used with any media type whose representation follows that established for "application/ fastinfoset". The media type structured syntax suffix registration form follows:
ITUは、Fast Infosetドキュメント形式を[ITU.X891.2005]のXML情報セットのバイナリ表現として定義しました。これらのドキュメントは、「application / fastinfoset」メディアタイプをさらに定義しています。接尾辞 "+ fastinfoset"は、 "application / fastinfoset"に対して確立されたものに従う表現に従う任意のメディアタイプで使用できます（MAY）。メディアタイプの構造化構文のサフィックス登録フォームは次のとおりです。
Name: Fast Infoset document format
名前：Fast Infosetドキュメント形式
+suffix: +fastinfoset References: [ITU.X891.2005]
+サフィックス：+ fastinfoset参照：[ITU.X891.2005]
Encoding considerations:
エンコードに関する考慮事項：
Fast Infoset is a binary encoding. The binary, quoted-printable, and base64 content-transfer-encodings are suitable for use with Fast Infoset.
Fast Infosetはバイナリエンコーディングです。バイナリ、quoted-printable、およびbase64 content-transfer-encodingsは、Fast Infosetでの使用に適しています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
The syntax and semantics of fragment identifiers specified for +fastinfoset SHOULD be as specified for "application/fastinfoset". (At publication of this document, there is no fragment identification syntax defined for "application/fastinfoset".)
+ fastinfosetに指定されたフラグメント識別子の構文とセマンティクスは、「application / fastinfoset」に指定されたとおりである必要があります（SHOULD）。 （このドキュメントの公開時には、「application / fastinfoset」に対して定義されたフラグメント識別構文はありません。）
The syntax and semantics for fragment identifiers for a specific "xxx/ yyy+fastinfoset" SHOULD be processed as follows:
特定の「xxx / yyy + fastinfoset」のフラグメント識別子の構文とセマンティクスは、次のように処理する必要があります。
For cases defined in +fastinfoset, where the fragment identifier resolves per the +fastinfoset rules, then process as specified in +fastinfoset.
+ fastinfosetで定義されているケースの場合、フラグメント識別子は+ fastinfosetルールに従って解決され、+ fastinfosetで指定されているように処理されます。
For cases defined in +fastinfoset, where the fragment identifier does not resolve per the +fastinfoset rules, then process as specified in "xxx/yyy+fastinfoset".
+ fastinfosetで定義されているケースで、フラグメント識別子が+ fastinfosetルールに従って解決されない場合は、「xxx / yyy + fastinfoset」で指定されているように処理します。
For cases not defined in +fastinfoset, then process as specified in "xxx/ yyy+fastinfoset".
+ fastinfosetで定義されていない場合は、「xxx / yyy + fastinfoset」で指定されているように処理します。
Interoperability considerations: n/a
相互運用性に関する考慮事項：なし
Security considerations:
セキュリティに関する考慮事項：
There are no security considerations inherent in Fast Infoset. Each individual media type registered with a +fastinfoset suffix can have additional security considerations.
Fast Infosetに固有のセキュリティに関する考慮事項はありません。 + fastinfosetサフィックスで登録された個々のメディアタイプには、セキュリティに関する追加の考慮事項があります。
Contact: Apps Area Working Group (apps-discuss@ietf.org)
連絡先：Apps Area Working Group（apps-discuss@ietf.org）
Author/Change controller:
著者/変更コントローラ：
The Apps Area Working Group. IESG has change control over this registration.
アプリ領域作業グループ。 IESGは、この登録を変更管理します。
The Wireless Application Protocol (WAP) Forum has defined the WAP Binary XML (WBXML) document format as a binary representation of XML in [WBXML]. This document further defines the "application/ vnd.wap.wbxml" media type. The suffix "+wbxml" MAY be used with any media type whose representation follows that established for "application/vnd.wap.wbxml". The media type structured syntax suffix registration form follows:
ワイヤレスアプリケーションプロトコル（WAP）フォーラムでは、WAPバイナリXML（WBXML）ドキュメント形式を[WBXML]のXMLのバイナリ表現として定義しています。このドキュメントでは、「application / vnd.wap.wbxml」メディアタイプをさらに定義しています。接尾辞「+ wbxml」は、「application / vnd.wap.wbxml」用に確立されたものに従う表現に従う任意のメディアタイプで使用できます。メディアタイプの構造化構文のサフィックス登録フォームは次のとおりです。
Name: WAP Binary XML (WBXML) document format
名前：WAP Binary XML（WBXML）ドキュメント形式
+suffix: +wbxml
References: [WBXML]
参照：[WBXML]
Encoding considerations: WBXML is a binary encoding.
エンコーディングに関する考慮事項：WBXMLはバイナリエンコーディングです。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
The syntax and semantics of fragment identifiers specified for +wbxml SHOULD be as specified for "application/vnd.wap.wbxml". (At publication of this document, there is no fragment identification syntax defined for "application/vnd.wap.wbxml".)
+ wbxmlに指定されたフラグメント識別子の構文とセマンティクスは、「application / vnd.wap.wbxml」に指定されたとおりである必要があります（SHOULD）。 （このドキュメントの公開時には、「application / vnd.wap.wbxml」に対して定義されたフラグメント識別構文はありません。）
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+wbxml" SHOULD be processed as follows:
特定の「xxx / yyy + wbxml」のフラグメント識別子の構文とセマンティクスは、次のように処理する必要があります。
For cases defined in +wbxml, where the fragment identifier resolves per the +wbxml rules, then process as specified in +wbxml.
+ wbxmlで定義されているケースの場合、フラグメント識別子は+ wbxmlルールに従って解決され、+ wbxmlで指定されているように処理されます。
For cases defined in +wbxml, where the fragment identifier does not resolve per the +wbxml rules, then process as specified in "xxx/yyy+wbxml".
+ wbxmlで定義されているケースで、フラグメント識別子が+ wbxmlルールに従って解決されない場合は、「xxx / yyy + wbxml」で指定されているように処理します。
For cases not defined in +wbxml, then process as specified in "xxx/yyy+wbxml".
+ wbxmlで定義されていない場合は、「xxx / yyy + wbxml」で指定されているように処理します。
Interoperability considerations: n/a
相互運用性に関する考慮事項：なし
Security considerations:
セキュリティに関する考慮事項：
There are no security considerations inherent in WBXML. Each individual media type registered with a +wbxml suffix can have additional security considerations.
WBXMLに固有のセキュリティに関する考慮事項はありません。 + wbxmlサフィックスで登録された各メディアタイプには、セキュリティに関する追加の考慮事項があります。
Contact: Apps Area Working Group (apps-discuss@ietf.org) Author/Change controller:
連絡先：Apps Area Working Group（apps-discuss@ietf.org）著者/変更コントローラ：
The Apps Area Working Group. IESG has change control over this registration.
アプリ領域作業グループ。 IESGは、この登録を変更管理します。
The ZIP format is a public domain, cross-platform, interoperable file storage and transfer format, originally defined by PKWARE, Inc.; it supports compression and encryption and is used as the underlying representation by a variety of file formats. The media type "application/zip" has been registered for such files. The suffix "+zip" MAY be used with any media type whose representation follows that established for "application/zip". The media type structured syntax suffix registration form follows:
ZIP形式は、PKWARE、Inc.によって最初に定義された、パブリックドメイン、クロスプラットフォーム、相互運用可能なファイルストレージおよび転送形式です。圧縮と暗号化をサポートし、さまざまなファイル形式の基礎となる表現として使用されます。このようなファイルには、メディアタイプ「application / zip」が登録されています。接尾辞「+ zip」は、「application / zip」用に確立されたものに従う表現に従う任意のメディアタイプで使用できます。メディアタイプの構造化構文のサフィックス登録フォームは次のとおりです。
Name: ZIP file storage and transfer format
名前：ZIPファイルの保存と転送形式
+suffix: +zip
References: [ZIP]
参照：[ZIP]
Encoding considerations: ZIP is a binary encoding.
エンコーディングに関する考慮事項：ZIPはバイナリエンコーディングです。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
The syntax and semantics of fragment identifiers specified for +zip SHOULD be as specified for "application/zip". (At publication of this document, there is no fragment identification syntax defined for "application/zip".)
+ zipに指定されたフラグメント識別子の構文とセマンティクスは、「application / zip」に指定されたとおりである必要があります（SHOULD）。 （このドキュメントの公開時には、「application / zip」に対して定義されたフラグメント識別構文はありません。）
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+zip" SHOULD be processed as follows:
特定の「xxx / yyy + zip」のフラグメント識別子の構文とセマンティクスは、次のように処理する必要があります。
For cases defined in +zip, where the fragment identifier resolves per the +zip rules, then process as specified in +zip.
+ zipで定義されたケースの場合、フラグメント識別子は+ zipルールに従って解決され、+ zipで指定されたように処理されます。
For cases defined in +zip, where the fragment identifier does not resolve per the +zip rules, then process as specified in "xxx/yyy+zip".
+ zipで定義されたケースで、フラグメント識別子が+ zipルールに従って解決されない場合は、「xxx / yyy + zip」で指定されているように処理します。
For cases not defined in +zip, then process as specified in "xxx/yyy+zip".
+ zipで定義されていない場合は、「xxx / yyy + zip」で指定されているように処理します。
Interoperability considerations: n/a Security considerations:
相互運用性に関する考慮事項：n / aセキュリティに関する考慮事項：
IP files support two forms of encryption: Strong Encryption and AES 128-bit, 192-bit, and 256-bit encryption; see the specification for further details. Each individual media type registered with a +zip suffix can have additional security considerations.
IPファイルは2つの形式の暗号化をサポートしています。強力な暗号化とAES 128ビット、192ビット、および256ビット暗号化です。詳細については、仕様を参照してください。 + zipサフィックスで登録された個々のメディアタイプには、セキュリティに関する追加の考慮事項があります。
Contact: Apps Area Working Group (apps-discuss@ietf.org)
連絡先：Apps Area Working Group（apps-discuss@ietf.org）
Author/Change controller: The Apps Area Working Group. IESG has change control over this registration.
著者/変更コントローラー：アプリ領域作業グループ。 IESGは、この登録を変更管理します。
See the media type structured syntax suffix registration forms in Sections 3.1 - 3.6.
セクション3.1から3.6のメディアタイプの構造化構文のサフィックス登録フォームを参照してください。
The following structured syntax suffix registration for "+xml" shall be used to reflect the information found in [RFC3023], with the addition of fragment identifier considerations. (Note that [RFC3023] is in the process of being updated by [XML-MEDIATYPES].)
次の「+ xml」の構造化構文サフィックス登録は、[RFC3023]で見つかった情報を反映するために使用され、フラグメント識別子の考慮事項が追加されます。 （[RFC3023]は[XML-MEDIATYPES]によって更新中であることに注意してください。）
Name: Extensible Markup Language (XML)
名前：Extensible Markup Language（XML）
+suffix: +xml
References: [RFC3023]
参考文献：[RFC3023]
Encoding considerations:
エンコードに関する考慮事項：
Per [RFC3023], XML is allowed to be represented using both 7-bit and 8-bit encodings. When XML is written in UTF-8, XML is 8bit compatible ([RFC2045]). When XML is written in UTF-16 or UTF-32, XML is binary ([RFC2045]).
[RFC3023]に従い、XMLは7ビットと8ビットの両方のエンコーディングを使用して表現できます。 XMLがUTF-8で記述されている場合、XMLは8ビット互換です（[RFC2045]）。 XMLがUTF-16またはUTF-32で記述されている場合、XMLはバイナリ（[RFC2045]）です。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
The syntax and semantics of fragment identifiers specified for +xml SHOULD be as specified for "application/xml". (At publication of this document, the fragment identification syntax considerations for "application/xml" are defined in [RFC3023], Sections 5 and 7.)
+ xmlに指定されたフラグメント識別子の構文とセマンティクスは、「application / xml」に指定されたとおりである必要があります（SHOULD）。 （このドキュメントの公開時、「application / xml」のフラグメント識別構文に関する考慮事項は、[RFC3023]のセクション5および7で定義されています。）
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+xml" SHOULD be processed as follows:
特定の「xxx / yyy + xml」のフラグメント識別子の構文とセマンティクスは、次のように処理する必要があります。
For cases defined in +xml, where the fragment identifier resolves per the +xml rules, then process as specified in +xml.
+ xmlで定義されたケースの場合、フラグメント識別子は+ xmlルールに従って解決され、+ xmlで指定されたとおりに処理されます。
For cases defined in +xml, where the fragment identifier does not resolve per the +xml rules, then process as specified in "xxx/yyy+xml".
+ xmlで定義されているケースで、フラグメント識別子が+ xmlルールに従って解決されない場合は、「xxx / yyy + xml」で指定されているように処理します。
For cases not defined in +xml, then process as specified in "xxx/yyy+xml".
+ xmlで定義されていない場合は、「xxx / yyy + xml」で指定されているように処理します。
Interoperability considerations: See [RFC3023].
相互運用性に関する考慮事項：[RFC3023]を参照してください。
Security considerations: See [RFC3023]
セキュリティに関する考慮事項：[RFC3023]を参照
Contact: Apps Area Working Group (apps-discuss@ietf.org)
連絡先：Apps Area Working Group（apps-discuss@ietf.org）
Author/Change controller:
著者/変更コントローラ：
The Apps Area Working Group. IESG has change control over this registration.
アプリ領域作業グループ。 IESGは、この登録を変更管理します。
See the Security Considerations sections found in the media type structured syntax suffix registration forms from Sections 3 and 4.
セクション3および4のメディアタイプの構造化構文のサフィックス登録フォームにあるセキュリティに関する考慮事項のセクションを参照してください。
When updating a +<suffix> registration, care should be taken to review all previously-registered xxx/yyy+<suffix> media types as to whether they might be affected by the updated +<suffix> registration. Because the generic fragment identifier processing rules take precedence over media-type-specific rules, introducing new or changing existing definitions may break the existing registrations of specific media types, as well as particular implementations of applications that process affected media types. Such changes can introduce interoperability and security issues.
+ <suffix>登録を更新する場合、更新された+ <suffix>登録の影響を受ける可能性があるかどうかについて、以前に登録されたすべてのxxx / yyy + <suffix>メディアタイプを確認するように注意する必要があります。汎用フラグメント識別子処理ルールはメディアタイプ固有のルールよりも優先されるため、新しい定義または既存の定義の変更を導入すると、特定のメディアタイプの既存の登録や、影響を受けるメディアタイプを処理するアプリケーションの特定の実装が壊れる可能性があります。このような変更により、相互運用性とセキュリティの問題が発生する可能性があります。
When updating the fragment identifier processing rules for a specific xxx/yyy+<suffix> media type, care should be taken to review the generic fragment identifier processing rules for the +<suffix> registration and not introduce any conflicts. Because the generic fragment identifier processing rules take precedence over media-type-specific rules, such conflicting processing requirements should be ignored by an implementation, but such conflicts can introduce interoperability and security issues.
特定のxxx / yyy + <suffix>メディアタイプのフラグメント識別子処理ルールを更新する場合は、+ <suffix>登録の一般的なフラグメント識別子処理ルールを確認し、競合が発生しないように注意する必要があります。汎用フラグメント識別子の処理ルールはメディアタイプ固有のルールよりも優先されるため、このような競合する処理要件は実装で無視する必要がありますが、このような競合は相互運用性とセキュリティの問題を引き起こす可能性があります。
Note that [FRAGID-BP] provides additional advice to designers of fragment identifier rules for media type suffixes and specific media types.
[FRAGID-BP]は、メディアタイプサフィックスおよび特定のメディアタイプのフラグメント識別子ルールの設計者に追加のアドバイスを提供することに注意してください。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627] Crockford、D。、「JavaScript Object Notation（JSON）のアプリケーション/ jsonメディアタイプ」、RFC 4627、2006年7月。
[ITU.X690.2008] International Telecommunications Union, "Recommendation ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", ITU-T Recommendation X.690, November 2008.
[ITU.X690.2008] International Telecommunications Union、「Recommendation ITU-T X.690 | ISO / IEC 8825-1（2008）、ASN.1 encoding rules：Specification of basic encoding Rules（BER）、Canonical encoding rules（CER ）およびDistinguished encoding rules（DER）」、ITU-T Recommendation X.690、2008年11月。
[ITU.X891.2005] International Telecommunications Union, "Recommendation ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications of ASN.1: Fast infoset", ITU-T Recommendation X.891, May 2005.
[ITU.X891.2005] International Telecommunications Union、「Recommendation ITU-T X.891 | ISO / IEC 24824-1（2007）、Generic applications of ASN.1：Fast infoset」、ITU-T Recommendation X.891、May 2005年
[WBXML] Open Mobile Alliance, "Binary XML Content Format Specification", OMA Wireless Access Protocol WAP-192- WBXML-20010725-a, July 2001.
[WBXML] Open Mobile Alliance、「Binary XML Content Format Specification」、OMAワイヤレスアクセスプロトコルWAP-192- WBXML-20010725-a、2001年7月。
[ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format Specification", PKWARE .ZIP File Format Specification - Version 6.3.2, September 2007.
[ZIP] PKWARE、Inc。、「APPNOTE.TXT-.ZIPファイル形式の仕様」、PKWARE .ZIPファイル形式の仕様-バージョン6.3.2、2007年9月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、2013年1月。
[FRAGID-BP] Tennison, J., "Best Practices for Fragment Identifiers and Media Type Definitions", July 2012, <http://www.w3.org/TR/fragid-best-practices/>.
[FRAGID-BP] Tennison、J。、「フラグメント識別子とメディアタイプ定義のベストプラクティス」、2012年7月、<http://www.w3.org/TR/fragid-best-practices/>。
[XML-MEDIATYPES] Lilley, C., Makoto, M., Melnikov, A., and H. Thompson, "XML Media Types", Work in Progress, November 2012.
[XML-MEDIATYPES]リリー、C。、マコト、M。、メルニコフ、A。、およびH.トンプソン、「XMLメディアタイプ」、Work in Progress、2012年11月。
Authors' Addresses
著者のアドレス
Tony Hansen AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA
Tony Hansen AT＆T Laboratories 200 Laurel Ave. South Middletown、NJ 07748 USA
EMail: tony+sss@maillennium.att.com
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com