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
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（Uniform Resource Identifier）の形式を定義します。 「MAILTO」のURI（RFC 2368）の前の構文に、これは、国際化資源識別子（RFC 3987のIRI）とのより良い国際化と互換性が追加されます。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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]、国際化のために非ASCII文字を扱うのより良い、より一貫性のある方法を提供しています基づいてパーセントエンコードできるようにするために、以前のスキームの定義を拡張します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
[STD66]の付録Cに記載されるように本書では、URIは、で囲まれた「<」と「>」されています。余分な空白や改行は長い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の構文は[RFC5322]（ドット原子テキスト、引用符で囲まれた文字列）、および[STD66]（予約されていないから非終端定義から[STD68]、非終端定義のABNFを用いて説明します、 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 = "!" / "$" / "'" / "(" / ")" / "*" / "+" / "," / ";" / ":" / "@"
mailtoURI = "mailtoの：" [へ] [hfields] = addrはスペック*（ "" ADDRスペック）hfields =に "？" hfield *（ "＆" hfield）hfield = hfname "=" hfvalue hfname = * qchar hfvalue = * qchar addrのスペック=ローカル部分ドメインローカル部分=ドット原子テキスト/引用符で囲まれた文字列のドメイン=ドット "@" - 原子テキスト/ "[" * dtext-NO-OBS "]" dtext-NO-OBS =％d33-90 /。印刷可能なUS-ASCII％のd94-126。含まない文字。 "["、 "]"、または "\" qchar =予約されていない/ PCT-エンコード/一部-delims一部-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仕様>に表示できる文字数はパーセントエンコードする必要があります。これらは、（それがパーセントエンコーディングのために使用されているため）[STD66]によるだけでなく、「％」URIに表示され、「@」を除くGEN-delimsのすべての文字とすることができない文字である「：」（すなわち、 "/"、 "？"、 "＃"、 "["、および "]"）。 「;」、および「=」「＆」、：サブdelimsの文字の、少なくとも以下もパーセントエンコードされなければなりません。ケアは、これらの操作は1回だけ適用されていることを確認するためにデコードする際にエンコードするだけでなく、ときの両方に注意しなければなりません。
2. <obs-local-part> and <NO-WS-CTL> as defined in [RFC5322] MUST NOT be used.
2. [RFC5322]で定義されるように、<OBSローカル部分>と<NO-WS、CTL>は使用してはいけません。
3. Whitespace and comments within <local-part> and <domain> MUST NOT be used. They would not have any operational semantics.
3.空白と<ローカル部分>と<ドメイン>内のコメントを使用してはいけません。彼らはすべての操作的意味論を持っていないでしょう。
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.パーセントエンコーディングは、国際化ドメイン名を示すために、<ADDR仕様>の<ドメイン>部分に使用することができます。中に<REG-name>のための考慮事項は[STD66]適用されます。具体的には、非ASCII文字は、最初のUTF-8 [STD63]に従って符号化されなければならない、そして、対応するUTF-8シーケンスの各オクテットは、パーセントエンコードされたURI文字として表現することでなければなりません。 UTF-8文字列を表すために使用されていない限り、URI生成アプリケーションは、ドメイン名にパーセントエンコーディングを使用してはなりません。国際化ドメイン名がメッセージを作成するために使用される場合、名前はアプリケーションに国際化ドメイン名に変換されなければならない（IDNA）適切な場合には[RFC5891]をコードします。彼らは「のmailto」URIの通訳レガシーとの相互運用性を最大化したい場合は、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.
<ローカル部分>非ASCIIオクテットの5パーセントエンコーディング<ADDR仕様>の<ローカル部分>の国際化のために予約されています。非ASCII文字は、最初の[STD63] UTF-8に従って符号化されなければならない、そして、対応する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仕様>について上に列挙したパーセントエンコーディングは、同じ文字のために必要とされます。 <hfname>大文字と小文字を区別しないで、しかし<hfvalue>一般的に、大文字と小文字が区別されます。 「：」<PCT-エンコード>はヘッダフィールド名の生産の一部である理由である、オプションのヘッダーフィールド名（セクション3.6.8）、に[RFC5322]は除くすべての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>は、メッセージの本体であることを示しています。 「本文」フィールドの値は、メッセージの最初のtext / plainのボディ部のコンテンツを含むように意図されます。 「本体」疑似ヘッダフィールドは、主に（例えば、メーリングリストのメッセージを「購読」のような）自動処理のための短いテキストメッセージの生成のためではなく、一般的な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 "のURI、「？」の中で、「=」、および「＆」区切り文字として、予約されています。デリミタとして機能しないときには（それぞれ、「％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が使用されているコンテキストに応じて適用される場合があります許可されている文字の上に追加の制限。このような制限は、コンテキスト固有のエスケープのメカニズムによって対処することができます。たとえば、「＆」（アンパサンド）文字はHTMLやXML、HTML / XMLエンティティに書き込まれるようにしているアンパサンドを含む任意の「のmailto」URIに予約されているので（「＆＃038;」）または数値文字参照（ "＆＃の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.
（[RFC2047]で定義されるように）1 MIMEエンコードされた単語は、<hfname>なく<hfvalue>における「本体」のヘッダフィールド値に許可されます。 MIMEエンコードされた言葉のように見える文字の配列は、<hfvalue>「体」<hfname>の中に表示されますが、その場合には特別な意味を持つことはできません。 「=」とことに注意してください「？」 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>、<hfvalue>を除いて、「本体」の好適（MIMEエンコードされた単語に変換[RFC2047]）符号化されなければならない<hfname>これは[RFC2045]に従って符号化されなければなりません。 MIMEエンコードされた単語のためにと合成電子メールメッセージでの体のためにそれを注意してください、UTF-8以外のエンコーディングは限り文字が適切にトランスコードされているとして使用することができます。
Also note that it is syntactically valid to specify both <to> and an <hfname> whose value is "to". That is,
また、<に>と<hfname>その値が「へ」の両方を指定する構文的に有効であることに注意してください。あれは、
<mailto:addr1@an.example,addr2@an.example>
<MAILTO：ADDR1 @ an.example、ADDR2 @ an.example>
is equivalent to
に相当します
<mailto:?to=addr1@an.example,addr2@an.example>
<MAILTO：？= ADDR1 @ an.example、ADDR2 @ an.exampleへ>
is equivalent to
に相当します
<mailto:addr1@an.example?to=addr2@an.example>
<の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> S「に」無視します。
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つを生成してはいけませんメッセージのヘッダフィールド。 「：を」ヘッダフィールドは、メッセージ（[RFC5322]、セクション3.6）中で最も回起こり得ます。また、「mailtoの」URIの作成者は、これらのヘッダフィールドは、メッセージのみで一度に使用できるのであれば、他のメッセージヘッダが複数回フィールド含んではいけません。
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を解決することは、クライアントソフトウェアと対話型サーバを実行しているホスト間の直接の相互作用を引き起こします。そのようなURIを解決することは、サーバーとの直接の相互作用を起こさないために「のmailto」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.
「のmailto」URIに<hfname> / <hfvalue>ペアは、電子メールメッセージのフィールドをヘッダに文法的に同等のが、直接メールメッセージのヘッダフィールドに対応していません。具体的には、TO、CC、およびBccの<hfvalue> Sは、必ずしも指定された値を含むヘッダフィールドをもたらしません。メールクライアントソフトウェアは、重複したアドレスを除去することができます。 「のmailto」URIのクリエイターは「MAILTO」URIに二度同じアドレスを使用しないでください。
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.
発信元からのようなフィールドと日付、（などどうやら-するために、はResent- *を、）ルーティングに関連するフィールド、フィールドをトレース、およびMIMEヘッダフィールド（MIME-バージョン、の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
ヘッダフィールドのいずれかが危険とみなされる場合は、メッセージを作成しないでください「のmailto」URIを解釈するユーザエージェント。それはまた、URIで指定されたヘッダフィールドのサブセットのみを使用してメッセージを作成することもできます。このようなヘッダフィールドの限られたセット
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.
件名やキーワードだけでなく、ボディ、一般的なケースでは、安全かつ有用両方であると考えられます。 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」URIが正しく、「件名」ヘッダフィールドと「体」を使用して、[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スキームに影響を与えます。そのような文字はスペース（」」、ASCIIの六角20）です。メッセージ本体内のスペースのためのその使用、「20％」以下の例に注意してください。また、メッセージの本文にその改行は「の％0D％0A」でエンコードする必要があります。実装は<hfield>「のmailto」URIの体内には末尾「の％0D％0A」がない場合でも、メッセージの本文に、最終的な改行を追加するかもしれません。他の<hfield> s内の改行は使うべきではありません。
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の中で使用されているすべての予約文字をエンコードする必要があります。メールメッセージが受信者のソフトウェアが理解した形で表示されるように、また、URIを読み込み、クライアントソフトウェアは、メールメッセージを作成する前に、文字列をデコードしなければなりません。これらの文字列は、送信ユーザーにメッセージを表示する前に復号化されなければなりません。
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」URIが同様に使用されているすべての予約文字をエンコードするように注意しなければなりません。 HTMLフォームは、「mailtoの」URIを作成するソフトウェアの一種です。現在の実装では、「+」のようにスペースをエンコードするが、そのような「+」はスペースのために立っているので、これは問題を作成します「の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>
<に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>
<のmailto：？infobot@example.com対象=現在の発行>
A mail response system that requires a "send" request in the body:
体内の「送信」要求を必要とするメール応答システム：
<mailto:infobot@example.com?body=send%20current-issue>
<のmailto：？infobot@example.com体=送信％の20current発行>
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>
<に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を含むヘッダを追加することによって行われます。
<mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@ example.com%3E>
<のmailto：？list@example.orgで、返信先=％3C3469A91.D10AF4C @ example.com％3E>
A request to subscribe to a mailing list:
メーリングリストに参加するための要求：
<mailto:majordomo@example.com?body=subscribe%20bamboo-l>
<のmailto：？majordomo@example.com体=％の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>
<の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:
上記の「＆」予約文字の使用に注意してください。次の例では、使用して「？」二回、間違っています：
<mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!
<？のmailto：joe@example.com cc=bob@example.com体=こんにちは>;違う！
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.
[RFC5322]、文字「？」、「＆」、さらには「％」によると、addrは、スペックに発生する可能性があります。彼らは文字を予約されているという事実は問題ではありません。これらの文字は、「MAILTO」のURIに表示される場合があります - 彼らはエンコードされていない形式で表示されない場合があります。標準URIエンコードメカニズム（二桁の16進数字が続く「％」）は、これらのケースで使用されなければなりません。
To indicate the address "gorby%kremvax@example.com" one would use:
アドレスを示すために、「gorby%kremvax@example.com」1が使用します。
<mailto:gorby%25kremvax@example.com>
<のmailto：gorby%25kremvax@example.com>
To indicate the address "unlikely?address@example.com", and include another header field, one would use:
アドレス「unlikely?address@example.com」を示し、他のヘッダフィールドを含めるには、一つは使用します。
<mailto:unlikely%3Faddress@example.com?blat=foop>
<の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:
上述したように、「＆」（アンパサンド）文字を用いて、例えば、HTMLに確保し、交換する必要がありされ、「＆＃038;」。このように、内部アンパサンドを持つ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.
？joe@an.example cc=bob@an.example&アンペア;ボディ=こんにちは</：<a href="mailto:joe@an.example?cc=bob@an.example& amp;body=hello">のmailtoをクリックしてください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" にメールを送信することです。<mailtoの：Mike%26family@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:
電子メールアドレス：「ではない私@」@ example.org。対応する 'のmailto' URI：
<mailto:%22not%40me%22@example.org>.
<のmailto：%22not%40me%22@example.org>。
Email address: "oh\\no"@example.org; corresponding 'mailto' URI:
電子メールアドレス：「いいえ\\ああ」@ example.org。対応する 'のmailto' URI：
<mailto:%22oh%5C%5Cno%22@example.org>.
<のmailto：%22oh%5C%5Cno%22@example.org>。
Email address: "\\\"it's\ ugly\\\""@example.org; corresponding 'mailto' URI:
電子メールアドレス：「\\\」それは\醜い\\\「」@ 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%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およびパーセントエンコーディング：
<mailto:user@example.org?subject=caf%C3%A9>
<のmailto：？user@example.org対象= 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>
<MAILTO：ユーザー@ 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>
<MAILTO：ユーザー@ 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>
<のmailto：？user@example.org対象= CAF％C3％A9＆ボディ= 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
投稿者：sender@example.netへ：user@example.org件名：= UTF-8 Q CAF = C3 = A9 =のContent-Type：text / plainの;のcharset = UTF-8コンテンツ転送エンコード？？？？： quoted-printable形式
caf=C3=A9
CAC = MCD =アイア
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
投稿者：sender@example.netへ：user@example.org件名：= ISO-8859-1 Q CAF = E9 =のContent-Type：？？？？テキスト/平野;のcharset = ISO-8859-1のContent-Transfer-エンコード：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:
次の例では、「納豆」.example.orgのユーザにメールを送信し、ドメイン名のラベルとして日本語の単語「納豆」（Unicode文字U + 7D0D U + 8C46）を使用しています。
<mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=NATTO>
<のmailto：？user@%E7%B4%8D%E8%B1%86.example.org対象=テスト＆ボディ=納豆>
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
投稿者：sender@example.netへ：user@xn--99zt52a.example.org件名：テストのContent-Type：text / plainのコンテンツ転送 - エンコード：7ビット
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はメールクライアントソフトウェアによって送信することができますメッセージのテンプレートを提供します。そのテンプレートの内容は、（例えば、HTMLのWebページ上のリンクがコンテンツ以外のものを表示することがありますURIを指定した時にユーザが読み不透明または難しいかもしれない、などのユーザインタフェースの中に隠されていますクリックしたときに使用される、対応する「のmailto」URIの）。これにより、メールクライアントは完全にデコードされ、第一のユーザに（「のmailto」URIで指定されたすべてのヘッダ・フィールドを含む）が送信される完全なメッセージを開示し、示すことなく「のmailto」URIに基づいてメッセージを送るべきではありません、および電子メールなどのメッセージを送信するために、承認のためにユーザに尋ねます。ユーザーが電子メールメッセージを送信しようとしていることをユーザーは、これが「のmailto」URIの結果であることを認識していなくてもよいので、メールクライアントも、それを明確にすべきです。電子メールメッセージの行：ユーザーが強くアドレスが「へ」に含ま一致する「のmailto」URIが彼らに提示することを確実にするために奨励されています。
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から生成されたメッセージに含まれる本質的に安全です。詳細については、一般に、URIから解釈少ないヘッダ・フィールドをセクション3を参照してください、にくくそれは送信エージェントが安全でないメッセージを作成することです。
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」URIを解釈するプログラムは、SMTP MAIL FROMコマンドへの引数として指定された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.
「mailtoの」公開WebページのURIは収穫のためのメールアドレスを公開します。これは、「BCC」<hfvalue>内のアドレスを含む「のmailto」URIの一部であるすべてのメールアドレスに適用されます。これらのアドレスは「から」フィールドと「に」と「CC」<hfvalue> Sでの受信者に送信されることはありませんが、それでも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」URIに細心の注意を取るために、そしてエスケープとアンエスケープ規則は、URIに関連し、メールアドレスに関する右の順に適用されていることを確認する必要があり、操作するプログラム。
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」URIの健全性チェックに注意しなければならない（例えば、攻撃者によって指定されたコードの実行）。
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スキームが広くウェブの開始以来使用されています。
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
仕様書（S）：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 [RFC5322] <ADDR仕様>にRFC 2822 <メールボックス>のシンタックスを変更しました。
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に基づくように、電子メールアドレスの国際化のために指定がある場合は、いつのために予約。
o Removed prohibition against "Bcc:" header fields, but added a warning about their visibility and harvesting for spam.
ヘッダフィールドを、しかし、スパムのための彼らの可視性と収穫に関する警告を追加しました：「Bccの」Oの禁止を削除。
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]での彼の仕事のためにポール・ホフマンに感謝します。
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.
このドキュメントに関する貴重な入力が（順不同）から受信したアレクセイ・メルニコフ、ポール・ホフマン、チャールズリンジー、ティム・キンドバーグ、フランクEllermann、ETANウェクスラー、マイケルHaardt、マイケル・アンソニーPULS II、エリオット・リア、デイブ・クロッカー、ダンハーキンズ、 Nevilブラウンリー、ジョン・クレンシン、アルフレッドHoenes、ネッドフリード、ショーン・ターナー、ピーター・サン・アンドレ、エードリアンファレル、Avshalomフーリー、ロバートスパークス、および多くの他。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ノッティンガム、M.、およびJ.モーグル、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、 "国際化リソース識別Fiers（IRI）"、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] Klensin、J.、 "アプリケーション（IDNA）のための国際化ドメイン名：定義とドキュメントフレームワーク"、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [STD68]クロッカー、D.、およびP. Overell、。
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, April 1998.
[RFC2324] Masinter、L.、 "ハイパーテキストコーヒーポット制御プロトコル（HTCPCP / 1.0）"、RFC 2324、1998年4月。
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2368]ホフマン、P.、Masinter、L.、およびJ. Zawinski、 "mailtoのURLスキーム"、RFC 2368、1998年7月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J.とY.コ、 "国際電子メールのための概要とフレームワーク"、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
マーティンDuerst（注：。、可能な限りのuウムラウトで「Duerstを」書く「D＆＃252; RST」として例えば下さいXMLとHTMLで）青山学院大学5-10-1淵野辺相模原市、神奈川県229から8558日本
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/
電話：+81 42 759 6329ファックス：+81 42 759 6495 Eメール：URI duerst@it.aoyama.ac.jp：http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
ラリーMasinter Adobe Systems Incorporated（アドビシステムズ社）345パークアベニューサンノゼ、CA 95110 USA
Phone: +1-408-536-3024 EMail: LMM@acm.org URI: http://larry.masinter.net/
電話：+ 1-408-536-3024 Eメール：LMM@acm.org URI：http://larry.masinter.net/
Jamie Zawinski DNA Lounge 375 Eleventh Street San Francisco, CA 94103 USA
ジェイミー・ザウィンスキーDNAラウンジ375第十ストリート、サンフランシスコ、CA 94103 USA
EMail: jwz@jwz.org
メールアドレス：jwz@jwz.org