idnits 2.17.1 draft-baer-listspec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 22, 1997) is 9896 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 466, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '1') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1738 (ref. '3') (Obsoleted by RFC 4248, RFC 4266) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Grant Neufeld 3 draft-baer-listspec-00.txt independent developer 4 Expires August 27, 1997 Joshua D. Baer 5 SkyWeyr Technologies 6 March 22, 1997 8 The Use of URLs as Meta-Syntax for Core Mail List Commands 9 and their Transport through Message Header Fields 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check 25 the ``1id-abstracts.txt'' listing contained in the Internet- 26 Drafts Shadow Directories on ftp.is.co.za (Africa), 27 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 The mailing list command specification header fields are a simple set 33 of fields to be added to email messages sent by email distribution 34 lists. Each field contains a URL (usually mailto or http) locating 35 the relevant information or performing the command directly. The 36 three core header fields described in this document are List-Help, 37 List-Subscribe, and List-Unsubscribe. 39 By including these header fields, mail clients can provide automated 40 tools for performing these functions. This could take the form of a 41 menu item, push button, or other user interface element. The intent 42 is to simplify the user experience, providing a common interface to 43 the often cryptic and varied mailing list manager commands. 45 1. Introduction 47 This is a proposal for additional header fields to be added to email 48 messages sent by email distribution lists. The content of each new 49 header is a URL (usually mailto or http) locating the relevant 50 information or performing the command directly. The three core 51 headers are List-Help, List-Subscribe, and List-Unsubscribe. 53 Implementing these headers will be optional. Significant 54 functionality and convenience can be gained by including them, 55 however. Many list managers, especially as the proposal first gains 56 acceptance, may only choose to implement one or two of the headers. 57 The List-Help header is the most useful individual header since it 58 provides an access point to detailed user support information, and 59 accommodates almost all existing list managers command sets. The 60 List-Subscribe and List-Unsubscribe headers are also very useful, but 61 cannot describe some list manager syntaxes at this time (those which 62 require variable substitution). See the appendix for an explanation. 64 The description of command syntax provided by the headers can be used 65 by mail client applications to provide simplified and consistent user 66 access to email distribution list functions. This could take the 67 form of menu items, push buttons, or other user interface elements. 68 The intent is to simplify the user experience, providing a common 69 interface to the often cryptic and varied mailing list manager 70 commands. 72 Consideration has been given to avoiding the creation of too many 73 headers, while at the same time avoiding the overloading of 74 individual headers and keeping the syntax clear and simple. 76 2. The Command Syntax 78 The contents of the list headers consist of angle-bracket ('<', '>') 79 enclosed URLs, with internal whitespace being ignored. 81 The use of URLs allows for the use of the syntax with existing URL 82 supporting applications. As the standard for URLs is extended, the 83 list headers will gain the benefit of those extensions. 84 Additionally, the use of URLs provides access to multiple transport 85 protocols (such as ftp and http) although it is expected that the 86 "mailto" protocol will be the focus of most use of the list headers. 88 Command syntaxes requiring variable fields to be set by the client 89 (such as including the user's email address within a command) are not 90 supported by this implementation at this time. However, systems 91 using such syntaxes may still take advantage of the List-Help header 92 to provide the user with detailed instructions as needed or - 93 perhaps more usefully - provide access to a web based command 94 interface. 96 The additional complications of supporting variable fields within the 97 command syntax was determined to be too difficult to support at this 98 stage and would compromise the likelihood of implementation by 99 software authors. 101 To allow for future extension, client applications must follow the 102 following guidelines for handling the contents of the headers 103 described in this document: 105 1) If the content of the header (following any leading whitespace) 106 begins with any character other than the opening angle bracket 107 '<', the header should be ignored. 108 2) Any characters in the header after the first closing angle 109 bracket '>' are to be ignored. 111 3. The Core Headers 113 This document presents three headers which will provide the command 114 syntax description for the 'core' functions of most email 115 distribution lists. The headers implemented on a given list should 116 be included on all posts to the list, and on other messages where the 117 message clearly applies to one distinct list. Only one header of 118 each type should be present in any given message, to avoid any 119 confusion on the part of the mail client. 121 The headers are presented in order of suggested priority. 123 3.1. List-Help 125 The List-Help header is the most important of these header fields. 126 It would be perfectly acceptable for a list manager to include only 127 this header, since by definition it should direct the user to 128 complete instructions for all other commands. Typically, this would 129 return the help file for the list or a web page with list 130 instructions. Of all four headers, this one is the most likely 131 candidate for an http URL rather than a mailto, since a web page can 132 be used to provide a lot more information about the list, as well as 133 a form interface for command access. 135 Examples: 137 List-Help: 138 List-Help: 139 List-Help: 140 List-Help: 141 List-Help: 143 3.2. List-Unsubscribe 145 The URL of the List-Unsubscribe header should generally describe the 146 mail message (mailto) to directly unsubscribe the user (removing them 147 from the list). Alternately, the URL may connect the user to some 148 other mechanism (such as a web page) which performs this function. 150 Examples: 152 List-Unsubscribe: 153 List-Unsubscribe: 154 155 List-Unsubscribe: 156 157 List-Unsubscribe: 158 List-Unsubscribe: 160 3.3. List-Subscribe 162 The URL of the List-Subscribe header should generally describe the 163 mail message (mailto) to directly subscribe the user (requesting 164 addition to the list). Alternately, the URL may connect the user to 165 some other mechanism (such as a web page ) which performs this 166 function. 168 Examples: 170 List-Subscribe: 171 List-Subscribe: 172 List-Subscribe: 173 174 List-Subscribe: 175 List-Subscribe: 177 4. Security Considerations 179 There are very few new security concerns generated with this 180 proposal. Headers are an existing standard, designed to easily 181 accommodate new types. There may be concern with multiple headers 182 being inserted or headers being forged, but these are problems 183 inherent in Internet email, not specific to this proposal. Further, 184 the implications are relatively harmless. 186 Mail list processors should not allow any user-originated list header 187 fields to pass through to their lists, lest they confuse the user and 188 have the potential to create security problems. 190 On the client side, there may be some concern with posts or commands 191 being sent in error. It is suggested that the user have a chance to 192 confirm any action before it is executed. In the case of mailto, it 193 may be appropriate to create the correctly formatted message without 194 sending it, allowing the user to see exactly what is happening and 195 giving the user the ability to stop the message before it is sent. 197 Mail client applications should not support list header field URLs 198 which could compromise the security of the user's system. This 199 includes the "file://" URL type which could potentially be used to 200 trigger the execution of a local application on some user systems. 202 5. Acknowledgements 204 The participants of the ListMom-Talk, List-Managers, MIDA-Mail and 205 List-Header mailing lists contributed much to the formation and 206 structure of this document. 208 Keith Moore and Christopher Allen 209 provided guidance on the standards 210 process. 212 Appendix 214 A. Background Discussion 216 This proposal arose from discussions started on the ListMom-Talk 217 Discussion List [2]. When the discussion reached a sufficient level, 218 a separate list was formed for discussing this proposal, the List 219 Headers Mail List [3] for deeper discussion. We have included edited 220 excerpts from that discussion here, in order to show some of the 221 alternatives examined and reasons for our decisions. 223 A.1. Multiple header fields vs. a single header field 225 Use of a single header field for transporting command meta-syntax was 226 rejected for a number of reasons. 228 Such a header would require the creation of a new meta-syntax in 229 order to describe the list commands (as opposed to the use of the 230 widely deployed URL syntax which was chosen for this implementation). 231 Every additional layer of complexity and newness reduces the 232 likelihood of actual implementation because it will require 233 additional work to support. Also, by using the existing URL syntax, 234 we can profit from the end users' knowledge of that syntax and 235 ability to use it even if their client applications do not support 236 the list header fields. 238 Restricting the transport of meta-syntax to the use of a single 239 header field also introduces complications with header size 240 limitations. Most individual commands can easily be described in a 241 single line, but describing a multitude of commands can take up many 242 lines in the header and runs a greater risk of being modified by an 243 existing server on route. 245 The client implementation is also easier with multiple headers, since 246 each command can be supported and implemented individually, 247 completely independent of the others. Thus, some list managers or 248 mail clients can choose to implement a subset of the headers based on 249 the specific needs of their individual lists. 251 Finally, this format is simple and well recognized, which reduces the 252 chances of errors in implementation and parsing. 254 A.2. URLs vs. parameter lists 256 URLs are already an established syntax which is flexible, 257 well-defined, and in wide spread use. As its definition matures and 258 expands, the abilities of the list headers will grow as well, without 259 requiring modification of this proposal. URLs are well prepared to 260 handle future protocols and developments, and can easily describe the 261 different existing access protocols such as mailto, http and ftp. 263 Many clients already have functionality for recognizing, parsing, and 264 evaluating URLs, either internally or by passing the request to a 265 helper application. This makes implementation easier and more 266 realistic. As an example, this existing support for URL parsing 267 allowed us to add prototype list header functionality to existing 268 mail clients (Eudora and Emailer for the Macintosh) without modifying 269 the source code. 271 A.3. Why not just create a standard command language? 273 A standard command language, supported by all email list services, 274 would go a long way to reducing the problems of list access that 275 currently plague existing services. It would reduce the amount of 276 learning required by end users and allow for a number of common 277 support tools to be developed. 279 However, such standardization does pose problems in the areas of 280 multi-lingual support and the custom needs of individual mailing 281 lists. The development of such a standard is also expected to be met 282 with a slow adoption rate by software developers and list service 283 providers. 285 These do not preclude the development of such a standard (in fact, it 286 would suggest that we should start sooner rather than later), but we 287 do need a solution that can be widely supported by the current list 288 services. 290 We can support most existing list manager command syntaxes without a 291 standard command language. By using URLs, we allow alternate access 292 methods a standard command language probably wouldn't enable, such as 293 web based control. 295 Finally, client support for a standard command language is not at all 296 clear or simple to implement. The variety and large number of 297 commands existing today would require complicated user interfaces 298 which could be confusing and difficult to implement. By restricting 299 this proposal to the core functions, the client implementation is 300 much simpler, which significantly increases the likelihood of 301 implementation (as evidenced by the support already announced by some 302 client and server application authors) and makes the entire proposal 303 more realistic. 305 A.4. Internationalization 307 Multilingual support is up to the URL standard. If URLs support it, 308 this proposal supports. This is another advantage of using URLs as 309 the building blocks of the headers. 311 A.5. Variable Substitution 313 Variables would allow this proposal to accommodate pretty much every 314 existing list manager. However, it would immeasurably increase the 315 complexity of the entire proposal, and possibly involve redefining 316 the URL standard. 318 Parameters would either have to be mandatory (i.e. the user agent 319 doesn't submit the message if it doesn't know what text to 320 substitute) or you need a way to say "if you know this parameter, add 321 its text here; otherwise, do this" where "this" is either: (a) 322 substitute a constant string, or (b) fail. 324 The reason you would want a facility like this is because some list 325 server applications insist on having certain parameters like users' 326 names, which the user agent might or might not know. e.g. listserv 327 insists on having a first name and a last name if you supply either 328 one. 330 Which would lead to something like the UNIX shell syntax, where 331 ${foo-bar} means substitute the value of parameter "foo" if "foo" is 332 defined, else substitute the string "bar". Perhaps $foo would mean 333 "substitute the value of parameter foo if it is defined, else 334 substitute the empty string" 336 This all seems far too complicated for the gains involved, especially 337 since the use of variables can often be avoided. 339 The use of variables in the command syntaxes of list services appears 340 to be lessening and does not, in any case, apply to all commands. 341 While the unsubscribe and subscribe command header fields may not be 342 usable by those systems which require the use of variables, the help 343 field will still provide end users with a consistent point of access 344 through which they can get support for their use of the list. 346 A.6. Why not use a specialized MIME part instead of header fields? 348 MIME parts were considered, but because most mail clients currently 349 either don't support MIME or are not equipped to handle such 350 specialized parts - such an implementation would in problems for end 351 users. It is also not as easy for many list servers to implement 352 MIME as it is to implement new headers. 354 However, we are looking at how to implement MIME support in the 355 future when the software is able to handle it. 357 A.7. Why include a Subscribe command? 359 Subscribe and Unsubscribe are the key commands needed by almost every 360 list. Other commands, such as digest mode, are not as widely 361 supported. 363 Additionally, users who have unsubscribed (before going on vacation, 364 or for whatever other reason) may want to resubscribe to a list. Or, 365 a message may be forwarded/bounced from a subscriber to a 366 non-subscriber. Or, the user may change addresses and want to 367 subscribe from their new address. Having the List-Subscribe header 368 available could certainly help in all these cases. 370 A.8. The Dangers of Header Bloat 372 At what point are there just too many header fields? It really 373 varies on a list by list basis. On some lists, the majority of users 374 will never be aware of a field unless the client software provides 375 some alternative user interface to it (akin to the Reply-To header). 376 On others, the users will often see the header fields of messages and 377 would be able to recognize the function of the URLs contained within. 379 We feel the flexibility afforded by this proposal (in that the 380 header fields may be individually implemented as deemed appropriate) 381 provides list administrators with sufficient 'room to maneuver' to 382 meet their individual needs. 384 A.9. Additional header fields for future consideration 386 Some of the other headers fields which have been considered, but 387 which have been set aside for further study, are as follows: 389 List-Digest: a command URL to switch to digest mode. 390 List-Post: email address to post to as a mailto URL. 391 List-Admin: contact URL for list administrator (usually a human). 392 List-Archive: access URL for list archives (old messages). 393 List-Software: list processing software name and version 395 B. Client Implementation 397 B.1. Guidelines 399 For 'mailto' URL based commands, mail client applications should 400 provide specialized feedback (such as presenting a dialog or alert), 401 instead of the actual command email message, asking for command 402 confirmation from the user. The feedback should identify the message 403 destination and command within a more descriptive explanation. For 404 example: 406 "Do you want to send the unsubscription command 'unsubscribe 407 somelist' to 'somelist-request@some.host.com'? 408 Sending the command will result in your removal from the 409 associated list." 411 If the user has multiple email addresses supported by the mail 412 client, the client application should prompt the user for which 413 address to use when subscribing or performing some other action where 414 the address to use cannot be specifically determined. When 415 unsubscribing or such, the address that is subscribed should be used, 416 unless that is not known by the application and cannot be determined 417 from the message headers. 419 B.2. Implementation Options 421 The following implementation possibilities are suggested here to give 422 some idea why these new headers will be useful, and how they could be 423 supported. Prototype menu items and floating pallettes have already 424 been implemented in more than one mail client. 426 In most cases, it may be helpful to disable the commands when not 427 applicable to the currently selected message. 429 B.2.1. Key combinations and command lines 431 On text based systems which utilize command lines or key 432 combinations, each header could be implemented as a separate command. 433 Thus one combination would subscribe the user, another would 434 unsubscribe, a third request help, etc. The commands would only be 435 available on messages containing the list headers. 437 B.2.2. Menu items 439 On graphical systems which have menus, these commands could take the 440 form of a menu or sub-menu of items. For example, a "Lists" menu 441 might appear when viewing messages containing the headers, with items 442 named "Subscribe", "Unsubscribe" and "Get Help". This menu could be 443 disabled when not applicable to the current message or disappear 444 entirely. 446 B.2.3. Push Buttons and Pallettes 448 On graphical window systems, buttons could be placed in the window of 449 the message, a toolbar, or in a floating pallette of their own. Each 450 button could correspond to a header, with names "Subscribe", 451 "Unsubscribe" and "Get Help". These buttons or pallettes could be 452 disabled when not applicable to the current message or disappear 453 entirely. 455 B.2.4 Feedback to the User 457 When putting up a dialog (or other feedback element) the client 458 application may find it useful to include an option for the user to 459 review (and possibly modify) the message before it is sent. The 460 application may also find it useful to provide a link to more 461 detailed context-sensitive assistance about mail list access in 462 general. 464 References 466 [1] David H. Crocker, "Standard for the Format of ARPA 467 Internet Text Messages" RFC 822, August 1982. 468 470 [2] P. Hoffman and L. Masinter, "The mailto URL scheme" 471 'work in progress' January 1997. 474 [3] T. Berners-Lee, L. Masinter and M. McCahill, 475 "Uniform Resource Locators (URL)" RFC 1738, December 1994. 476 478 Editors' addresses 480 Joshua D. Baer 481 Box 273 482 4902 Forbes Avenue 483 Pittsburgh, PA 15213-3799 484 USA 486 Email: josh@skyweyr.com 488 Grant Neufeld 489 Ottawa, Ontario 490 Canada 492 Email: grant@acm.org 494 This document expires August 27, 1997