[要約] RFC 2231は、MIMEパラメータ値とエンコードされたワードの拡張に関する規格であり、文字セット、言語、継続性について定義しています。このRFCの目的は、MIMEメッセージのパラメータ値を効果的に表現するための方法を提供することです。
Network Working Group N. Freed
Request for Comments: 2231 Innosoft
Updates: 2045, 2047, 2183 K. Moore
Obsoletes: 2184 University of Tennessee
Category: Standards Track November 1997
MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
MIMEパラメータ値とエンコードされたWordの拡張機能：文字セット、言語、継続
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms to provide
このメモは、RFC 2045メディアタイプとRFC 2183処理パラメータ値メカニズムの拡張を定義して、
(1) a means to specify parameter values in character sets other than US-ASCII,
（1）パラメータ値をUS-ASCII以外の文字セットで指定する手段、
(2) to specify the language to be used should the value be displayed, and
（2）値を表示する場合に使用する言語を指定する。
(3) a continuation mechanism for long parameter values to avoid problems with header line wrapping.
（3）ヘッダー行の折り返しの問題を回避するための長いパラメーター値の継続メカニズム。
This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set.
このメモは、RFC 2047で定義されているエンコードされた単語への拡張も定義しており、文字セットだけでなく表示にも言語の仕様を使用できます。
The Multipurpose Internet Mail Extensions, or MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049], define a message format that allows for:
多目的インターネットメール拡張機能、またはMIME [RFC-2045、RFC-2046、RFC-2047、RFC-2048、RFC-2049]は、以下を可能にするメッセージ形式を定義します。
(1) textual message bodies in character sets other than US-ASCII,
（1）US-ASCII以外の文字セットのテキストメッセージ本文
(2) non-textual message bodies,
（2）非テキストのメッセージ本文、
(3) multi-part message bodies, and
（3）マルチパートメッセージ本文、および
(4) textual header information in character sets other than US-ASCII.
（4）US-ASCII以外の文字セットのテキストヘッダー情報。
MIME is now widely deployed and is used by a variety of Internet protocols, including, of course, Internet email. However, MIME's success has resulted in the need for additional mechanisms that were not provided in the original protocol specification.
現在、MIMEは広く展開されており、インターネットメールなどのさまざまなインターネットプロトコルで使用されています。ただし、MIMEの成功により、元のプロトコル仕様では提供されなかった追加のメカニズムが必要になりました。
In particular, existing MIME mechanisms provide for named media type (content-type field) parameters as well as named disposition (content-disposition field). A MIME media type may specify any number of parameters associated with all of its subtypes, and any specific subtype may specify additional parameters for its own use. A MIME disposition value may specify any number of associated parameters, the most important of which is probably the attachment disposition's filename parameter.
特に、既存のMIMEメカニズムは、名前付きメディアタイプ（コンテンツタイプフィールド）パラメータと名前付きディスポジション（コンテンツディスポジションフィールド）を提供します。 MIMEメディアタイプは、そのすべてのサブタイプに関連付けられた任意の数のパラメーターを指定でき、特定のサブタイプは、それ自体が使用する追加のパラメーターを指定できます。 MIMEディスポジション値は、関連するパラメータをいくつでも指定できますが、最も重要なのは、おそらく添付ファイルディスポジションのファイル名パラメータです。
These parameter names and values end up appearing in the content-type and content-disposition header fields in Internet email. This inherently imposes three crucial limitations:
これらのパラメーターの名前と値は、インターネット電子メールのcontent-typeおよびcontent-dispositionヘッダーフィールドに表示されます。これには、本質的に3つの重要な制限があります。
(1) Lines in Internet email header fields are folded according to RFC 822 folding rules. This makes long parameter values problematic.
（1）インターネット電子メールヘッダーフィールドの行は、RFC 822折りたたみ規則に従って折りたたまれます。これにより、長いパラメーター値が問題になります。
(2) MIME headers, like the RFC 822 headers they often appear in, are limited to 7bit US-ASCII, and the encoded-word mechanisms of RFC 2047 are not available to parameter values. This makes it impossible to have parameter values in character sets other than US-ASCII without specifying some sort of private per-parameter encoding.
（2）MIMEヘッダーは、RFC 822ヘッダーと同様に、7ビットUS-ASCIIに制限されており、パラメーター値ではRFC 2047のエンコードされた語のメカニズムを使用できません。これにより、ある種のプライベートパラメータごとのエンコーディングを指定せずに、US-ASCII以外の文字セットにパラメータ値を含めることができなくなります。
(3) It has recently become clear that character set information is not sufficient to properly display some sorts of information -- language information is also needed [RFC-2130]. For example, support for handicapped users may require reading text string aloud. The language the text is written in is needed for this to be done correctly. Some parameter values may need to be displayed, hence there is a need to allow for the inclusion of language information.
（3）ある種の情報を適切に表示するには文字セット情報では不十分であることが最近明らかになりました。言語情報も必要です[RFC-2130]。たとえば、障害を持つユーザーのサポートでは、テキスト文字列を読み上げる必要がある場合があります。これが正しく行われるためには、テキストが書かれている言語が必要です。一部のパラメータ値は表示する必要がある場合があるため、言語情報を含めることができるようにする必要があります。
The last problem on this list is also an issue for the encoded words defined by RFC 2047, as encoded words are intended primarily for display purposes.
このリストの最後の問題は、RFC 2047で定義されているエンコードされた単語の問題でもあります。エンコードされた単語は、主に表示を目的としているためです。
This document defines extensions that address all of these limitations. All of these extensions are implemented in a fashion that is completely compatible at a syntactic level with existing MIME implementations. In addition, the extensions are designed to have as little impact as possible on existing uses of MIME.
このドキュメントでは、これらすべての制限に対処する拡張機能を定義しています。これらの拡張機能はすべて、既存のMIME実装と構文レベルで完全に互換性のある方法で実装されます。さらに、拡張機能は、MIMEの既存の使用にできるだけ影響を与えないように設計されています。
IMPORTANT NOTE: These mechanisms end up being somewhat gibbous when they actually are used. As such, these mechanisms should not be used lightly; they should be reserved for situations where a real need for them exists.
重要な注意：これらのメカニズムは、実際に使用された場合、やや厄介なものになります。そのため、これらのメカニズムは軽く使用しないでください。それらは、それらに対する真の必要性が存在する状況のために予約されるべきです。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC- 2119].
このドキュメントでは、大文字で表示される用語を使用することがあります。 「MUST」、「SHOULD」、「MUST NOT」、「SHOULD NOT」、および「MAY」という用語は、大文字で表記されている場合、この仕様の特定の要件を示すために使用されています。これらの用語の意味の議論は[RFC-2119]に現れます。
Long MIME media type or disposition parameter values do not interact well with header line wrapping conventions. In particular, proper header line wrapping depends on there being places where linear whitespace (LWSP) is allowed, which may or may not be present in a parameter value, and even if present may not be recognizable as such since specific knowledge of parameter value syntax may not be available to the agent doing the line wrapping. The result is that long parameter values may end up getting truncated or otherwise damaged by incorrect line wrapping implementations.
長いMIMEメディアタイプまたはディスポジションパラメータの値は、ヘッダー行の折り返し規則とうまく相互作用しません。特に、適切なヘッダー行の折り返しは、線形空白（LWSP）が許可されている場所に依存します。これはパラメーター値に存在する場合と存在しない場合があり、存在する場合でもパラメーター値の構文に関する特定の知識があるため認識できない場合があります。行の折り返しを行うエージェントが利用できない場合があります。その結果、長いパラメーター値は、誤った行折り返しの実装によって切り捨てられたり、損傷したりする可能性があります。
A mechanism is therefore needed to break up parameter values into smaller units that are amenable to line wrapping. Any such mechanism MUST be compatible with existing MIME processors. This means that
したがって、パラメータ値を行の折り返しが可能な小さな単位に分割するメカニズムが必要です。このようなメカニズムは、既存のMIMEプロセッサと互換性がある必要があります。この意味は
(1) the mechanism MUST NOT change the syntax of MIME media type and disposition lines, and
（1）メカニズムはMIMEメディアタイプとディスポジション行の構文を変更してはならない（MUST NOT）、および
(2) the mechanism MUST NOT depend on parameter ordering since MIME states that parameters are not order sensitive. Note that while MIME does prohibit modification of MIME headers during transport, it is still possible that parameters will be reordered when user agent level processing is done.
（2）MIMEはパラメータは順序に依存しないと述べているため、メカニズムはパラメータの順序に依存してはならない（MUST NOT）。 MIMEはトランスポート中のMIMEヘッダーの変更を禁止していますが、ユーザーエージェントレベルの処理が完了したときにパラメーターが並べ替えられる可能性があることに注意してください。
The obvious solution, then, is to use multiple parameters to contain a single parameter value and to use some kind of distinguished name to indicate when this is being done. And this obvious solution is exactly what is specified here: The asterisk character ("*") followed by a decimal count is employed to indicate that multiple parameters are being used to encapsulate a single parameter value. The count starts at 0 and increments by 1 for each subsequent section of the parameter value. Decimal values are used and neither leading zeroes nor gaps in the sequence are allowed.
したがって、明白な解決策は、複数のパラメーターを使用して単一のパラメーター値を格納し、ある種の識別名を使用して、これがいつ行われるかを示すことです。そして、この明らかな解決策は、ここで指定されているものとまったく同じです。アスタリスク文字（ "*"）の後に小数が続き、単一のパラメーター値をカプセル化するために複数のパラメーターが使用されていることを示します。カウントは0から始まり、パラメーター値の後続のセクションごとに1ずつ増加します。 10進値が使用され、シーケンスの先行ゼロもギャップも許可されません。
The original parameter value is recovered by concatenating the various sections of the parameter, in order. For example, the content-type field
元のパラメータ値は、パラメータのさまざまなセクションを順番に連結することによって復元されます。たとえば、content-typeフィールド
Content-Type: message/external-body; access-type=URL;
URL*0="ftp://";
URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
is semantically identical to
意味的に同一
Content-Type: message/external-body; access-type=URL;
URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
Note that quotes around parameter values are part of the value syntax; they are NOT part of the value itself. Furthermore, it is explicitly permitted to have a mixture of quoted and unquoted continuation fields.
パラメータ値を囲む引用符は値の構文の一部であることに注意してください。それらは値自体の一部ではありません。さらに、引用符付きと引用符なしの継続フィールドを混在させることも明示的に許可されています。
Some parameter values may need to be qualified with character set or language information. It is clear that a distinguished parameter name is needed to identify when this information is present along with a specific syntax for the information in the value itself. In addition, a lightweight encoding mechanism is needed to accommodate 8 bit information in parameter values.
一部のパラメーター値は、文字セットまたは言語情報で修飾する必要がある場合があります。この情報が値自体の情報の特定の構文とともに存在する場合を識別するために、識別されたパラメーター名が必要であることは明らかです。さらに、パラメータ値の8ビット情報に対応するには、軽量のエンコードメカニズムが必要です。
Asterisks ("*") are reused to provide the indicator that language and character set information is present and encoding is being used. A single quote ("'") is used to delimit the character set and language information at the beginning of the parameter value. Percent signs ("%") are used as the encoding flag, which agrees with RFC 2047.
アスタリスク（ "*"）は、言語と文字セットの情報が存在し、エンコーディングが使用されていることを示すために再利用されます。単一引用符（ "'"）は、パラメーター値の先頭で文字セットと言語情報を区切るために使用されます。パーセント記号（ "％"）はエンコーディングフラグとして使用され、RFC 2047に準拠しています。
Specifically, an asterisk at the end of a parameter name acts as an indicator that character set and language information may appear at the beginning of the parameter value. A single quote is used to separate the character set, language, and actual value information in the parameter value string, and an percent sign is used to flag octets encoded in hexadecimal. For example:
具体的には、パラメーター名の末尾のアスタリスクは、文字セットと言語情報がパラメーター値の先頭に表示されることを示すインジケーターとして機能します。パラメータ値文字列の文字セット、言語、および実際の値情報を区切るために一重引用符が使用され、16進数でエンコードされたオクテットにフラグを付けるためにパーセント記号が使用されます。例えば：
Content-Type: application/x-stuff;
title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
Note that it is perfectly permissible to leave either the character set or language field blank. Note also that the single quote delimiters MUST be present even when one of the field values is omitted. This is done when either character set, language, or both are not relevant to the parameter value at hand. This MUST NOT be done in order to indicate a default character set or language -- parameter field definitions MUST NOT assign a default character set or language.
文字セットまたは言語フィールドを空白のままにすることは完全に許容されることに注意してください。また、フィールド値の1つが省略されている場合でも、単一引用符の区切り文字が存在する必要があることにも注意してください。これは、文字セット、言語、またはその両方が、手元のパラメーター値に関連していない場合に行われます。これは、デフォルトの文字セットまたは言語を示すために行ってはなりません-パラメータフィールド定義は、デフォルトの文字セットまたは言語を割り当ててはなりません。
Character set and language information may be combined with the parameter continuation mechanism. For example:
文字セットおよび言語情報は、パラメーター継続メカニズムと組み合わせることができます。例えば：
Content-Type: application/x-stuff
title*0*=us-ascii'en'This%20is%20even%20more%20
title*1*=%2A%2A%2Afun%2A%2A%2A%20
title*2="isn't it!"
Note that:
ご了承ください：
(1) Language and character set information only appear at the beginning of a given parameter value.
（1）言語と文字セットの情報は、特定のパラメーター値の先頭にのみ表示されます。
(2) Continuations do not provide a facility for using more than one character set or language in the same parameter value.
（2）継続は、同じパラメーター値で複数の文字セットまたは言語を使用する機能を提供しません。
(3) A value presented using multiple continuations may contain a mixture of encoded and unencoded segments.
（3）複数の継続を使用して表示される値には、エンコードされたセグメントとエンコードされていないセグメントが混在している場合があります。
(4) The first segment of a continuation MUST be encoded if language and character set information are given.
（4）継続の最初のセグメントは、言語と文字セットの情報が提供されている場合はエンコードする必要があります。
(5) If the first segment of a continued parameter value is encoded the language and character set field delimiters MUST be present even when the fields are left blank.
（5）継続パラメーター値の最初のセグメントがエンコードされている場合、フィールドが空白のままであっても、言語と文字セットのフィールド区切り文字が存在している必要があります。
RFC 2047 provides support for non-US-ASCII character sets in RFC 822 message header comments, phrases, and any unstructured text field. This is done by defining an encoded word construct which can appear in any of these places. Given that these are fields intended for display, it is sometimes necessary to associate language information with encoded words as well as just the character set. This specification extends the definition of an encoded word to allow the inclusion of such information. This is simply done by suffixing the character set specification with an asterisk followed by the language tag. For example:
RFC 2047は、RFC 822メッセージヘッダーのコメント、フレーズ、およびすべての非構造化テキストフィールドで、非US-ASCII文字セットをサポートします。これは、これらの場所のいずれかに出現する可能性があるエンコードされた単語構成を定義することによって行われます。これらは表示を目的としたフィールドであるため、言語情報を文字セットだけでなくエンコードされた単語にも関連付ける必要がある場合があります。この仕様は、そのような情報を含めることができるように、エンコードされた単語の定義を拡張します。これは、文字セット仕様の後にアスタリスクとその後に続く言語タグを付加することによって簡単に行われます。例えば：
From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>
IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations when generating the BODY and BODYSTRUCTURE fetch attributes.
IMAP4 [RFC-2060]サーバーは、BODYおよびBODYSTRUCTUREフェッチ属性の生成時にパラメーター値の継続をデコードする必要があります（SHOULD）。
The ABNF for MIME parameter values given in RFC 2045 is:
RFC 2045で指定されているMIMEパラメータ値のABNFは次のとおりです。
parameter := attribute "=" value
attribute := token ; Matching of attributes ; is ALWAYS case-insensitive.
属性：=トークン;属性のマッチング。常に大文字と小文字を区別しません。
This specification changes this ABNF to:
この仕様は、このABNFを次のように変更します。
parameter := regular-parameter / extended-parameter
regular-parameter := regular-parameter-name "=" value
regular-parameter-name := attribute [section]
regular-parameter-name：=属性[セクション]
attribute := 1*attribute-char
attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
"*", "'", "%", or tspecials>
section := initial-section / other-sections
initial-section := "*0"
other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
"6" / "7" / "8" / "9") *DIGIT)
extended-parameter := (extended-initial-name "="
extended-value) /
(extended-other-names "="
extended-other-values)
extended-initial-name := attribute [initial-section] "*"
extended-other-names := attribute other-sections "*"
extended-initial-value := [charset] "'" [language] "'"
extended-other-values
extended-other-values := *(ext-octet / attribute-char)
ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
charset := <registered character set name>
language := <registered language tag [RFC-1766]>
The ABNF given in RFC 2047 for encoded-words is:
エンコードされた単語についてRFC 2047で指定されているABNFは次のとおりです。
encoded-word := "=?" charset "?" encoding "?" encoded-text "?="
This specification changes this ABNF to:
この仕様は、このABNFを次のように変更します。
encoded-word := "=?" charset ["*" language] "?" encoded-text "?="
In the future it is likely that some character sets will provide facilities for inline language labeling. Such facilities are inherently more flexible than those defined here as they allow for language switching in the middle of a string.
将来的には、一部の文字セットがインライン言語のラベル付け機能を提供する可能性があります。このような機能は、文字列の途中で言語を切り替えることができるため、ここで定義する機能よりも本質的に柔軟性があります。
If and when such facilities are developed they SHOULD be used in preference to the language labeling facilities specified here. Note that all the mechanisms defined here allow for the omission of language labels so as to be able to accommodate this possible future usage.
そのような機能が開発される場合、それらはここで指定された言語ラベル付け機能よりも優先して使用されるべきです（SHOULD）。ここで定義されているすべてのメカニズムでは、言語ラベルを省略できるため、この将来の使用に対応できることに注意してください。
This RFC does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of MIME.
このRFCではセキュリティの問題については説明されておらず、電子メールにまだ固有のものではなく、MIMEの完全に準拠した実装に存在するセキュリティの問題を提起するとは考えられていません。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822 August 1982.
[RFC-822] Crocker、D。、「Standard for the Format for ARPA Internet Text Messages」、STD 11、RFC 822 August 1982。
[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC-1766] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[RFC-2045] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年12月。
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[RFC-2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年12月。
[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC 2047, December 1996.
[RFC-2047]ムーア、K。、「多目的インターネットメール拡張（MIME）パート3：インターネットメッセージヘッダー内の非ASCIIテキストの表現」、RFC 2047、1996年12月。
[RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC 2048, December 1996.
[RFC-2048] Freed、N.、Klensin、J。、およびJ. Postel、「Multipurpose Internet Mail Extensions（MIME）Part Four：MIME Registration Procedures」、RFC 2048、1996年12月。
[RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996.
[RFC-2049] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part 5：Conformance Criteria and Examples」、RFC 2049、1996年12月。
[RFC-2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC-2060] Crispin、M.、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 2060、1996年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
[RFC-2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M., and P. Svanberg, "Report from the IAB Character Set Workshop", RFC 2130, April 1997.
[RFC-2130]ウィダー、C。、プレストン、C。、サイモンセン、K。、アルベストランド、H。、アトキンソン、R。、クリスピン、M。、およびP.スヴァンバーグ、「IAB Character Set Workshopからのレポート」、 RFC 2130、1997年4月。
[RFC-2183] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997.
[RFC-2183] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージでのプレゼンテーション情報の伝達：Content-Dispositionヘッダー」、RFC 2183、1997年8月。
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Ned Freed Innosoft International、Inc. 1050 Lakes Drive West Covina、CA 91790 USA
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Keith Moore Computer Science Dept. University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA
キースムーアコンピューターサイエンス学部テネシー大学107エアーズホールノックスビル、テネシー37996-1301アメリカ
EMail: moore@cs.utk.edu
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。