RFC8058和訳ーList-Unsubscribeのためのワンクリック機能の仕様
List-Unsubscribeメールヘッダーフィールドのための ワンクリック機能をシグナリングする方法について記載されている仕様書を翻訳する。
Googleのガイドライン変更でList-Unsubscribeが要件に追加されたけど、そのへんのRFCの日本語訳がなさすぎるので作った。
RFC2369の和訳はこちら。
原文はこちらで確認。
翻訳はDeepLにぶっ込んだもの。
Signaling One-Click Functionality for List Email Headers
リストメールヘッダーのワンクリックシグナリング機能
Abstract
要旨
This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.
このドキュメントでは、List-Unsubscribeメールヘッダーフィールドのための ワンクリック機能をシグナリングする方法について記述する。 この必要性は、メールソフトウェアが時々メールヘッダーフィールドの URL を取得し、それによって List-Unsubscribe ヘッダーフィールドの場合に誤って購読解除をトリガーしてしまうという現 実から生じる。
Status of This Memo
本メモの位置づけ
This is an Internet Standards Track document.
これはInternet Standards Trackの文書である。
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 7841.
本文書は、インターネット技術タスクフォース（IETF）の成果物である。 IETFコミュニティの総意を表している。 パブリックレビューを受け、インターネットエンジニアリン ググループ(IESG)によって発行が承認されている。 インターネット標準に関する詳しい情報は、RFC 7841のセクション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/rfc8058.
この文書の現在の状況、正誤表、フィードバック方法に関する情報は、http://www.rfc-editor.org/info/rfc8058。
Copyright Notice
著作権について
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. 無断複写・転載を禁じます。
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トラストのIETF文書に 関する法的規定(http://trustee.ietf.org/license-info)に従うものとする。 これらの文書には、この文書に関するあなたの権利と制限が記述されていますので、注意深く確認してください。 この文書から抽出されたコードコンポーネントは、トラスト法的条項の第4.e項 に記述されているように、簡易BSDライセンスのテキストを含まなければな らず、簡易BSDライセンスに記述されているように、保証なしで提供されます。
Table of Contents
目次
1.Introduction and Motivation
1.はじめにと動機
A List-Unsubscribe email header field [RFC2369] can contain HTTPS [RFC7230] URIs. In that header field, the HTTPS URI is intended to unsubscribe the recipient of the message from the list. But anti- spam software often fetches all resources in mail header fields automatically, without any action by the user, and there is no mechanical way for a sender to tell whether a request was made automatically by anti-spam software or manually requested by a user. To prevent accidental unsubscriptions, senders return landing pages with a confirmation step to finish the unsubscribe request. A live user would recognize and act on this confirmation step, but an automated system would not. That makes the unsubscription process more complex than a single click.
List-Unsubscribeメールヘッダーフィールド(参考文献[RFC2369])はHTTPS URI (参考文献[RFC7230])を含むことができる。 このヘッダーフィールドでは、HTTPS URIはメッセージの受信者をリストから退会させることを意図している。 しかし、アンチスパムソフトウェアは多くの場合、ユーザーによる 操作なしに、メールヘッダーフィールドのすべてのリソースを自動的に取 り出してしまうので、送信者がアンチスパムソフトウェアによって自動的に 要求されたのか、それともユーザーによって手動で要求されたのかを見分ける 機械的な方法はない。偶発的な配信停止を防ぐために、送信者は配信停止リクエストを完了するための確認ステップを含むランディングページを返します。 生身のユーザーであれば、この確認ステップを認識して行動するでしょうが、自動化されたシステムではそうはいきません。 そのため、配信停止プロセスはシングルクリックよりも複雑になっています。
Operators of broadcast marketing lists tend to be primarily concerned about deliverability of their mail: whether the mail is delivered to the recipients and how the messages are presented, e.g., whether in the primary inbox or in a junk folder. Many mail systems allow recipients to report mail as spam or junk, and mail streams from senders whose mail is often reported as junk tend to have poor deliverability. Hence, the mailers want to make it as easy as possible for recipients to unsubscribe; if an unsubscription process is too difficult, the recipient's alternative is to report mail from the sender as junk until the mail no longer appears in the recipient's inbox.
ブロードキャスト・マーケティング・リストの運営者は、メールが受信者に届くかどうか、また、メッセージがどのように表示されるか（たとえば、受信トレイに入るか、迷惑メールフォルダに入るか）、といったメールの配信可能性を主に気にする傾向があります。 多くのメールシステムでは、受信者がメールをスパムや迷惑メールとして報告できるようになっており、迷惑メールとして報告されることの多い送信者からのメールストリームは、配送性が悪い傾向がある。 従って、メーラーは受信者ができるだけ簡単に購読解除できるようにしたい。購読解除のプロセスが難しすぎる場合、受信者の選択肢は、メールが受信者の受信箱に表示されなくなるまで、送信者からのメールを迷惑メールとして報告することである。
Operators of recipient mail systems are aware that their users do not make a clear distinction between unsubscription and junk. In some cases, they allow trustworthy mailers to request notification when their mail is reported as junk so they can unsubscribe the recipient, but the process of identifying trustworthy mailers and notifying them does not scale well to large numbers of small mailers. This specification provides a way for recipient systems to notify the mailer automatically, using only information within the mail message, and without prearrangement. Some recipient systems might wish to send an unsubscription notice to mailers whenever a user reports a message as junk, or they might offer the user the option of reporting and unsubscribing.
受信者メールシステムの運営者は、ユーザーが配信停止と迷惑メールを明確に区別していないことを認識している。 場合によっては、信頼できるメーラーが、そのメールが迷惑メールとして報告されたときに通知を要求し、受信者の購読を解除できるようにしているが、信頼できるメーラーを識別して通知するプロセスは、多数の小規模なメーラーにはうまく拡張できない。 この仕様は、受信者システムが、メールメッセージ内の情報だけを使って、事前準備なしに自動的にメーラーに通知する方法を提供する。 受信者システムによっては、ユーザーがメッセージを迷惑メールとして報告するたびにメーラーに配信停止通知を送りたいかもしれないし、ユーザーに報告と配信停止のオプションを提供するかもしれない。
If a mail recipient is unsubscribing manually and the unsubscription process requires confirmation, the resulting web page is presented to the recipient who can then click the appropriate button. But when the unsubscribe action is combined with a user junk report, there is no direct user interaction with the mailer's website. Similarly, if a mail system automatically unsubscribes recipient mailboxes that have been closed or abandoned, there can be no interaction with a user who is not present. In those cases, the unsubscription process has to work without manual intervention, and in particular without requiring that software attempt to interpret the contents of a confirmation page.
メール受信者が手動で配信停止を行い、配信停止処理に確認が必要な場合、結果としてウェブページが受信者に表示され、受信者は適切なボタンをクリックすることができます。 しかし、購読解除のアクションがユーザーの迷惑メール報告と組み合わされている場合、メーラーのウェブサイトとユーザーとの直接的なやりとりはありません。 同様に、メールシステムが、閉じられたり放棄された受信者のメールボックスを自動的に購読解除する場合、その場にいないユーザーとのインタラクションはありえません。 このような場合、配信停止処理は手作業で行われることなく、特にソフトウェアが確認ページの内容を解釈しようとすることなく行われなければならない。
This document addresses this part of the problem, with an HTTPS POST action for mail receivers. Mail senders can distinguish this action from other unsubscribe requests and handle it as a one-click unsubscription without manual intervention by the mail recipient.
この文書では、メール受信者のための HTTPS POST アクションで、この問題の一部に対処している。 メール送信者は、このアクションを他の配信停止リクエストと区別し、メール受信者が手動で操作することなく、ワンクリックで配信停止として処理することができます。
This document has two goals:
この文書には2つの目的がある：
o Allow email senders to signal that a List-Unsubscribe header field [RFC2369] has one-click functionality.
o メール送信者が、List-Unsubscribeヘッダーフィールド[RFC2369]にワンクリック 機能があることをシグナリングできるようにする。
o Allow MUA (Mail User Agent) users to unsubscribe from mailing lists in a familiar environment and without leaving the MUA context. A receiving system can process an unsubscription request in the background without further interaction and know that it can be fully processed by the mail sender's system.
o MUA (Mail User Agent)のユーザーが、MUAのコンテキストを離れることなく、使い慣れた環境でメーリングリストの購読を解除できるようにする。 受信システムは、それ以上のインタラクションなしにバックグラウンドで配信停止要求を処理し、それがメール送信者のシステムで完全に処理できることを知ることができる。
2.Definitions
2.定義
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] when written in all capital letters.
本文書のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、 および "OPTIONAL "は、すべて大文字で書かれている場合、[RFC2119]に 記述されているように解釈される。
3.Implementation
3.実施
3.1. Mail Senders
3.1. メール送信者
A mail sender that wishes to enable one-click unsubscriptions places one List-Unsubscribe header field and one List-Unsubscribe-Post header field in the message. The List-Unsubscribe header field MUST contain one HTTPS URI. It MAY contain other non-HTTP/S URIs such as MAILTO:. The List-Unsubscribe-Post header MUST contain the single key/value pair "List-Unsubscribe=One-Click". As described below, the message MUST have a valid DomainKeys Identified Mail (DKIM) signature that covers at least the List-Unsubscribe and List-Unsubscribe-Post headers.
ワンクリックアンサブスクリプションを有効にすることを望むメール送信者は、メッ セージ中に一つの List-Unsubscribe ヘッダーフィールドと一つの List-Unsubscribe-Post ヘッダー フィールドを置く。 List-Unsubscribe ヘッダーは一つの HTTPS URI を含まなければならない[MUST]。 MAILTO:のような他の非HTTP/S URIを含んでもよい[MAY]。 List-Unsubscribe-Postヘッダーは一つのkey/valueペア「List-Unsubscribe=One-Click」を 含まなければならない[MUST]。 以下に述べるように、メッセージは少なくともList-Unsubscribeヘッダーと List-Unsubscribe-Postヘッダーをカバーする有効なDKIM(DomainKeys Identified Mail)署名を持たなければならない[MUST]。
The URI in the List-Unsubscribe header MUST contain enough information to identify the mail recipient and the list from which the recipient is to be removed, so that the unsubscription process can complete automatically. Since there is no provision for extra POST arguments, any information about the message or recipient is encoded in the URI. In particular, one-click has no way to ask the user what address or from what list the user wishes to unsubscribe.
List-UnsubscribeヘッダーのURIは、メール受信者とその受信者が削除され るリストを特定するために十分な情報を含まなければならない[MUST]。 余分な POST 引数の規定はないので、メッセージや受信者に関するいかなる情報も URI にエンコードされる。 特に、one-clickは、ユーザがどのアドレスから、またはどのリストから購読停止を希望しているかをユーザに問い合わせる手段を持っていません。
The POST request MUST NOT include cookies, HTTP authorization, or any other context information. The unsubscribe operation is logically unrelated to any previous web activity, and context information could inappropriately link the unsubscribe to previous activity.
POST リクエストはクッキー、HTTP 認証、その他のコンテキスト情報を含んではならない(MUST NOT)。 登録解除の操作は論理的に以前のウェブアクティビティとは無関係であり、コンテキスト情報は登録解除を以前のアクティビティと不適切に結びつける可能性がある。
The URI SHOULD include an opaque identifier or another hard-to-forge component in addition to, or instead of, the plaintext names of the list and the subscriber. The server handling the unsubscription SHOULD verify that the opaque or hard-to-forge component is valid. This will deter attacks in which a malicious party sends spam with List-Unsubscribe links for a victim list, with the intention of causing list unsubscriptions from the victim list as a side effect of users reporting the spam, or where the attacker does POSTs directly to the mail sender's unsubscription server.
URIは、リストとサブスクライバーのプレーンテキストの名前に加え て、あるいはその代わりに、不透明な識別子または他の生成困難なコン ポーネントを含むべきである[SHOULD]。 登録解除を処理するサーバーは、不透明なコンポーネントまたは偽造困難な コンポーネントが有効であることを検証するべきである[SHOULD]。これは、悪意のあるパーティが、スパムを報告するユーザの副次的な効果として犠牲となるリストの購読解除を引き起こすことを意図して、犠牲となるリストのための List-Unsubscribe リンクを持つスパムを送信する攻撃や、攻撃者がメール送信者の購読解除サーバに直接 POST を行う攻撃を抑止するでしょう。
The mail sender needs to provide the infrastructure to handle POST requests to the specified URI in the List-Unsubscribe header, and to handle the unsubscribe requests that its mail will provoke.
メール送信者は、List-Unsubscribe ヘッダで指定された URI への POST リクエストを処理し、そのメールが引き起こす配信停止リクエストを処理するためのインフラストラクチャを提供する必要がある。
The mail sender MUST NOT return an HTTPS redirect, since redirected POST actions have historically not worked reliably, and many browsers have turned redirected HTTP POSTs into GETs.
メール送信者はHTTPSリダイレクトを返してはならない(MUST NOT)。なぜなら、リダイレクトされたPOSTアクションは歴史的に確実に動作しておらず、多くのブラウザはリダイレクトされたHTTP POSTをGETに変えてしまっているからである。
This document does not update [RFC2369], so the usage of List- Unsubscribe URIs other than for one-click remains unchanged.
本文書は[RFC2369]を更新しないので、ワンクリック以外のList- Unsubscribe URIの用法は変わらない。
3.2. Mail Receivers
3.2. メールレシーバー
A mail receiver can do a one-click unsubscription by performing an HTTPS POST to the HTTPS URI in the List-Unsubscribe header. It sends the key/value pair in the List-Unsubscribe-Post header as the request body.
メール受信者は、List-Unsubscribe ヘッダーにある HTTPS URI に対して HTTPS POST を実行することで、ワンクリックで購読を解除することができる。 それはリクエストボディとして List-Unsubscribe-Postヘッダーのkey/valueペアを送る。
The POST content SHOULD be sent as 'multipart/form-data' [RFC7578] or MAY be sent as 'application/x-www-form-urlencoded'. These encodings are the ones used by web browsers when sending forms. The target of the POST action is the same as the one in the GET action for a manual unsubscription, so this is intended to allow the same server code to handle both.
POSTのコンテンツは「multipart/form-data」[RFC7578]として送られるべき である[SHOULD]が、「application/x-www-form-urlencoded」として送 られてもよい[MAY]。 これらのエンコーディングは、フォームを送信するときにウェブブラウザが使用するものです。 POSTアクションのターゲットは手動による購読解除のGETアクションのターゲットと同じであるため、同じサーバーコードで両方を処理できるようにすることが意図されている。
The mail receiver MUST NOT perform a POST on the HTTPS URI without user consent. When and how the user consent is obtained is not part of this specification.
メール受信者は、ユーザーの同意なしにHTTPS URI上でPOSTを行ってはならない[MUST NOT]。 ユーザーの同意をいつどのように得るかは、この仕様の一部ではない。
4.Additional Requirements
4.追加要件
The message needs at least one valid authentication identifier. In this version of the specification, the only supported identifier type is DKIM [RFC6376]. Hence, senders MUST apply at least one valid DKIM signature to the message.
メッセージは、少なくとも1つの有効な認証識別子を必要とする。 このバージョンの仕様では、サポートされている識別子のタイプはDKIM [RFC6376]のみである。 したがって、送信者はメッセージに少なくとも一つの有効な DKIM署名を適用しなければならない[MUST]。
The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.
List-UnsubscribeとList-Unsubscribe-Postヘッダーは署名でカバーされ、 有効なDKIM-Signatureヘッダーフィールドの「h=」タグに含まれなければ ならない[MUST]。
If the message does not have the required DKIM signature, the mail receiver SHOULD NOT offer a one-click unsubscribe for that message.
メッセージが要求されたDKIM署名を持たない場合、メール受信者はそのメッセー ジに対してワンクリックで購読解除を提供すべきではない[SHOULD NOT]。
5.Header Syntax
5.ヘッダー構文
The following ABNF imports fields, WSP, and CRLF from [RFC5322].
以下のABNFはfields、WSP、CRLFを[RFC5322]からインポートしている。
fields =/ list-unsubscribe-post
list-unsubscribe-post = "List-Unsubscribe-Post:" 0*1WSP postarg CRLF
postarg = "List-Unsubscribe=One-Click"6.Security Considerations
6.セキュリティに関する考察
The List-Unsubscribe header can contain a plaintext or encoded version of the recipient address, but that address is usually also in the To: header. This specification allows anyone with access to a message to unsubscribe the recipient of the message, but that's typically the case with existing List-Unsubscribe, just with more steps.
List-Unsubscribe ヘッダは受信者のアドレスをプレーンテキストまたはエンコードしたものを含むことができるが、そのアドレスは通常 To: ヘッダにも含まれている。 この仕様では、メッセージにアクセスできる人であれば誰でも、そのメッセージの受信者の配信を停止することができますが、これは既存の List-Unsubscribe と同じで、手順が増えるだけです。
A malicious mailer could send spam with content intended to provoke large numbers of unsubscriptions and with suitably crafted headers to send POST requests to servers that perhaps don't want them. But it's been possible to provoke GET requests in a similar way for a long time (and much easier, due to spam filter auto-fetches), so the chances of significantly increased annoyance seem low. The content of the List-Unsubscribe-Post header is limited to a single known key/ value pair to prevent an attacker from creating malicious messages where the POST operation could simulate a user filling in an arbitrary form on a victim website.
悪意のあるメーラーは、大量の配信停止を誘発するような内容のスパムを送り、適切な細工を施したヘッダで、おそらく配信を望まないサーバに POST リクエストを送ることができます。 しかし、同様の方法でGETリクエストを誘発することは以前から可能だったので（スパムフィルタの自動フェッチにより、より簡単に）、迷惑行為が著しく増加する可能性は低いと思われます。 List-Unsubscribe-Post ヘッダのコンテンツは、攻撃者が POST 操作でユーザが被害者 Web サイトの任意のフォームに入力することをシミュレートできるような悪意のあるメッセージを作成することを防ぐために、単一の既知のキーと値のペアに制限されています。
The unsubscribe operation provides a strong hint to the mailer that the address to which the message was sent was valid, and could in principle be used as a way to test whether an email address is valid. In practice, though, there are simpler ways such as embedding image links into the HTML of a message and seeing whether the recipient fetches the images.
unsubscribe 操作は、メッセージが送られたアドレスが有効であるという強いヒントをメーラーに提供する。しかし、実際には、メッセージの HTML に画像リンクを埋め込んで、受信者がその画像を取得するかどうかを確認するような、もっと単純な方法があります。
Since the mailer's server that receives the POST request cannot in general tell where the request is coming from, the URI SHOULD contain an opaque identifier or another hard-to-forge component to identify the list and recipient address. That can ensure that the request originated from the List-Unsubscribe and List-Unsubscribe-Post headers in a message the mailer sent. Also, the request MUST NOT include cookies or other context information to prevent the server from associating the request with previous web requests.
POST リクエストを受け取るメーラーのサーバーは、一般的にリクエストの発信元を知る ことができないので、URI はリストと受信者のアドレスを特定するために、不透明な識別子 または他の偽造が難しいコンポーネントを含むべきである[SHOULD]。 これにより、メーラーの送ったメッセージ中の List-Unsubscribe と List-Unsubscribe-Post ヘッダーがリクエストの発信元であることを保証できる。 また、リクエストは、サーバーがそのリクエストを以前の Web リクエストと関連付けることを防ぐために、クッキーや他のコンテキスト情報を含んではならない[MUST NOT]。
7.IANA Considerations
7.IANAに関する考察
IANA has added a new entry to the "Permanent Message Header Field Names" registry.
IANAは "Permanent Message Header Field Names "レジストリに新しいエントリを追加した。
Header field name: List-Unsubscribe-Post
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document: RFC 8058
ヘッダーフィールド名: List-Unsubscribe-Post
適用プロトコル：mail
ステータス: standard
作成者/変更管理者: IETF
仕様文書 RFC 8058
8.Examples
8.例
8.1. Simple
8.1. 簡単な
Header in Email
メール中のヘッダ
List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickResulting POST request
結果の POST リクエスト
POST /unsubscribe/opaquepart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26List-Unsubscribe=One-Click
リスト配信停止=ワンクリック
8.2. Complex
8.2. コンプレックス
Header in Email
メールのヘッダー
List-Unsubscribe:
<mailto:listrequest@example.com?subject=unsubscribe>,
<https://example.com/unsubscribe.html?opaque=123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickResulting POST request
結果の POST リクエスト
POST /unsubscribe.html?opaque=123456789 HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26List-Unsubscribe=One-Click
リスト配信停止=ワンクリック
8.3. Complex with 'multipart/form-data'
8.3. multipart/form-data'を使った複雑な処理
Header in Email
メールのヘッダ
List-Unsubscribe:
<mailto:listrequest@example.com?subject=unsubscribe>,
<https://example.com/unsubscribe.html/opaque123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickResulting POST request
POSTリクエストの結果
POST /unsubscribe.html/opaque=123456789 HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=---FormBoundaryjWmhtjORrn
Content-Length: 124
---FormBoundaryjWmhtjORrn
Content-Disposition: form-data; name="List-Unsubscribe"
One-Click
---FormBoundaryjWmhtjORrn--9.Normative References
9.規範となる参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119.
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, DOI 10.17487/RFC2369, July 1998, http://www.rfc-editor.org/info/rfc2369.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, http://www.rfc-editor.org/info/rfc5322.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, http://www.rfc-editor.org/info/rfc6376.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, http://www.rfc-editor.org/info/rfc7230.
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015, http://www.rfc-editor.org/info/rfc7578.
Authors' Addresses
著者住所
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 United States of America
Phone: +1 831 480 2300 Email: standards@taugh.com URI: http://jl.ly
Tobias Herkula optivo GmbH Wallstrasse 16 Berlin 10179 Germany
Phone: +49 30 768078 129 Email: t.herkula@optivo.com URI: https://www.optivo.com
この記事が気に入ったらサポートをしてみませんか？