Network Working Group G. Neufeld
Request for Comments: 2369 Nisto
Category: Standards Track J. Baer
SkyWeyr Technologies
July 1998
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.
版权所有（C）互联网协会（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]），用于定位相关信息或直接执行命令。本文档中描述的三个核心标题字段是列表帮助、列表订阅和列表取消订阅。
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.
这里还描述了三个其他标题字段，虽然应用范围不太广泛，但对于足够数量的邮件列表来说，这些标题字段很有用，可以证明它们在这里的形式化。它们是列表帖子、列表所有者和列表存档。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
实现这些字段是可选的。然而，通过包含它们，可以获得显著的功能性和便利性。许多列表管理员，尤其是在提案首次获得接受时，可能会选择只实现一个或两个字段。列表帮助字段是最有用的单个字段，因为它提供了详细用户支持信息的访问点，并且容纳了几乎所有现有的列表管理器命令集。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不得在括号内插入空格，但客户端应用程序应将任何可能由行为不良的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具有从左到右的优先顺序。客户端应用程序应该使用它支持的最左边的协议，或者知道如何通过单独的应用程序进行访问。通过这种机制，可以指定http之类的协议，同时仍然为那些无法访问非邮件协议的客户机提供基本的mailto支持。客户端应仅为命令使用一个可用URL，仅当第一个使用失败时才使用另一个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]将是列表头字段大多数使用的焦点。应根据那些无法访问指定机制的用户（那些只有电子邮件，没有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.
此实现不支持要求客户端设置变量字段的命令语法（例如在命令中包含用户的电子邮件地址）。然而，使用这种语法的系统仍然应该利用列表帮助字段为用户提供所需的详细说明，或者——也许更有用——提供对某种形式的结构化命令界面（如基于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) 除特定字段的注释外，如果字段内容（在任何前导空格后，包括注释）以除开头角括号“<”以外的任何字符开头，则应忽略该字段。
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，则应忽略字段的其余部分（当前和所有后续子项）。
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.
本文档提供了标题字段，这些字段将为大多数电子邮件通讯组列表的“核心”和关键辅助功能提供命令语法描述。给定列表上实现的字段应包含在列表分发的所有消息（包括对单个用户的命令响应）中，以及消息明确应用于一个不同列表的其他消息中。在任何给定消息中，每个字段不得超过一个。
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.
列表帮助字段是本文档中描述的最重要的标题字段。列表管理器只包含此字段是可以接受的，因为根据定义，它应该指导用户完成所有其他命令的说明。通常，指定的URL会请求帮助文件，可能包含列表命令的HTML表单，或者提供对指导性网站的访问。
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>
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: <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>
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).
列表订阅字段描述直接订阅用户（请求添加到列表）的命令（最好使用邮件）。
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>
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".
列表过帐字段描述过帐到列表的方法。这通常是列表的地址，但可能是版主，也可能是其他形式的提交。对于不允许发布的列表（例如公告列表）的特殊情况，列表发布字段可能包含特殊值“否”。
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)
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).
列表所有者字段标识与列表管理员联系的路径。URL可能包含列表管理员、邮件系统管理员或任何其他可以处理列表用户联系人的人的地址。如果列表所有者与邮件系统管理员（邮政局长）是同一个人，则无需指定列表所有者。
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>
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.
列表存档字段描述如何访问列表的存档。
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)
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.
作为嵌套邮件列表层次结构中另一个列表的子列表的列表将需要修改一些列表标题字段，而将其他字段保留为父列表设置字段。
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.
子列表应删除父列表的列表帮助、列表订阅、列表取消订阅和列表所有者字段，并应插入这些字段的自己版本。
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.
如果子列表提供了自己的存档，则应将列表存档替换为自己的存档。否则，它必须保持列表存档字段不变。
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.
根据如何处理向列表的过账，子列表可以替换列表过账字段。是否更换名单员额的适当性由各名单管理人员决定。如果目的是将帖子分发给主列表的所有成员，则子列表不应更改列表帖子，因为帖子将仅分发给子列表的成员。
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.
这项提议很少产生新的安全问题。消息头是一种现有的标准，旨在方便地容纳新类型。可能存在插入多个字段或伪造标题的问题，但这些是Internet电子邮件中固有的问题，不特定于本文档中描述的协议。此外，这些影响相对无害。
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
在客户端，可能会有一些关于错误发送帖子或命令的问题。要求用户在执行任何操作之前有机会确认该操作。就mailto而言，它
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.
可能适合在不发送的情况下创建格式正确的消息，允许用户准确地看到发生了什么，并允许用户在发送消息之前批准或放弃消息。
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.
列表标题[5]、ListMom Talk[6]、列表管理员和MIDA邮件列表的众多参与者对本文档的形成和结构做出了很大贡献。
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.
这样一个字段需要创建一个新的元语法来描述list命令（而不是使用广泛部署的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.
最后，本文中描述的格式简单且易于识别，这减少了实现和解析中出现错误的机会。
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，也可以通过将请求传递给帮助程序应用程序来识别、解析和评估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支持它，那么列表标题字段支持它。这是将URL用作列表标题字段的构建块的另一个优点。
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.
变量将允许列表标题字段容纳几乎所有现有的列表管理器。然而，这将极大地增加整个方案的复杂性，可能涉及重新定义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.
参数必须是强制性的（即，如果用户代理不知道要替换的文本，则不会提交消息），或者您需要一种方式来说“如果您知道此参数，请在此处添加其文本；否则，请执行此操作”，其中“this”是：（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.
您需要这样一个功能的原因是，一些列表服务器应用程序坚持使用某些参数，例如用户名，而用户代理可能知道也可能不知道。e、 g.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 shell语法的情况，其中${foo bar}表示如果定义了“foo”，则替换参数“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命令标题字段，但帮助字段仍将为最终用户提供一致的访问点，通过该访问点，他们可以获得对列表使用的支持。
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部分的设计，以便更全面地描述list命令语法，并试图找到使其得到适用软件支持的方法。
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.
此外，已取消订阅的用户（在度假前或出于其他原因）可能希望重新订阅列表。或者，消息可以从订阅者转发/反弹到非订阅者。或者，用户可能会更改地址并希望从其新地址订阅。在所有这些情况下，让列表订阅字段可用肯定会有所帮助。
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.
在什么情况下标题字段太多？事实上，每一个列表都有所不同。在某些列表中，大多数用户永远不会知道某个字段，除非客户机软件为其提供了某种替代用户界面（类似于回复字段）。在其他情况下，用户通常会看到消息的标题字段，并且能够识别其中包含的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."
"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."translate error, please retry
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.
在使用命令行或键组合的基于文本的系统上，每个字段都可以作为单独的命令来实现。因此，一个组合将订阅用户，另一个组合将取消订阅，第三个组合将请求帮助，等等。这些命令仅在包含列表头字段的消息上可用。
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.
“列表”、“联系人列表所有者”和“访问列表存档”。当不适用于当前邮件时，此菜单可能被禁用或完全消失。
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，“统一资源定位器（URL）”RFC 17381994年12月。
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997.
[RFC2142]Crocker，D.，“公共服务、角色和功能的邮箱名称”，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，“邮件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/>
[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>
[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
美国宾夕法尼亚州匹兹堡福布斯大道273 4902号约书亚·D·贝尔信箱15213-3799
EMail: josh@skyweyr.com
EMail: josh@skyweyr.com
Grant Neufeld Calgary, Alberta Canada
加拿大阿尔伯塔省格兰特纽菲尔德卡尔加里市
EMail: grant@acm.org
Web: http://www.nisto.com/
EMail: grant@acm.org
Web: http://www.nisto.com/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。