RFC2369和訳ーList-Help、List-Subscribe、List-Unsubscribeの仕様

メールヘッダーに付与する3つのヘッダー、List-Help、List-Subscribe、およびList-Unsubscribeに関する要件を記載した仕様書を翻訳する。

Googleがガイドライン変更したのでこの辺のこと調べたいけど和訳が転がってなくて死にそうなので調べて書き残す。

Email sender guidelines - Google Workspace Admin Help

引用元は下記。

RFC 2369: The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields

和訳はDeepLで自動翻訳する。もし分かりづらいところがあったら後日注釈するかもしれない。

RFC8058はこちら。

The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
コア・メール・リスト・コマンドのメタ構文としてのURLの使用と、メッセージ・ヘッダ・フィールドによるその転送

Status of this 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.
本文書は、インターネットコミュニティのためのインターネット標準追跡 プロトコルを規定し、改善のための議論と提案を要求する。 このプロトコルの標準化状況とステータスについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照のこと。 このメモの配布は無制限である。

Copyright Notice
著作権について

Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright (C) The Internet Society (1998). 無断複写・転載を禁じます。

Abstract
要旨

The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. Each field typically contains a URL (usually mailto [RFC2368]) locating the relevant information or performing the command directly. The three core header fields described in this document are List-Help, List-Subscribe, and List-Unsubscribe.
メーリングリストコマンド仕様のヘッダーフィールドは、電子メール配 布リストによって送られる電子メールメッセージに追加される、構造化さ れたフィールドのセットである。各フィールドは通常、関連する情報を探すか直接コマンドを実行する ためのURL(通常はmailto[RFC2368])を含む。このドキュメントで述べられている3つのコアヘッダーフィールドは、 List-Help、List-Subscribe、およびList-Unsubscribeである。

There are three other header fields described here which, although not as widely applicable, will have utility for a sufficient number of mailing lists to justify their formalization here. These are List-Post, List-Owner and List-Archive.
ここで説明される他の3つのヘッダーフィールドは、それほど広く適用で きるものではないが、十分な数のメーリングリストにとって有用であり、こ こで正式に記述することを正当化するものである。これらは List-Post、List-Owner、List-Archiveである。

By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands.
これらのヘッダーフィールドを含めることで、リストサーバーはメールクライアントが ユーザーがリスト機能を実行するための自動化されたツールを提供できるように することができる。これはメニューアイテム、プッシュボタン、または他のユーザーインターフェイス要素の形をとることができます。その意図は、ユーザーエクスペリエンスを単純化し、しばしば暗号化され、多様なメーリングリストマネージャコマンドに共通のインターフェースを提供することです。

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 RFC 2119.
本文書のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL "は、RFC2119に記述されているとおりに解釈される。

1.Introduction
1.はじめに

This is a proposal for additional header fields to be added to email messages sent by email distribution lists. The content of each new field is typically a URL - usually mailto [RFC2368] - which locates the relevant information or performs the command directly. MTAs generating the header fields SHOULD usually include a mailto based command, in addition to any other protocols used, in order to support users who do not have access to non-mail-based protocols.
これは、電子メール配布リストが送る電子メールメッセージに追加するヘッダー フィールドの提案である。各新しいフィールドの内容は、通常、関連する情報を見つけるか、直接コマン ドを実行するURL(通常はmailto[RFC2368])である。ヘッダーフィールドを生成するMTAは、非メールベースのプロトコルにアクセ スできないユーザーをサポートするために、使用される他のプロトコルに加えて、 通常mailtoベースのコマンドを含むべきである[SHOULD]。

Implementing these fields will be optional. Significant functionality and convenience can be gained by including them, however. Many list managers, especially as the proposal first gains acceptance, MAY choose to implement only one or two of the fields. The List-Help field is the most useful individual field since it provides an access point to detailed user support information, and accommodates almost all existing list managers command sets. The List-Subscribe and List-Unsubscribe fields are also very useful, but cannot describe
some list manager syntaxes at this time (those which require variable substitution). See appendix A.5 for an explanation.
これらのフィールドの実装は任意である。しかし、これらのフィールドを含めることで、重要な機能と利便性を得ることができる。多くのリスト管理者は、特にこの提案が最初に受け入れられるようになると、フィールドの1つか2つだけを実装することを選択するかもしれません。 List-Helpフィールドは、詳細なユーザーサポート情報へのアクセスポイントを提供し、ほとんどすべての既存のリスト管理者のコマンドセットに対応するので、最も有用な個々のフィールドである。List-SubscribeフィールドとList-Unsubscribeフィールドも非常に便利ですが、現時点ではリストマネージャの構文(変数の置換を必要とするもの)を記述することはできません。説明については付録A.5を参照のこと。

The description of command syntax provided by the fields can be used by mail client applications to provide simplified and consistent user access to email distribution list functions. This could take the form of menu items, push buttons, or other user interface elements. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands.
フィールドによって提供されるコマンド構文の説明は、メールクライアントアプリケーションによって、電子メール配信リスト機能への簡略化された一貫したユーザーアクセスを提供するために使用することができます。これは、メニューアイテム、プッシュボタン、または他のユーザーインターフェイス要素の形をとることができます。 この意図は、ユーザーエクスペリエンスを簡素化し、暗号化されがちで多様なメーリングリストマネージャのコマンドに共通のインターフェースを提供することです。

Consideration has been given to avoiding the creation of too many fields, while at the same time avoiding the overloading of individual fields and keeping  the syntax clear and simple. 
フィールドが増えすぎないように配慮され、同時に個々のフィールドの過負荷を避け、シンタックスを明確かつシンプルに保つ。

The use of these fields does not remove the requirement to support the -Request command address for mailing lists [RFC2142].
これらのフィールドを使用しても、メーリングリストの -Requestコマンドアドレス[RFC2142]をサポートする要件がなくなるわけではない。

2.The Command Syntax
2.コマンド構文

The list header fields are subject to the encoding and character　restrictions for mail headers as described in [RFC822]. Additionally, the URL content is further restricted to the set of URL safe characters [RFC1738].
リストヘッダーフィールドは、[RFC822]で述べられているように、メー ルヘッダーのためのエンコーディングと文字の制限に従う。さらに、URLコンテンツはURLセーフ文字のセット[RFC1738]に制限される。

The contents of the list header fields mostly consist of angle-bracket ('<', '>') enclosed URLs, with internal whitespace being ignored. MTAs MUST NOT insert whitespace within the brackets, but client applications should treat any whitespace, that might be inserted by poorly behaved MTAs, as characters to ignore.
リストヘッダーフィールドのコンテンツは、ほとんどがアングルブラケット('<', '>')で囲まれたURLで構成され、内部の空白は無視される。MTAは括弧の中に空白文字を挿入してはならない[MUST NOT]が、クライア ントアプリケーションは、行儀の悪いMTAが挿入するかもしれない空白文字を、 無視すべき文字として扱うべきである。

A list of multiple, alternate, URLs MAY be specified by a comma-separated list of angle-bracket enclosed URLs. The URLs have order of preference from left to right. The client application should use the left most protocol that it supports, or knows how to access by a separate application. By this mechanism, protocols like http may be specified while still providing the basic mailto support for those clients who do not have access to non-mail protocols. The client should only use one of the available URLs for a command, using another only if the first one used failed.
複数の代替URLのリストは、角括弧で囲まれたURLをカンマで区切って指定しても よい(MAY)。URLは左から右の順に優先される。クライアントアプリケーショ ンは、サポートしている、または別のアプリケーションでアクセスする方法を知 っている、最も左のプロトコルを使用するべきである。このメカニズムによって、httpのようなプロトコルを指定することができ、同時にメール以外のプロトコルにアクセスできないクライアントのために基本的なmailtoサポートを提供することができます。クライアントは、コマンドに使用可能なURLのうち1つだけを使用し、最初に使用したものが失敗した場合にのみ別のものを使用します。

The use of URLs allows for the use of the syntax with existing URL supporting applications. As the standard for URLs is extended, the list header fields will gain the benefit of those extensions. Additionally, the use of URLs provides access to multiple transport protocols (such as ftp and http) although it is expected that the "mailto" protocol [RFC2368] will be the focus of most use of the list header fields. Use of non-mailto protocols should be considered in light of those users who do not have access to the specified mechanism (those who only have email - with no web access).
URLの使用は、既存のURLサポートアプリケーションで構文を使用することを 可能にする。URLの標準が拡張されると、リストヘッダーフィールドはそれらの拡張の利点を 得ることになる。さらに、URLの使用は複数のトランスポートプロトコル(ftpやhttpなど)への アクセスを提供するが、「mailto」プロトコル[RFC2368]がリストヘッダーフィー ルドのほとんどの使用の中心になると予想される。mailto以外のプロトコルの使用は、指定された仕組みにアクセスできない ユーザー(電子メールだけを持っていてWebにアクセスできないユーザー)を 考慮して考慮されるべきである。

Command syntaxes requiring variable fields to be set by the client (such as including the user's email address within a command) are not supported by this implementation. However, systems using such syntaxes SHOULD still take advantage of the List-Help field to provide the user with detailed instructions as needed or - perhaps more usefully - provide access to some form of structured command interface such as an HTML-based form.
クライアントが設定する可変フィールドを必要とするコマンド構文(例えば、コマン ド内にユーザーの電子メールアドレスを含める)は、この実装ではサポートされない。しかしながら、そのような構文を使用するシステムは、必要に応じて詳細な指示をユー ザーに提供するためにList-Helpフィールドを利用するべきである[SHOULD]。

The additional complications of supporting variable fields within the command syntax was determined to be too difficult to support by this protocol and would compromise the likelihood of implementation by software authors.
コマンドシンタックス内で変数フィールドをサポートするという、さらなる複雑さは、このプロトコルでサポートするにはあまりにも困難であり、ソフトウェア作者による実装の可能性を損なうと判断された。

To allow for future extension, client applications MUST follow the following guidelines for handling the contents of the header fields described in this document:
将来の拡張を可能にするために、クライアントアプリケーションは、この ドキュメントで述べられているヘッダーフィールドのコンテンツを操作するため の以下のガイドラインに従わなければならない[MUST]：

1)Except where noted for specific fields, if the content of the field (following any leading whitespace, including comments) begins with any character other than the opening angle bracket '<', the field SHOULD be ignored.
1)特定のフィールドについて明記されている場合を除き、フィールドの内容（コメントを含む先頭の空白に続く）が開始角括弧「<」以外の文字で始まる場合、そのフィールドは無視されるべきである（SHOULD）。

2)Any characters following an angle bracket enclosed URL SHOULD be ignored, unless a comma is the first non-whitespace/comment character after the closing angle bracket.
2)角括弧で囲まれたURLの後に続く文字は、閉じ角括弧の後の最初の空白ま たはコメント以外の文字がカンマでない限り、無視されるべきである(SHOULD)。

3)If a sub-item (comma-separated item) within the field is not an angle-bracket enclosed URL, the remainder of the field (the current, and all subsequent, sub-items) SHOULD be ignored.
3)フィールド内の小項目(カンマで区切られた項目)がアングルブラケットで囲 まれたURLでない場合、フィールドの残りの部分(現在の小項目とそれに続くすべ ての小項目)は無視されるべきである[SHOULD]。

3.The List Header Fields
3.リスト・ヘッダー・フィールド

This document presents header fields which will provide the command syntax description for the 'core' and key secondary functions of most email distribution lists. The fields implemented on a given list SHOULD be included on all messages distributed by the list (including command responses to individual users), and on other messages where the message clearly applies to one distinct list. There MUST be no more than one of each field present in any
given message.
この文書では、ほとんどの電子メール配布リストの「コア」と主要なセカンダリ 機能のコマンド構文の説明を提供するヘッダーフィールドを提示します。あるメーリングリストに実装されているフィールドは、そのメーリングリストが配信するすべてのメッセージ(個々のユーザーへのコマンド応答を含む)と、メッセージが明らかにあるメーリングリストに適用される他のメッセージに含まれるべきです(SHOULD)。与えられたメッセージの中に、各フィールドが一つ以上存在してはならない(MUST)。

These fields MUST only be generated by mailing lists, not end users.
これらのフィールドは、エンドユーザーではなく、メーリングリストによってのみ生成されなければならない（MUST）。

3.1.List-Help
3.1.リストヘルプ

The List-Help field is the most important of the header fields described in this document. It would be acceptable for a list manager to include only this field, since by definition it SHOULD direct the user to complete instructions for all other commands. Typically, the URL specified would request the help file, perhaps incorporating an HTML form for list commands, for the list, and alternatively provide access to an instructive website.
List-Helpフィールドは、このドキュメントで述べられているヘッダー フィールドの中で最も重要である。定義上、他のすべてのコマンドの完全な指示にユーザーを導く べきである[SHOULD]ので、リスト管理者がこのフィールドだけを含むことは容認 できるだろう。通常、指定されたURLは、おそらくリストコマンド用のHTMLフォームを組み 込んだ、そのリストのヘルプファイルを要求し、代わりに有益なWebサイトへの アクセスを提供する。

Examples:
例を挙げよう：

List-Help: mailto:list@host.com?subject=help (List Instructions)
List-Help: mailto:list-manager@host.com?body=info
List-Help: mailto:list-info@host.com (Info about the list)
List-Help: http://www.host.com/list/, mailto:list-info@host.com
List-Help: ftp://ftp.host.com/list.txt (FTP),
mailto:list@host.com?subject=help

3.2.List-Unsubscribe
3.2.リスト配信停止

The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).
List-Unsubscribeフィールドには、ユーザーを直接退会させる(リストから削除する)コマンドを記述する(できればメールを使う)。

Examples:
例を挙げよう：

List-Unsubscribe: mailto:list@host.com?subject=unsubscribe
List-Unsubscribe: (Use this command to get off the list)
mailto:list-manager@host.com?body=unsubscribe list
List-Unsubscribe: mailto:list-off@host.com
List-Unsubscribe: http://www.host.com/list.cgi?cmd=unsub&lst=list,
mailto:list-request@host.com?subject=unsubscribe

3.3List-Subscribe
3.3リスト購読

The List-Subscribe field describes the command (preferably using mail) to directly subscribe the user (request addition to the list).
List-Subscribeフィールドには、ユーザーを直接購読する(リストへの追加を要求する)ためのコマンド(できればメールを使う)を記述する。

Examples:
例を挙げよう：

List-Subscribe: mailto:list@host.com?subject=subscribe
List-Subscribe: mailto:list-request@host.com?subject=subscribe
List-Subscribe: (Use this command to join the list) mailto:list-manager@host.com?body=subscribe list
List-Subscribe: mailto:list-on@host.com
List-Subscribe: http://www.host.com/list.cgi?cmd=sub&lst=list, mailto:list-manager@host.com?body=subscribe list

3.4.List-Post
3.4.リストポスト

The List-Post field describes the method for posting to the list. This is typically the address of the list, but MAY be a moderator, or potentially some other form of submission. For the special case of a list that does not allow posting (e.g., an announcements list), the List-Post field may contain the special value "NO".
List-Postフィールドはリストへの投稿方法を記述します。これは典型的にはリストのアドレスですが、モデレーターや他の投稿フォームであってもかまいません。投稿を許可しないリスト(たとえばアナウンスメントリスト)の特別な場合、List-Postフィールドは特別な値 "NO "を含むことができます。

Examples:
例を挙げよう：

List-Post: mailto:list@host.com
List-Post: mailto:moderator@host.com (Postings are Moderated)
List-Post: mailto:moderator@host.com?subject=list posting
List-Post: NO (posting not allowed on this list)

3.5.List-Owner
3.5.リスト・オーナー

The List-Owner field identifies the path to contact a human administrator for the list. The URL MAY contain the address of a administrator for the list, the mail system administrator, or any other person who can handle user contact for the list. There is no need to specify List-Owner if it is the same person as the mail system administrator (postmaster).
リスト所有者(List-Owner)フィールドはリストの管理者に連絡するためのパスを指定します。URLにはリストの管理者、メールシステム管理者、またはリストのユーザーとの連絡を担当できる他の人のアドレスを書いてもかまいません(MAY)。メールシステムの管理者(postmaster)と同じ人であれば、List-Ownerを指定する必要はありません。

Examples:
例を挙げよう：

List-Owner: mailto:listmom@host.com (Contact Person for Help)
List-Owner: mailto:grant@foo.bar (Grant Neufeld)
List-Owner: mailto:josh@foo.bar?Subject=list

3.6.List-Archive
3.6.リストアーカイブ

The List-Archive field describes how to access archives for the list.
List-Archiveフィールドには、リストのアーカイブへのアクセス方法を記述します。

Examples:
例を挙げよう：

List-Archive: mailto:archive@host.com?subject=index list
List-Archive: ftp://ftp.host.com/pub/list/archive/
List-Archive: http://www.host.com/list/archive/ (Web Archive)

4.Supporting Nested Lists
4.入れ子リストのサポート

A list that is a sublist for another list in a nested mailing list hierarchy will need to modify some of the List- header fields, while leaving others as the parent list set them.
ネストされたメーリングリスト階層で、他のリストのサブリストになるリストは、List-ヘッダーフィールドのいくつかを修正する必要がありますが、他のフィールドは親リストが設定したままにしておく必要があります。

Sublists SHOULD remove the parent list's List-Help, List-Subscribe, List-Unsubscribe and List-Owner fields, and SHOULD insert their own versions of those fields.
サブリストは親リストのList-Help、List-Subscribe、List-Unsubscribe、List-Ownerフィールドを削除し、それらのフィールドの独自のバージョンを挿入すべきです(SHOULD)。

If the sublist provides its own archive, it SHOULD replace the List-Archive with its own. Otherwise, it MUST leave the List-Archive field untouched.
サブリストがそれ自身のアーカイブを提供する場合、それは List-Archiveをそれ自身のもので置き換えるべきである[SHOULD]。そうでなければ、List-Archiveフィールドはそのままにしておかなければならない[MUST]。

Dependant on how postings to the list are handled, the sublist MAYreplace the List-Post field. The appropriateness of whether toreplace List-Post is left to the determination of the individual listmanagers. If the intention is that postings should be distributed toall members of the primary list, List-Post should not be changed by asublist in such a way that postings will be distributed only tomembers of the sublist.
リストへの投稿がどのように扱われるかによって、サブリストはList-Postフィールドを置き換えてもよい。List-Postを置き換えることが適切かどうかは、個々のリスト管理者の判断に任されています。投稿がプライマリリストのすべてのメンバーに配布されるべきであるという意図がある場合、投稿がサブリストのメンバーだけに配布されるような方法で、List-Postをサブリストによって変更すべきではありません。

5.Security Considerations
5.セキュリティへの配慮

There are very few new security concerns generated with this proposal. Message headers are an existing standard, designed to easily accommodate new types. There may be concern with multiple fields being inserted or headers being forged, but these are problems inherent in Internet email, not specific to the protocol described in this document. Further, the implications are relatively harmless.
この提案で新たに発生するセキュリティ上の懸念はほとんどない。メッセージヘッダーは既存の標準であり、新しいタイプに容易に対応できるように設計されている。複数のフィールドが挿入されたり、ヘッダーが偽造されたりすることが懸念されるかもしれないが、これらはインターネット電子メールに固有の問題であり、この文書で説明されているプロトコルに固有のものではない。さらに、その影響は比較的無害である。

Mail list processors should not allow any user-originated list header fields to pass through to their lists, lest they confuse the user and have the potential to create security problems.
メールリストプロセッサーは、ユーザーを混乱させ、セキュリティー上の問 題を引き起こす可能性がないように、ユーザー起源のリストヘッダーフィール ドを自分のリストに通すことを許可すべきではない。

On the client side, there may be some concern with posts or commands being sent in error. It is required that the user have a chance to confirm any action before it is executed. In the case of mailto, it may be appropriate to create the correctly formatted message without sending it, allowing the user to see exactly what is happening and giving the user the opportunity to approve or discard the message before it is sent.
クライアント側では、投稿やコマンドが誤って送信される懸念があるかもしれない。実行される前に、ユーザーがアクションを確認する機会があることが必要です。mailtoの場合、送信せずに正しい書式のメッセージを作成し、ユーザが何が起こっているかを正確に見ることができるようにし、ユーザが送信前にメッセージを承認または破棄する機会を与えることが適切かもしれません。

All security considerations for the use of URLs [RFC1738] apply equally to this protocol. Mail client applications should not support list header field URLs which could compromise the security of the user's system. This includes the "file://" URL type which could potentially be used to trigger the execution of a local application on some user systems.
URLの使用に関するすべてのセキュリティ上の考慮事項[RFC1738]は、このプ ロトコルにも等しく適用される。メールクライアントアプリケーションは、ユーザーシステムのセキュリ ティを脅かす可能性のあるリストヘッダーフィールドURLをサポートすべきで はない。これには「file://」URLタイプが含まれる。このURLタイプは、 ユーザーシステムによってはローカルアプリケーションの実行をトリガー するために使用される可能性がある。

6.Acknowledgements
6.謝辞

The numerous participants of the List-Header [5], ListMom-Talk [6], List-Managers and MIDA-Mail mailing lists contributed much to the formation and structure of this document.
List-Header [5]、ListMom-Talk [6]、List-ManagersおよびMIDA-Mailメーリングリストの多数の参加者は、この文書の形成と構成に多大な貢献をした。

Keith Moore moore@cs.utk.edu and Christopher Allen ChristopherA@consensus.com provided guidance on the standards process.
キース・ムーア moore@cs.utk.edu とクリストファー・アレン ChristopherA@consensus.com は、スタンダードのプロセスについて指導を行った。

A.Background Discussion
A.背景の議論

This proposal arose from discussions started on the ListMom-Talk Discussion List [6]. When the discussion reached a sufficient level, a separate list was formed for discussing this proposal, the List Headers Mail List [5] for deeper discussion. We have included summaries of key issues raised, in order to show some of the alternatives examined and reasons for our decisions.
この提案は、ListMom-Talk Discussion List [6]で始まった議論から生まれた。議論が十分なレベルに達したとき、この提案を議論するための別のリスト、より深い議論のためのリストヘッダー・メール・リスト [5] が形成されました。私たちは、検討された選択肢の一部と私たちの決定の理由を示すために、提起された主要な問題の要約を含めました。

A.1. Multiple header fields vs. a single header field
A.1. 複数のヘッダーフィールドと単一のヘッダーフィールドの比較

Use of a single header field for transporting command meta-syntax was rejected for a number of reasons.
コマンドのメタ構文を転送(transport)するために一つのヘッダーフィールドを使 用することは、多くの理由から拒否された。

Such a field would require the creation of a new meta-syntax in order to describe the list commands (as opposed to the use of the widely deployed URL syntax which was chosen for this implementation). Every additional layer of complexity and newness reduces the likelihood of actual implementation because it will require additional work to support. Also, by using the existing URL syntax, we can profit from the end users' knowledge of that syntax and ability to use it even if their client applications do not support the list header fields.
このようなフィールドは、リストコマンドを記述するために新しいメタ構文を 作成する必要がある(この実装のために選択された、広く使われているURL構文の 使用とは対照的である)。 複雑さと新しさのレイヤーが増えるたびに、サポートに追加作業が必要になるため、実際に実装される可能性は低くなります。また、既存のURL構文を使用することで、クライアントアプリケーションがリ ストヘッダーフィールドをサポートしていなくても、エンドユーザーがその構文を知 り、使用できることから利益を得ることができる。

Restricting the transport of meta-syntax to the use of a single header field also introduces complications with header field size limitations. Most individual commands can easily be described in a single line, but describing a multitude of commands can take up many lines in the field and runs a greater risk of being modified by an existing server on route.
メタ構文のトランスポートを一つのヘッダーフィールドの使用に制限する ことは、ヘッダーフィールドのサイズ制限の複雑さももたらす。ほとんどの個々のコマンドは一行で簡単に記述できるが、多数のコマンドを記 述することはフィールドで何行も占めることになり、ルート上の既存のサーバーに よって修正される危険性が高くなる。

The client implementation is also easier with multiple fields, since each command can be supported and implemented individually, completely independent of the others. Thus, some list managers or mail clients can choose to implement a subset of the fields based on the specific needs of their individual lists.
各コマンドは他のものから完全に独立して個別にサポートされ、実装することができるからです。したがって、リスト管理者やメールクライアントによっては、個々のリストの特定の必要性に基づいて、フィールドのサブセットを実装することを選択することができます。

Finally, the format described in this document is simple and well recognized, which reduces the chances of errors in implementation and parsing.
最後に、この文書で説明されているフォーマットはシンプルでよく認識されているため、実装やパースでエラーが発生する可能性が低くなっている。

A.2. URLs vs. parameter lists
A.2. URLとパラメータリストの比較

URLs are already an established syntax which is flexible, well- defined, and in wide spread use. As its definition matures and expands, the abilities of the list fields will grow as well, without requiring modification of this proposal. URLs are well prepared to handle future protocols and developments, and can easily describe the different existing access protocols such as mailto, http and ftp.
URLはすでに確立された構文であり、柔軟で、よく定義され、広く使われている。その定義が成熟し、拡大するにつれて、リストフィールドの能力も、この提案の修正を必要とせずに、同様に成長するだろう。URLは将来のプロトコルや開発に対応する準備が整っており、mailto、http、ftpのような既存のさまざまなアクセスプロトコルを簡単に記述することができる。

Many clients already have functionality for recognizing, parsing, and evaluating URLs, either internally or by passing the request to a helper application. This makes implementation easier and more realistic. As an example, this existing support for URL parsing allowed us to add prototype list header functionality to existing mail clients (Eudora and Emailer for the Macintosh) without modifying their source code.
多くのクライアントは、内部的に、あるいはヘルパーアプリケーションに リクエストを渡すことで、URLを認識、解析、評価する機能をすでに持っている。これにより、実装が容易になり、より現実的になります。一例として、URL解析のこの既存のサポートにより、既存のメールクライアント(MacintoshのEudoraとEmailer)に、ソースコードを変更することなく、プロトタイプのリストヘッダ機能を追加することができました。

A.3. Why not just create a standard command language?
A.3. なぜ標準的なコマンド言語を作らないのか？

A standard command language, supported by all email list services, would go a long way to reducing the problems of list access that currently plague existing services. It would reduce the amount of learning required by end users and allow for a number of common support tools to be developed.
すべての電子メール・リスト・サービスによってサポートされる標準的なコマンド言語は、現在既存のサービスを悩ませているリスト・アクセスの問題を減らすのに大いに役立つだろう。エンドユーザーの学習量を減らし、多くの共通サポートツールを開発することができるだろう。

However, such standardization does pose problems in the areas of multi-lingual support and the custom needs of individual mailing lists. The development of such a standard is also expected to be met with a slow adoption rate by software developers and list service providers.
しかし、このような標準化は、多言語サポートや個々のメーリングリストのカスタムニーズの分野で問題を引き起こす。また、このような標準の策定は、ソフトウェア開発者やメーリングリスト・サービス・プロバイダーによる採用が遅々として進まないことが予想される。

These points do not preclude the development of such a standard (in fact, it would suggest that we should start sooner rather than later), but we do need a solution that can be widely supported by the current list services.
これらの点は、このような標準の開発を妨げるものではないが（むしろ、早急に着手すべきことを示唆している）、現在のリストサービスが広くサポートできるソリューションが必要である。

We can support most existing list manager command syntaxes without a standard command language. By using URLs, we allow alternate access methods a standard command language probably wouldn't enable, such as web based control.
標準的なコマンド言語がなくても、既存のリストマネージャコマンド構文のほとんどをサポートすることができます。URLを使用することで、ウェブベースのコントロールなど、標準のコマンド言語ではおそらく不可能な代替アクセス方法を可能にします。

Finally, client support for a standard command language is not at all clear or necessarily simple to implement. The variety and large number of commands existing today would require complicated user interfaces which could be confusing and difficult to implement. By restricting this proposal to the core functions, the client implementation is much simpler, which significantly increases the likelihood of implementation (as evidenced by the support already announced by a number of client and server application authors).
最後に、標準的なコマンド言語に対するクライアントのサポートはまったく明確ではないし、実装も必ずしも簡単ではない。現在存在する多種多様で多数のコマンドは、複雑なユーザーインターフェイスを必要とし、混乱を招き、実装が困難になる可能性がある。この提案をコア機能に限定することで、クライアントの実装はよりシンプルになり、実装の可能性が大幅に高まります（すでに多くのクライアントとサーバーアプリケーションの作者によってサポートが発表されていることからも明らかです）。

A.4. Internationalization
A.4. 国際化

Multilingual support is up to the URL standard. If URLs support it, then the List- header fields support it. This is another advantage of using URLs as the building blocks for the list header fields.
多言語サポートはURL標準次第です。もしURLがそれをサポートするなら、List-ヘッダー フィールドはそれをサポートする。これは、リストヘッダーフィールドの構成要素としてURLを使うもう一つの利点です。

A.5. Variable Substitution
A.5. 変数の置換

Variables would allow the List- header fields to accommodate nearly every existing list manager. However, it would immeasurably increase the complexity of the entire proposal, and possibly involve redefining the URL standard, or force us to use something more complicated (and hence more difficult to implement) than URLs to describe the command syntax.
変数は、List-ヘッダーフィールドがほとんどすべての既存のリスト マネージャに対応することを可能にするだろう。しかしながら、それは提案全体の複雑さを計り知れないほど増大させ、おそらくURL標準の再定義を伴うか、コマンド構文を記述するためにURLよりも複雑なもの(したがって、実装がより困難なもの)を使わざるを得なくなるでしょう。

Parameters would either have to be mandatory (i.e. the user agent doesn't submit the message if it doesn't know what text to substitute) or you need a way to say "if you know this parameter, add its text here; otherwise, do this" where "this" is either: (a) substitute a constant string, or (b) fail.
パラメータは必須でなければならないか（つまり、ユーザーエージェントは、どのテキストを代入すればいいかわからなければ、メッセージを送信しない）、あるいは、「このパラメータを知っているなら、ここにそのテキストを追加してください。

The reason you would want a facility like this is because some list server applications insist on having certain parameters like users' names, which the user agent might or might not know. e.g. listserv insists on having a first name and a last name if you supply either one.
このような機能が必要な理由は、リストサーバーアプリケーションの中には、ユーザーエージェントが知っているかどうかわからないユーザー名などの特定のパラメータを要求するものがあるからだ。

Which could lead to something like the UNIX shell syntax, where ${foo-bar} means substitute the value of parameter "foo" if "foo" is defined, else substitute the string "bar". Perhaps $foo would mean "substitute the value of parameter foo if it is defined, else substitute the empty string"
つまり、UNIXのシェル構文のように、${foo-bar}は、パラメータ "foo "が定義されていればその値を、そうでなければ文字列 "bar "を代入するという意味になる。おそらく$fooは、「パラメータfooが定義されていればその値を代入し、そうでなければ空文字列を代入する」という意味になるだろう。

This all seems far too complicated for the gains involved, especially since the use of variables can often be avoided.
特に変数の使用は避けられることが多いからだ。

The use of variables in the command syntaxes of list services appears to be lessening and does not, in any case, apply to all commands. While the unsubscribe and subscribe command header fields may not be usable by those systems which require the use of variables, the help field will still provide end users with a consistent point of access through which they can get support for their use of the list.
リストサービスのコマンド構文における変数の使用は減少しているようであり、 どのような場合でもすべてのコマンドに適用されるわけではない。unsubscribeとsubscribeコマンドのヘッダーフィールドは、変数の使用を必要とするシステムでは使用できないかもしれませんが、helpフィールドは、リストの使用に関するサポートを得ることができる一貫したアクセスポイントをエンドユーザーに提供します。

A.6. Why not use a specialized MIME part instead of header fields?
A.6. なぜ、ヘッダーフィールドの代わりに特殊なMIMEパートを使わないのですか？

MIME parts were considered, but because most mail clients currently either don't support MIME or are not equipped to handle such specialized parts - such an implementation would result in problems for end users. It is also not as easy for many list servers to implement MIME as it is to implement new header fields.
MIMEパートも検討されたが、現在ほとんどのメールクライアントはMIMEを サポートしていないか、そのような特殊なパートを処理する機能がないため、 そのような実装はエンドユーザーにとって問題になるだろう。また、多くのリストサーバーがMIMEを実装するのは、新しいヘッダー フィールドを実装するほど簡単ではない。

However, we are looking at the design of a MIME part to more fully describe list command syntax, as well as trying to find ways to get it supported by the applicable software.
しかし、私たちはリストコマンドの構文をより完全に記述するためのMIMEパートの設計を検討していますし、適用可能なソフトウェアでサポートされる方法を見つけようとしています。

A.7. Why include a Subscribe command?
A.7. なぜ Subscribe コマンドを含めるのですか？

Subscribe and Unsubscribe are the key commands needed by almost every list. Other commands, such as digest mode, are not as widely supported.
SubscribeとUnsubscribeは、ほとんどすべてのリストで必要とされる主要なコマンドです。ダイジェストモードなど、他のコマンドはあまり広くサポートされていません。

Additionally, users who have unsubscribed (before going on vacation, or for whatever other reason) may want to resubscribe to a list. Or, a message may be forwarded/bounced from a subscriber to a non- subscriber. Or, the user may change addresses and want to subscribe from their new address. Having the List-Subscribe field available could certainly help in all these cases.
さらに、(休暇に入る前やその他の理由で)購読を解除したユーザが、リストに再登録したいと思うかもしれません。あるいは、購読者から非購読者にメッセージが転送/バウンスされるかもしれない。あるいは、ユーザがアドレスを変更し、新しいアドレスから購読したくなるかもしれません。List-Subscribeフィールドがあれば、このようなすべてのケースで役に立つでしょう。

A.8. The Dangers of Header Bloat
A.8. ヘッダー肥大化の危険性

At what point are there just too many header fields? It really varies on a list by list basis. On some lists, the majority of users will never be aware of a field unless the client software provides some alternative user interface to it (akin to the Reply-To field). On others, the users will often see the header fields of messages and would be able to recognize the function of the URLs contained within.
ヘッダーフィールドが多すぎるというのはどのような場合でしょうか？ それはリストごとに異なります。あるリストでは、クライアントソフトウェアがそのフィールドの代替ユー ザーインターフェイス(Reply-Toフィールドのようなもの)を提供しない限り、 大部分のユーザーはそのフィールドを意識することはないでしょう。他のリストでは、ユーザーはメッセージのヘッダーフィールドをよく見 るので、その中に含まれるURLの機能を認識できるだろう。

The flexibility afforded by the protocol described in this document (in that the header fields may be individually implemented as deemed appropriate) provides list administrators with sufficient 'room to maneuver' to meet their individual needs.
このドキュメントで述べられているプロトコルが提供する柔軟性(ヘッダー フィールドは適切とみなされるように個々に実装することができるという点 で)は、リスト管理者に個々のニーズを満たすための十分な「操作の余地」を 提供する。

B. Client Implementation
B. クライアントの実装

B.1. Guidelines
B.1. ガイドライン

For 'mailto' URL based commands, mail client applications may choose to provide specialized feedback (such as presenting a dialog or alert), instead of the actual command email message, asking for command confirmation from the user. The feedback should identify the message destination and command within a more descriptive explanation. For example:
mailto」URLベースのコマンドでは、メールクライアントアプリケーションは、実際のコマンドメールメッセージの代わりに、特別なフィードバック（ダイアログやアラートの表示など）を提供し、ユーザーにコマンドの確認を求めることができる。フィードバックは、より説明的な説明の中で、メッセージの宛先とコマンドを特定する必要があります。例えば

"Do you want to send the unsubscription command 'unsubscribe somelist' to 'somelist-request@some.host.com'? Sending the command will result in your removal from the associated list."
"somelist-request@some.host.com "に配信停止コマンド "unsubscribe somelist "を送信しますか？ このコマンドを送信すると、関連リストから削除されます。"

If the user has multiple email addresses supported by the mail client, the client application should prompt the user for which address to use when subscribing or performing some other action where the address to use cannot be specifically determined. When unsubscribing or such, the address that is subscribed should be used, unless that is not known by the application and cannot be determined from the message headers.
ユーザーがメールクライアントでサポートされている複数のメールアドレスを持っている場合、クライアントアプリケーションは、購読するときや、使用するアドレスを明確に決めることができない他のアクションを実行するときに、どのアドレスを使用するかをユーザーに促す必要があります。購読を解除したりするときには、アプリケーションによって知られておらず、メッセージヘッダから判断できない場合を除き、購読しているアドレスを使うべきです。

B.2. Implementation Options
B.2. 実装オプション

The following implementation possibilities are suggested here to give some idea as to why these new header fields will be useful, and how they could be supported.
以下の実装の可能性は、これらの新しいヘッダーフィールドが有用である理由 と、それらがどのようにサポートされうるかについてのアイデアを与えるた めに、ここで提案されている。

In most cases, it may be helpful to disable the interface for the commands when not applicable to the currently selected message.
ほとんどの場合、現在選択されているメッセー ジに適用できないときは、コマンドのインターフェースを無効にすることが有用 であろう。

B.2.1. Key combinations and command lines
B.2.1. キーの組み合わせとコマンドライン

On text based systems which utilize command lines or key combinations, each field could be implemented as a separate command. Thus one combination would subscribe the user, another would unsubscribe, a third request help, etc. The commands would only be available on messages containing the list header fields.
コマンドラインやキーの組み合わせを利用するテキストベースのシステムでは、 各フィールドを個別のコマンドとして実装することができる。ある組み合わせはユーザーを登録し、別の組み合わせは登録を解除し、 3番目はヘルプを要求する、といった具合である。コマンドはリストヘッダーフィールドを含むメッセージでのみ使用可能である。

B.2.2. Menu items
B.2.2. メニュー項目

On graphical systems which have menus, these commands could take the form of a menu or sub-menu of items. For example, a "Lists" menu might appear when viewing messages containing the header fields, with items named "Subscribe", "Unsubscribe", "Get Help", "Post Message to List", "Contact List Owner" and "Access List Archive". This menu could be disabled when not applicable to the current message or disappear entirely.
メニューがあるグラフィカルなシステムでは、これらのコマンドはメニューや サブメニューの形をとることができる。例えば、"Subscribe"、"Unsubscribe"、"Get Help"、"Post Message to List"、"Contact List Owner"、"Access List Archive "といった項目のある "Lists "メニューが、ヘッダー フィールドを含むメッセージを表示するときに表示されるかもしれない。このメニューは、現在のメッセージに適用されないときは無効にするか、完全に消えてしまうかもしれません。

B.2.3. Push Buttons and Pallettes
B.2.3. プッシュボタンとパレット

On graphical window systems, buttons could be placed in the window of the message, a toolbar, or in a floating pallette of their own. Each button could correspond to a command, with names "Subscribe", "Unsubscribe", "Get Help", "Post to List", "List Owner" and "Archive". These buttons or pallettes could be disabled when not applicable to the current message or disappear entirely.
グラフィカル・ウィンドウ・システムでは、ボタンはメッセージのウィンドウ、ツールバー、またはフローティング・パレットの中に置くことができる。それぞれのボタンはコマンドに対応し、"Subscribe"、"Unsubscribe"、"Get Help"、"Post to List"、"List Owner"、"Archive "といった名前があります。これらのボタンやパレットは、現在のメッセージに適用できないときは無効にしたり、完全に消したりすることができます。

B.2.4 Feedback to the User
B.2.4 ユーザーへのフィードバック

If using a dialog interface (or other feedback element) the client application MUST include an option for the user to review (and possibly modify) the message before it is sent. The application may also find it useful to provide a link to more detailed context- sensitive assistance about mail list access in general.
ダイアログインターフェース(または他のフィードバック要素)を使用する場合、クライアントアプリケーションは、送信前にユーザーがメッセージを確認する(そして場合によっては修正する)ためのオプションを含めなければならない(MUST)。アプリケーションは、メールリストへのアクセス全般について、文脈に応じたより詳細な支援へのリンクを提供することも有用であろう。

References
参考文献

[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.

[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource  Locators (URL)" RFC 1738, December 1994.

[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997.

[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.

[5] "List-Header" Mail list. list-header@list.nisto.com
URL:http://www.nisto.com/listspec/mail/
URL:http://www.nisto.com/listspec/

[6] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
URL:http://cgi.skyweyr.com/ListMom.Home