0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0011
0012
0013
0014
0015
0016
0017
0018
0019
0020
0021
0022
0023
0024
0025
0026
0027
0028
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
0059
0060
0061
0062
0063
0064
0065
0066
0067
0068
0069
0070
0071
0072
0073
0074
0075
0076
0077
0078
0079
0080
0081
0082
0083
0084
0085
0086
0087
0088
0089
0090
0091
0092
0093
0094
0095
0096
0097
0098
0099
0100
0101
0102
0103
0104
0105
0106
0107
0108
0109
0110
0111
0112
0113
0114
0115
0116
0117
0118
0119
0120
0121
0122
0123
0124
0125
0126
0127
0128
0129
0130
0131
0132
0133
0134
0135
0136
0137
0138
0139
0140
0141
0142
0143
0144
0145
0146
0147
0148
0149
0150
0151
0152
0153
0154
0155
0156
0157
0158
0159
0160
0161
0162
0163
0164
0165
0166
0167
0168
0169
0170
0171
0172
0173
0174
0175
0176
0177
0178
0179
0180
0181
0182
0183
0184
0185
0186
0187
0188
0189
0190
0191
0192
0193
0194
0195
0196
0197
0198
0199
0200
0201
0202
0203
0204
0205
0206
0207
0208
0209
0210
0211
0212
0213
0214
0215
0216
0217
0218
0219
0220
0221
0222
0223
0224
0225
0226
0227
0228
0229
0230
0231
0232
0233
0234
0235
0236
0237
0238
0239
0240
0241
0242
0243
0244
0245
0246
0247
0248
0249
0250
0251
0252
0253
0254
0255
0256
0257
0258
0259
0260
0261
0262
0263
0264
0265
0266
0267
0268
0269
0270
0271
0272
0273
0274
0275
0276
0277
0278
0279
0280
0281
0282
0283
0284
0285
0286
0287
0288
0289
0290
0291
0292
0293
0294
0295
0296
0297
0298
0299
0300
0301
0302
0303
0304
0305
0306
0307
0308
0309
0310
0311
0312
0313
0314
0315
0316
0317
0318
0319
0320
0321
0322
0323
0324
0325
0326
0327
0328
0329
0330
0331
0332
0333
0334
0335
0336
0337
0338
0339
0340
0341
0342
0343
0344
0345
0346
0347
0348
0349
0350
0351
0352
0353
0354
0355
0356
0357
0358
0359
0360
0361
0362
0363
0364
0365
0366
0367
0368
0369
0370
0371
0372
0373
0374
0375
0376
0377
0378
0379
0380
0381
0382
0383
0384
0385
0386
0387
0388
0389
0390
0391
0392
0393
0394
0395
0396
0397
0398
0399
0400
0401
0402
0403
0404
0405
0406
0407
0408
0409
0410
0411
0412
0413
0414
0415
0416
0417
0418
0419
0420
0421
0422
0423
0424
0425
0426
0427
0428
0429
0430
0431
0432
0433
0434
0435
0436
0437
0438
0439
0440
0441
0442
0443
0444
0445
0446
0447
0448
0449
0450
0451
0452
0453
0454
0455
0456
0457
0458
0459
0460
0461
0462
0463
0464
0465
0466
0467
0468
0469
0470
0471
0472
0473
0474
0475
0476
0477
0478
0479
0480
0481
0482
0483
0484
0485
0486
0487
0488
0489
0490
0491
0492
0493
0494
0495
0496
0497
0498
0499
0500
0501
0502
0503
0504
0505
0506
0507
0508
0509
0510
0511
0512
0513
0514
0515
0516
0517
0518
0519
0520
0521
0522
0523
0524
0525
0526
0527
0528
0529
0530
0531
0532
0533
0534
0535
0536
0537
0538
0539
0540
0541
0542
0543
0544
0545
0546
0547
0548
0549
0550
0551
0552
0553
0554
0555
0556
0557
0558
0559
0560
0561
0562
0563
0564
0565
0566
0567
0568
0569
0570
0571
0572
0573
0574
0575
0576
0577
0578
0579
0580
0581
0582
0583
0584
0585
0586
0587
0588
0589
0590
0591
0592
0593
0594
0595
0596
0597
0598
0599
0600
0601
0602
0603
0604
0605
0606
0607
0608
0609
0610
0611
0612
0613
0614
0615
0616
0617
0618
0619
0620
0621
0622
0623
0624
0625
0626
0627
0628
0629
0630
0631
0632
0633
0634
0635
0636
0637
0638
0639
0640
0641
0642
0643
0644
0645
0646
0647
0648
0649
0650
0651
0652
0653
0654
0655
0656
0657
0658
0659
0660
0661
0662
0663
0664
0665
0666
0667
0668
0669
0670
0671
0672
0673
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

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.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

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.

   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.

Neufeld & Baer              Standards Track                     [Page 1]

RFC 2369                  URLs as Meta-Syntax                  July 1998

1. Introduction

   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.

   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.

   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].

2. The Command Syntax

   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].

   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.

Neufeld & Baer              Standards Track                     [Page 2]

RFC 2369                  URLs as Meta-Syntax                  July 1998

   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.

   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).

   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.

   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.

   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.

Neufeld & Baer              Standards Track                     [Page 3]

RFC 2369                  URLs as Meta-Syntax                  July 1998

   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. The List Header Fields

      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.

3.1. List-Help

      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.

      Examples:

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

3.2. List-Unsubscribe

   The List-Unsubscribe field describes the command (preferably using
   mail) to directly unsubscribe the user (removing them from the list).

   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>

Neufeld & Baer              Standards Track                     [Page 4]

RFC 2369                  URLs as Meta-Syntax                  July 1998

     List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
         <mailto:list-request@host.com?subject=unsubscribe>

3.3. List-Subscribe

   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>

3.4. List-Post

   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)

3.5. List-Owner

   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).

   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>

Neufeld & Baer              Standards Track                     [Page 5]

RFC 2369                  URLs as Meta-Syntax                  July 1998

3.6. List-Archive

   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)

4. Supporting Nested Lists

   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.

5. Security Considerations

   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

Neufeld & Baer              Standards Track                     [Page 6]

RFC 2369                  URLs as Meta-Syntax                  July 1998

   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.

6. Acknowledgements

   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.

   Keith Moore <moore@cs.utk.edu> and Christopher Allen
   <ChristopherA@consensus.com> provided guidance on the standards
   process.

Neufeld & Baer              Standards Track                     [Page 7]

RFC 2369                  URLs as Meta-Syntax                  July 1998

A. Background Discussion

   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.

A.1. Multiple header fields vs. a single header field

   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.

   Restricting the transport of meta-syntax to the use of a single
   header field also introduces complications with header field size
   limitations. Most individual commands can easily be described in a
   single line, but describing a multitude of commands can take up many
   lines in the field and runs a greater risk of being modified by an
   existing server on route.

   The client implementation is also easier with multiple fields, since
   each command can be supported and implemented individually,
   completely independent of the others. Thus, some list managers or
   mail clients can choose to implement a subset of the fields based on
   the specific needs of their individual lists.

   Finally, the format described in this document is simple and well
   recognized, which reduces the chances of errors in implementation and
   parsing.

A.2. URLs vs. parameter lists

   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.

Neufeld & Baer              Standards Track                     [Page 8]

RFC 2369                  URLs as Meta-Syntax                  July 1998

   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.

A.3. Why not just create a standard command language?

   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.

   Finally, client support for a standard command language is not at all
   clear or necessarily simple to implement. The variety and large
   number of commands existing today would require complicated user
   interfaces which could be confusing and difficult to implement. By
   restricting this proposal to the core functions, the client

   implementation is much simpler, which significantly increases the
   likelihood of implementation (as evidenced by the support already
   announced by a number of client and server application authors).

A.4. Internationalization

   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.

Neufeld & Baer              Standards Track                     [Page 9]

RFC 2369                  URLs as Meta-Syntax                  July 1998

A.5. Variable Substitution

   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.

   Parameters would either have to be mandatory (i.e. the user agent
   doesn't submit the message if it doesn't know what text to
   substitute) or you need a way to say "if you know this parameter, add
   its text here; otherwise, do this" where "this" is either: (a)
   substitute a constant string, or (b) fail.

   The reason you would want a facility like this is because some list
   server applications insist on having certain parameters like users'
   names, which the user agent might or might not know. e.g. listserv
   insists on having a first name and a last name if you supply either
   one.

   Which could lead to something like the UNIX shell syntax, where
   ${foo-bar} means substitute the value of parameter "foo" if "foo" is
   defined, else substitute the string "bar". Perhaps $foo would mean
   "substitute the value of parameter foo if it is defined, else
   substitute the empty string"

   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.

A.6. Why not use a specialized MIME part instead of header fields?

   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.

   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.

Neufeld & Baer              Standards Track                    [Page 10]

RFC 2369                  URLs as Meta-Syntax                  July 1998

A.7. Why include a Subscribe command?

   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.

A.8. The Dangers of Header Bloat

   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.

   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.

Neufeld & Baer              Standards Track                    [Page 11]

RFC 2369                  URLs as Meta-Syntax                  July 1998

B. Client Implementation

B.1. Guidelines

   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:

     "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."

   If the user has multiple email addresses supported by the mail
   client, the client application should prompt the user for which
   address to use when subscribing or performing some other action where
   the address to use cannot be specifically determined. When
   unsubscribing or such, the address that is subscribed should be used,
   unless that is not known by the application and cannot be determined
   from the message headers.

B.2. Implementation Options

   The following implementation possibilities are suggested here to give
   some idea as to why these new header fields will be useful, and how
   they could be supported.

   In most cases, it may be helpful to disable the interface for the
   commands when not applicable to the currently selected message.

B.2.1. Key combinations and command lines

   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.

B.2.2. Menu items

   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

Neufeld & Baer              Standards Track                    [Page 12]

RFC 2369                  URLs as Meta-Syntax                  July 1998

   List", "Contact List Owner" and "Access List Archive". This menu
   could be disabled when not applicable to the current message or
   disappear entirely.

B.2.3. Push Buttons and Pallettes

   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.

B.2.4 Feedback to the User

   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.

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

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

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

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

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

Neufeld & Baer              Standards Track                    [Page 13]

RFC 2369                  URLs as Meta-Syntax                  July 1998

Editors' Addresses

   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/

Neufeld & Baer              Standards Track                    [Page 14]

RFC 2369                  URLs as Meta-Syntax                  July 1998

Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   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.

Neufeld & Baer              Standards Track                    [Page 15]

Search by Algolia