[要約] RFC 2369は、メールリストのコマンドとその転送にURLを使用する方法について説明しています。このRFCの目的は、メーリングリストの管理と操作を簡素化するための標準化を提供することです。
Network Working Group G. Neufeld
Request for Comments: 2369 Nisto
Category: Standards Track J. Baer
SkyWeyr Technologies
July 1998
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（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」は、 RFC 2119で説明されているように解釈されます。
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ベースのコマンドを含める必要があります。
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]。
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のコンマ区切りのリストで指定できます。 URLには、左から右への優先順位があります。クライアントアプリケーションは、サポートする左端のプロトコルを使用するか、別のアプリケーションによるアクセス方法を知っている必要があります。このメカニズムにより、非メールプロトコルにアクセスできないクライアントに基本的なmailtoサポートを提供しながら、httpなどのプロトコルを指定できます。クライアントは、コマンドで使用可能なURLの1つのみを使用し、最初の使用に失敗した場合にのみ別のURLを使用する必要があります。
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フィールドを利用して、必要に応じてユーザーに詳細な指示を提供するか、またはおそらくより便利な方法で、HTMLベースのフォームなどの構造化コマンドインターフェイスのフォームへのアクセスを提供する必要があります。
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:
将来の拡張を可能にするために、クライアントアプリケーションは、このドキュメントで説明されているヘッダーフィールドのコンテンツを処理するための次のガイドラインに従う必要があります。
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に続く文字は、コンマが閉じ山かっこの後の最初の非空白文字/コメント文字でない限り、無視してください。
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）。
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.
このドキュメントでは、ほとんどの電子メール配布リストの「コア」および主要な2次機能のコマンド構文の説明を提供するヘッダーフィールドについて説明します。特定のリストに実装されたフィールドは、リストによって配布されるすべてのメッセージ（個々のユーザーへのコマンド応答を含む）、およびメッセージが明確に1つの異なるリストに適用される他のメッセージに含める必要があります（SHOULD）。特定のメッセージに存在する各フィールドは1つだけでなければなりません。
These fields MUST only be generated by mailing lists, not end users.
これらのフィールドは、エンドユーザーではなく、メーリングリストによってのみ生成される必要があります。
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フィールドは、このドキュメントで説明されているヘッダーフィールドの中で最も重要です。リストマネージャーがこのフィールドのみを含めることは許容されます。定義により、ユーザーに他のすべてのコマンドの指示を完了するように指示する必要があるためです。通常、指定された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>
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%20list>
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>
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%20list>
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%20list>
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%20posting>
List-Post: NO (posting not allowed on this list)
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>
The List-Archive field describes how to access archives for the list.
List-Archiveフィールドは、リストのアーカイブにアクセスする方法を説明します。
Examples:
例：
List-Archive: <mailto:archive@host.com?subject=index%20list>
List-Archive: <ftp://ftp.host.com/pub/list/archive/>
List-Archive: <http://www.host.com/list/archive/> (Web Archive)
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）、それらのフィールドの独自のバージョンを挿入する必要があります（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を独自のものに置き換える必要があります。それ以外の場合は、List-Archiveフィールドをそのままにする必要があります。
Dependant on how postings to the list are handled, the sublist MAY replace the List-Post field. The appropriateness of whether to replace List-Post is left to the determination of the individual list managers. If the intention is that postings should be distributed to all members of the primary list, List-Post should not be changed by a sublist in such a way that postings will be distributed only to members of the sublist.
リストへの投稿の処理方法に応じて、サブリストがList-Postフィールドを置き換える場合があります。 List-Postを置き換えるかどうかの妥当性は、個々のリストマネージャーの決定に委ねられています。投稿がプライマリリストのすべてのメンバーに配信される必要がある場合は、サブリストのメンバーにのみ投稿が配信されるように、List-Postをサブリストによって変更しないでください。
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タイプが含まれます。
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ディスカッションリスト[6]で開始されたディスカッションから生じました。議論が十分なレベルに達したとき、この提案を議論するための別のリストが形成されました、より深い議論のためのリストヘッダーメールリスト[5]。検討された代替案のいくつかと私たちの決定の理由を示すために、提起された主要な問題の要約を含めました。
Use of a single header field for transporting command meta-syntax was rejected for a number of reasons.
コマンドのメタ構文を転送するための単一のヘッダーフィールドの使用は、いくつかの理由により拒否されました。
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.
メタ構文の転送を単一のヘッダーフィールドの使用に制限すると、ヘッダーフィールドのサイズ制限による複雑化も生じます。個々のコマンドのほとんどは1行で簡単に記述できますが、多数のコマンドを記述するとフィールドで多くの行を占める可能性があり、ルート上の既存のサーバーによって変更されるリスクが高くなります。
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.
最後に、このドキュメントで説明する形式はシンプルでよく認識されているため、実装や解析でエラーが発生する可能性が低くなります。
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 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を使用することで、Webベースのコントロールなど、標準のコマンド言語ではおそらく有効にできない代替アクセス方法を許可しています。
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).
実装がはるかに簡単になり、実装の可能性が大幅に増加します（多くのクライアントおよびサーバーアプリケーションの作成者がすでに発表しているサポートからも明らかです）。
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を使用するもう1つの利点です。
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.
パラメータは必須である（つまり、置換するテキストがわからない場合、ユーザーエージェントはメッセージを送信しない）か、「このパラメータがわかっている場合は、ここにテキストを追加します。それ以外の場合は、 「これ」を実行します。「これ」は次のいずれかです。（a）定数文字列を置き換えるか、（b）失敗します。
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.
このような機能が必要な理由は、一部のリストサーバーアプリケーションは、ユーザーエージェントのようなユーザーの名前など、特定のパラメーターをユーザーの名前のように要求するためです。例えばlistservは、姓と名のどちらかを指定した場合、姓と名を要求します。
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」が定義されている場合はパラメーター「foo」の値を置き換えることを意味します。おそらく$ 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コマンドヘッダーフィールドは、変数の使用を必要とするシステムでは使用できない場合がありますが、ヘルプフィールドは、エンドユーザーがリストの使用をサポートできる一貫したアクセスポイントを提供します。
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パーツの設計を検討しているほか、該当するソフトウェアでサポートされるようにする方法を模索しています。
Subscribe and Unsubscribe are the key commands needed by almost every list. Other commands, such as digest mode, are not as widely supported.
購読と購読解除は、ほとんどすべてのリストで必要な主要なコマンドです。ダイジェストモードなどの他のコマンドは、それほど広くサポートされていません。
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フィールドを利用できるようにすると、これらすべてのケースで確かに役立つ可能性があります。
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.クライアントの実装
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."
「購読解除コマンド「unsubscribe somelist」を「somelist-request@some.host.com」に送信しますか？コマンドを送信すると、関連付けられたリストから削除されます。」
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.
ユーザーがメールクライアントでサポートされている複数のメールアドレスを持っている場合、クライアントアプリケーションは、使用するアドレスを明確に決定できない他のアクションをサブスクライブまたは実行するときに、どのアドレスを使用するかをユーザーに要求する必要があります。サブスクライブ解除などの場合、アプリケーションで認識されておらず、メッセージヘッダーから判別できない場合を除いて、サブスクライブしたアドレスを使用する必要があります。
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.
ほとんどの場合、現在選択されているメッセージに該当しない場合は、コマンドのインターフェースを無効にすると役立つ場合があります。
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.
コマンドラインまたはキーの組み合わせを利用するテキストベースのシステムでは、各フィールドを個別のコマンドとして実装できます。したがって、1つの組み合わせはユーザーをサブスクライブし、別の組み合わせはサブスクライブ解除し、3番目の要求ヘルプなどを行います。コマンドは、リストヘッダーフィールドを含むメッセージでのみ使用できます。
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」という名前のヘッダーフィールドを含むメッセージを表示すると、「Lists」メニューが表示される場合があります。アーカイブ"。現在のメッセージに該当しない場合、このメニューを無効にするか、完全に非表示にすることができます。
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.
グラフィカルウィンドウシステムでは、メッセージのウィンドウ、ツールバー、または独自のフローティングパレットにボタンを配置できます。各ボタンは、「購読」、「購読解除」、「ヘルプ」、「リストに投稿」、「リストの所有者」、「アーカイブ」という名前のコマンドに対応します。これらのボタンまたはパレットは、現在のメッセージに適用できない場合や、完全に表示されない場合に無効にすることができます。
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.
ダイアログインターフェイス（または他のフィードバック要素）を使用する場合、クライアントアプリケーションは、メッセージが送信される前にユーザーがメッセージを確認（および場合によっては変更）するためのオプションを含める必要があります。また、メールリストへのアクセス全般に関する状況に応じた詳細な支援へのリンクを提供すると、アプリケーションで役立つ場合があります。
References
参考文献
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)" RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」RFC 1738、1994年12月。
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997.
[RFC2142] Crocker、D。、「Common Services、Roles、およびFunctionsのメールボックス名」、RFC 2142、1997年5月。
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2368] Hoffman、P.、Masinter、L。、およびJ. Zawinski、「mailto URLスキーム」、RFC 2368、1998年7月。
[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>
Editors' Addresses
編集者のアドレス
Joshua D. Baer Box 273 4902 Forbes Avenue Pittsburgh, PA 15213-3799 USA
Joshua D. Baer Box 273 4902 Forbes Avenue Pittsburgh、PA 15213-3799 USA
EMail: josh@skyweyr.com
Grant Neufeld Calgary, Alberta Canada
グラントノイフェルドカルガリー、アルバータ州カナダ
EMail: grant@acm.org
Web: http://www.nisto.com/
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。