usefor-article-03 February 2000
[< Prev]
[TOC] [ Next >]
11. Acknowledgements
[It is intended to insert a list of those who have been prominent
contributors to the mailing list of the working group at this point.]
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../rfc2822/Acknowledgements.out April 2001
+++ ../usefor-article-03/Acknowledgements.out February 2000
@@ -1,457 +1,5 @@
-8. Acknowledgements
+11. Acknowledgements
- Many people contributed to this document. They included folks who
- participated in the Detailed Revision and Update of Messaging
- Standards (DRUMS) Working Group of the Internet Engineering Task
- Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
- people who simply sent their comments in via e-mail. The editor is
- deeply indebted to them all and thanks them sincerely. The below
- list includes everyone who sent e-mail concerning this document.
- Hopefully, everyone who contributed is named here:
-
- Matti Aarnio Barry Finkel Larry Masinter
- Tanaka Akira Erik Forsberg Denis McKeon
- Russ Allbery Chuck Foster William P McQuillan
- Eric Allman Paul Fox Alexey Melnikov
- Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger
- Ran Atkinson Ned Freed Steven Miller
- Jos Backus Jochen Friedrich Keith Moore
- Bruce Balden Randall C. Gellens John Gardiner Myers
- Dave Barr Sukvinder Singh Gill Chris Newman
- Alan Barrett Tim Goodwin John W. Noerenberg
- John Beck Philip Guenther Eric Norman
- J. Robert von Behren Tony Hansen Mike O'Dell
- Jos den Bekker John Hawkinson Larry Osterman
- D. J. Bernstein Philip Hazel Paul Overell
- James Berriman Kai Henningsen Jacob Palme
- Norbert Bollow Robert Herriot Michael A. Patton
- Raj Bose Paul Hethmon Uzi Paz
- Antony Bowesman Jim Hill Michael A. Quinlan
- Scott Bradner Paul E. Hoffman Eric S. Raymond
- Randy Bush Steve Hole Sam Roberts
- Tom Byrer Kari Hurtta Hugh Sasse
- Bruce Campbell Marco S. Hyman Bart Schaefer
- Larry Campbell Ofer Inbar Tom Scola
- W. J. Carpenter Olle Jarnefors Wolfgang Segmuller
- Michael Chapman Kevin Johnson Nick Shelness
- Richard Clayton Sudish Joseph John Stanley
- Maurizio Codogno Maynard Kang Einar Stefferud
- Jim Conklin Prabhat Keni Jeff Stephenson
- R. Kelley Cook John C. Klensin Bernard Stern
- Steve Coya Graham Klyne Peter Sylvester
- Mark Crispin Brad Knowles Mark Symons
- Dave Crocker Shuhei Kobayashi Eric Thomas
- Matt Curtin Peter Koch Lee Thompson
- Michael D'Errico Dan Kohn Karel De Vriendt
- Cyrus Daboo Christian Kuhtz Matthew Wall
- Jutta Degener Anand Kumria Rolf Weber
- Mark Delany Steen Larsen Brent B. Welch
- Steve Dorner Eliot Lear Dan Wing
- Harold A. Driscoll Barry Leiba Jack De Winter
- Michael Elkins Jay Levitt Gregory J. Woodhouse
- Robert Elz Lars-Johan Liman Greg A. Woods
- Johnny Eriksson Charles Lindsey Kazu Yamamoto
- Erik E. Fair Pete Loshin Alain Zahm
- Roger Fajman Simon Lyall Jamie Zawinski
- Patrik Faltstrom Bill Manning Timothy S. Zurcher
- Claus Andre Farber John Martin
-Appendix A. Example messages
-
- This section presents a selection of messages. These are intended to
- assist in the implementation of this standard, but should not be
- taken as normative; that is to say, although the examples in this
- section were carefully reviewed, if there happens to be a conflict
- between these examples and the syntax described in sections 3 and 4
- of this document, the syntax in those sections is to be taken as
- correct.
-
- Messages are delimited in this section between lines of "----". The
- "----" lines are not part of the message itself.
-
-A.1. Addressing examples
-
- The following are examples of messages that might be sent between two
- individuals.
-
-A.1.1. A message from one person to another with simple addressing
-
- This could be called a canonical message. It has a single author,
- John Doe, a single recipient, Mary Smith, a subject, the date, a
- message identifier, and a textual message in the body.
-
-----
-From: John Doe <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-This is a message just to say hello.
-So, "Hello".
-----
- If John's secretary Michael actually sent the message, though John
- was the author and replies to this message should go back to him, the
- sender field would be used:
-
-----
-From: John Doe <jdoe@machine.example>
-Sender: Michael Jones <mjones@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
-A.1.2. Different types of mailboxes
-
- This message includes multiple addresses in the destination fields
- and also uses several different forms of addresses.
-
-----
-From: "Joe Q. Public" <john.q.public@example.com>
-To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
-Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
-Date: Tue, 1 Jul 2003 10:52:37 +0200
-Message-ID: <5678.21-Nov-1997@example.com>
-
-Hi everyone.
-----
-
- Note that the display names for Joe Q. Public and Giant; "Big" Box
- needed to be enclosed in double-quotes because the former contains
- the period and the latter contains both semicolon and double-quote
- characters (the double-quote characters appearing as quoted-pair
- construct). Conversely, the display name for Who? could appear
- without them because the question mark is legal in an atom. Notice
- also that jdoe@example.org and boss@nil.test have no display names
- associated with them at all, and jdoe@example.org uses the simpler
- address form without the angle brackets.
-A.1.3. Group addresses
-
-----
-From: Pete <pete@silly.example>
-To: A Group:Chris Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
-Cc: Undisclosed recipients:;
-Date: Thu, 13 Feb 1969 23:32:54 -0330
-Message-ID: <testabcd.1234@silly.example>
-
-Testing.
-----
-
- In this message, the "To:" field has a single group recipient named A
- Group which contains 3 addresses, and a "Cc:" field with an empty
- group recipient named Undisclosed recipients.
-
-A.2. Reply messages
-
- The following is a series of three messages that make up a
- conversation thread between John and Mary. John firsts sends a
- message to Mary, Mary then replies to John's message, and then John
- replies to Mary's reply message.
-
- Note especially the "Message-ID:", "References:", and "In-Reply-To:"
- fields in each message.
-
-----
-From: John Doe <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-This is a message just to say hello.
-So, "Hello".
-----
- When sending replies, the Subject field is often retained, though
- prepended with "Re: " as described in section 3.6.5.
-
-----
-From: Mary Smith <mary@example.net>
-To: John Doe <jdoe@machine.example>
-Reply-To: "Mary Smith: Personal Account" <smith@home.example>
-Subject: Re: Saying Hello
-Date: Fri, 21 Nov 1997 10:01:10 -0600
-Message-ID: <3456@example.net>
-In-Reply-To: <1234@local.machine.example>
-References: <1234@local.machine.example>
-
-This is a reply to your hello.
-----
-
- Note the "Reply-To:" field in the above message. When John replies
- to Mary's message above, the reply should go to the address in the
- "Reply-To:" field instead of the address in the "From:" field.
-
-----
-To: "Mary Smith: Personal Account" <smith@home.example>
-From: John Doe <jdoe@machine.example>
-Subject: Re: Saying Hello
-Date: Fri, 21 Nov 1997 11:00:00 -0600
-Message-ID: <abcd.1234@local.machine.tld>
-In-Reply-To: <3456@example.net>
-References: <1234@local.machine.example> <3456@example.net>
-
-This is a reply to your reply.
-----
-
-A.3. Resent messages
-
- Start with the message that has been used as an example several
- times:
-
-----
-From: John Doe <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-This is a message just to say hello.
-So, "Hello".
-----
- Say that Mary, upon receiving this message, wishes to send a copy of
- the message to Jane such that (a) the message would appear to have
- come straight from John; (b) if Jane replies to the message, the
- reply should go back to John; and (c) all of the original
- information, like the date the message was originally sent to Mary,
- the message identifier, and the original addressee, is preserved. In
- this case, resent fields are prepended to the message:
-
-----
-Resent-From: Mary Smith <mary@example.net>
-Resent-To: Jane Brown <j-brown@other.example>
-Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
-Resent-Message-ID: <78910@example.net>
-From: John Doe <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
- If Jane, in turn, wished to resend this message to another person,
- she would prepend her own set of resent header fields to the above
- and send that.
-A.4. Messages with trace fields
-
- As messages are sent through the transport system as described in
- [RFC2821], trace fields are prepended to the message. The following
- is an example of what those trace fields might look like. Note that
- there is some folding white space in the first one since these lines
- can be long.
-
-----
-Received: from x.y.test
- by example.net
- via TCP
- with ESMTP
- id ABC12345
- for <mary@example.net>; 21 Nov 1997 10:05:43 -0600
-Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600
-From: John Doe <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: Fri, 21 Nov 1997 09:55:06 -0600
-Message-ID: <1234@local.machine.example>
-
-This is a message just to say hello.
-So, "Hello".
-----
-A.5. White space, comments, and other oddities
-
- White space, including folding white space, and comments can be
- inserted between many of the tokens of fields. Taking the example
- from A.1.3, white space and comments can be inserted into all of the
- fields.
-
-----
-From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
-To:A Group(Some people)
- :Chris Jones <c@(Chris's host.)public.example>,
- joe@example.org,
- John <jdoe@one.test> (my dear friend); (the end of the group)
-Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ;
-Date: Thu,
- 13
- Feb
-1969
- 23:32
- -0330 (Newfoundland Time)
-Message-ID: <testabcd.1234@silly.test>
-
-Testing.
-----
-
- The above example is aesthetically displeasing, but perfectly legal.
- Note particularly (1) the comments in the "From:" field (including
- one that has a ")" character appearing as part of a quoted-pair); (2)
- the white space absent after the ":" in the "To:" field as well as
- the comment and folding white space after the group name, the special
- character (".") in the comment in Chris Jones's address, and the
- folding white space before and after "joe@example.org,"; (3) the
- multiple and nested comments in the "Cc:" field as well as the
- comment immediately following the ":" after "Cc"; (4) the folding
- white space (but no comments except at the end) and the missing
- seconds in the time of the date field; and (5) the white space before
- (but not within) the identifier in the "Message-ID:" field.
-
-A.6. Obsoleted forms
-
- The following are examples of obsolete (that is, the "MUST NOT
- generate") syntactic elements described in section 4 of this
- document.
-A.6.1. Obsolete addressing
-
- Note in the below example the lack of quotes around Joe Q. Public,
- the route that appears in the address for Mary Smith, the two commas
- that appear in the "To:" field, and the spaces that appear around the
- "." in the jdoe address.
-
-----
-From: Joe Q. Public <john.q.public@example.com>
-To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example
-Date: Tue, 1 Jul 2003 10:52:37 +0200
-Message-ID: <5678.21-Nov-1997@example.com>
-
-Hi everyone.
-----
-
-A.6.2. Obsolete dates
-
- The following message uses an obsolete date format, including a non-
- numeric time zone and a two digit year. Note that although the
- day-of-week is missing, that is not specific to the obsolete syntax;
- it is optional in the current syntax as well.
-
-----
-From: John Doe <jdoe@machine.example>
-To: Mary Smith <mary@example.net>
-Subject: Saying Hello
-Date: 21 Nov 97 09:55:06 GMT
-Message-ID: <1234@local.machine.example>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
-A.6.3. Obsolete white space and comments
-
- White space and comments can appear between many more elements than
- in the current syntax. Also, folding lines that are made up entirely
- of white space are legal.
-----
-From : John Doe <jdoe@machine(comment). example>
-To : Mary Smith
-__
-<mary@example.net>
-Subject : Saying Hello
-Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
-Message-ID : <1234 @ local(blah) .machine .example>
-
-This is a message just to say hello.
-So, "Hello".
-----
-
- Note especially the second line of the "To:" field. It starts with
- two space characters. (Note that "__" represent blank spaces.)
- Therefore, it is considered part of the folding as described in
- section 4.2. Also, the comments and white space throughout
- addresses, dates, and message identifiers are all part of the
- obsolete syntax.
-
-Appendix B. Differences from earlier standards
-
- This appendix contains a list of changes that have been made in the
- Internet Message Format from earlier standards, specifically [RFC822]
- and [STD3]. Items marked with an asterisk (*) below are items which
- appear in section 4 of this document and therefore can no longer be
- generated.
-
- 1. Period allowed in obsolete form of phrase.
- 2. ABNF moved out of document to [RFC2234].
- 3. Four or more digits allowed for year.
- 4. Header field ordering (and lack thereof) made explicit.
- 5. Encrypted header field removed.
- 6. Received syntax loosened to allow any token/value pair.
- 7. Specifically allow and give meaning to "-0000" time zone.
- 8. Folding white space is not allowed between every token.
- 9. Requirement for destinations removed.
- 10. Forwarding and resending redefined.
- 11. Extension header fields no longer specifically called out.
- 12. ASCII 0 (null) removed.*
- 13. Folding continuation lines cannot contain only white space.*
- 14. Free insertion of comments not allowed in date.*
- 15. Non-numeric time zones not allowed.*
- 16. Two digit years not allowed.*
- 17. Three digit years interpreted, but not allowed for generation.
- 18. Routes in addresses not allowed.*
- 19. CFWS within local-parts and domains not allowed.*
- 20. Empty members of address lists not allowed.*
- 21. Folding white space between field name and colon not allowed.*
- 22. Comments between field name and colon not allowed.
- 23. Tightened syntax of in-reply-to and references.*
- 24. CFWS within msg-id not allowed.*
- 25. Tightened semantics of resent fields as informational only.
- 26. Resent-Reply-To not allowed.*
- 27. No multiple occurrences of fields (except resent and received).*
- 28. Free CR and LF not allowed.*
- 29. Routes in return path not allowed.*
- 30. Line length limits specified.
- 31. Bcc more clearly specified.
-
-Appendix C. Notices
-
- Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
+[It is intended to insert a list of those who have been prominent
+contributors to the mailing list of the working group at this point.]