ftp://ftp.nic.ad.jp/rfc/rfc2368.txt
http://www.bekkoame.ne.jp/%7Epoetlabo/WWW/rfc2368J.html
訳文に関するご意見はHTML研究室専用掲示板へどうぞ
Copyleft: 1998, 魔術幻燈
Request for Comments: 2368
Internet Mail Consortium
Updates: 1738, 1808
Category: Standards Track
P. Hoffman
L. Masinter
Xerox Corporation
J. Zawinski
Netscape Communications
July 1998
この文書は、インターネット社会のためのインターネット標準過程作法を決めるもので、改良のための議論や教示を求めます。この作法の標準化の状況と現状については、『Internet Official Protocol Standards 』(STD 1)の最新版を参照してください。この書き付けの配布は無制限です。
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.
この文書は、電子郵便宛先を設計する定型素材識別子(URL)の形式を定義するものです。これはRFC 1738『定型素材識別子』、RFC 1808『相対性定型素材識別子』を書き換える文書の一つです。RFC 1738 に由来する'mailto' URLs 構文は、 URL が追加の頭と本文項目を表すのを認めることにより、より多くの RFC822 通信文の制作を可能にするよう拡張されています。
This document defines the format of Uniform Resource Locators (URL)for designating electronic mail addresses. It is one of a suite of documents which replace RFC 1738, 'Uniform Resource Locators', and RFC 1808, 'Relative Uniform Resource Locators'. The syntax of 'mailto' URLs from RFC 1738 is extended to allow creation of more RFC822 messages by allowing the URL to express additional header and body fields.
mailto URL 用語は、個人または法人のインターネット郵便宛先を指定するのに使用されます。
その最も単純な形において、 mailto URL はインターネット郵便宛先を含みます。
The mailto URL scheme is used to designate the Internet mailing address of an individual or service. In its simplest form, a mailto URL contains an Internet mail address.
素材との交信によっては郵便宛先だけでなく通信文頭か通信文本文の指定を要求されるかもしれないので、より大きい機能性のために、 mailto URL 用語は、郵便頭項目と通信文本文の設定を可能にするよう拡張されます。
For greater functionality, because interaction with some resources may require message headers or message bodies to be specified as well as the mail address, the mailto URL scheme is extended to allow setting mail header fields and the message body.
RFC 1738 [ RFC1738 ] の構文取り決めに従うと、"mailto" URL の形は以下のとおりです。
Following the syntax conventions of RFC 1738 [ RFC1738 ] , a "mailto" URL has the form:
mailtoURL = "mailto:" [ to ] [ headers ]
to = #mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *urlc
hvalue = *urlc
"#mailbox"は RFC 822 [RFC822]で決められているとおりです。ということは、コンマで区切られた0個以上の郵便宛先〜"phrase"と"comment"構成要素を含む〜から成り立つわけです。"to" にあるURL予約文字、特に"mailbox" 構文によく出て来る括弧・コンマ・パーセント記号は、全て符号化しなくてはならないことに注意してください。
"#mailbox" is as specified in RFC 822 [RFC822]. This means that it consists of zero or more comma-separated mail addresses, possibly including "phrase" and "comment" components. Note that all URL reserved characters in "to" must be encoded: in particular,parentheses, commas, and the percent sign ("%"), which commonly occur in the "mailbox" syntax.
"hname"と"hvalue"はそれぞれ、 RFC 822 頭の名前と値の符号化形式です。"to"が伴うと、全てのURL予約文字は符号化されなくてはなりません。
"hname" and "hvalue" are encodings of an RFC 822 header name and value, respectively. As with "to", all URL reserved characters must be encoded.
特別の hname "body"は、結合している hvalue が通信文本文であることを示すものです。"body" hname は、通信文の最初の text/plain 本文部分の内容を含むことになります。mailto URL は主に、一般的な MIME 文ではなく、メーリングリストへの"subscribe"通信文など、実際に自動処理の内容となる短い通信文の生成のために用意されています。
The special hname "body" indicates that the associated hvalue is the body of the message. The "body" hname should contain the content for the first text/plain body part of the message. The mailto URL is primarily intended for generation of short text messages that are actually the content of automatic processing (such as "subscribe" messages for mailing lists), not general MIME bodies.
mailto URLsにあっては、文字"?", "=", "&" は予約済みです。
Within mailto URLs, the characters "?", "=", "&" are reserved.
"&"（アンパサンド）文字は HTML で予約済みなので、アンパサンドを含む mailto URL は、 HTML では他の文脈とは異なって綴られなければなりません。 HTML 文書に現われる mailto URL では、 "&"に代えて"&"を使わなくてはなりません。
Because the "&" (ampersand) character is reserved in HTML, any mailto URL which contains an ampersand must be spelled differently in HTML than in other contexts. A mailto URL which appears in an HTML document must use "&" instead of "&".
また、"to"と"hname"の両方で、"to"を値に持つ書き方は正当であることに注意してください。つまり、
Also note that it is legal to specify both "to" and an "hname" whose value is "to". That is,
mailto:addr1%2C%20addr2
mailto:?to=addr1%2C%20addr2
mailto:addr1?to=addr2
mailto URLs 中の8ビット文字は禁止されています。[RFC2047]で定義される MIME 符号化言葉は、頭の値としては許されるが、"body" hname の部分では許されません。
8-bit characters in mailto URLs are forbidden. MIME encoded words (as defined in [RFC2047]) are permitted in header values, but not for any part of a "body" hname.
mailto URL では、『インターネット素材』を指定します。これは、宛先に指定されたmailboxとなります。追加頭が与えられるときは、指定される素材は同じ宛先でありながら、素材を呼び出すための追加プロフィールを持ちます。電子郵便によってだけ呼び出されるインターネット素材もありますが、 mailto URL は、そのようなものを自動的に拾い上げる方法として考えられてはいません。
A mailto URL designates an "internet resource", which is the mailbox specified in the address. When additional headers 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 URL is not intended as a way of retrieving such objects automatically.
現在の慣例では、"http"用語にあるような分解された URLs が、クライアントソフトウェアと双方向サーバを走らせているホストとの間の即刻の相互作用を起こすことになっています。"mailto" URL では、そのような分解された URL が即刻の相互作用を引き起こさないので、その意味論は普通と違います。その代わりにクライアントは、既定値として様々な頭項目集合を持つ指定された宛先への通信文を生成します。利用者は通信文を編集するか、 この通信文をそのまま送るか、通信文を送らないようにすることができます。 URL 用語をいかに分解するかの操作は、 URL 仕様書に委ねられてはいません。
In current practice, resolving URLs such as those in the "http" scheme causes an immediate interaction between client software and a host running an interactive server. The "mailto" URL has unusual semantics because resolving such a URL does not cause an immediate interaction. 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 this message unedited, or choose not to send the message. The operation of how any URL scheme is resolved is not mandated by the URL specifications.
mailto URL を解釈する利用者手先は、もし頭が何かしら危険であると思われるときには、通信文を造り出さないことを選ぶべきです。またこの場合、 URL で与えられた頭の下位集合にだけ通信文を造り出すことを選ぶこともできます。Subject ・ Keywords ・ Body 頭のみが安全にして有用であると考えられます。
The user agent interpreting a mailto URL SHOULD choose not to create a message if any of the headers are considered dangerous; it may also choose to create a message with only a subset of the headers given in the URL. Only the Subject, Keywords, and Body headers are believed to be both safe and useful.
mailto URL の制作者は、"subject"と"body"以外の頭を理解する URL 解析器をあてにすることはできません。 mailto URLs をメール通信文に分解するクライアントは、"subject"と"body"頭を使って、 RFC 822 に基くメール通信文を正しく造り出せるようにすべきです。
The creator of a mailto URL cannot expect the resolver of a URL to understand more than the "subject" and "body" headers. Clients that resolve mailto URLs into mail messages should be able to correctly create RFC 822-compliant mail messages using the "subject" and "body" headers.
RFC 1738 は、URLs 中の多くの文字が符号化されることを要求しています。これは宛先か頭か通信文内容に現われるかもしれないいくつかの一般的な文字のための mailto 用語に影響を及ぼします。そのような文字の１つが、空白文字（" ",アスキー 16進法 20 番）です。上の例では、通信文本文の空白には"%20"を使っていることに注意してください。通信文本文中の改行は"%0D%0A"で符号化されることにも注意してください。
RFC 1738 requires that many characters in URLs be encoded. This affects the mailto scheme for some common characters that might appear in addresses, headers or message contents. One such character is space (" ", ASCII hex 20). Note the examples above 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".
mailto URLs を造り出している人々は、適切に書かれた URL のインタプリタがそれを読むことができるように、 URLs で使用された予約文字が符号化されるよう気を付けなければなりません。 また URLs を読むクライアントソフトウェアは、メール通信文を造り出すに先立って、受取人が理解できる形でメール通信文が現れるように、文字列を復号するよう気を付けなければなりません。これらの文字列は、通信文を利用者に示す前に復号されるべきです。
People creating mailto URLs must be careful to encode any reserved characters that are used in the URLs so that properly-written URL interpreters can read them. Also, client software that reads URLs must be careful to decode strings before creating the mail message so that the mail messages appear in a form that the recipient will understand. These strings should be decoded before showing the user the message.
mailto URL 用語は、変数の代用に必要なものを与えない範囲に限られています。従って利用者の email 宛先を含まなければならない通信文本文が、mailto URL を使って符号化されることがあってはなりません。この制限はまた、 mailto URLs が公のカギやその他可変性の情報で署名されることを妨げています。
The mailto URL scheme is limited in that it does not provide for substitution of variables. Thus, a message body that must include a user's email address can not be encoded using the mailto URL. This limitation also prevents mailto URLs that are signed with public keys and other such variable information.
通常の個人メール宛先へのURLsは：
URLs for an ordinary individual mailing address:
<mailto:chris@example.com>
subjectにファイル名を必要とするメール返送システムのURLは：
A URL for a mail response system that requires the name of the file
in the subject:
<mailto:infobot@example.com?subject=current-issue>
本文に"send"請求を必要とするメール返送システムでは：
A mail response system that requires a "send" request in the body:
<mailto:infobot@example.com?body=send%20current-issue>
似たようなURLで、2行で異なる"send"請求を持たせることができます。ここでは、"send current-issue"とその次の行に"send index"があります。
A similar URL could have two lines with different "send" requests (in this case, "send current-issue" and, on the next line, "send index".)
<mailto:infobot@example.com?body=send%20current-
issue%0D%0Asend%20index>
通信文集積を拾い読みするときには、 あなたのmailto URL の面白い使い方ができます。拾った通信文はそれぞれ、こんなmailto URLを持っているかもしれません。
An interesting use of your mailto URL is when browsing archives of messages. Each browsed message might contain a mailto URL like:
<mailto:foobar@example.com?In-Reply-
To=%3c3469A91.D10AF4C@example.com>
メーリングリストへの配信の請求は：
A request to subscribe to a mailing list:
<mailto:majordomo@example.com?body=subscribe%20bamboo-l>
一人の利用者宛で別の利用者へのCCを含むURLは：
A URL for a single user which includes a CC of another user:
<mailto:joe@example.com?cc=bob@example.com&body=hello>
同じことの別な表現では：
Another way of expressing the same thing:
<mailto:?to=joe@example.com&cc=bob@example.com&body=hello>
上にある"&"予約文字の使用に注意してください。下記の例では"?"を2度使用しているので、不正になります。
Note the use of the "&" reserved character, above. The following example, by using "?" twice, is incorrect:
<mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!
RFC 822に従えば、文字"?"や"&"、あるいは"%"でさえ、アドレス空間に見い出されて構いません。これらがURL用語での予約文字であるという事実は、問題にはなりません。それらの文字が、 mailto URLs に出て来るのは構わないのであって、ただそれらは 符号化されない形で出て来てはいけないのです。そのような場合には、標準 URL 符号化機構（"%"の後に2桁の16進法番号が続く）が使用されなければなりません。
According to RFC 822, the characters "?", "&", and even "%" may occur in addr-specs. The fact that they are reserved characters in this URL scheme is not a problem: those characters may appear in mailto URLs, they just may not appear in unencoded form. The standard URL encoding mechanisms ("%" followed by a two-digit hex number) must be used in certain cases.
宛先"gorby%kremvax@example.com"を示す1つの方法としては：
To indicate the address "gorby%kremvax@example.com" one would do:
<mailto:gorby%25kremvax@example.com>
宛先"unlikely?address@example.com"を示しつつ、別の頭を取り込むには：
To indicate the address "unlikely?address@example.com", and include another header, one would do:
<mailto:unlikely%3Faddress@example.com?blat=foop>
上に描写したとおり、"&" (アンパサンド)文字はHTMLで予約されており、必ず"&"に置き換えなくてはなりません。かくて、内部にアンパサンドを持つ複合URLは次のようになるでしょう：
As described above, the "&" (ampersand) character is reserved in HTML and must be replacded with "&". Thus, a complex URL that has internal ampersands might look like:
Click
<a href="mailto:?to=joe@xyz.com&cc=bob@xyz.com&body=hello">
mailto:?to=joe@xyz.com&cc=bob@xyz.com&body=hello</a> to
send a greeting message to <i>Joe and Bob</i>.
mailto 用語を使うと、通信文を１人の利用者から他のものに送ることができるので、数多くの防犯注意事項が挙げられます。メール通信文は、配達パスに沿って源泉と受取場所と中継地点で記録可能です。もし通信文が符号化されていなければ、それは以上の場所のいずれでも読まれてしまいます。
The mailto 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 encoded, they can also be read at any of those sites.
mailto URL はメールクライアントソフトウェアによって送られる通信文のための雛型を与えます。 URL を指定する時点では、その雛型の内容は不透明であるか、利用者が読むことは難しいかもしれません。従って郵便クライアントは決して、まず送られるはずの（mailto URL によって指定された全ての頭を含む）全通信文を完全に復号して利用者に見せ、利用者に通信文を電子郵便として送ることに同意するか訊くことなしに、mailto URL に基づく通信文を送るべきではありません。郵便クライアントはまた、利用者がこれが mailto URL の結果であるということを知らないかもしれないので、利用者が電子郵便通信文を送るところであるということをはっきりさせるようにするべきでもあります。
A mailto URL 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 URL. Thus, a mail client should never send a message based on a mailto URL without first showing the user the full message that will be sent (including all headers that were specified by the mailto URL), 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 URL.
メールクライアントは、何が送られるか利用者の目に完全にさらさずには、決してどんなものも送るべきではありません。通信文目的地だけでなく、どんな頭も明示すべきです。認識されない頭やメールクライアントが通常送る値と一致していない値のある頭は特に疑ってかかるべきです。ルーティング(From・Bcc・Apparently-To など)に関係があることとしては、おそらくMIME 頭(MIME- Version, Content-*)が不適切なのではないでしょうか。
A mail client should never send anything without complete disclosure to the user of what is will be sent; it should disclose not only the message destination, but also any headers. Unrecognized headers, or headers with values inconsistent with those the mail client would normally send should be especially suspect. MIME headers (MIME- Version, Content-*) are most likely inappropriate, as are those relating to routing (From, Bcc, Apparently-To, etc.)
URL から生成された通信文を含めると、頭によってはどうしても安全でないものがあることに注意してください。例えば、"From:"や"Bcc:"などのような頭は、決して URL から解釈されるべきではありません。概して、 URL から解釈される頭が少なくなるほど、送信エージェントが安全でない通信文を造り出すことが減るようです。
Note that some headers are inherently unsafe to include in a message generated from a URL. For example, headers such as "From:", "Bcc:", and so on, should never be interpreted from a URL. In general, the fewer headers interpreted from the URL, the less likely it is that a sending agent will create an unsafe message.
承認されていないメールを送ることにまつわる問題の例
Examples of problems with sending unapproved mail include:
mailto URLsを解釈するプログラムは、SMTP "From"宛先が定められていてそれが正しいことを保証すべきです。
Programs that interpret mailto URLs should ensure that the SMTP "From" address is set and correct.
この文書は、mailto: URI用語の定義を変更するものです。URI用語の登録には、従前のRFC 1738ではなくこの文書を参照すべきです。
This document changes the definition of the mailto: URI scheme; any registry of URI schemes should refer to this document rather than its predecessor, RFC 1738.
RFC 1738は、頭のない単純な'mailto'、完全なmailboxではなく宛先指定のみの定義にとどまっていました。しかしながら、利用法と実装上の必要から、より多くの頭項目を含む拡張語法の発達が促されました。
RFC 1738 defined only a simple 'mailto' with no headers, just an addr-spec (not a full mailbox.) However, required usage and implementation has led to the development of an extended syntax that included more header fields.
この文書はRFC 1738 と RFC 1808に由来するものであり、この2つの仕様書にある謝辞はそのままです。
This document was derived from RFC 1738 and RFC 1808 [RFC1808]; the acknowledgments from those specifications still applies.
以下の皆様には、この書き付けに貢献あるいはmailtoと似た概念を持ち寄り議論していただきました。
The following people contributed to this memo or had and discussed similar ideas for mailto.
この文書とその翻訳については、写しを取ったり、配って回ったりしてかまいません。これらについて批評もしくは説明したり、あるいはその普及を助ける等の派生的作業については、上記の著作権表示とこの文章を含むものはすべて、その全部または一部を、一切の制約なしに、用意し、謄写し、出版・配布してかまいません。
しかしながら、この文書自体は、いかなる方法にせよ変更してはなりません。インターネット標準化過程において定義されている著作権のための手続きに従ってインターネット標準を開発するために必要とされる、あるいは英語以外の言語に翻訳する必要があるという場合を除き、著作権表示あるいはインターネット協会の参考文献あるいは他のインターネット組織への参照を抹消するなどの改竄を禁じます。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
以上に認められた条件は永続的なものであり、インターネット協会及びその継承者、又はその受託者が、これを撤回することはありません。
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
この文書とここに含まれる情報は、「AS IS（あるがまま）」の原則に則って提供され、インターネット協会と IETF は、明示されているか否かに関わらず、内容について保証しません。
無保証の範囲には、ここにある情報の使用がいかなる権利も侵害しないという保証や市場性あるいは特定の目的に対する適合性についてのあらゆる暗黙の保証をはじめとするすべての保証が含まれます。
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.