[要約] RFC 6068は、メールアドレスを含むURIスキームである'mailto'の仕様を定義しています。このRFCの目的は、メールクライアントとウェブブラウザ間でのメール送信を容易にするための標準化です。
Internet Engineering Task Force (IETF) M. Duerst
Request for Comments: 6068 Aoyama Gakuin University
Obsoletes: 2368 L. Masinter
Category: Standards Track Adobe Systems Incorporated
ISSN: 2070-1721 J. Zawinski
DNA Lounge
October 2010
The 'mailto' URI Scheme
「Mailto」URIスキーム
Abstract
概要
This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368).
このドキュメントでは、インターネットメールを使用して到達したリソースを識別するために、均一なリソース識別子（URI）の形式を定義します。これは、国際化されたリソース識別子（IRIS; RFC 3987）とのより良い国際化と互換性を、「Mailto」URIS（RFC 2368）の以前の構文に追加します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc6068.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6068で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Syntax of a 'mailto' URI . . . . . . . . . . . . . . . . . . . 3
3. Semantics and Operations . . . . . . . . . . . . . . . . . . . 7
4. Unsafe Header Fields . . . . . . . . . . . . . . . . . . . . . 7
5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Examples of Complicated Email Addresses . . . . . . . . . 10
6.3. Examples Using UTF-8-Based Percent-Encoding . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Update of the Registration of the 'mailto' URI Scheme . . 14
8.2. Registration of the Body Header Field . . . . . . . . . . 15
9. Main Changes from RFC 2368 . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
The 'mailto' URI scheme is used to identify resources that are reached using Internet mail. In its simplest form, a 'mailto' URI contains an Internet mail address. For interactions that require message headers or message bodies to be specified, the 'mailto' URI scheme also allows providing mail header fields and the message body.
「Mailto」URIスキームは、インターネットメールを使用して到達するリソースを識別するために使用されます。最も単純な形式では、「Mailto」URIにはインターネットメールアドレスが含まれています。メッセージヘッダーまたはメッセージ本文を指定する必要があるインタラクションの場合、「Mailto」URIスキームでは、メールヘッダーフィールドとメッセージ本文を提供することもできます。
This specification extends the previous scheme definition to also allow character data to be percent-encoded based on UTF-8 [STD63], which offers a better and more consistent way of dealing with non-ASCII characters for internationalization.
この仕様は、以前のスキーム定義を拡張して、UTF-8 [STD63]に基づいてキャラクターデータをパーセントエンコードすることもできます。
This specification does not address the needs of the ongoing Email Address Internationalization effort (see [RFC4952]). In particular, this specification does not include syntax for fallback addresses.
この仕様は、進行中のメールアドレス国際化の取り組みのニーズに対応していません（[RFC4952]を参照）。特に、この仕様には、フォールバックアドレスの構文は含まれていません。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In this document, URIs are enclosed in '<' and '>' as described in Appendix C of [STD66]. Extra whitespace and line breaks are added to present long URIs -- they are not part of the actual URI.
このドキュメントでは、urisは[std66]の付録Cに記載されているように、「<」と '>'に囲まれています。余分な空白とラインブレークが追加され、長いURIが提示されます - それらは実際のURIの一部ではありません。
The syntax of a 'mailto' URI is described using the ABNF of [STD68], non-terminal definitions from [RFC5322] (dot-atom-text, quoted-string), and non-terminal definitions from [STD66] (unreserved, pct-encoded):
'mailto' uriの構文は、[std68]のabnf、[rfc5322]（dot-atom-text、quoted-string）の非末端定義、および[std66]の非末端定義を使用して記述されています。PCTエンコード）：
mailtoURI = "mailto:" [ to ] [ hfields ]
to = addr-spec *("," addr-spec )
hfields = "?" hfield *( "&" hfield )
hfield = hfname "=" hfvalue
hfname = *qchar
hfvalue = *qchar
addr-spec = local-part "@" domain
local-part = dot-atom-text / quoted-string
domain = dot-atom-text / "[" *dtext-no-obs "]"
dtext-no-obs = %d33-90 / ; Printable US-ASCII
%d94-126 ; characters not including
; "[", "]", or "\"
qchar = unreserved / pct-encoded / some-delims
some-delims = "!" / "$" / "'" / "(" / ")" / "*"
/ "+" / "," / ";" / ":" / "@"
<addr-spec> is a mail address as specified in [RFC5322], but excluding <comment> from [RFC5322]. However, the following changes apply:
<addr-spec>は、[RFC5322]で指定されているメールアドレスですが、[RFC5322]から<コメント>を除外します。ただし、次の変更が適用されます。
1. A number of characters that can appear in <addr-spec> MUST be percent-encoded. These are the characters that cannot appear in a URI according to [STD66] as well as "%" (because it is used for percent-encoding) and all the characters in gen-delims except "@" and ":" (i.e., "/", "?", "#", "[", and "]"). Of the characters in sub-delims, at least the following also have to be percent-encoded: "&", ";", and "=". Care has to be taken both when encoding as well as when decoding to make sure these operations are applied only once.
1. <AddR-Spec>に表示できる多くの文字は、パーセントエンコードされている必要があります。これらは、[std66]と「％」（パーセントエンコードに使用されるため）に従ってURIに表示できないキャラクターであり、「@」と「：」（つまり、」を除くGen-delimsのすべてのキャラクターが"/"、 "？"、 "＃"、 "["、 と "]"）。サブデリムの文字のうち、少なくとも次のキャラクターは、 "＆"、 ";"、および "="というパーセントをエンコードする必要があります。エンコードの場合とデコード時には、これらの操作が一度だけ適用されるように注意する必要があります。
2. <obs-local-part> and <NO-WS-CTL> as defined in [RFC5322] MUST NOT be used.
2. [RFC5322]で定義されている<Obs-Local-Part>および<No-WS-CTL>は使用してはなりません。
3. Whitespace and comments within <local-part> and <domain> MUST NOT be used. They would not have any operational semantics.
3. <Local-Part>および<domain>内のWhitespaceとコメントは使用してはなりません。彼らは運用上のセマンティクスを持っていません。
4. Percent-encoding can be used in the <domain> part of an <addr-spec> in order to denote an internationalized domain name. The considerations for <reg-name> in [STD66] apply. In particular, non-ASCII characters MUST first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence MUST be percent-encoded to be represented as URI characters. URI-producing applications MUST NOT use percent-encoding in domain names unless it is used to represent a UTF-8 character sequence. When the internationalized domain name is used to compose a message, the name MUST be transformed to the Internationalizing Domain Names in Applications (IDNA) encoding [RFC5891] where appropriate. URI producers SHOULD provide these domain names in the IDNA encoding, rather than percent-encoded, if they wish to maximize interoperability with legacy 'mailto' URI interpreters.
4. パーセントエンコードは、国際化されたドメイン名を示すために、<domain> <addr-spec>の部分で使用できます。[std66]の<reg-name>の考慮事項が適用されます。特に、非ASCII文字は最初にUTF-8 [STD63]に従ってエンコードする必要があり、次に、対応するUTF-8シーケンスの各オクテットは、URI文字として表されるようにパーセントエンコードする必要があります。URI生産アプリケーションは、UTF-8文字シーケンスを表すために使用されない限り、ドメイン名でパーセントエンコードを使用しないでください。国際化されたドメイン名を使用してメッセージを作成する場合、名前は必要に応じて[RFC5891]をエンコードするアプリケーション（IDNA）の国際化ドメイン名に変換する必要があります。URIプロデューサーは、レガシー「Mailto」URI通訳者との相互運用性を最大化したい場合、エンコードではなく、IDNAエンコードでこれらのドメイン名を提供する必要があります。
5. Percent-encoding of non-ASCII octets in the <local-part> of an <addr-spec> is reserved for the internationalization of the <local-part>. Non-ASCII characters MUST first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence MUST be percent-encoded to be represented as URI characters. Any other percent-encoding of non-ASCII characters is prohibited. When a <local-part> containing non-ASCII characters will be used to compose a message, the <local-part> MUST be transformed to conform to whatever encoding may be defined in a future specification for the internationalization of email addresses.
5. <addr-spec>の<ローカルパート>の非ASCIIオクテットのパーセントエンコードは、<ローカルパート>の国際化のために予約されています。非ASCII文字は、最初にUTF-8 [STD63]に従ってエンコードする必要があり、次に、対応するUTF-8シーケンスの各オクテットは、URI文字として表されるようにパーセントエンコードする必要があります。ASCII以外のキャラクターの他のパーセントエンコードは禁止されています。非ASCII文字を含む<ローカルパート>を使用してメッセージを作成する場合、<ローカルパート>は、電子メールアドレスの国際化のための将来の仕様で定義される可能性のあるエンコードに準拠するために変換する必要があります。
<hfname> and <hfvalue> are encodings of an [RFC5322] header field name and value, respectively. Percent-encoding is needed for the same characters as listed above for <addr-spec>. <hfname> is case-insensitive, but <hfvalue> in general is case-sensitive. Note that [RFC5322] allows all US-ASCII printable characters except ":" in optional header field names (Section 3.6.8), which is the reason why <pct-encoded> is part of the header field name production.
<hfname>および<hfvalue>は、それぞれ[RFC5322]ヘッダーのフィールド名と値のエンコーディングです。<AddR-Spec>の上記と同じ文字には、パーセントエンコードが必要です。<hfname>は症例に敏感ですが、一般的には<hfvalue>は症例に敏感です。[RFC5322]は、オプションのヘッダーフィールド名（セクション3.6.8）で「：」を除くすべてのUS-ASCIIの印刷可能な文字を許可することに注意してください。
The special <hfname> "body" indicates that the associated <hfvalue> is the body of the message. The "body" field value is intended to contain the content for the first text/plain body part of the message. The "body" pseudo header field is primarily intended for the generation of short text messages for automatic processing (such as "subscribe" messages for mailing lists), not for general MIME bodies. Except for the encoding of characters based on UTF-8 and percent-encoding, no additional encoding (such as e.g., base64 or quoted-printable; see [RFC2045]) is used for the "body" field value. As a consequence, header fields related to message encoding (e.g., Content-Transfer-Encoding) in a 'mailto' URI are irrelevant and MUST be ignored. The "body" pseudo header field name has been registered with IANA for this special purpose (see Section 8.2).
特別な<hfname>「ボディ」は、関連する<hfvalue>がメッセージの本文であることを示します。「ボディ」フィールド値は、メッセージの最初のテキスト/プレーンボディ部分のコンテンツを含めることを目的としています。「ボディ」擬似ヘッダーフィールドは、主に、一般的なMIME体ではなく、自動処理（メーリングリストの「購読」メッセージなど）の短いテキストメッセージの生成を目的としています。UTF-8およびパーセントエンコードに基づく文字のエンコードを除き、追加のエンコード（例えば、base64や引用プリント可能、[RFC2045]を参照）は「ボディ」フィールド値に使用されません。結果として、「Mailto」URIのメッセージエンコード（たとえば、コンテンツトランスファーエンコード）に関連するヘッダーフィールドは無関係であり、無視する必要があります。「ボディ」疑似ヘッダーフィールド名は、この特別な目的のためにIANAに登録されています（セクション8.2を参照）。
Within 'mailto' URIs, the characters "?", "=", and "&" are reserved, serving as delimiters. They have to be escaped (as "%3F", "%3D", and "%26", respectively) when not serving as delimiters.
「mailto」ウリ内で、キャラクター "？"？ "、" = "、"＆ "は予約されており、区切り文字として機能します。デリミターとして機能しない場合、それらは（それぞれ「％3F」、「％3D」、および「％26」として逃げる必要があります。
Additional restrictions on what characters are allowed might apply depending on the context where the URI is used. Such restrictions can be addressed by context-specific escaping mechanisms. For example, because the "&" (ampersand) character is reserved in HTML and XML, any 'mailto' URI that contains an ampersand has to be written with an HTML/XML entity ("&") or numeric character reference ("&" or "&").
URIが使用されるコンテキストに応じて、許可されているキャラクターに対する追加の制限が適用される場合があります。このような制限は、コンテキスト固有の脱出メカニズムによって対処できます。たとえば、「＆」（ampersand）文字はHTMLとXMLに予約されているため、アンパサンドを含む「Mailto」URIは、HTML/XMLエンティティ（ "＆amp;"）または数値文字参照（ "＆＃x26; "または"＆＃38; "）。
Non-ASCII characters can be encoded in <hfvalue> as follows:
非ASCII文字は、次のように<hfvalue>でエンコードできます。
1. MIME encoded words (as defined in [RFC2047]) are permitted in header field values, but not in an <hfvalue> of a "body" <hfname>. Sequences of characters that look like MIME encoded words can appear in an <hfvalue> of a "body" <hfname>, but in that case have no special meaning. Please note that the '=' and '?' characters used as delimiters in MIME encoded words have to be percent-encoded. Also note that the use of MIME encoded words differs slightly for so-called structured and unstructured header fields.
1. mimeエンコードされた単語（[rfc2047]で定義されている）は、ヘッダーフィールド値で許可されていますが、「body」<hfname>の<hfvalue>では許可されていません。mimeエンコードされた単語のように見える文字のシーケンスは、「body」<hfname>の<hfvalue>に表示されますが、その場合は特別な意味がありません。「=」と「？」に注意してくださいMIMEエンコードされた単語の区切り文字として使用される文字は、パーセントエンコードされている必要があります。また、MIMEエンコードされた単語の使用は、いわゆる構造化された構造的および非構造化ヘッダーフィールドでわずかに異なることに注意してください。
2. Non-ASCII characters can be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence is percent-encoded to be represented as URI characters. When header field values encoded in this way are used to compose a message, the <hfvalue> has to be suitably encoded (transformed into MIME encoded words [RFC2047]), except for an <hfvalue> of a "body" <hfname>, which has to be encoded according to [RFC2045]. Please note that for MIME encoded words and for bodies in composed email messages, encodings other than UTF-8 MAY be used as long as the characters are properly transcoded.
2. 非ASCII文字は、UTF-8 [STD63]に従ってエンコードでき、次に、対応するUTF-8シーケンスの各オクテットは、URI文字として表されるようにパーセントエンコードされます。この方法でエンコードされたヘッダーフィールド値がメッセージを構成するために使用される場合、<hfvalue>は適切にエンコードする必要があります（mimeエンコードされた単語[rfc2047]に変換されます[rfc2047]）。[RFC2045]に従ってエンコードする必要があります。MIMEエンコードされた単語および構成された電子メールメッセージのボディの場合、文字が適切にトランスコーディングされている限り、UTF-8以外のエンコーディングが使用される場合があることに注意してください。
Also note that it is syntactically valid to specify both <to> and an <hfname> whose value is "to". That is,
また、値が「to」である<to>と<hfname>の両方を指定することは構文的に有効であることに注意してください。あれは、
<mailto:addr1@an.example,addr2@an.example>
is equivalent to
に相当します
<mailto:?to=addr1@an.example,addr2@an.example>
is equivalent to
に相当します
<mailto:addr1@an.example?to=addr2@an.example>
However, the latter form is NOT RECOMMENDED because different user agents handle this case differently. In particular, some existing clients ignore "to" <hfvalue>s.
ただし、異なるユーザーエージェントがこのケースを異なる方法で処理するため、後者のフォームは推奨されません。特に、一部の既存のクライアントは「<hfvalue>」を無視します。
Implementations MUST NOT produce two "To:" header fields in a message; the "To:" header field may occur at most once in a message ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs MUST NOT include other message header fields multiple times if these header fields can only be used once in a message.
実装は、次の2つの「to」を作成してはなりません。メッセージ内のヘッダーフィールド。「to：」ヘッダーフィールドは、メッセージで最大1回発生する場合があります（[RFC5322]、セクション3.6）。また、「Mailto」URIの作成者は、これらのヘッダーフィールドをメッセージで1回しか使用できない場合、他のメッセージヘッダーフィールドを複数回含めるべきではありません。
To avoid interoperability problems, creators of 'mailto' URIs SHOULD NOT use the same <hfname> multiple times in the same URI. If the same <hfname> appears multiple times in a URI, behavior varies widely for different user agents, and for each <hfname>. Examples include using only the first or last <hfname>/<hfvalue> pair, creating multiple header fields, and combining each <hfvalue> by simple concatenation or in a way appropriate for the corresponding header field.
相互運用性の問題を回避するために、「Mailto」URIの作成者は、同じURIで同じ<HFNAME>を複数回使用してはなりません。同じ<hfname>がURIで複数回表示される場合、動作はユーザーエージェントごとに、および各<hfname>で大きく異なります。例には、最初または最後の<hfname>/<hfvalue>ペアのみを使用し、複数のヘッダーフィールドを作成し、各<hfvalue>を単純な連結または対応するヘッダーフィールドに適した方法で組み合わせることが含まれます。
Note that this specification, like any URI scheme specification, does not define syntax or meaning of a fragment identifier (see [STD66]), because these depend on the type of a retrieved representation. In the currently known usage scenarios, a 'mailto' URI cannot be used to retrieve such representations. Therefore, fragment identifiers are meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored upon resolution. The character "#" in <hfvalue>s MUST be escaped as %23.
この仕様は、任意のURIスキーム仕様と同様に、フラグメント識別子の構文または意味を定義していないことに注意してください（[STD66]を参照）。これらは取得した表現のタイプに依存するためです。現在既知の使用シナリオでは、そのような表現を取得するために「Mailto」URIを使用することはできません。したがって、フラグメント識別子は無意味であり、「Mailto」URIで使用されるべきではなく、解決時に無視する必要があります。<hfvalue> sのキャラクター「＃」は％23として逃げる必要があります。
A 'mailto' URI designates an "Internet resource", which is the mailbox specified in the address. When additional header fields are supplied, the resource designated is the same address but with an additional profile for accessing the resource. While there are Internet resources that can only be accessed via electronic mail, the 'mailto' URI is not intended as a way of retrieving such objects automatically.
「Mailto」URIは、アドレスで指定されたメールボックスである「インターネットリソース」を指定します。追加のヘッダーフィールドが提供されると、指定されたリソースは同じアドレスですが、リソースにアクセスするための追加プロファイルがあります。電子メールでのみアクセスできるインターネットリソースがありますが、「Mailto」URIは、そのようなオブジェクトを自動的に取得する方法として意図されていません。
The operation of how any URI scheme is resolved is not mandated by the URI specifications. In current practice, resolving URIs such as those in the 'http' URI scheme causes an immediate interaction between client software and a host running an interactive server. The 'mailto' URI has unusual semantics because resolving such a URI does not cause an immediate interaction with a server. Instead, the client creates a message to the designated address with the various header fields set as default. The user can edit the message, send the message unedited, or choose not to send the message.
URIスキームの解決方法の操作は、URI仕様によって義務付けられていません。現在の練習では、「HTTP」URIスキームのようなURIを解決することで、クライアントソフトウェアとインタラクティブサーバーを実行するホストとの間に即時のやり取りが生じます。「Mailto」URIには異常なセマンティクスがあります。なぜなら、そのようなURIを解決しても、サーバーとの即時の相互作用は発生しないからです。代わりに、クライアントは、デフォルトとして設定されたさまざまなヘッダーフィールドを使用して、指定されたアドレスにメッセージを作成します。ユーザーは、メッセージを編集したり、編集されていないメッセージを送信したり、メッセージを送信したりしないことを選択できます。
The <hfname>/<hfvalue> pairs in a 'mailto' URI, although syntactically equivalent to header fields in a mail message, do not directly correspond to the header fields in a mail message. In particular, the To, Cc, and Bcc <hfvalue>s don't necessarily result in a header field containing the specified value. Mail client software MAY eliminate duplicate addresses. Creators of 'mailto' URIs SHOULD avoid using the same address twice in a 'mailto' URI.
<hfname>/<hfvalue>「Mailto」URIのペアは、メールメッセージ内のヘッダーフィールドと構文的に同等ですが、メールメッセージのヘッダーフィールドに直接対応していません。特に、to、cc、およびbcc <hfvalue> sは、指定された値を含むヘッダーフィールドに必ずしもそうではありません。メールクライアントソフトウェアは、重複するアドレスを排除する場合があります。「Mailto」ウリスの作成者は、「Mailto」URIで同じアドレスを2回使用することを避ける必要があります。
Originator fields like From and Date, fields related to routing (Apparently-To, Resent-*, etc.), trace fields, and MIME header fields (MIME-Version, Content-*), when present in the URI, MUST be ignored. The mail client MUST create new fields when necessary, as it would for any new message. Unrecognized header fields and header fields with values inconsistent with those the mail client would normally send SHOULD be treated as especially suspect. For example, there may be header fields that are totally safe but not known to the MUA, so the MUA MAY choose to show them to the user.
オリジネーターフィールドFromと日付、ルーティングに関連するフィールド（明らかに、res、*など）、トレースフィールド、およびMimeヘッダーフィールド（Mime-version、content-*）は、URIに存在する場合、無視する必要があります。。メールクライアントは、必要に応じて、新しいメッセージの場合と同様に、新しいフィールドを作成する必要があります。認識されていないヘッダーフィールドとヘッダーフィールドは、通常送信するメールクライアントが通常送信するものと矛盾する値を持つものを特に疑わしいものとして扱う必要があります。たとえば、MUAには完全に安全ではないが知られていないヘッダーフィールドがある可能性があるため、MUAはユーザーに表示することを選択する場合があります。
The user agent interpreting a 'mailto' URI SHOULD NOT create a message if any of the header fields are considered dangerous; it MAY also choose to create a message with only a subset of the header fields given in the URI. Only a limited set of header fields such as Subject and Keywords, as well as Body, are believed to be both safe and useful in the general case. In cases where the source of a URI is well known, and/or specific header fields are limited to specific well-known values, other header fields MAY be considered safe, too.
「Mailto」URIを解釈するユーザーエージェントは、ヘッダーフィールドのいずれかが危険と見なされる場合、メッセージを作成すべきではありません。また、URIに与えられたヘッダーフィールドのサブセットのみを使用してメッセージを作成することもできます。対象やキーワード、ボディなどの限られたヘッダーフィールドのセットのみが、一般的なケースで安全で有用であると考えられています。URIのソースがよく知られている場合、および/または特定のヘッダーフィールドが特定のよく知られた値に限定されている場合、他のヘッダーフィールドも安全であると見なされる場合があります。
The creator of a 'mailto' URI cannot expect the resolver of a URI to understand more than the "subject" header field and "body". Clients that resolve 'mailto' URIs into mail messages MUST be able to correctly create [RFC5322]-compliant mail messages using the "subject" header field and "body".
「Mailto」URIの作成者は、URIのリゾルバーが「サブジェクト」ヘッダーフィールドと「ボディ」以上のものを理解することを期待することはできません。「MailTo」URISをメールメッセージに解決するクライアントは、[RFC5322] - 「件名」ヘッダーフィールドと「ボディ」を使用して、[RFC5322] - 統合メールメッセージを正しく作成できる必要があります。
[STD66] requires that many characters in URIs be encoded. This affects the 'mailto' URI scheme for some common characters that might appear in addresses, header fields, or message contents. One such character is space (" ", ASCII hex 20). Note the examples below that use "%20" for space in the message body. Also note that line breaks in the body of a message MUST be encoded with "%0D%0A". Implementations MAY add a final line break to the body of a message even if there is no trailing "%0D%0A" in the body <hfield> of the 'mailto' URI. Line breaks in other <hfield>s SHOULD NOT be used.
[STD66]では、URIの多くの文字をエンコードする必要があります。これは、アドレス、ヘッダーフィールド、またはメッセージの内容に表示される可能性のあるいくつかの一般的な文字の「Mailto」URIスキームに影響します。そのようなキャラクターの1つはスペースです（ ""、ascii hex 20）。メッセージ本文のスペースに「％20」を使用する以下の例に注意してください。また、メッセージの本体の線が「％0D％0A」でエンコードする必要があることに注意してください。実装は、「Mailto」URIのボディ<hfield>に「％0D％0A」が続く場合でも、メッセージの本体に最終ラインブレークを追加する場合があります。他の<hfield>のラインブレークは使用しないでください。
When creating 'mailto' URIs, any reserved characters that are used in the URIs MUST be encoded so that properly written URI interpreters can read them. Also, client software that reads URIs MUST decode strings before creating the mail message so that the mail message appears in a form that the recipient software will understand. These strings SHOULD be decoded before showing the message to the sending user.
「Mailto」URIを作成する場合、URIで使用される予約されたキャラクターは、適切に書かれたURI通訳者が読み取れるようにエンコードする必要があります。また、urisを読み取るクライアントソフトウェアは、メールメッセージを作成する前に文字列をデコードする必要があり、受信者ソフトウェアが理解するフォームにメールメッセージが表示されるようにします。これらの文字列は、送信ユーザーにメッセージを表示する前にデコードする必要があります。
Software creating 'mailto' URIs likewise has to be careful to encode any reserved characters that are used. HTML forms are one kind of software that creates 'mailto' URIs. Current implementations encode a space as '+', but this creates problems because such a '+' standing for a space cannot be distinguished from a real '+' in a 'mailto' URI. When producing 'mailto' URIs, all spaces SHOULD be encoded as %20, and '+' characters MAY be encoded as %2B. Please note that '+' characters are frequently used as part of an email address to indicate a subaddress, as for example in <bill+ietf@example.org>.
同様に、「Mailto」URISを作成するソフトウェアは、使用されている予約された文字をエンコードするように注意する必要があります。HTMLフォームは、「Mailto」URIを作成する1つのソフトウェアです。現在の実装はスペースを「 '」としてエンコードしますが、これは問題を引き起こします。なぜなら、「スペースの立場は、「Mailto」URIの実際の」と区別することはできないからです。「Mailto」URIを生成する場合、すべてのスペースは％20としてエンコードする必要があり、文字は％2Bとしてエンコードされる場合があります。たとえば、<bill ietf@example.org>のように、「電子メールアドレスの一部として文字が頻繁に使用されることに注意してください。
The 'mailto' URI scheme is limited in that it does not provide for substitution of variables. Thus, it is impossible to create a 'mailto' URI that includes a user's email address in the message body. This limitation also prevents 'mailto' URIs that are signed with public keys and other such variable information.
「Mailto」URIスキームは、変数の置換を提供しないという点で制限されています。したがって、メッセージ本文にユーザーのメールアドレスを含む「MailTo」URIを作成することは不可能です。この制限は、パブリックキーやその他の変動情報で署名された「Mailto」URIを防ぎます。
A URI for an ordinary individual mailing address:
通常の個々の郵送先住所のためのURI：
<mailto:chris@example.com>
A URI for a mail response system that requires the name of the file to be sent back in the subject:
ファイルの名前を件名に返送する必要があるメール応答システムのURI：
<mailto:infobot@example.com?subject=current-issue>
A mail response system that requires a "send" request in the body:
ボディ内の「送信」要求を必要とするメール応答システム：
<mailto:infobot@example.com?body=send%20current-issue>
A similar URI, with two lines with different "send" requests (in this case, "send current-issue" and, on the next line, "send index"):
異なる「送信」リクエストを持つ2行を持つ同様のURI（この場合、「電流問題を送信」、次の行で「インデックスを送信する」）：
<mailto:infobot@
example.com?body=send%20current-issue%0D%0Asend%20index>
An interesting use of 'mailto' URIs occurs when browsing archives of messages. A link can be provided that allows replying to a message and conserving threading information. This is done by adding an In-Reply-To header field containing the Message-ID of the message where the link is added, for example:
「Mailto」URIの興味深い使用は、メッセージのアーカイブを閲覧するときに発生します。メッセージに返信し、スレッド情報を保存できるリンクを提供できます。これは、リンクが追加されているメッセージのメッセージIDを含むIn-Reply-to Headerフィールドを追加することによって行われます。
<mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@
example.com%3E>
A request to subscribe to a mailing list:
メーリングリストに購読するリクエスト：
<mailto:majordomo@example.com?body=subscribe%20bamboo-l>
A URI that is for a single user and that includes a CC of another user:
単一のユーザー向けで、別のユーザーのCCを含むURI：
<mailto:joe@example.com?cc=bob@example.com&body=hello>
Note the use of the "&" reserved character above. The following example, using "?" twice, is incorrect:
上記の「＆」予約文字の使用に注意してください。次の例は、「？」を使用しています。2回、間違っています：
<mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG! According to [RFC5322], the characters "?", "&", and even "%" may occur in addr-specs. The fact that they are reserved characters is not a problem: those characters may appear in 'mailto' URIs -- they just may not appear in unencoded form. The standard URI encoding mechanisms ("%" followed by a two-digit hex number) MUST be used in these cases.
<mailto：joe@example.com？cc=bob@example.com？body = hello>;間違い！[RFC5322]によると、文字「？」、「＆」、さらには「％」はADDRスペックで発生する可能性があります。それらが予約されたキャラクターであるという事実は問題ではありません。これらのキャラクターは「Mailto」ウリに表示される可能性があります。これらの場合には、標準のURIエンコーディングメカニズム（「％」に続く2桁の16進数）を使用する必要があります。
To indicate the address "gorby%kremvax@example.com" one would use:
「gorby%kremvax@example.com」アドレスを示すには、使用します。
<mailto:gorby%25kremvax@example.com>
To indicate the address "unlikely?address@example.com", and include another header field, one would use:
アドレス「可能性はありませんか？address@example.com」を示すには、別のヘッダーフィールドを含めるには、使用します。
<mailto:unlikely%3Faddress@example.com?blat=foop>
As described above, the "&" (ampersand) character is reserved in HTML and has to be replaced, e.g., with "&". Thus, a URI with an internal ampersand might look like:
上記のように、「＆」（Ampersand）文字はHTMLで予約されており、たとえば「＆amp;」に置き換える必要があります。したがって、内部アンパンとアンパイのURIは次のように見えるかもしれません。
Click <a href="mailto:joe@an.example?cc=bob@an.example&body=hello" >mailto:joe@an.example?cc=bob@an.example&body=hello</a> to send a greeting message to Joe and Bob.
<a href="mailto:joe@an.example?cc=bob@an.example& body=hello"> mailto：joe@an.example？cc=bob@an.example& body = hello </a>をクリックしますジョーとボブに挨拶メッセージを送る。
When an email address itself includes an "&" (ampersand) character, that character has to be percent-encoded. For example, the 'mailto' URI to send mail to "Mike&family@example.org" is <mailto:Mike%26family@example.org>.
電子メールアドレス自体に「＆」（アンペアンド）文字が含まれている場合、そのキャラクターはパーセントエンコードされなければなりません。たとえば、「mailto」uriは、「mike＆family@example.org」にメールを送信します。
Following are a few examples of how to treat email addresses that contain complicated escaping syntax.
以下は、複雑な脱出構文を含むメールアドレスを扱う方法のいくつかの例です。
Email address: "not@me"@example.org; corresponding 'mailto' URI:
メールアドレス：「@me not@me」@embles.org;対応する 'mailto' uri：
<mailto:%22not%40me%22@example.org>.
<mailto：％not%40me%22@example.org>。
Email address: "oh\\no"@example.org; corresponding 'mailto' URI:
メールアドレス： "OH \\ no"@example.org;対応する 'mailto' uri：
<mailto:%22oh%5C%5Cno%22@example.org>.
<mailto：％2oh%5c%5cno%22@example.org>。
Email address: "\\\"it's\ ugly\\\""@example.org; corresponding 'mailto' URI:
メールアドレス： "\\\"それは\ ugly \\\ ""@example.org;対応する 'mailto' uri：
<mailto:%22%5C%5C%5C%22it's%5C%20ugly%5C%5C%5C%22%22@example.org>.
<MailTo：％22%5C%5C%5C%22it's%5C%20ugly%5C%5C%22%22@example.org>。
Sending a mail with the subject "coffee" in French, i.e., "cafe" where the final e is an e-acute, using UTF-8 and percent-encoding:
被写体の「コーヒー」をフランス語で送信する、つまり、最終eがUTF-8とパーセントエンコードを使用してe-actuteである「カフェ」を送信します。
<mailto:user@example.org?subject=caf%C3%A9>
The same subject, this time using an encoded-word (escaping the "=" and "?" characters used in the encoded-word syntax, because they are reserved):
同じ主題、今回はエンコードされた単語を使用して（エンコードされた単語の構文で使用される「= "および"？」文字を逃がします。
<mailto:user@
example.org?subject=%3D%3Futf-8%3FQ%3Fcaf%3DC3%3DA9%3F%3D>
The same subject, this time encoded as iso-8859-1:
同じ主題、今回はISO-8859-1としてエンコードされました：
<mailto:user@
example.org?subject=%3D%3Fiso-8859-1%3FQ%3Fcaf%3DE9%3F%3D>
Going back to straight UTF-8 and adding a body with the same value:
まっすぐなUTF-8に戻り、同じ値のボディを追加します。
<mailto:user@example.org?subject=caf%C3%A9&body=caf%C3%A9>
This 'mailto' URI may result in a message looking like this:
この「mailto」uriは、次のように見えるメッセージが生じる可能性があります。
From: sender@example.net
To: user@example.org
Subject: =?utf-8?Q?caf=C3=A9?=
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
caf=C3=A9
CAF = C3 = A9
The software sending the email is not restricted to UTF-8, but can use other encodings. The following shows the same email using iso-8859-1 two times:
メールを送信するソフトウェアはUTF-8に制限されていませんが、他のエンコーディングを使用できます。以下は、ISO-8859-1を2回使用して同じメールを示しています。
From: sender@example.net
To: user@example.org
Subject: =?iso-8859-1?Q?caf=E9?=
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
caf=E9
CAF = E9
Different content transfer encodings (i.e., "8bit" or "base64" instead of "quoted-printable") and different encodings in encoded words (i.e., "B" instead of "Q") can also be used.
異なるコンテンツ転送エンコーディング（つまり、「引用プリント可能」ではなく「8ビット」または「base64」）とエンコードされた単語（つまり、「Q」の代わりに「b」）で異なるエンコードを使用することもできます。
For more examples of encoding the word coffee in different languages, see [RFC2324].
異なる言語でコーヒーという単語をエンコードする例については、[RFC2324]を参照してください。
The following example uses the Japanese word "natto" (Unicode characters U+7D0D U+8C46) as a domain name label, sending a mail to a user at "natto".example.org:
次の例では、日本語の単語「natto」（unicode文字u 7d0d u 8c46）をドメイン名ラベルとして使用し、「natto」.example.orgでユーザーにメールを送信します。
<mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=NATTO>
When constructing the email, the domain name label is converted to punycode. The resulting message may look as follows:
電子メールを作成するとき、ドメイン名ラベルはPunycodeに変換されます。結果のメッセージは次のように見える場合があります。
From: sender@example.net
To: user@xn--99zt52a.example.org
Subject: Test
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
NATTO
ナット
The 'mailto' URI scheme can be used to send a message from one user to another, and thus can introduce many security concerns. Mail messages can be logged at the originating site, the recipient site, and intermediary sites along the delivery path. If the messages are not encrypted, they can also be read at any of those sites.
「MailTo」URIスキームを使用して、あるユーザーから別のユーザーにメッセージを送信できるため、多くのセキュリティ上の懸念を導入できます。メールメッセージは、配信パスに沿って、元のサイト、受信サイト、および仲介サイトでログに記録できます。メッセージが暗号化されていない場合は、それらのサイトのいずれかで読み取ることもできます。
A 'mailto' URI gives a template for a message that can be sent by mail client software. The contents of that template may be opaque or difficult to read by the user at the time of specifying the URI, as well as being hidden in the user interface (for example, a link on an HTML Web page might display something other than the content of the corresponding 'mailto' URI that would be used when clicked). Thus, a mail client SHOULD NOT send a message based on a 'mailto' URI without first disclosing and showing to the user the full message that will be sent (including all header fields that were specified by the 'mailto' URI), fully decoded, and asking the user for approval to send the message as electronic mail. The mail client SHOULD also make it clear that the user is about to send an electronic mail message, since the user may not be aware that this is the result of a 'mailto' URI. Users are strongly encouraged to ensure that the 'mailto' URI presented to them matches the address included in the "To:" line of the email message.
「Mailto」URIは、メールクライアントソフトウェアで送信できるメッセージのテンプレートを提供します。そのテンプレートの内容は、URIを指定した時点でユーザーが不透明または読みにくい場合があり、ユーザーインターフェイスに隠されている場合があります（たとえば、HTML Webページのリンクにはコンテンツ以外のものが表示される場合がありますクリック時に使用される対応する「Mailto」URIの）。したがって、メールクライアントは、「Mailto」URIに基づいて「MailTo」URIに基づいてメッセージを送信してはいけません。、およびユーザーに電子メールとしてメッセージを送信するための承認を求めます。また、ユーザーは「Mailto」URIの結果であることに気付かない可能性があるため、ユーザーが電子メールメッセージを送信しようとしていることを確認する必要があります。ユーザーは、提示された「MailTo」URIが「TO」に含まれるアドレスと一致するようにすることを強くお勧めします。電子メールメッセージの行。
Some header fields are inherently unsafe to include in a message generated from a URI. For details, please see Section 3. In general, the fewer header fields interpreted from the URI, the less likely it is that a sending agent will create an unsafe message.
一部のヘッダーフィールドは、URIから生成されたメッセージに含めることが本質的に安全ではありません。詳細については、セクション3を参照してください。一般に、URIから解釈されるヘッダーフィールドが少なければ少ないほど、送信エージェントが安全でないメッセージを作成する可能性が低くなります。
Examples of problems with sending unapproved mail include:
承認されていないメールの送信に関する問題の例は次のとおりです。
mail that breaks laws upon delivery, such as making illegal threats;
違法な脅威をするなど、配達時に法律を破る郵便物。
mail that identifies the sender as someone interested in breaking laws;
送信者を法律を破ることに興味がある人として識別するメール。
mail that identifies the sender to an unwanted third party;
送信者を不要な第三者に識別するメール。
mail that causes a financial charge to be incurred by the sender;
送信者が財政料金を発生させるメール。
mail that causes an action on the recipient machine that causes damage that might be attributed to the sender.
送信者に起因する可能性のある損傷を引き起こす受信機にアクションを引き起こすメール。
Programs that interpret 'mailto' URIs SHOULD ensure that the SMTP envelope return path address, which is given as an argument to the SMTP MAIL FROM command, is set and correct, and that the resulting email is a complete, workable message.
「Mailto」URISを解釈するプログラムは、コマンドからSMTPメールへの引数として与えられたSMTPエンベロープリターンパスアドレスが設定され、正しいことを保証する必要があり、結果の電子メールが完全で実行可能なメッセージであることを確認する必要があります。
'mailto' URIs on public Web pages expose mail addresses for harvesting. This applies to all mail addresses that are part of the 'mailto' URI, including the addresses in a "bcc" <hfvalue>. Those addresses will not be sent to the recipients in the 'to' field and in the "to" and "cc" <hfvalue>s, but will still be publicly visible in the URI. Addresses in a "bcc" <hfvalue> may also leak to other addresses in the same <hfvalue> or become known otherwise, depending on the mail user agent used.
パブリックWebページの「Mailto」Urisは、収穫のためにメールアドレスを公開します。これは、「bcc」<hfvalue>のアドレスを含む「mailto」uriの一部であるすべてのメールアドレスに適用されます。これらのアドレスは、「to」フィールドおよび「to」および「cc」<hfvalue>の「フィールド」の受信者に送信されませんが、URIではまだ公開されます。「bcc」<hfvalue>のアドレスは、使用するメールユーザーエージェントに応じて、同じ<hfvalue>の他のアドレスに漏れたり、そうでない場合も知られるようになる場合があります。
Programs manipulating 'mailto' URIs have to take great care to not inadvertently double-escape or double-unescape 'mailto' URIs, and to make sure that escaping and unescaping conventions relating to URIs and relating to mail addresses are applied in the right order.
「Mailto」URIを操作するプログラムは、不注意に二重のエスケープや二重のアフアンスケープ「Mailto」ウリスを操作し、urisに関連し、メールアドレスに関連する逃亡と解明の慣習を正しい順序で適用するように細心の注意を払わなければなりません。
Implementations parsing 'mailto' URIs must take care to sanity check 'mailto' URIs in order to avoid buffer overflows and problems resulting from them (e.g., execution of code specified by the attacker).
「Mailto」URIを解析する実装は、バッファーのオーバーフローやそれらの問題（たとえば、攻撃者によって指定されたコードの実行）を避けるために、「mailto 'uris」を確認するように注意する必要があります。
The security considerations of [STD66], [RFC5890], [RFC5891], and [RFC3987] also apply. Implementers and users are advised to check them carefully.
[STD66]、[RFC5890]、[RFC5891]、および[RFC3987]のセキュリティ上の考慮事項も適用されます。実装者とユーザーは、注意深くチェックすることをお勧めします。
This document changes the definition of the 'mailto' URI scheme; the registry of URI schemes has been updated to refer to this document rather than its predecessor, [RFC2368]. The registration template is as follows:
このドキュメントは、「Mailto」URIスキームの定義を変更します。URIスキームのレジストリは、前身ではなくこのドキュメントを参照するように更新されました[RFC2368]。登録テンプレートは次のとおりです。
URI scheme name: 'mailto'
URIスキーム名： 'mailto'
Status: permanent
ステータス：永続的
URI scheme syntax: See the syntax section of RFC 6068.
URIスキーム構文：RFC 6068の構文セクションを参照してください。
URI scheme semantics: See the semantics section of RFC 6068.
URIスキームセマンティクス：RFC 6068のセマンティクスセクションを参照してください。
Encoding considerations: See the syntax and encoding sections of RFC 6068.
考慮事項のエンコード：RFC 6068の構文とエンコードセクションを参照してください。
Applications/protocols that use this URI scheme name: The 'mailto' URI scheme is widely used since the start of the Web.
このURIスキームを使用するアプリケーション/プロトコル名：「Mailto」URIスキームは、Webの開始以来広く使用されています。
Interoperability considerations: Interoperability for 'mailto' URIs with UTF-8-based percent-encoding might be somewhat lower than interoperability for 'mailto' URIs with US-ASCII only.
相互運用性の考慮事項：UTF-8ベースのパーセントエンコードを持つ「Mailto」URIの相互運用性は、US-ASCIIのみの「Mailto」URIの相互運用性よりもやや低い場合があります。
Security considerations: See the security considerations section of RFC 6068.
セキュリティ上の考慮事項：RFC 6068のセキュリティに関する考慮事項セクションを参照してください。
Contact: IETF
連絡先：IETF
Author/Change controller: IETF
著者/変更コントローラー：IETF
References: RFC 6068
参照：RFC 6068
IANA has registered the Body header field in the Message Header Fields Registry ([RFC3864]) as follows:
IANAは、次のように、メッセージヘッダーフィールドレジストリ（[RFC3864]）にボディヘッダーフィールドを登録しています。
Header field name: Body
ヘッダーフィールド名：ボディ
Applicable protocol: None. This registration is made to assure that this header field name is not used at all, in order to not create any problems for 'mailto' URIs.
該当するプロトコル：なし。この登録は、「Mailto」URIの問題を作成しないために、このヘッダーフィールド名がまったく使用されないことを保証するために行われます。
Status: reserved
ステータス：予約済み
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document(s): RFC 6068
仕様文書：RFC 6068
Related information: none
関連情報：なし
The main changes from RFC 2368 are as follows:
RFC 2368からの主な変更は次のとおりです。
o Changed syntax from RFC 2822 <mailbox> to [RFC5322] <addr-spec>.
o 構文をRFC 2822 <MailBox>から[RFC5322] <AddR-Spec>に変更しました。
o Allowed UTF-8-based percent-encoding for domain names and in <hfvalue>.
o ドメイン名と<hfvalue>のUTF-8ベースのパーセントエンコードが許可されました。
o Nailed down percent-encoding in <local-part> to be based on UTF-8, reserved for if and when there is a specification for the internationalization of email addresses.
o UTF-8に基づくために<Local-Part>の割合を釘付けにしました。
o Removed prohibition against "Bcc:" header fields, but added a warning about their visibility and harvesting for spam.
o 「BCC：」に対する禁止策を削除しましたが、ヘッダーフィールドがありますが、スパムの視認性と収穫についての警告が追加されました。
o Added clarifications for escaping.
o 逃げるための説明を追加しました。
This document was derived from [RFC2368]; the acknowledgments from that specification still apply. In addition, we thank Paul Hoffman for his work on [RFC2368].
このドキュメントは[RFC2368]から派生しました。その仕様からの謝辞は引き続き適用されます。さらに、[RFC2368]の仕事についてPaul Hoffmanに感謝します。
Valuable input on this document was received from (in no particular order): Alexey Melnikov, Paul Hoffman, Charles Lindsey, Tim Kindberg, Frank Ellermann, Etan Wexler, Michael Haardt, Michael Anthony Puls II, Eliot Lear, Dave Crocker, Dan Harkins, Nevil Brownlee, John Klensin, Alfred Hoenes, Ned Freed, Sean Turner, Peter Saint-Andre, Adrian Farrel, Avshalom Houri, Robert Sparks, and many others.
この文書に関する貴重な入力は（順不同）から受け取られました：アレクシー・メルニコフ、ポール・ホフマン、チャールズ・リンジー、ティム・キンダーグ、フランク・エラーマン、エタン・ウェクスラー、マイケル・ハード、マイケル・アンソニー・パルスII、エリオット・リア、デイブ・クロッカー、ダン・ハーキンス、Nevil Brownlee、John Klensin、Alfred Hoenes、Ned Freed、Sean Turner、Peter Saint-Andre、Adrian Farrel、Avshalom Houri、Robert Sparksなど。
[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、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K。、「MIMEパート3：ASCII以外のテキストのメッセージヘッダー拡張機能」、RFC 2047、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月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[RFC5322] Resnik, P., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnik、P。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：プロトコル」、RFC 5891、2010年8月。
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[Std63] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[STD66] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[STD68] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, April 1998.
[RFC2324] Masinter、L。、「Hyper Text Coffee Pot Control Protocol（HTCPCP/1.0）」、RFC 2324、1998年4月。
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2368] Hoffman、P.、Masinter、L。、およびJ. Zawinski、「The Mailto URL Scheme」、RFC 2368、1998年7月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J。およびY. Ko、「国際化された電子メールの概要とフレームワーク」、RFC 4952、2007年7月。
Authors' Addresses
著者のアドレス
Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.) Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan
Martin Duerst（注：可能な限りU-Umlaut、たとえば「D＆＃252; rst」としてu-umlautで「Duerst」を書いてください。
Phone: +81 42 759 6329
Fax: +81 42 759 6495
EMail: duerst@it.aoyama.ac.jp
URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose、CA 95110 USA
Phone: +1-408-536-3024
EMail: LMM@acm.org
URI: http://larry.masinter.net/
Jamie Zawinski DNA Lounge 375 Eleventh Street San Francisco, CA 94103 USA
Jamie Zawinski DNA Lounge 375 Efreenth Street San Francisco、CA 94103 USA
EMail: jwz@jwz.org