RFC2368 日本語訳
2368 The mailto URL scheme. P. Hoffman, L. Masinter, J. Zawinski. July 1998. (Format: TXT=16502 bytes) (Updates RFC1738, RFC1808) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Hoffman
Request for Comments: 2368 Internet Mail Consortium
Updates: 1738, 1808 L. Masinter
Category: Standards Track Xerox Corporation
J. Zawinski
Netscape Communications
July 1998
コメントを求めるワーキンググループP.ホフマン要求をネットワークでつないでください: 2368のインターネットメール共同体アップデート: 1738、1808L.Masinterカテゴリ: 標準化過程ゼロックス社のJ.Zawinskiネットスケープ・コミュニケーションズ1998年7月
The mailto URL scheme
mailto URL計画
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
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 RFC 822 messages by allowing the URL to express additional header and body fields.
このドキュメントは、電子メールアドレスを指定するためにUniform Resource Locator(URL)の書式を定義します。 それはRFC1738、'Uniform Resource Locator'、およびRFC1808、'相対的なUniform Resource Locator'を取り替えるひとそろいのドキュメントの1つです。 RFC1738からの'mailto'URLの構文は、URLが追加ヘッダーを急送するのを許容するのによる822のメッセージをより多くのRFCの創造に許容して、ボディーに分野を許容するために広げられます。
1. Introduction
1. 序論
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計画は、個人の、または、サービスの郵送先住所にインターネットを指定するのに使用されます。 最も簡単なフォームでは、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.
より大きい機能性に関しては、いくつかのリソースとの相互作用が、メッセージヘッダーかメッセージ本体が郵便の宛先と同様に指定されるのを必要とするかもしれないので、mailto URL計画はメールヘッダ分野とメッセージ本体を設定するのを許容するために広げられます。
2. Syntax of a mailto URL
2. 1つのmailto URLの構文
Following the syntax conventions of RFC 1738 [RFC1738], a "mailto" URL has the form:
"mailto"URLには、RFC1738[RFC1738]の構文コンベンションに続いて、フォームがあります:
Hoffman, et. al. Standards Track [Page 1] RFC 2368 The mailto URL scheme July 1998
etホフマン、アル。 規格Track[1ページ]RFC2368 mailto URL計画1998年7月
mailtoURL = "mailto:" [ to ] [ headers ]
to = #mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *urlc
hvalue = *urlc
mailtoURL=は「以下をmailtoします」。 []、“?"#メールボックスヘッダー=ヘッダー*(“&"ヘッダー)ヘッダー=hnameと等しい[ヘッダー]はhvalue hname=*urlc hvalue=*urlcと「等しいです」。
"#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.
「#メールボックス」がRFC822[RFC822]で指定されるようにあります。 これは、それがことによると「句」と「コメント」コンポーネントを含むゼロかコンマで、より切り離された郵便の宛先から成ることを意味します。 すべてのURLが“to"でキャラクタを予約したというメモをコード化しなければなりません: 特に、括弧、コンマ、およびパーセントは(「%」)にサインします。(一般的に、それは、「メールボックス」構文で起こります)。
"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"と"hvalue"はそれぞれRFC822ヘッダー名と価値のencodingsです。 “to"なら、すべてのURL控え目なキャラクタをコード化しなければなりません。
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.
特別なhname「ボディー」は、関連hvalueがメッセージ欄であることを示します。 「ボディー」hnameはメッセージの最初のテキスト/平らな身体の部分のための内容を含むはずです。 mailto URLは一般的なMIME本体ではなく、実際に自動処理の内容である短いテキスト・メッセージ(メーリングリストへのメッセージを「申し込む」)の世代のために主として意図します。
Within mailto URLs, the characters "?", "=", "&" are reserved.
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 "&".
“&"(アンパーサンド)キャラクタがHTMLで予約されるので、他の文脈よりアンパーサンドを含むどんなmailto URLもHTMLで異なってつづらなければなりません。 HTMLドキュメントに現れるmailto URLは“&"の代わりに"&"を使用しなければなりません。
Also note that it is legal to specify both "to" and an "hname" whose value is "to". That is,
また、“to"と値が“to"である"hname"の両方を指定するのが法的であることに注意してください。 That is,
mailto:addr1%2C%20addr2
mailto: addr1%2Cの%20addr2
is equivalent to
相当
mailto:?to=addr1%2C%20addr2
=addr1%2Cの%20addr2に以下をmailtoします。
is equivalent to
相当
mailto:addr1?to=addr2
mailto: addr2と等しいaddr1?
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の8ビットのキャラクタは禁じられます。 ヘッダー値で受入れられますが、MIMEのコード化された単語([RFC2047]で定義されるように)は「ボディー」hnameのどんな部分にも受入れられるというわけではありません。
Hoffman, et. al. Standards Track [Page 2] RFC 2368 The mailto URL scheme July 1998
etホフマン、アル。 規格Track[2ページ]RFC2368 mailto URL計画1998年7月
3. Semantics and operations
3. 意味論と操作
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.
mailto URLは「インターネットリソース」を指定します。(それは、アドレスで指定されたメールボックスです)。 追加ヘッダーを供給するとき、同じアドレスですが、指定されたリソースはリソースにアクセスするための追加プロフィールで供給します。 電子メールを通してアクセスできるだけであるインターネット資料がある間、mailto 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.
実際には、現在の"http"計画におけるそれらなどのURLを決議すると、即座の相互作用は、対話的なサーバを走らせながら、クライアントソフトウェアとホストの間で引き起こされます。そのようなURLを決議するのが即座の相互作用を引き起こさないので、"mailto"URLには、珍しい意味論があります。 代わりに、クライアントはデフォルトとして設定された様々なヘッダーフィールドで指定されたアドレスにメッセージを作成します。 ユーザがメッセージを編集できて、このメッセージを送ってください、どんな編集、もメッセージを送らないのを選ばないでください。 どんなURL計画もどう決議されているかに関する操作はURL仕様で強制されません。
4. Unsafe headers
4. 危険なヘッダー
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 SHOULDを解釈するユーザエージェントは、ヘッダーのどれかが危険であると考えられるならメッセージを作成しないのを選びます。 また、それは、URLでヘッダーの部分集合だけを与えていてメッセージを作成するのを選ぶかもしれません。 安全であって、かつSubject、Keywords、およびBodyヘッダーだけが役に立つと信じられています。
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.
1つのmailto URLの創造者は、1つのURLのレゾルバが「対象」と「ボディー」ヘッダーより分かることを期待できません。 mailto URLにメール・メッセージに変えるクライアントは、「対象」と「ボディー」ヘッダーを使用することで正しくRFCの822対応することのメール・メッセージを作成できるべきです。
5. Encoding
5. コード化
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".
RFC1738は、URLの多くのキャラクタがコード化されるのを必要とします。 これはアドレス、ヘッダーまたはメッセージ内容に載るかもしれない何人かの一般的なキャラクタのmailto計画に影響します。 あるそのようなキャラクタがスペースである、(「「ASCII十六進法20)、」 メッセージ本体のスペースへの%20インチの「その使用を超えて例に注意してください。」 「また、」 %0D%0Aと共にメッセージのボディーのラインブレイクをコード化しなければならないことに注意してください。」
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
mailto URLを作成する人々は適切に書かれたURLインタプリタが彼らを読むことができるようにURLで使用されるどんな控え目なキャラクタもコード化するのに慎重であるに違いありません。 また、URLを読むクライアントソフトウェアもしたがって、メール・メッセージを作成する前にストリングを解読するのに慎重であるに違いありません。
Hoffman, et. al. Standards Track [Page 3] RFC 2368 The mailto URL scheme July 1998
etホフマン、アル。 規格Track[3ページ]RFC2368 mailto URL計画1998年7月
that the mail messages appear in a form that the recipient will understand. These strings should be decoded before showing the user the message.
メール・メッセージは受取人が理解しているフォームに載っています。 メッセージをユーザに示している前に、これらのストリングは解読されるべきです。
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.
変数の代替に備えないので、mailto URL計画は限られています。 したがって、mailto URLを使用することでユーザのEメールアドレスを含まなければならないメッセージ本体はコード化できません。 また、この制限は公開鍵を契約されるmailto URLと他のそのような可変情報を防ぎます。
6. Examples
6. 例
URLs for an ordinary individual mailing address:
普通の個々の郵送のためのURLは以下を記述します。
<mailto:chris@example.com>
<mailto: chris@example.com 、gt。
A URL for a mail response system that requires the name of the file in the subject:
対象でファイルの名前を必要とするメール応答システムのためのURL:
<mailto:infobot@example.com?subject=current-issue>
<mailto: infobot@example.com?subject は最新号>と等しいです。
A mail response system that requires a "send" request in the body:
ボディーで「発信してください」という要求を必要とするメール応答システム:
<mailto:infobot@example.com?body=send%20current-issue>
<mailto: infobot@example.com?body =は20current-issue>を%に送ります。
A similar URL could have two lines with different "send" requests (in this case, "send current-issue" and, on the next line, "send index".)
同様のURLは、異なるのがある2つの線が要求を「送ること」を持っているかもしれません。(この場合、「最新号を送ってください」と次の線では、「インデックスを送ってください」。)
<mailto:infobot@example.com?body=send%20current-
issue%0D%0Asend%20index>
<mailto: infobot@example.com?body =は20current-問題%0D%0Asend%20index>を%に送ります。
An interesting use of your mailto URL is when browsing archives of messages. Each browsed message might contain a mailto URL like:
メッセージのアーカイブをブラウズするとき、あなたのmailto URLのおもしろい使用があります。 それぞれのブラウズされたメッセージは以下のようにmailto URLを含むかもしれません。
<mailto:foobar@example.com?In-Reply-
To=%3c3469A91.D10AF4C@example.com>
<mailto: =%3c3469A91.D10AF4C@example.com>への foobar@example.com?In-Reply-
A request to subscribe to a mailing list:
メーリングリストに加入するという要求:
<mailto:majordomo@example.com?body=subscribe%20bamboo-l>
<mailto: majordomo@example.com?body =は%20bamboo-l>を申し込みます。
A URL for a single user which includes a CC of another user:
シングルユーザーのための別のユーザのCCを含んでいるURL:
<mailto:joe@example.com?cc=bob@example.com&body=hello>
<mailto: joe@example.com?cc はこんにちは、ボブ@example.comとボディー=>と等しいです。
Another way of expressing the same thing:
同じことを言い表す別の方法:
<mailto:?to=joe@example.com&cc=bob@example.com&body=hello>
<は以下をmailtoします--こんにちは、 joe@example.com&cc =ボブ@example.comとボディー=>と等しいように
Hoffman, et. al. Standards Track [Page 4] RFC 2368 The mailto URL scheme July 1998
etホフマン、アル。 規格Track[4ページ]RFC2368 mailto URL計画1998年7月
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!
<mailto: joe@example.com?cc はボブ@example.comと等しいです--こんにちは、ボディー=>。 間違う!
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.
RFC822によると、キャラクタ“?"、“&"、および「%」さえaddr-仕様に現れるかもしれません。 それらがこのURL計画で控え目なキャラクタであるという事実は問題ではありません: それらのキャラクタはmailto URLに現れるかもしれなくて、それらは暗号化されていないフォームにただ載らないかもしれません。 ある場合には、メカニズム(2ケタの十六進法番号があとに続いた「%」)をコード化する標準のURLを使用しなければなりません。
To indicate the address "gorby%kremvax@example.com" one would do:
アドレスを示すために、" gorby%kremvax@example.com "1は以下をするでしょう。
<mailto:gorby%25kremvax@example.com>
<mailto: gorby%25kremvax@example.com 、gt。
To indicate the address "unlikely?address@example.com", and include another header, one would do:
アドレス" unlikely?address@example.com "を示して、別のヘッダーを含むように、1つは以下をするでしょう。
<mailto:unlikely%3Faddress@example.com?blat=foop>
<mailto: unlikely%3Faddress@example.com?blat がfoopと等しい、gt。
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:
上で説明されるように、“&"(アンパーサンド)キャラクタをHTMLで予約されて、"&"でreplacdedしなければなりません。 したがって、内部のアンパーサンドを持っている複雑なURLに似るかもしれません:
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>.
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>.
7. Security Considerations
7. セキュリティ問題
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計画は、1人のユーザから別のものにメッセージを送るのに使用できて、その結果、多くの安全上の配慮を導入できます。 送信側サイト、被移植部、および配送経路に沿った仲介者サイトにメール・メッセージを登録できます。 また、メッセージがコード化されないなら、それらのサイトのいずれでもそれらを読むことができます。
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.
mailto URLはメールクライアントソフトウェアで送ることができるメッセージのためにテンプレートを与えます。 そのテンプレートのコンテンツは、不透明であるか、またはURLを指定する時点でユーザで読むのが難しいかもしれません。 したがって、メールクライアントは最初に送られる完全なメッセージをユーザに示していなくてmailto URLに基づくメッセージを決して送るべきではありません(mailto URLによって指定されたすべてのヘッダーを含んでいて)、完全に解読されて、電子メールとしてメッセージを送るための許可をユーザに求めて。 また、メールクライアントは、ユーザが電子メールメッセージを送ろうとしていると断言するべきです、ユーザがこれが1つのmailto URLの結果であることを意識していないかもしれないので。
Hoffman, et. al. Standards Track [Page 5] RFC 2368 The mailto URL scheme July 1998
etホフマン、アル。 規格Track[5ページ]RFC2368 mailto URL計画1998年7月
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.)
クライアントが何に関するユーザへの完全な公開なしで何も決して送るべきでないメールは送るということです。 それはメッセージの目的地だけではなく、どんなヘッダーも明らかにするべきです。 認識されていないヘッダー、または通常、メールクライアントが送るものに矛盾した値があるヘッダーが特にそうであるべきです。疑います。 MIMEヘッダー(MIMEバージョン、Content-*)はたぶんルーティングに関連するもののように不適当です。(Bcc、Apparently、-、など)
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.
何人かのヘッダーはURLから発生するメッセージに含んでいるのが本来危険であることに注意してください。 例えば、「From:」などのヘッダー(「Bcc:」など)は、URLから決して解釈されるべきではありません。 送付エージェントは、一般に、より少ないヘッダーがURLから解釈したのを危険なメッセージをより作成しそうにないでしょう。
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 on 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 URLs should ensure that the SMTP "From" address is set and correct.
mailto URLを解釈するプログラムはSMTP “From"アドレスが確実にセットで正しくなるようにするはずです。
8. IANA Considerations
8. IANA問題
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.
このドキュメントはmailtoの定義を変えます: URI計画。 URI計画のどんな登録も前任者、RFC1738よりむしろこのドキュメントを参照するべきです。
Hoffman, et. al. Standards Track [Page 6] RFC 2368 The mailto URL scheme July 1998
etホフマン、アル。 規格Track[6ページ]RFC2368 mailto URL計画1998年7月
9. References
9. 参照
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, Editors,
"Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] バーナーズ・リーとT.とMasinter、L.とM.McCahill、エディターズ、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
1808, June 1995.
[RFC1808] フィールディング、R.、「相対的なUniform Resource Locator」、RFC1808、1995年6月。
[RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、「パートThreeをまねてください」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
Hoffman, et. al. Standards Track [Page 7] RFC 2368 The mailto URL scheme July 1998
etホフマン、アル。 規格Track[7ページ]RFC2368 mailto URL計画1998年7月
A. Change from RFC 1738
A。 RFC1738から、変化してください。
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.
RFC1738はヘッダーなしで簡単な'mailto'だけ、を定義して、まさしくaddr-仕様は(完全なメールボックスでない)です。 しかしながら、必要な用法と実現は、より多くのヘッダーフィールドを含んでいた拡張構文の開発につながりました。
B. Acknowledgments
B。 承認
This document was derived from RFC 1738 and RFC 1808 [RFC1808]; the acknowledgments from those specifications still applies.
RFC1738とRFC1808[RFC1808]からこのドキュメントを得ました。 それらの仕様からの承認はまだ適用されています。
The following people contributed to this memo or had and discussed similar ideas for mailto.
以下の人々は、mailtoのために同様の考えをこのメモに貢献したか、持って、または議論しました。
Harald Alvestrand Bryan Costales Steve Dorner Al Gilman Mark Joseph Laurence Lundblade Keith Moore Jacob Palme Michael Patton
ハラルド・Alvestrandブライアン・Costalesスティーブ・デルナー・アル・ギルマン・マークジョゼフ・ローレンス・Lundbladeキース・ムーア・ヤコブ・パルメ・マイケル・パットン
Hoffman, et. al. Standards Track [Page 8] RFC 2368 The mailto URL scheme July 1998
etホフマン、アル。 規格Track[8ページ]RFC2368 mailto URL計画1998年7月
C. Author Contact Information
C。 作者問い合わせ先
Paul E. Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールE.ホフマンインターネットメール共同体127セグレ・Placeカリフォルニア95060サンタクルス(米国)
EMail: phoffman@imc.org
メール: phoffman@imc.org
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94304 USA
ラリーMasinterゼロックス社3333のコヨーテヒル・Roadカリフォルニア94304パロアルト(米国)
EMail: masinter@parc.xerox.com
メール: masinter@parc.xerox.com
Jamie Zawinski Netscape Communications Corp. 501 East Middlefield Road Mountain View, CA 94043 USA
東Middlefield RoadジェイミーZawinskiネットスケープ・コミュニケーションズ501カリフォルニア94043マウンテンビュー(米国)
EMail: jwz@netscape.com
メール: jwz@netscape.com
Hoffman, et. al. Standards Track [Page 9] RFC 2368 The mailto URL scheme July 1998
etホフマン、アル。 規格Track[9ページ]RFC2368 mailto URL計画1998年7月
D. Full Copyright Statement
D。 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Hoffman, et. al. Standards Track [Page 10]
etホフマン、アル。 標準化過程[10ページ]
一覧
スポンサーリンク
