RFC2376 日本語訳
2376 XML Media Types. E. Whitehead, M. Murata. July 1998. (Format: TXT=32143 bytes) (Obsoleted by RFC3023) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Whitehead
Request for Comments: 2376 UC Irvine
Category: Informational M. Murata
Fuji Xerox Info. Systems
July 1998
コメントを求めるワーキンググループE.ホワイトヘッド要求をネットワークでつないでください: 2376年のUCアーバインカテゴリ: 情報のM.ムラタ富士ゼロックスインフォメーション。 システム1998年7月
XML Media Types
XMLメディアタイプ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.
このドキュメントは2ニューメディア血液型亜型、テキスト/xml、およびアプリケーション/xmlを提案します、拡張マークアップ言語(XML)を従わせているネットワーク実体を交換することにおける使用のために。 XML実体は、現在WWWのHyperText Transferプロトコルで交換されて、リモートウェブオーサリングのためのWebDAVプロトコルの不可欠の部分であり、多くのドメインにユーティリティを持っていると予想されます。
Table of Contents
目次
1 INTRODUCTION ....................................................2 2 NOTATIONAL CONVENTIONS ..........................................3 3 XML MEDIA TYPES .................................................3 3.1 Text/xml Registration ........................................3 3.2 Application/xml Registration .................................6 4 SECURITY CONSIDERATIONS .........................................8 5 THE BYTE ORDER MARK (BOM) AND CONVERSIONS TO/FROM UTF-16 ........9 6 EXAMPLES ........................................................9 6.1 text/xml with UTF-8 Charset .................................10 6.2 text/xml with UTF-16 Charset ................................10 6.3 text/xml with ISO-2022-KR Charset ...........................10 6.4 text/xml with Omitted Charset ...............................11 6.5 application/xml with UTF-16 Charset .........................11 6.6 application/xml with ISO-2022-KR Charset ....................11 6.7 application/xml with Omitted Charset and UTF-16 XML Entity ..12 6.8 application/xml with Omitted Charset and UTF-8 Entity .......12 6.9 application/xml with Omitted Charset and Internal Encoding Declaration.......................................................12
1つの序論…2 2の記号法のコンベンション…3 3のXMLメディアタイプ…3 3.1 テキスト/xml登録…3 3.2 アプリケーション/xml登録…6 4のセキュリティ問題…UTF-16からの/へのバイトオーダーがマークする8 5(BOM)と変換…9 6の例…9 UTF-8 Charsetと6.1テキスト/xml…10 UTF-16 Charsetと6.2テキスト/xml…10 ISO-2022-KR Charsetと6.3テキスト/xml…10 Omitted Charsetと6.4テキスト/xml…11 UTF-16 Charsetと6.5アプリケーション/xml…11 ISO-2022-KR Charsetと6.6アプリケーション/xml…11 6.7 Omitted CharsetとUTF-16 XML Entityとアプリケーション/xml。12 Omitted CharsetとUTF-8 Entityと6.8アプリケーション/xml…12 Omitted CharsetとInternal Encoding Declarationと6.9アプリケーション/xml…12
Whitehead & Murata Informational [Page 1] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[1ページ]のRFC2376XML Mediaタイプ1998年7月
7 REFERENCES .....................................................13 8 ACKNOWLEDGEMENTS ...............................................14 9 ADDRESSES OF AUTHORS ...........................................14 10 FULL COPYRIGHT STATEMENT ......................................15
7つの参照箇所…13 8つの承認…14 作者の9つのアドレス…14 10の完全な著作権宣言文…15
1 Introduction
1つの序論
The World Wide Web Consortium (W3C) has issued a Recommendation [REC-XML] which defines the Extensible Markup Language (XML), version 1. To enable the exchange of XML network entities, this document proposes two new media types, text/xml and application/xml.
ワールドワイドウェブコンソーシアム(W3C)は拡張マークアップ言語(XML)を定義するRecommendation[REC-XML]、バージョン1を発行しました。 XMLネットワーク実体の交換を可能にするために、このドキュメントは2つのニューメディアタイプ、テキスト/xml、およびアプリケーション/xmlを提案します。
XML entities are currently exchanged on the World Wide Web, and XML is also used for property values and parameter marshalling by the WebDAV protocol for remote web authoring. Thus, there is a need for a media type to properly label the exchange of XML network entities. (Note that, as sometimes happens between two communities, both MIME and XML have defined the term entity, with different meanings.)
現在WWWでXML実体を交換します、そして、また、リモートウェブオーサリングのためにWebDAVプロトコルによって整理される特性の値とパラメタにXMLを使用します。 したがって、メディアタイプが適切にXMLネットワーク実体の交換をラベルする必要があります。 (MIMEとXMLの両方が異なった意味で2つの共同体の間で時々起こると実体という用語を定義したことに注意してください。)
Although XML is a subset of the Standard Generalized Markup Language (SGML) [ISO-8897], and currently is assigned the media types text/sgml and application/sgml, there are several reasons why use of text/sgml or application/sgml to label XML is inappropriate. First, there exist many applications which can process XML, but which cannot process SGML, due to SGML's larger feature set. Second, SGML applications cannot always process XML entities, because XML uses features of recent technical corrigenda to SGML. Third, the definition of text/sgml and application/sgml [RFC-1874] includes parameters for SGML bit combination transformation format (SGML- bctf), and SGML boot attribute (SGML-boot). Since XML does not use these parameters, it would be ambiguous if such parameters were given for an XML entity. For these reasons, the best approach for labeling XML network entities is to provide new media types for XML.
XMLはStandard Generalized Markup Language(SGML)[ISO-8897]の部分集合であり、現在メディアタイプのテキスト/sgmlとアプリケーション/sgmlに割り当てられますが、テキスト/sgmlかXMLをラベルするアプリケーション/sgmlの使用が不適当であるいくつかの理由があります。 まず最初に、XMLを処理できますが、SGMLは処理できない多くの利用がSGMLの、より大きい特徴セットのため存在します。 2番目に、XMLが最近の技術的な正誤表の特徴をSGMLに使用するので、SGMLアプリケーションはいつもXML実体を処理できるというわけではありません。 3番目に、テキスト/sgmlとアプリケーション/sgml[RFC-1874]の定義はSGMLビット・コンビネーション変換形式(SGML bctf)、およびSGMLブーツ属性(SGMLブーツ)のためのパラメタを含んでいます。 XMLがこれらのパラメタを使用しないので、それはそのようなパラメタがXML実体のために与えられたかどうかあいまいでしょう。 これらの理由で、XMLネットワーク実体をラベルするための最も良いアプローチはニューメディアタイプをXMLに供給することです。
Since XML is an integral part of the WebDAV Distributed Authoring Protocol, and since World Wide Web Consortium Recommendations have conventionally been assigned IETF tree media types, and since similar media types (HTML, SGML) have been assigned IETF tree media types, the XML media types also belong in the IETF media types tree.
XMLがWebDAV Distributed Authoringプロトコルの不可欠の部分であり、ワールドワイドウェブコンソーシアムRecommendationsが慣習上IETF木のメディアタイプに割り当てられて、同様のメディアタイプ(HTML、SGML)がIETF木のメディアタイプに選任されたので、メディアがまた、IETFメディアにはあるのをタイプするXMLは木をタイプします。
Whitehead & Murata Informational [Page 2] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[2ページ]のRFC2376XML Mediaタイプ1998年7月
2 Notational Conventions
2 記号法のコンベンション
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 [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
3 XML Media Types
3 XMLメディアタイプ
This document introduces two new media types for XML entities, text/xml and application/xml. Registration information for these media types are described in the sections below.
このドキュメントはXML実体、テキスト/xml、およびアプリケーション/xmlのために2つのニューメディアタイプを導入します。 下のセクションで、説明されますこれらのメディアのためのレジスト情報が、タイプする。
Every XML entity is suitable for use with the application/xml media type without modification. But this does not exploit the fact that XML can be treated as plain text in many cases. MIME user agents (and web user agents) that do not have explicit support for application/xml will treat it as application/octet-stream, for example, by offering to save it to a file.
アプリケーション/xmlメディアタイプにおいて、あらゆるXML実体が変更なしで使用に適しています。 しかし、これは多くの場合、プレーンテキストとしてXMLを扱うことができるという事実を利用しません。 例えば、ファイルにそれを保存すると申し出ることによって、アプリケーション/xmlの明白なサポートを持っていないMIMEユーザエージェント(そして、ウェブユーザーエージェント)が八重奏アプリケーション/ストリームとしてそれを扱うでしょう。
To indicate that an XML entity should be treated as plain text by default, use the text/xml media type. This restricts the encoding used in the XML entity to those that are compatible with the requirements for text media types as described in [RFC-2045] and [RFC-2046], e.g., UTF-8, but not UTF-16 (except for HTTP).
XML実体がプレーンテキストとして扱われるべきであるのを示すには、デフォルトで、テキスト/xmlメディアタイプを使用してください。 これはXML実体にUTF-16(HTTPを除いた)ではなく、[RFC-2045]と[RFC-2046]、例えば、UTF-8で説明されるようにテキストメディアタイプのための要件と互換性があるものに使用されるコード化を制限します。
XML provides a general framework for defining sequences of structured data. In some cases, it may be desirable to define new media types which use XML but define a specific application of XML, perhaps due to domain-specific security considerations or runtime information. This document does not prohibit future media types dedicated to such XML applications. However, developers of such media types are recommended to use this document as a basis. In particular, the charset parameter should be used in the same manner.
XMLは構造化されたデータの系列を定義するのに一般的なフレームワークを提供します。 いくつかの場合、XMLを使用するニューメディアタイプを定義しますが、XMLの特定のアプリケーションを定義するのは望ましいかもしれません、恐らくドメイン特有のセキュリティ問題かランタイム情報のため。 このドキュメントはそのようなXMLアプリケーションに専念した将来のメディアタイプを禁止しません。 しかしながら、そのようなメディアタイプの開発者は基礎としてこのドキュメントを使用するためにお勧めです。 特に、charsetパラメタは同じ方法で使用されるべきです。
Within the XML specification, XML entities can be classified into four types. In the XML terminology, they are called "document entities", "external DTD subsets", "external parsed entities", and "external parameter entities". The media types text/xml and application/xml can be used for any of these four types.
XML仕様の中では、XML実体を4つのタイプに分類できます。 XML用語で、それらは「ドキュメント実体」、「外部のDTD部分集合」、「外部の解析対象実体」、および「外部のパラメタ実体」と呼ばれます。 これらの4つのタイプのいずれにもメディアタイプのテキスト/xmlとアプリケーション/xmlを使用できます。
3.1 Text/xml Registration
3.1 テキスト/xml登録
MIME media type name: text
MIMEメディア型名: テキスト
MIME subtype name: xml
MIME「副-タイプ」は以下を命名します。 xml
Mandatory parameters: none
義務的なパラメタ: なし
Whitehead & Murata Informational [Page 3] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[3ページ]のRFC2376XML Mediaタイプ1998年7月
Optional parameters: charset
任意のパラメタ: charset
Although listed as an optional parameter, the use of the charset
parameter is STRONGLY RECOMMENDED, since this information can be
used by XML processors to determine authoritatively the character
encoding of the XML entity. The charset parameter can also be used
to provide protocol-specific operations, such as charset-based
content negotiation in HTTP. "UTF-8" [RFC-2279] is the
recommended value, representing the UTF-8 charset. UTF-8 is
supported by all conforming XML processors [REC-XML].
任意のパラメタとして記載されていますが、charsetパラメタの使用はSTRONGLY RECOMMENDEDです、この情報がXMLプロセッサによって使用されて、厳然とXML実体の文字符号化を決定できるので。 また、HTTPにおけるcharsetベースの満足している交渉などのプロトコル特有の操作を提供するのにcharsetパラメタを使用できます。 「UTF-8 charsetを表して、UTF-8インチ[RFC-2279]は推奨値です。」 UTF-8はすべての従うXMLプロセッサ[REC-XML]によってサポートされます。
If the XML entity is transmitted via HTTP, which uses a MIME-like
mechanism that is exempt from the restrictions on the text top-
level type (see section 19.4.1 of HTTP 1.1 [RFC-2068]), "UTF-16"
(Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646]) is also
recommended. UTF-16 is supported by all conforming XML processors
[REC-XML]. Since the handling of CR, LF and NUL for text types in
most MIME applications would cause undesired transformations of
individual octets in UTF-16 multi-octet characters, gateways from
HTTP to these MIME applications MUST transform the XML entity from
a text/xml; charset="utf-16" to application/xml; charset="utf-16".
HTTP(テキストの最高平らなタイプにおける制限によって免除されているMIMEのようなメカニズムを使用する)でXML実体が伝えられるなら(.1のセクション19.4HTTP1.1[RFC-2068]を見てください)、「また、UTF-16インチ([ISO-10646]の[ユニコード]と修正1の付録C.3)もお勧めです」。 UTF-16はすべての従うXMLプロセッサ[REC-XML]によってサポートされます。 ほとんどのMIMEアプリケーションにおけるテキストタイプのためのCR、LF、およびNULの取り扱いはUTF-16マルチ八重奏キャラクタにおける個々の八重奏の望まれない変換を引き起こすでしょう、したがって、HTTPからこれらのMIMEアプリケーションへのゲートウェイはテキスト/xmlからXML実体を変えなければなりません。 charsetは「16インチをutfしているアプリケーション/xml」と等しいです。 charset=「utf16インチ。」
Conformant with [RFC-2046], if a text/xml entity is received with
the charset parameter omitted, MIME processors and XML processors
MUST use the default charset value of "us-ascii". In cases where
the XML entity is transmitted via HTTP, the default charset value
is still "us-ascii".
[RFC-2046]があるConformant、charsetパラメタが省略されている状態でテキスト/xml実体を受け取るか、そして、MIMEプロセッサ、およびXMLプロセッサがデフォルトcharset価値を使用しなければならない、「私たち、-、ASCII、」 XML実体がHTTPで伝えられる場合では、デフォルトcharset価値がまだそうである、「私たち、-、ASCII、」
Since the charset parameter is authoritative, the charset is not
always declared within an XML encoding declaration. Thus, special
care is needed when the recipient strips the MIME header and
provides persistent storage of the received XML entity (e.g., in a
file system). Unless the charset is UTF-8 or UTF-16, the recipient
SHOULD also persistently store information about the charset,
perhaps by embedding a correct XML encoding declaration within the
XML entity.
charsetパラメタが正式であるので、charsetは宣言をコード化するXMLの中でいつも申告されるというわけではありません。 受取人がMIMEヘッダーを裸にして、容認されたXML実体の永続的なストレージを提供するとき(例えば、ファイルシステムで)、したがって、特別な注意が必要です。 また、charsetがUTF-8かUTF-16でないなら、受取人SHOULDはcharsetの情報を持続して保存します、恐らくXML実体の中で宣言をコード化する正しいXMLを埋め込むことによって。
Encoding considerations:
問題をコード化します:
This media type MAY be encoded as appropriate for the charset and
the capabilities of the underlying MIME transport. For 7-bit
transports, data in both UTF-8 and UTF-16 is encoded in quoted-
printable or base64. For 8-bit clean transport (e.g., ESMTP,
8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64
encoded. For binary clean transports (e.g., HTTP), no content-
transfer-encoding is necessary.
このメディアタイプは基本的なMIME輸送のcharsetと能力のために適宜コード化されるかもしれません。 7ビットにおいて、輸送、UTF-8とUTF-16の両方のデータは引用されるところで印刷可能な状態でコード化されます。または、base64。 8ビットの清潔な輸送(例えば、ESMTP、8BITMIME、またはNNTP)において、UTF-8はコード化されませんが、UTF-16はコード化されたbase64です。 2進の清潔な輸送(例えば、HTTP)に、内容転送コード化は必要ではありません。
Whitehead & Murata Informational [Page 4] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[4ページ]のRFC2376XML Mediaタイプ1998年7月
Security considerations:
セキュリティ問題:
See section 4 below.
下のセクション4を見てください。
Interoperability considerations:
相互運用性問題:
XML has proven to be interoperable across WebDAV clients and
servers, and for import and export from multiple XML authoring
tools.
XMLはWebDAVクライアントとサーバの向こう側に共同利用できると判明して、複数のXMLオーサリングツールからの輸出入のためにそうします。
Published specification: see [REC-XML]
広められた仕様: 見てください。[REC-XML]
Applications which use this media type:
このメディアタイプを使用するアプリケーション:
XML is device-, platform-, and vendor-neutral and is supported by
a wide range of Web user agents, WebDAV clients and servers, as
well as XML authoring tools.
XMLはデバイスと、プラットホームと、ベンダー中立であり、さまざまなウェブユーザエージェント、WebDAVクライアント、およびサーバによってサポートされます、XMLオーサリングツールと同様に。
Additional information:
追加情報:
Magic number(s): none
マジックナンバー(s): なし
Although no byte sequences can be counted on to always be present,
XML entities in ASCII-compatible charsets (including UTF-8) often
begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"). For more
information, see Appendix F of [REC-XML].
バイト列を全くいつも存在させているのを頼りにすることができませんが、ASCIIコンパチブルcharsets(UTF-8を含んでいる)のXML実体は16進3C3F78 6Dと共にしばしば6C(「<?xml」)始まります。 詳しくは、[REC-XML]のAppendix Fを見てください。
File extension(s): .xml, .dtd
Macintosh File Type Code(s): "TEXT"
ファイル拡張子(s): .xml、.dtdマッキントッシュファイルの種類コード: 「テキスト」
Person & email address for further information:
詳細のための人とEメールアドレス:
Dan Connolly <connolly@w3.org>
Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp>
ダン Connolly <connolly@w3.org 、gt;、誠ムラタ(与えられているファミリー) <murata@fxis.fujixerox.co.jp 、gt。
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller:
コントローラを書くか、または変えてください:
The XML specification is a work product of the World Wide Web
Consortium's XML Working Group, and was edited by:
XML仕様は、ワールドワイドウェブコンソーシアムのXML作業部会の作業生産物であり、以下によって編集されました。
Tim Bray <tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
ティム Bray <tbray@textuality.com 、gt;、ジーン Paoli <jeanpa@microsoft.com 、gt;、C.M. Sperberg-McQueen <cmsmcq@uic.edu 、gt。
The W3C, and the W3C XML working group, has change control over
the XML specification.
W3C、およびW3C XMLワーキンググループには、XML仕様の変化コントロールがあります。
Whitehead & Murata Informational [Page 5] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[5ページ]のRFC2376XML Mediaタイプ1998年7月
3.2 Application/xml Registration
3.2 アプリケーション/xml登録
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: xml
MIME「副-タイプ」は以下を命名します。 xml
Mandatory parameters: none
義務的なパラメタ: なし
Optional parameters: charset
任意のパラメタ: charset
Although listed as an optional parameter, the use of the charset
parameter is STRONGLY RECOMMENDED, since this information can be
used by XML processors to determine authoritatively the charset of
the XML entity. The charset parameter can also be used to provide
protocol-specific operations, such as charset-based content
negotiation in HTTP.
任意のパラメタとして記載されていますが、charsetパラメタの使用はSTRONGLY RECOMMENDEDです、この情報がXMLプロセッサによって使用されて、厳然とXML実体のcharsetを決定できるので。 また、HTTPにおけるcharsetベースの満足している交渉などのプロトコル特有の操作を提供するのにcharsetパラメタを使用できます。
"UTF-8" [RFC-2279] and "UTF-16" (Appendix C.3 of [UNICODE] and
Amendment 1 of [ISO-10646]) are the recommended values,
representing the UTF-8 and UTF-16 charsets, respectively. These
charsets are preferred since they are supported by all conforming
XML processors [REC-XML].
「UTF-8インチ[RFC-2279]と「UTF-16インチ([ISO-10646]の[ユニコード]と修正1の付録C.3)は推奨値です、それぞれUTF-8とUTF-16 charsetsを表して」。 彼らがすべての従うXMLプロセッサ[REC-XML]によってサポートされて、これらのcharsetsは好まれます。
If an application/xml entity is received where the charset
parameter is omitted, no information is being provided about the
charset by the MIME Content-Type header. Conforming XML processors
MUST follow the requirements in section 4.3.3 of [REC-XML] which
directly address this contingency. However, MIME processors which
are not XML processors should not assume a default charset if the
charset parameter is omitted from an application/xml entity.
charsetパラメタが省略されるところにアプリケーション/xml実体を受け取るなら、MIMEコンテントタイプヘッダーはcharsetに関して情報を全く提供していません。 XMLプロセッサを従わせると、直接この偶然性を扱う.3セクション4.3[REC-XML]の要件は続かなければなりません。 しかしながら、charsetパラメタがアプリケーション/xml実体から省略されるなら、XMLプロセッサでないMIMEプロセッサは、デフォルトがcharsetであると仮定するはずがありません。
Since the charset parameter is authoritative, the charset is not
always declared within an XML encoding declaration. Thus, special
care is needed when the recipient strips the MIME header and
provides persistent storage of the received XML entity (e.g., in a
file system). Unless the charset is UTF-8 or UTF-16, the
recipient SHOULD also persistently store information about the
charset, perhaps by embedding a correct XML encoding declaration
within the XML entity.
charsetパラメタが正式であるので、charsetは宣言をコード化するXMLの中でいつも申告されるというわけではありません。 受取人がMIMEヘッダーを裸にして、容認されたXML実体の永続的なストレージを提供するとき(例えば、ファイルシステムで)、したがって、特別な注意が必要です。 また、charsetがUTF-8かUTF-16でないなら、受取人SHOULDはcharsetの情報を持続して保存します、恐らくXML実体の中で宣言をコード化する正しいXMLを埋め込むことによって。
Whitehead & Murata Informational [Page 6] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[6ページ]のRFC2376XML Mediaタイプ1998年7月
Encoding considerations:
問題をコード化します:
This media type MAY be encoded as appropriate for the charset and
the capabilities of the underlying MIME transport. For 7-bit
transports, data in both UTF-8 and UTF-16 is encoded in quoted-
printable or base64. For 8-bit clean transport (e.g., ESMTP,
8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64
encoded. For binary clean transport (e.g., HTTP), no content-
transfer-encoding is necessary.
このメディアタイプは基本的なMIME輸送のcharsetと能力のために適宜コード化されるかもしれません。 7ビットにおいて、輸送、UTF-8とUTF-16の両方のデータは引用されるところで印刷可能な状態でコード化されます。または、base64。 8ビットの清潔な輸送(例えば、ESMTP、8BITMIME、またはNNTP)において、UTF-8はコード化されませんが、UTF-16はコード化されたbase64です。 2進の清潔な輸送(例えば、HTTP)に、内容転送コード化は必要ではありません。
Security considerations:
セキュリティ問題:
See section 4 below.
下のセクション4を見てください。
Interoperability considerations:
相互運用性問題:
XML has proven to be interoperable for import and export from
multiple XML authoring tools.
XMLは輸入のように共同利用できると判明して、複数のXMLオーサリングツールからエクスポートします。
Published specification: see [REC-XML]
広められた仕様: 見てください。[REC-XML]
Applications which use this media type:
このメディアタイプを使用するアプリケーション:
XML is device-, platform-, and vendor-neutral and is supported by
a wide range of Web user agents and XML authoring tools.
XMLはデバイスと、プラットホームと、ベンダー中立であり、さまざまなウェブユーザエージェントとXMLオーサリングツールによってサポートされます。
Additional information:
追加情報:
Magic number(s): none
マジックナンバー(s): なし
Although no byte sequences can be counted on to always be present,
XML entities in ASCII-compatible charsets (including UTF-8) often
begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in
UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D
or FF FE 3C 00 3F 00 78 00 6D 00 (the Byte Order Mark (BOM)
followed by "<?xml"). For more information, see Annex F of [REC-
XML].
バイト列を全くいつも存在させているのを頼りにすることができませんが、ASCIIコンパチブルcharsets(UTF-8を含んでいる)のXML実体は16進3C3F78 6Dと共にしばしば6C(「<?xml」)始まります、そして、UTF-16のものはしばしば16進でFE FF00 3の3FのC00 00 78 00 6DかFF FE3C00 3F00 78 00 6D00を始めます(Byte Orderマーク(BOM)は「<?xml」で続きました)。 詳しくは、[REC- XML]のAnnex Fを見てください。
File extension(s): .xml, .dtd
Macintosh File Type Code(s): "TEXT"
ファイル拡張子(s): .xml、.dtdマッキントッシュファイルの種類コード: 「テキスト」
Person & email address for further information:
詳細のための人とEメールアドレス:
Dan Connolly <connolly@w3.org>
Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp>
ダン Connolly <connolly@w3.org 、gt;、誠ムラタ(与えられているファミリー) <murata@fxis.fujixerox.co.jp 、gt。
Intended usage: COMMON
意図している用法: 一般的
Whitehead & Murata Informational [Page 7] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[7ページ]のRFC2376XML Mediaタイプ1998年7月
Author/Change controller:
コントローラを書くか、または変えてください:
The XML specification is a work product of the World Wide Web
Consortium's XML Working Group, and was edited by:
XML仕様は、ワールドワイドウェブコンソーシアムのXML作業部会の作業生産物であり、以下によって編集されました。
Tim Bray <tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
ティム Bray <tbray@textuality.com 、gt;、ジーン Paoli <jeanpa@microsoft.com 、gt;、C.M. Sperberg-McQueen <cmsmcq@uic.edu 、gt。
The W3C, and the W3C XML working group, has change control over
the XML specification.
W3C、およびW3C XMLワーキンググループには、XML仕様の変化コントロールがあります。
4 Security Considerations
4 セキュリティ問題
XML, as a subset of SGML, has the same security considerations as specified in [RFC-1874].
XMLには、SGMLの部分集合として、[RFC-1874]の指定されるのと同じセキュリティ問題があります。
To paraphrase section 3 of [RFC-1874], XML entities contain information to be parsed and processed by the recipient's XML system. These entities may contain and such systems may permit explicit system level commands to be executed while processing the data. To the extent that an XML system will execute arbitrary command strings, recipients of XML entities may be at risk. In general, it may be possible to specify commands that perform unauthorized file operations or make changes to the display processor's environment that affect subsequent operations.
[RFC-1874]のセクション3について言い換えるために、XML実体は受取人のXMLシステムによって分析された、処理されるべき情報を含んでいます。 これらの実体は含むかもしれません、そして、そのようなシステムはデータを処理している間に実行されるべき明白なシステムレベルコマンドを可能にするかもしれません。 XMLシステムが任意のコマンドストリングを実行するという範囲に、XML実体の受取人は危険であるかもしれません。 一般に、権限のないファイル操作を実行するコマンドを指定するか、またはディスプレイ・プロセッサの環境へのその後の操作に影響する変更を行うのが可能であるかもしれません。
Use of XML is expected to be varied, and widespread. XML is under scrutiny by a wide range of communities for use as a common syntax for community-specific metadata. For example, the Dublin Core group is using XML for document metadata, and a new effort has begun which is considering use of XML for medical information. Other groups view XML as a mechanism for marshalling parameters for remote procedure calls. More uses of XML will undoubtedly arise.
様々であって、XMLの使用が広範囲であると予想されます。 XMLは一般的な構文としての共同体特有のメタデータの使用のためのさまざまな共同体による精査でのものです。 例えば、ダブリンCoreグループはドキュメントメタデータにXMLを使用しています、そして、XMLの医療情報の使用を考えている新しい取り組みは始まりました。 他のグループは、遠隔手続き呼び出しのためのパラメタを整理するためにXMLをメカニズムであるとみなします。 XMLの、より多くの用途が確かに起こるでしょう。
Security considerations will vary by domain of use. For example, XML medical records will have much more stringent privacy and security considerations than XML library metadata. Similarly, use of XML as a parameter marshalling syntax necessitates a case by case security review.
セキュリティ問題は地上権で異なるでしょう。 例えば、XMLカルテには、XMLライブラリメタデータよりはるかに厳しいプライバシーとセキュリティ問題があるでしょう。 同様に、パラメタ整理構文としてのXMLの使用はケースバイケースでaを必要とします。安全レビュー。
XML may also have some of the same security concerns as plain text. Like plain text, XML can contain escape sequences which, when displayed, have the potential to change the display processor environment in ways that adversely affect subsequent operations. Possible effects include, but are not limited to, locking the keyboard, changing display parameters so subsequent displayed text is unreadable, or even changing display parameters to deliberately
また、XMLには、プレーンテキストと同じセキュリティ関心のいくつかがあるかもしれません。 プレーンテキストのように、XMLは表示するとその後の操作に悪影響を与える方法でディスプレイ・プロセッサ環境を変える可能性を持っているエスケープシーケンスを含むことができます。 可能な効果は、含んでいますが、ディスプレイパラメタを変えて、キーボードをロックして、その後の表示されたテキストが読みにくくて、制限されるか、または故意にディスプレイパラメタを変えてさえいません。
Whitehead & Murata Informational [Page 8] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[8ページ]のRFC2376XML Mediaタイプ1998年7月
obscure or distort subsequent displayed material so that its meaning is lost or altered. Display processors should either filter such material from displayed text or else make sure to reset all important settings after a given display operation is complete.
その後の表示された材料を見えなくするか、または歪めてくださいので、意味は、失われているか、または変更されます。 与えられたディスプレイ操作が完全になった後に、ディスプレイ・プロセッサは、表示されたテキストからそのような材料をフィルターにかけるはずであるか、またはすべての重要な設定をリセットするのを確実にするはずです。
Some terminal devices have keys whose output, when pressed, can be changed by sending the display processor a character sequence. If this is possible the display of a text object containing such character sequences could reprogram keys to perform some illicit or dangerous action when the key is subsequently pressed by the user. In some cases not only can keys be programmed, they can be triggered remotely, making it possible for a text display operation to directly perform some unwanted action. As such, the ability to program keys should be blocked either by filtering or by disabling the ability to program keys entirely.
いくつかの端末装置が押されるとキャラクタシーケンスをディスプレイ・プロセッサに送ることによって出力を変えることができるキーを持っています。 これが可能であるなら、そのようなキャラクタシーケンスを含むテキストオブジェクトのディスプレイは、キーが次にユーザによって押されたら何らかの不法であるか危険な動きを実行するようにキーにプログラムを変えるかもしれません。 いくつかの場合缶のキーだけがプログラムされないで、それらを離れて引き起こすことができます、テキストディスプレイ操作が直接何らかの求められていない動作を実行するのを可能にして。 そういうものとして、キーをプログラムする能力は、フィルタリングかプログラムキーに能力を完全に無効にすることによって、妨げられるべきです。
Note that it is also possible to construct XML documents which make use of what XML terms "entity references" (using the XML meaning of the term "entity", which differs from the MIME definition of this term), to construct repeated expansions of text. Recursive expansions are prohibited [REC-XML] and XML processors are required to detect them. However, even non-recursive expansions may cause problems with the finite computing resources of computers, if they are performed many times.
また、使用を構造物の「実体参照」(「実体」という今期のMIME定義と異なっている用語のXML意味を使用する)がどんなXML用語のときにテキストの拡張を繰り返したかをするXMLドキュメントを構成するのも可能であることに注意してください。 再帰的な拡張は禁止されています、そして、[REC-XML]XMLプロセッサが、それらを検出するのに必要です。 しかしながら、それらが何回も実行されるなら、非再帰的な拡張さえコンピュータの有限コンピューティング資源で問題を起こすかもしれません。
5 The Byte Order Mark (BOM) and Conversions to/from UTF-16
5 UTF-16からの/へのByte Orderマーク(BOM)とConversions
The XML Recommendation, in section 4.3.3, specifies that UTF-16 XML entities must begin with a byte order mark (BOM), which is the ZERO WIDTH NO-BREAK SPACE character, hexadecimal sequence 0xFEFF (or 0xFFFE, depending on endian). The XML Recommendation further states that the BOM is an encoding signature, and is not part of either the markup or the character data of the XML document.
セクション4.3.3では、XML Recommendationは、UTF-16 XML実体がバイト・オーダー・マーク(BOM)で始まらなければならないと指定します。(ZERO WIDTH NO-BREAK SPACEキャラクタ、バイト・オーダー・マークは16進系列0xFEFF(または、エンディアンによる0xFFFE)です)。 XML RecommendationはBOMがコード化署名であり、XMLドキュメントに関するマーク付けかキャラクタデータのどちらかの一部でないとさらに述べます。
Due to the BOM, applications which convert XML from the UTF-16 encoding to another encoding SHOULD strip the BOM before conversion. Similarly, when converting from another encoding into UTF-16, the BOM SHOULD be added after conversion is complete.
BOMのため、SHOULDをコード化しながらUTF-16コード化から別のものまでXMLを変換するアプリケーションが変換の前にBOMを剥取ります。 同様である、別のコード化からUTF-16に変えるときのBOM SHOULD、変換が完全になった後に加えられてください。
6 Examples
6つの例
The examples below give the value of the Content-type MIME header and
the XML declaration (which includes the encoding declaration) inside
the XML entity. For UTF-16 examples, the Byte Order Mark character
is denoted as "{BOM}", and the XML declaration is assumed to come at
the beginning of the XML entity, immediately following the BOM. Note
that other MIME headers may be present, and the XML entity may
以下の例はXML実体で文書内容MIMEヘッダーとXML宣言の値(コード化宣言を含んでいる)を与えます。 UTF-16の例、マークキャラクタが指示されるByte Order、「BOM、」 XML宣言がXML実体の始めに来ると思われます、すぐにBOMに続いて。 他のMIMEヘッダーが出席しているかもしれないことに注意してください。そうすれば、XML実体は注意してもよいです。
Whitehead & Murata Informational [Page 9] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[9ページ]のRFC2376XML Mediaタイプ1998年7月
contain other data in addition to the XML declaration; the examples focus on the Content-type header and the encoding declaration for clarity.
XML宣言に加えた他のデータを含んでください。 例は文書内容ヘッダーと明快のためのコード化宣言に焦点を合わせます。
6.1 text/xml with UTF-8 Charset
6.1 UTF-8 Charsetとテキスト/xml
Content-type: text/xml; charset="utf-8"
文書内容: テキスト/xml。 charset=「utf8インチ」
<?xml version="1.0" encoding="utf-8"?>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ>。
This is the recommended charset value for use with text/xml. Since the charset parameter is provided, MIME and XML processors must treat the enclosed entity as UTF-8 encoded.
これはテキスト/xmlとの使用のためのお勧めのcharset値です。 charsetパラメタを提供するので、MIMEとXMLプロセッサはコード化されたUTF-8として同封の実体を扱わなければなりません。
If sent using a 7-bit transport (e.g. SMTP), the XML entity must use a content-transfer-encoding of either quoted-printable or base64. For an 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), or a binary clean transport (e.g., HTTP) no content-transfer-encoding is necessary.
7ビットの輸送(例えば、SMTP)を使用させて、XML実体がどちらかの引用されて印刷可能な満足している転送コード化を使用しなければならないかどうか、さもなければ、base64。 8ビット、輸送(例えば、ESMTP、8BITMIME、またはNNTP)を掃除してください。さもないと、2進の清潔な輸送内容転送(例えば、HTTP)ノーコード化が必要です。
6.2 text/xml with UTF-16 Charset
6.2 UTF-16 Charsetとテキスト/xml
Content-type: text/xml; charset="utf-16"
文書内容: テキスト/xml。 charset=「utf16インチ」
{BOM}<?xml version='1.0' encoding='utf-16'?>
BOM、<(='utf-16'をコード化する'1.0'というxmlバージョン=)>。
This is possible only when the XML entity is transmitted via HTTP, which uses a MIME-like mechanism and is a binary-clean protocol, hence does not perform CR and LF transformations and allows NUL octets. This differs from typical text MIME type processing (see section 19.4.1 of HTTP 1.1 [RFC-2068] for details).
これは、XML実体がMIMEのようなメカニズムを使用するHTTPで伝えられるときだけ、可能であり、2進に清潔なプロトコルであり、したがって、CRとLF変換を実行しないで、NULに八重奏を許容します。 これは典型的なテキストMIMEの種類処理と異なっています(詳細に関して.1のセクション19.4HTTP1.1[RFC-2068]を見てください)。
Since HTTP is binary clean, no content-transfer-encoding is necessary.
HTTPが清潔な状態で2進であるので、満足している転送コード化は必要ではありません。
6.3 text/xml with ISO-2022-KR Charset
6.3 ISO-2022-KR Charsetとテキスト/xml
Content-type: text/xml; charset="iso-2022-kr"
文書内容: テキスト/xml。 charsetは「iso2022Kr」と等しいです。
<?xml version="1.0" encoding='iso-2022-kr'?>
<?xmlバージョン= 「1インチのコード化='iso2022Kr?'」>。
This example shows text/xml with a Korean charset (e.g., Hangul) encoded following the specification in [RFC-1557]. Since the charset parameter is provided, MIME and XML processors must treat the enclosed entity as encoded per [RFC-1557].
この例は[RFC-1557]の仕様に従って、コード化された韓国のcharset(例えば、ハングル)でテキスト/xmlを示しています。 charsetパラメタを提供するので、MIMEとXMLプロセッサは[RFC-1557]単位でコード化されるように同封の実体を扱わなければなりません。
Since ISO-2022-KR has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport.
ISO-2022-KRが7ビットのデータだけを使用するために定義されたとき、どんな輸送によっても、満足している転送コード化は必要ではありません。
Whitehead & Murata Informational [Page 10] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[10ページ]のRFC2376XML Mediaタイプ1998年7月
6.4 text/xml with Omitted Charset
6.4 Omitted Charsetとテキスト/xml
Content-type: text/xml
文書内容: テキスト/xml
{BOM}<?xml version="1.0" encoding="utf-16"?>
<?がxmlするBOM、バージョン=、「=「utf-16インチ?」をコード化する1インチ>。
This example shows text/xml with the charset parameter omitted. In this case, MIME and XML processors must assume the charset is "us- ascii", the default charset value for text media types specified in [RFC-2046]. The default of "us-ascii" holds even if the text/xml entity is transported using HTTP.
charsetパラメタが省略されている状態で、この例はテキスト/xmlを示しています。 この場合MIMEとXMLプロセッサが、charsetがそうであると仮定しなければならない、「私たち、-、ASCII、」、テキストメディアタイプのためのデフォルトcharset価値は[RFC-2046]で指定しました。 デフォルト、「私たち、-、ASCII、」 テキスト/xml実体がHTTPを使用することで輸送されても、成立します。
Omitting the charset parameter is NOT RECOMMENDED for text/xml. For example, even if the contents of the XML entity are UTF-16 or UTF-8, or the XML entity has an explicit encoding declaration, XML and MIME processors must assume the charset is "us-ascii".
charsetパラメタを省略するのは、テキスト/xmlのためのNOT RECOMMENDEDです。 例えば、XML実体の内容がUTF-16かUTF-8であるかXML実体に明白なコード化宣言があっても、XMLとMIMEプロセッサが、charsetがそうであると仮定しなければならない、「私たち、-、ASCII、」
6.5 application/xml with UTF-16 Charset
6.5 UTF-16 Charsetとアプリケーション/xml
Content-type: application/xml; charset="utf-16"
文書内容: アプリケーション/xml。 charset=「utf16インチ」
{BOM}<?xml version="1.0"?>
BOM、<?xmlバージョン= 「1インチ?」>。
This is a recommended charset value for use with application/xml. Since the charset parameter is provided, MIME and XML processors must treat the enclosed entity as UTF-16 encoded.
これはアプリケーション/xmlとの使用のためのお勧めのcharset値です。 charsetパラメタを提供するので、MIMEとXMLプロセッサはコード化されたUTF-16として同封の実体を扱わなければなりません。
If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), the XML entity must be encoded in quoted-printable or base64. For a binary clean transport (e.g., HTTP), no content-transfer-encoding is necessary.
7ビットの輸送(例えば、SMTP)か8ビットの清潔な輸送(例えば、ESMTP、8BITMIME、またはNNTP)を使用させて、引用されて印刷可能でXML実体をコード化しなければならないかどうか、さもなければ、base64。 2進の清潔な輸送(例えば、HTTP)に、満足している転送コード化は必要ではありません。
6.6 application/xml with ISO-2022-KR Charset
6.6 ISO-2022-KR Charsetとアプリケーション/xml
Content-type: application/xml; charset="iso-2022-kr"
文書内容: アプリケーション/xml。 charsetは「iso2022Kr」と等しいです。
<?xml version="1.0" encoding="iso-2022-kr"?>
<?xmlバージョン= 「1インチのコード化=「iso2022Kr?」」>。
This example shows application/xml with a Korean charset (e.g., Hangul) encoded following the specification in [RFC-1557]. Since the charset parameter is provided, MIME and XML processors must treat the enclosed entity as encoded per [RFC-1557], independent of whether the XML entity has an internal encoding declaration (this example does show such a declaration, which agrees with the charset parameter).
この例は[RFC-1557]の仕様に従って、コード化された韓国のcharset(例えば、ハングル)でアプリケーション/xmlを示しています。 charsetパラメタを提供するので、MIMEとXMLプロセッサは[RFC-1557]単位でコード化されるように同封の実体を扱わなければなりません、XML実体に内部のコード化宣言があるかどうか(この例はcharsetパラメタに同意するそのような宣言を示しています)の如何にかかわらず。
Since ISO-2022-KR has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport.
ISO-2022-KRが7ビットのデータだけを使用するために定義されたとき、どんな輸送によっても、満足している転送コード化は必要ではありません。
Whitehead & Murata Informational [Page 11] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[11ページ]のRFC2376XML Mediaタイプ1998年7月
6.7 application/xml with Omitted Charset and UTF-16 XML Entity
6.7 Omitted CharsetとUTF-16 XML Entityとアプリケーション/xml
Content-type: application/xml
文書内容: アプリケーション/xml
{BOM}<?xml version='1.0'?>
BOM、<('1.0'というxmlバージョン=)>。
For this example, the XML entity begins with a BOM. Since the charset has been omitted, a conforming XML processor follows the requirements of [REC-XML], section 4.3.3. Specifically, the XML processor reads the BOM, and thus knows deterministically that the charset encoding is UTF-16.
この例に関しては、XML実体はBOMと共に始まります。 charsetが省略されたので、従っているXMLプロセッサは[REC-XML]の要件、セクション4.3.3に続きます。 明確に、XMLプロセッサは、BOMを読んで、その結果、charsetコード化がUTF-16であることを決定論的に知っています。
An XML-unaware MIME processor should make no assumptions about the charset of the XML entity.
XML気づかないMIMEプロセッサはXML実体のcharsetに関する仮定を全くするはずがありません。
6.8 application/xml with Omitted Charset and UTF-8 Entity
6.8 Omitted CharsetとUTF-8 Entityとアプリケーション/xml
Content-type: application/xml
文書内容: アプリケーション/xml
<?xml version='1.0'?>
<?xmlバージョン= '1.0'?>。
In this example, the charset parameter has been omitted, and there is no BOM. Since there is no BOM, the XML processor follows the requirements in section 4.3.3, and optionally applies the mechanism described in appendix F (which is non-normative) of [REC-XML] to determine the charset encoding of UTF-8. The XML entity does not contain an encoding declaration, but since the encoding is UTF-8, this is still a conforming XML entity.
この例では、charsetパラメタは省略されました、そして、BOMが全くありません。 BOMが全くないので、XMLプロセッサは、セクション4.3.3における要件に続いて、任意にUTF-8のcharsetコード化を決定するために[REC-XML]の付録F(非規範的です)で説明されたメカニズムを適用します。 XML実体はコード化宣言を含んでいませんが、コード化がUTF-8であるので、それでも、これは従っているXML実体です。
An XML-unaware MIME processor should make no assumptions about the charset of the XML entity.
XML気づかないMIMEプロセッサはXML実体のcharsetに関する仮定を全くするはずがありません。
6.9 application/xml with Omitted Charset and Internal Encoding
Declaration
6.9 Omitted CharsetとInternal Encoding Declarationとアプリケーション/xml
Content-type: application/xml
文書内容: アプリケーション/xml
<?xml version='1.0' encoding="ISO-10646-UCS-4"?>
<?xmlバージョン= '1.0'=をコード化することでの「ISO-10646-UCS-4インチ?」>。
In this example, the charset parameter has been omitted, and there is no BOM. However, the XML entity does have an encoding declaration inside the XML entity which specifies the entity's charset. Following the requirements in section 4.3.3, and optionally applying the mechanism described in appendix F (non-normative) of [REC-XML], the XML processor determines the charset encoding of the XML entity (in this example, UCS-4).
この例では、charsetパラメタは省略されました、そして、BOMが全くありません。 しかしながら、XML実体は実体のcharsetを指定するXML実体でコード化宣言を持っています。 セクション4.3.3における要件に続いて、任意に[REC-XML]の付録F(非標準の)で説明されたメカニズムを適用して、XMLプロセッサはXML実体(この例のUCS-4)のcharsetコード化を決定します。
Whitehead & Murata Informational [Page 12] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[12ページ]のRFC2376XML Mediaタイプ1998年7月
An XML-unaware MIME processor should make no assumptions about the charset of the XML entity.
XML気づかないMIMEプロセッサはXML実体のcharsetに関する仮定を全くするはずがありません。
7 References
7つの参照箇所
[ISO-10646] ISO/IEC, Information Technology - Universal Multiple-
Octet Coded Character Set (UCS) - Part 1: Architecture
and Basic Multilingual Plane, May 1993.
情報技術--普遍的な複数の八重奏コード化文字集合(UCS)--[ISO-10646]ISO/IEC、第1部: アーキテクチャと基本多言語水準、1993年5月。
[ISO-8897] ISO (International Organization for Standardization) ISO
8879:1986(E) Information Processing -- Text and Office
Systems -- Standard Generalized Markup Language (SGML).
First edition -- 1986- 10-15.
[ISO-8897]ISO(国際標準化機構)ISO8879: 1986(E)情報処理--テキストとオフィス・システム--マークアップ言語(SGML)。 初版--1986- 10-15。
[REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible
Markup Language (XML)" World Wide Web Consortium
Recommendation REC- xml-19980210.
http://www.w3.org/TR/1998/REC-xml-19980210.
[REC-XML]T.Bray、J.パオリC.M.Sperberg-マックィーン、「拡張マークアップ言語(XML)」ワールドワイドウェブコンソーシアムRecommendation REC- xml-19980210 http://www.w3.org/TR/1998/REC-xml-19980210 。
[RFC-1557] Choi, U., Chon, K., and H. Park. "Korean Character
Encoding for Internet Messages", RFC 1557. December,
1993.
[RFC-1557] チェ、U.、Chon、K.、およびH.は駐車します。 「インターネットメッセージのための韓国の文字符号化」、RFC1557。 1993年12月。
[RFC-1874] Levinson, E., "SGML Media Types", RFC 1874. December
1995.
[RFC-1874] レヴィンソン、E.、「SGMLメディアタイプ」、RFC1874。 1995年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[RFC-2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC-2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
解放された[RFC-2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[RFC-2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997.
[RFC-2068] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月。」
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC-2279]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[UNICODE] The Unicode Consortium, "The Unicode Standard -- Version
2.0", Addison-Wesley, 1996.
[ユニコード] ユニコード共同体、「バージョン2インチ、アディソン・ウエスリー、ユニコード規格--1996。」
Whitehead & Murata Informational [Page 13] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[13ページ]のRFC2376XML Mediaタイプ1998年7月
8 Acknowledgements
8つの承認
Chris Newman and Yaron Y. Goland both contributed content to the security considerations section of this document. In particular, some text in the security considerations section is copied verbatim from work in progress, draft-newman-mime-textpara-00, by permission of the author. Chris Newman additionally contributed content to the encoding considerations sections. Dan Connolly contributed content discussing when to use text/xml. Discussions with Ned Freed and Dan Connolly helped refine the author's understanding of the text media type; feedback from Larry Masinter was also very helpful in understanding media type registration issues.
クリス・ニューマンとヤロンY.Golandはともにこのドキュメントのセキュリティ問題部に内容を寄付しました。 特に、セキュリティ問題部の何らかのテキストが処理中の作業から逐語的にコピーされます、草稿newmanパントマイムtextpara-00、作者の許可で。 クリス・ニューマンはさらに、コード化している問題部に内容を寄付しました。 いつテキスト/xmlを使用するかを議論しながら、ダン・コノリーは内容を寄付しました。 ネッド・フリードとダン・コノリーとの議論は、作者のテキストメディアタイプの理解を洗練するのを助けました。 また、メディアが登録問題をタイプするのを理解する際にラリーMasinterからのフィードバックも非常に役立っていました。
Members of the W3C XML Working Group and XML Special Interest group have made significant contributions to this document, and the authors would like to specially recognize James Clark, Martin Duerst, Rick Jelliffe, Gavin Nicol for their many thoughtful comments.
W3C XML作業部会とXML特別利益団体グループのメンバーはこのドキュメントへの重要な貢献をしました、そして、特に、作者はジェームス・クラークを見分けたがっています、マーチンDuerst、リックJelliffe、彼らの多くの考え深いコメントのためのギャヴィン・ニコル。
9 Addresses of Authors
作者の9つのアドレス
E. James Whitehead, Jr. Dept. of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425
E.ジェームス・ホワイトヘッドと情報のJr.部とカリフォルニア大学アーバイン校アーバイン、コンピュータサイエンスカリフォルニア92697-3425
EMail: ejw@ics.uci.edu
メール: ejw@ics.uci.edu
Murata Makoto (Family Given) Fuji Xerox Information Systems, KSP 9A7, 2-1, Sakado 3-chome, Takatsu-ku, Kawasaki-shi, Kanagawa-ken, 213 Japan
誠ムラタ(与えられているファミリー)富士ゼロックス情報システム、KSP 9A7、2-1、3丁目の坂戸高津区、川崎市、神奈川県、213日本
EMail: murata@fxis.fujixerox.co.jp
メール: murata@fxis.fujixerox.co.jp
Whitehead & Murata Informational [Page 14] RFC 2376 XML Media Types July 1998
ホワイトヘッドとムラタ情報[14ページ]のRFC2376XML Mediaタイプ1998年7月
10 Full Copyright Statement
10 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Whitehead & Murata Informational [Page 15]
ホワイトヘッドとムラタInformationalです。[15ページ]
一覧
スポンサーリンク
