Keeping all the authors [xml2rfc]

[elwynd at dial.pipex.com (Elwyn Davies)]

I notice that the draft contents wrt authors and contributors; and their 
addresses differs significantly from what is on the RFC Editor web pages 
at http://www.rfc-editor.org/policy.html


      Authors vs. Contributors

Questions are still arising about the editorial policies on RFC 
authorship, and the contents of the first page, of the Contributors 
section, and of the Authors' Address section. We will attempt to clarify.

   1. When the RFC Editor refers to "authors", we mean exactly the set
      of names listed on the first page of an RFC. These people are
      considered to be equally responsible for the contents of the
      document, and all will be asked to read and approve the RFC before
      publication.

   2. When the RFC Editor refers to "contributors", we mean people,
      other than the authors, who also contributed significantly to the
      RFC. They should be listed in a Contributors section of the body
      of the document.

   3. The last section of the document (before the ISOC copyright
      statement) has traditionally been a section listing contact
      information for authors. The intent of this section is to tell
      readers how to get in touch with those people responsible for the
      document, to seek clarification, make comments, etc. This section
      should include contact information for all authors; it may contain
      contact information for some or all contributors. In unusual cases
      it might even include useful contacts who are highly relevant but
      are neither authors nor contributors. This section has been titled
      "Author(s)' Addresses", but this title is misleading. It really
      should be "Contact Information". It is the RFC Editor's intent to
      change the title of this section in the future to "Contact
      Information", after the community has had time to digest and
      accept the change.

   4. The issue has arisen: can/should the Contributors section include
      contact information? With the clarification above, it should be
      clear that the answer will be: "No, contact information should be
      in the Contact Information section." The Contributors section
      should just list the contributors. (It can also provide more
      fine-grained information about contributions.)

19 August 2003.


      Author Responsibility

The RFC Editor will hold all the people listed on the front page equally 
responsible for the final form and content of the published RFC. In 
particular, the "Author's 48 Hours" final approval period will require 
signoff from all listed authors. There will be no "honorary" authors.

Go to Top. <http://www.rfc-editor.org/policy.html#policy.top>


      Author Overload

The IESG and IETF have ratified a policy of limiting the number of 
authors listed in the first page header of an RFC. Objections to huge 
author lists are both practical and ideological. The practical issues 
have to do with the long-existing RFC formatting conventions that do not 
comfortably handle large author lists. Ideological objections stem from 
the Internet community's tradition of individual rather than corporate 
action and responsibility. Some might see a list of 17 authors on one 
RFC as motivated by a desire for corporate name-dropping, which would be 
inappropriate in the IETF/RFC context. If there is a desire to 
demonstrate how many companies are interested in this spec, a simple 
acknowledgment section can accomplish the same thing, without Author 
Overload.

The Internet community's conventions for RFC authors are one of the 
distinctive features of the IETF culture. Most standards bodies publish 
anonymous standards, whereas we attach the names of real people, who get 
both credit and blame, to our specifications. (This is probably a result 
of the historical beginnings of the IETF in the academic research 
community.) The person(s) who actually write a document take 
responsiblity for it, even though there may be a large working group of 
several hundred people who potentially contributed to it. When there are 
a number of significant contributors, there is usually a single person 
tasked with integrating the results into a single document; that person 
may be listed as "Editor", with acknowledgments for the other 
contributors. Independent submissions presumably did not originate in an 
IETF working group, but the same conventions should apply to any 
informal industry group acting outside the IETF, when the resulting spec 
is published as an RFC.

The specific policy is as follows:

   1. A small set of author names, with affiliations, may appear on the
      front page header. These should be the lead author(s) who are most
      responsible for the actual text. When there are many contributors,
      the best choice will be to list the person or (few) persons who
      acted as document editor(s) (e.g.,"Tom Smith, Editor").

      There is no rigid limit on the size of this set, but there is
      likely to be a discussion if the set exceeds five authors, in
      which case the right answer is probably to list one editor.

   2. An RFC may include a Contributors section, listing those
      contributors who deserve significant credit for the document
      contents. The Contributors section is intended to provide a level
      of recognition greater than an acknowledgment and nearly equal to
      listing on the front page. The choice of either, both, or none of
      Contributor and Acknowledgment sections in a particular RFC
      depends upon the circumstance.

   3. The body of an RFC may include an Acknowledgements section, in
      addition to or instead of a Contributors section. An
      Acknowledgments section may be lengthy, and it may explain scope
      and nature of contributions. It may also specify affiliations.

   4. The Author's Address section at the end of the RFC must include
      the authors listed in the front page header. The purpose of this
      section is to (1) unambiguously define author/contributor identity
      (e.g., the John Smith who works for FooBar Systems) and to (2)
      provide contact information for future readers who have questions
      or comments.

      At the discretion of the author(s), contact addresses may also be
      included in the Contributors section for those contributors whose
      knowledge makes them useful future contacts for information about
      the RFC.

   5. The RFC Editor may grant exceptions to these guidelines upon
      specific IESG request or in other exceptional circumstances.

=============================

This talks about possibly changing section names which doesn't seem to 
have totally followed through into the draft.

Regards,
Elwyn

Pekka Savola wrote:

> On Mon, 9 Jan 2006, JORDI PALET MARTINEZ wrote:
>
>> Thanks to all that replied to this.
>>
>> I agree, should not be a strict limit, but a simple way to "mark" 
>> only one
>> or several authors for the header and keep the rest in the authors 
>> section.
>
>
> I guess a fix would be extending the author role=[editor] attribute to 
> do certain stuff automatically if you give the right attribute..
>
>>> De: "Glen Zorn (gwz)" <[e-mail]>
>>> Responder a: <[e-mail]>
>>> Fecha: Mon, 9 Jan 2006 12:23:17 -0800
>>> Para: <[e-mail]>, <[e-mail]>
>>> Conversaci?n: Keeping all the authors  [xml2rfc]
>>> Asunto: RE: Keeping all the authors  [xml2rfc]
>>>
>>> Charles Levert <> supposedly scribbled:
>>>
>>>> * On Monday 2006-01-09 at 19:37:53 +0100, JORDI PALET MARTINEZ wrote:
>>>>
>>>>>
>>>>> I've tried to find this document, but no luck. Any URL to find it ?
>>>>>
>>>>>> De: David B Harrington <[e-mail]>
>>>>>>
>>>>>> Take a look at draft-rfc-editor-rfc2233bis-08.txt, section 4.7a
>>>>>
>>>>
>>>> Either one of:
>>>>
>>>>
>>>>
>>>> <ftp://ftp.isi.edu/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt>
>>>
>>>
>>> Note, though, that this (expired) I-D states wrt to the number of 
>>> authors
>>> "There is no rigid limit...but there is likely to be a discussion if 
>>> the set
>>> exceeds five authors, in           which case the right answer is 
>>> probably to
>>> list one editor."  Enforcing this limit in xml2rfc seems a bit rigid 
>>> to me...
>>>
>>> ...
>>>
>>> Hope this helps,
>>>
>>> ~gwz
>>>
>>> Why is it that most of the world's problems can't be solved by simply
>>>   listening to John Coltrane? -- Henry Gabriel
>>>
>>> _______________________________________________
>>> xml2rfc mailing list
>>> [e-mail]
>>> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>>
>>
>>
>>
>>
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>>
>> This electronic message contains information which may be privileged 
>> or confidential. The information is intended to be for the use of the 
>> individual(s) named above. If you are not the intended recipient be 
>> aware that any disclosure, copying, distribution or use of the 
>> contents of this information, including attached files, is prohibited.
>>
>>
>>
>>
>> _______________________________________________
>> xml2rfc mailing list
>> [e-mail]
>> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>xml2rfc mailing list
>[e-mail]
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>  
>
>From mrose at dbc.mtview.ca.us  Mon Jan  9 16:50:06 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan  9 16:50:22 2006
Subject: [xml2rfc] Keeping all the authors
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

> Can someone point me to a solution for this ? May be a concrete XML  
> of a
> draft that is doing it already ?

jordi - add

	role='editor'

to the list of attributes in the desired <author/> elements.


all - if it is desired that xml2rfc have a limit as to how many  
authors get listed, then we need to decide how to indicate that. here  
is one possibility:

	add an attribute which indicates 'visibility' to the <author/> element
	have the default be 'visible'
	have it be independent of the role attribute in any <author/> element

i suggest that the list discuss alternatives, and converge on a  
solution.

/mtr