I always put Acknowledgements sections early in my documents. It's
sometimes a bit arbitrary who is listed as an author and who is listed
as contributing. If you have have one to three authors and handful of
contributors, seems like they both should be pretty prominent. On the
other hand, if you dump in the name of anyone who ever sent in any email
or showed up at any meeting as a "contributor", as some standards
organizations do, then burying the resulting huge list at the end of the
doucment is fine.
Donald
======================================================================
Donald E. Eastlake 3rd
dee3(_at_)torque(_dot_)pothole(_dot_)com
155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w)
Milford, MA 01757 USA
Donald(_dot_)Eastlake(_at_)motorola(_dot_)com
On Tue, 21 May 2002, Randall Gellens wrote:
Date: Tue, 21 May 2002 17:10:03 -0700
From: Randall Gellens <randy(_at_)QUALCOMM(_dot_)COM>
To: rfc-editor(_at_)rfc-editor(_dot_)org, iesg(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org
Subject: Comment on 'RFC Editor Guidelines on Author Lists'
There is no fixed position for a Contributors
section or an Acknowledgments section within the body of the RFC. If
they appear, they must appear later than the Abstract section and
earlier than the Author's Address section.
It seems to me that these sections are most often at the end, just
prior to the Author's Address. I'd like to see some recommendation
to continue this, or at least acknowledge it as common practice,
because I think it would detract from most documents to have such
sections appear early.
At 5:58 PM -0400 5/20/02, The IESG wrote:
The RFC Editor and the IESG have not yet decided whether this document
will be published separately or as part of a revision of
draft-rfc-editor-rfc2223bis-02.txt (itself a revision of RFC 2223), but
wish to gauge the IETF consensus on this specific issue.
I think this is more properly a part of the instructions to RFC
editors, but I can see why people may want it to be its own document
-- to highlight it and address a timely issue.