Subject: Re: [xml2rfc] Keeping some authors off the front page ?

From: Alice Hagens <[email-masked]>
Date: Fri, 3 Jun 2011 16:52:38 -0400

On May 25, 2011, at 3:10 AM, Julian Reschke wrote:

> On 2011-05-24 23:52, Alice Hagens wrote:
>> Julian wrote:
>>> Alice, can this be clarified at this point? Alternatively, could you state how *you* read it, and whether the production center would accept texts where the front page only has a subset of the names mentioned in the back section?
>> 
>> Per discussion with the Acting RSE, we recommend that documents have a one-to-one mapping of names on the front page to names in the authors' addresses; however, it not a MUST. In practice, we do not change documents to have a one-to-one mapping.  As mentioned, http://www.rfc-editor.org/policy.html#policy.authlist will remain in place until a change is determined by a new RFC Series Editor.
> 
> When this is the case, what's the set of authors added to the RFC database entry?

The authors that are listed in the first-page header.

> 
>> Thomas correctly pointed out a case where some RFCs do not have a one-to-one mapping:
> 
> Which?

We don't keep a list of RFCs, but an example is RFC 5286 (of the case where editors are listed on the first page, but editors and additional authors are listed in "Authors' Addresses").

Thank you.
Alice
for the RFC Production Center

> 
>>> (e.g. cases where only editors are on front page, but every author in the "Authors' Addresses" section).
>> 
>> To reiterate, we suggest that the tool be flexible -- allow authors to create output as desired.
>> ...
> 
> Best regards, Julian
> 
On May 25, 2011, at 3:10 AM, Julian Reschke wrote:

> On 2011-05-24 23:52, Alice Hagens wrote:
>> Julian wrote:
>>> Alice, can this be clarified at this point? Alternatively, could you state how *you* read it, and whether the production center would accept texts where the front page only has a subset of the names mentioned in the back section?
>> 
>> Per discussion with the Acting RSE, we recommend that documents have a one-to-one mapping of names on the front page to names in the authors' addresses; however, it not a MUST. In practice, we do not change documents to have a one-to-one mapping.  As mentioned, http://www.rfc-editor.org/policy.html#policy.authlist will remain in place until a change is determined by a new RFC Series Editor.
> 
> When this is the case, what's the set of authors added to the RFC database entry?
> 
>> Thomas correctly pointed out a case where some RFCs do not have a one-to-one mapping:
> 
> Which?
> 
>>> (e.g. cases where only editors are on front page, but every author in the "Authors' Addresses" section).
>> 
>> To reiterate, we suggest that the tool be flexible -- allow authors to create output as desired.
>> ...
> 
> Best regards, Julian
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Jun 2011 17:33:55 -0400

--On Friday, June 03, 2011 16:52 -0400 Alice Hagens
<[email-masked]> wrote:

>... 
>>> Per discussion with the Acting RSE, we recommend that
>>> documents have a one-to-one mapping of names on the front
>>> page to names in the authors' addresses; however, it not a
>>> MUST. In practice, we do not change documents to have a
>>> one-to-one mapping.  As mentioned,
>>> http://www.rfc-editor.org/policy.html#policy.authlist will
>>> remain in place until a change is determined by a new RFC
>>> Series Editor.
>> 

While I think flexibility in the xml2rfc tool is fine, I note
that having a contact information ("Authors' Addresses") list
that is different from the first-page list puts us on a slippery
slope vis-a-vis the Contributor Section and also with the IPR
status and assumptions about the author list (whatever list that
actually becomes).  If we are serious about not making policy
changes, or significant policy decisions, until we have a
"permanent" RSE in place, this should go on that "deferred"
list.  If we are not serious, I think several of us have
candidate lists of far more significant issues to be addressed.

   john

---

From: Julian Reschke <[email-masked]>
Date: Sun, 05 Jun 2011 12:15:57 +0200

> candidate lists of far more significant issues to be addressed.

+1

My biggest concern here is that people might believe that a contact not 
listed on the front page can continue to be considered an "author". This 
is not the case right now, ad thus it would be very confusing to add 
xml2rfc features to get that result.

If* we believe that we'll keep the authors/contributors distinction, we 
should look into supporting *that* better in xml2rfc.

Best regards, Julian

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 05 Jun 2011 10:08:47 -0700

On 6/3/2011 1:52 PM, Alice Hagens wrote:
>>> Per discussion with the Acting RSE, we recommend that documents have a
>>> one-to-one mapping of names on the front page to names in the authors'
>>> addresses; however, it not a MUST.
...
> We don't keep a list of RFCs, but an example is RFC 5286 (of the case where
> editors are listed on the first page, but editors and additional authors are
> listed in "Authors' Addresses").

Folks,

I'm going to suggest that this really needs to be a MUST, both for 
straightforward simplicity of the model, as well as for consonance with IETF 
culture.

First, a more relaxed rule makes tools more complicated, as demonstrated by the 
xml2rfc issue that started this thread.  We need to careful that our natural 
inclination to be permissive about how things are done does not wind up creating 
excessive burden on those maintaining the IETF infrastructure. It's permissive 
to some authors, but it's a hassle on the support staff.  (There are all sorts 
of comparisons one might make, here, to the tradeoffs that apply to the way 
protocols should be specified and implemented, but beyond citing the 
opportunity, I won't pursue it...)

Second, the primary purpose of listing authors on an RFC is to distinguish the 
folks with physical responsibility for assembling the document.  In some cases, 
this is also the set of folk who were the principal creative contributors to the 
content, such as for most documents submitted through the Independent Stream, 
and for IETF efforts that represent the fine-tuning of a core group's original 
creativity.  Most IETF work is committee work.  The product is the product of 
the committee.  The 'authors' have done the documentation work and typically 
contribute to semantic creativity, but only as part of the team.

The IETF distinguishes two levels of contribution:  author/editor vs. 'team', 
whether the team is a working group or something less formal.  The team is cited 
in Acknowledgements.

To provide for a distinction between the front page author list and the later 
author contact set is to define a new class of contributor.  The simple, 
two-level arrangement has worked well for forty years.  If it needs to be 
modified and made more complex, the rationale needs to be compelling.

So, what is the compelling IETF community need for this?  Absent that compelling 
need, we need to refrain from burdening the operations side of the IETF with 
supporting this added bit of complexity that has no apparent functional benefit 
for the IETF.

And by the way, let's note that none of this results in creating a barrier to 
the detailed citation of special or additional contributors.  There are no 
restrictions to the content of an Acknowledgments section, nor is there a 
restriction against having a separate section designed to provide a set of 
contact information that is parallel to Authors, but refersg to some other, 
relevant principals.

Neither of these alternatives requires any changes to the tools.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 05:37:00 -0500

On Sun, Jun 5, 2011 at 5:15 AM, Julian Reschke <[email-masked]> wrote:
> listed on the front page can continue to be considered an "author". This is
> not the case right now, ad thus it would be very confusing to add xml2rfc
> features to get that result.

Why is that a problem?  Why would a contact not listed on the front
page but listed in the back not be useful to contact?  The RFC-Editor
never said that the distinction between front- and back-page author
listing would relate to which is appropriate to contact.  (Also, quite
frankly, contact information really does expire eventually.  Authors
drop off and even move on to other careers, and eventually we all pass
away.  So yours is an odd concern for that reason also.)

> should look into supporting *that* better in xml2rfc.

We should first ask the RFC-Editor to reconsider their policy.  If
they continue to assert it, why should the tools team refuse to help
them implement it?  (One answer is that the tools team serves the
IETF, not the RFC-Editor, but that would be a short-sighted view IMO.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 05:39:58 -0500

On Sun, Jun 5, 2011 at 12:08 PM, Dave CROCKER <[email-masked]> wrote:
> First, a more relaxed rule makes tools more complicated, as demonstrated by
> the xml2rfc issue that started this thread.  We need to careful that our

Demonstrated by...?  Three of us saying "no".  The RFC-Editor,
meanwhile, has a policy that _they_ set and enforce.  Even the IESG
might be unable to force the RFC-Editor to do otherwise, IIUC anyways.

The RFC-Editor's policy on this is quite sensible: they want to avoid
docs with lots of authors just to please employers, but they want
flexibility in case there really are some docs with large numbers of
actual authors.  If they have real examples where a document truly had
many actual authors, then that should suffice for us to let them have
their policy, no?  If not then we can always say: wait until you do.
But at the very least this seems like the wrong forum to debate the
RFC-Editor's policies.

> natural inclination to be permissive about how things are done does not wind
> up creating excessive burden on those maintaining the IETF infrastructure.

I suppose if you might be afraid of death by a thousand cuts.  But
there's no evidence that xml2rfc is suffering from that.  Perhaps the
larger tools team is suffering from a thousand cuts in other tools,
but not this one.  Or at least not visibly.  In any case, the
maintainers have not made that argument.

> To provide for a distinction between the front page author list and the
> later author contact set is to define a new class of contributor.  The
> simple, two-level arrangement has worked well for forty years.  If it needs
> to be modified and made more complex, the rationale needs to be compelling.

Not really.  The front-page/back-page distinction is one dictated by
space availability, nothing else.  One alternative might be to list
only "Various" on the front page when there's more authors than would
fit on the front page, then there would be no question of creating a
new type of author.

> So, what is the compelling IETF community need for this?  Absent that
> compelling need, we need to refrain from burdening the operations side of
> the IETF with supporting this added bit of complexity that has no apparent
> functional benefit for the IETF.

This tool (xml2rfc) already has functionality that the neither the
IETF nor the RFC-Editor need.  That doesn't excuse adding more such
functionality, certainly, but here we have the RFC-Editor asking for
it, so that argument wouldn't wash.  (Nor would I suggest removing
functionality that the IETF doesn't need.  I have, for example, made
use of xml2rfcs private memo functionality and thus I appreciate it's
being there.)

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jun 2011 12:48:35 +0200

On 2011-06-06 12:37, Nico Williams wrote:
> On Sun, Jun 5, 2011 at 5:15 AM, Julian Reschke<[email-masked]>  wrote:

I didn't say that. Please re-read what I said.

> away.  So yours is an odd concern for that reason also.)

Yes.

> IETF, not the RFC-Editor, but that would be a short-sighted view IMO.)

The *documented* policy is that there are authors and contributors, and 
the authors are listed on the front page.

Alice said that they do not *enforce* this, thus allow the authors 
section to include contacts not on the front page. But, as it was jsut 
clarified, this doesn't *make* those contacts authors (only the persons 
on the front page are considered authors for the purpose of AUTH48, RFC 
database, and citations).

So what's the advantage to have this confusion, instead of putting this 
information into the "Contributors" section?

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 06:08:47 -0500

On Mon, Jun 6, 2011 at 5:48 AM, Julian Reschke <[email-masked]> wrote:
> The *documented* policy is that there are authors and contributors, and the
> authors are listed on the front page.

Not so.  The policy quite clearly does NOT say that.  We've been over
this.  You refuse to accept the plain English language meaning of the
policy.  Granted, a cursory reading might differ from a careful one,
but that's not important.

> Alice said that they do not *enforce* this, thus allow the authors section
> to include contacts not on the front page. But, as it was jsut clarified,
> this doesn't *make* those contacts authors (only the persons on the front
> page are considered authors for the purpose of AUTH48, RFC database, and
> citations).

I can't find where she said that.

> information into the "Contributors" section?

What's confusing?

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jun 2011 13:51:56 +0200

> I can't find where she said that.

Three days ago; over here: 
<http://www.ietf.org/mail-archive/web/xml2rfc/current/msg03017.html>

>> information into the "Contributors" section?

It's confusing to call people "authors", but not have their names appear 
in the RFC database or in citations.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Jun 2011 11:42:36 -0500

On Mon, Jun 6, 2011 at 6:51 AM, Julian Reschke <[email-masked]> wrote:
>>> section

Ah, I must have been blind there for a bit.

*That* I would object to.  All authors in the Authors section must be
considered authors when searching by author.  As for citation,
obviously one must shorten to "So and so et. al." at some point --
that's what's done in academic scolarship.

> It's confusing to call people "authors", but not have their names appear in
> the RFC database or in citations.

It's unavoidable that some authors may not appear in a citation (see
above).  As for the RFC DB, I completely agree.

Nico
--

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 7 Jun 2011 17:58:30 +0100

> modified and made more complex, the rationale needs to be compelling.

To take an example where something different has been done, look at RFC
3626.
This has two names top right, marked as editors, and those two names
only in
an Authors section. But as I understand it, it had eight authors at
various
stages and these are listed in a Contributors section with contact
information.

Certainly those people did more work than those just in the
acknowledgements
section (I'm one of the latter). It was (as I recall) only later in its
history
as an Internet Draft that the authors were reduced to two to keep under
the
five limit. As not an author I don't know what negotiations with the
IESG/RFC
Editor produced that pattern.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jun 2011 13:51:16 -0400

--On Monday, June 06, 2011 11:42 -0500 Nico Williams
<[email-masked]> wrote:

>...
> *That* I would object to.  All authors in the Authors section
> must be considered authors when searching by author.  As for
> citation, obviously one must shorten to "So and so et. al." at
> some point -- that's what's done in academic scolarship.

Traditionally in the RFC Series (and several academic and
research style manuals), references for a document are shown as 

   A          (document whose author is A only)
   A and B    (document whose authors are A and B only)
   A et al.   (document whose authors are A, B, C, and maybe D
and E)

Recently, the ARSE has permitted an exception to list
   A, B, and C
if it fits.

Be that as it may, listing some folks as authors on the first
page and an expanded list under "Authors Addresses" is just an
opportunity for confusion about what belongs in the various
databases, what is found on search, and to whom the special IPR
provisions for Authors apply.    The "Contributors" category was
developed precisely to avoid some of those ambiguities.

And those distinctions, IMO, turn this into a policy matter, not
one that gets resolved on the basis of what xml2rfc does (or the
Production Center might choose to ignore in an input document).
I'm not arguing for any particular conclusion, only pointing out
that these are rather fundamental "style manual" issues and that
the community had agreed to defer those until after the
permanent RSE is in place.

>>>> So what's the advantage to have this confusion, instead of
>>>> putting this information into the "Contributors" section?
>>> 
>>> What's confusing?
>> 
>> It's confusing to call people "authors", but not have their
>> names appear in the RFC database or in citations.
> 
> It's unavoidable that some authors may not appear in a
> citation (see above).  As for the RFC DB, I completely agree.

Yes.  but I don't know whether that is an argument for including
everyone listed in "Authors' Addresses" in the database or for
not including anyone in that section who isn't a real, Page 1,
"author".  And, unless Olaf and the IAB/RSOC change their
collective minds about what decisions can be made this year, no
one else knows the answer to that question either.

     john

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jun 2011 13:58:26 -0400

--On Sunday, June 05, 2011 12:15 +0200 Julian Reschke
<[email-masked]> wrote:

> My biggest concern here is that people might believe that a
> contact not listed on the front page can continue to be
> considered an "author". This is not the case right now, ad
> thus it would be very confusing to add xml2rfc features to get
> that result.

I think it is part of that policy matter, but I share that
concern.

> If* we believe that we'll keep the authors/contributors
> distinction, we should look into supporting *that* better in
> xml2rfc.

Julian, if I were trying to design better handling for this into
xml2rfc, I'd expand that "author" element (at the risk of a
slight misnomer) to include a value for "role" other than
"editor".  "Contributor" is obvious; one might think about also
adopting the convention in many journals of "contact" (the
person who agreed to take the lead for being bugged about the
document).  That would permit grouping all of the
author/contact/etc. information in the source document (Good,
IMO), would permit indexing Contributors as well as authors (or
authors and editors separately) (Possibly useful), and would
leave the question of sections and formatting to the output
steps.

Just my opinion, of course.  And I could probably think of a
long list of xml2rfc changes I'd consider more important, but
YMMD.

    john

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Jun 2011 20:06:40 +0200

> long list of xml2rfc changes I'd consider more important, but

:-)

My preference is not to overload <author>, as there may be code out 
there which assumes that <author> elements indeed identity ... authors.

Instead of that, I'd allow a <contact> element, with the same content 
model as <author>.

The other question is whether we need more control on where to put 
these. The way of least resistance would be to automatically create a 
"Contributors" section below the Authors section, but I hear people 
asking for more formatting control.

Best regards, Julian

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 07 Jun 2011 13:12:18 -0700

On 6/6/2011 3:37 AM, Nico Williams wrote:
> page but listed in the back not be useful to contact?

I think your question misses the deeper issue:

      When you create additional structure, you invite interpretations as to its 
meaning.

      Absent highly precise definition of its meaning and 100% successful 
education of everyone as to that definition, people will impart meanings that 
are not correct.

The IETF's culture has only two classes of contributors:

      1)  Authors

      2)  Everyone Else

We do allow modifying the first class with the sub-label "editor", as a means of 
letting authors declare less direct responsibility for creating the content -- 
that is, for implying that the content really was created by a larger team. 
(And choice of adding the editor label seems to be nearly randomly made by 
authors...)

But that's it.  The model is otherwise trivial and consistent.

Having the front page be a subset of the detailed Author section is really an 
attempt to invent a new class of contributor.  (For reference, I did see the 
earlier reference to an existence proof for allowing this. That is, I know it's 
been done.  However it's still rare enough for us to declare it a mistake and 
prohibit future cases.)

Before we institutionalize mechanisms for having the Author section be a 
superset of the names listed on the front page, we should see a compelling 
justification and develop some community consensus around the cultural change it 
creates.

On 6/6/2011 4:51 AM, Julian Reschke wrote:
 > It's confusing to call people "authors", but not have their names appear in the
 > RFC database or in citations.

+1

>
>
> On 6/7/2011 11:06 AM, Julian Reschke wrote:
>> My preference is not to overload <author>, as there may be code out there which
>> assumes that <author> elements indeed identity ... authors.
>>
>> Instead of that, I'd allow a <contact> element, with the same content model as
>> <author>.

+10

Note that this can be accomplished today, with the existing xml2rfc tool and 
without any policy changes by the RFC Editor.

A change to xml2rfc, to create the specific, structured <contact> element would 
make that section a bit easier to construct, but it's not essential.

d/

-- 

   Dave Crocker

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 16:05:12 -0500

On Tue, Jun 7, 2011 at 3:12 PM, Dave CROCKER <[email-masked]> wrote:
>     When you create additional structure, you invite interpretations as to
> its meaning.

I don't think we disagree as to that.  The disagreement is about how
confusing two classes of authors might be.  I don't think it will be
confusing at all.  For example, when I look at the front page of an
RFC I don't learn any author's contact info, just their names and
organization abbreviation -- if I want to contact them at all I must
turn to the Authors section at the end of the RFC, and that's exactly
what I do.  I suspect everyone else does the same.

> education of everyone as to that definition, people will impart meanings
> that are not correct.

I don't see what's imprecise here: the authors and RFC-Editor agree on
who will be on the front page and who will be the "et. al." and all go
into the Authors section.  The former also appear on citation, while
all can be used for RFC DB searches (this would be my requirement).
Where's the lack of precision?

> The IETF's culture has only two classes of contributors:

That wouldn't change.  I and I'm sure everyone else already turn to
the back pages to get author contact info, necessarily.

> Having the front page be a subset of the detailed Author section is really
> an attempt to invent a new class of contributor.  (For reference, I did see
> the earlier reference to an existence proof for allowing this. That is, I
> know it's been done.  However it's still rare enough for us to declare it a
> mistake and prohibit future cases.)

To me it's just an attempt to manage a scarce resource: front page
real estate.  I think that's pretty obvious.

Let's flip this around: our typographic conventions are dictating
conventions for authorship versus contributorship.  You don't see a
problem with that??

It's really odd to let typographic conventions dictate more important
matters, shocking even.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Jun 2011 07:51:51 +0200

> real estate.  I think that's pretty obvious.

I've also heard that one motivation was to keep the AUTH48 phase manageable.

What's your opinion on who needs to approve publication?

> It's really odd to let typographic conventions dictate more important

It doesn't dictate. it advises. There is no hard limit, as far as I 
understand.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 09:52:33 -0500

> What's your opinion on who needs to approve publication?

The authors should designate AUTH48 contacts and the shepherd should tell
the RFC-Editor who they are.  But all should be cc'ed.

understand.

Surely things break at some point.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 08 Jun 2011 09:17:28 -0700

On 6/8/2011 7:52 AM, Nico Williams wrote:
> The authors should designate AUTH48 contacts and the shepherd should tell the
> RFC-Editor who they are.  But all should be cc'ed.

So, without having any compelling need for changing a well-running system, let's 
create additional, formal structure, by distinguishing a new class of 
participants.

Then, since that creates an ambiguity with an essential document processing 
step, let's create more mechanism to fix this.

An entirely revolutionary alternative would be to observe that things have been 
working well and no significant problem exists that needs solving.

So we should leave things alone.

d/
-- 

   Dave Crocker

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 8 Jun 2011 16:54:22 -0400

+1

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Wednesday, June 08, 2011 12:17 PM
> To: Nico Williams
> Cc: [email-masked]; [email-masked]; RFC Editor
> Subject: Re: [xml2rfc] Keeping some authors off the front page ?
> 
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>

---

From: "Olaf Kolkman (Acting RFC Series Editor)" <[email-masked]>
Date: Thu, 9 Jun 2011 13:05:48 +0200

Colleagues,

I've been following this thread with interest and been discussing the
topic with the Production Center staff. A few comments:

First, there are at this time, and in relation to how authors are
handled, no specific requirements from the RFC Editor for XML2RFC
functionality. I do not see any problems with XML2RFC having a few
extra handles that might in the future be able to deal with different
policies than those we use now.

Second, the RFC Editor policy is, and has been for more than a decade,
to recommend that if there are more than 5 authors that a special
'Contributors Section' is created. Exceptions are made as necessary.

Although it is not enforced policy currently (and there are
exceptions) the RFC editor will continue to strive to have a
1-to-1-to-1 mapping between the authors in the header, the authors in
the Authors Addresses section, and the authors in the RFC meta
data. Going forward we will strive to implement as such.  However, I
will not rigidly set this as policy until a new RSE has had the
ability to spend cycles on this. I assume this situation will not
occur during the rest of my tenure and that exceptions can be avoided.

I hope this helps to converge the discussion

Olaf, as Acting RFC Series Editor.

PS: This started with:
On May 10, 2011, at 10:54 AM, Thomas Morin wrote:
> While reviewing a draft I edit, the AD in charge pointed out the
> usual "too many authors on the front page" 
> > issue: Would it be possible to consider moving everyone except for
> > the editor off the front page? [all authors] will still all be
> > listed as authors at the end of the document.

It should be clear from the above that if asked, the RFC Editor would
have suggested to move some of the authors to a contributors section
and not given the advice that this AD had given.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 09 Jun 2011 09:13:37 -0700

Olaf,

Many thanks for the posting and clarifications.

A few comments...

> 'Contributors Section' is created. Exceptions are made as necessary.

An implication of this extended discussion thread and of who has been 
participating in it:  No one knows about that section, although I do see it 
documented in the RFC Document Style Guide:

    <http://www.rfc-editor.org/rfc-style-guide/rfc-style>, Section 4.8, y).

But apparently it hasn't been socialized.  Since it is exactly the approach some 
of us have been "proposing", it might be worth promoting it more...

However the document reasonably notes that it might contain more than just 
contributor contact information, to comment on the details of their contribution.

Still, it might be worth having xml2rfc know about the section, so it can 
provide structured support for the contact information, along with the optional 
commentary.

> data.

This is where this is a possible problem, since xml2rfc doesn't support the 
split and I sure wish it were not required to.

>  Going forward we will strive to implement as such.

Just to make sure I understand this statement:  within the constraints of your 
being /acting/ RSE, you plan is to apply a 1:1:1 rule?

> and not given the advice that this AD had given.

Again, I think there's an underlying problem that few, if any, experienced folk 
knew about the additional section.

d/

-- 

   Dave Crocker

---

From: "Olaf Kolkman (Acting RFC Series Editor)" <[email-masked]>
Date: Tue, 14 Jun 2011 10:04:15 +0200

On Jun 9, 2011, at 6:13 PM, Dave CROCKER wrote:

> Just to make sure I understand this statement:  within the constraints of your being /acting/ RSE, you plan is to apply a 1:1:1 rule?
> 

Acknowledged. Obviously without availability of sticks or carrots.

> Again, I think there's an underlying problem that few, if any, experienced folk knew about the additional section.

Clear, any suggestions on how to fix that? 

--Olaf

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 14 Jun 2011 07:45:13 -0700

> Clear, any suggestions on how to fix that?

In an IETF in which almost everyone thinks that the rules require normative 
words to be capitalized, probably not...

I was going to suggest something cheap and easy, as a small effort in that 
direction, but decided to confirm that it wasn't already in the style guide:

    <http://www.rfc-editor.org/rfc-style-guide/rfc-style>

Alas, Section 4 already contains the simple template I was thinking of, with 
"Contributors" included...

sigh.

d/

-- 

   Dave Crocker

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jun 2011 10:27:03 -0500

Fair enough.

As long as Alice seemed to be representing a desire by the RFC-Editor
for this change I was willing to support it.  I'm clearly on the rough
side of consensus here, so I'll drop it.

Nico
--

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 14 Jun 2011 17:35:07 +0200

Hi,

For what it's worth, i use xml2rfc a lot and the "notfirstpage" option would be *extremely* helpful to allow all the authors being listed in the same section (i.e. "Author's addresses).

If introducing such enhancement does not cause any major issue i would really appreaciate it.

Thanks
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: martedì 14 giugno 2011 17.27
To: [email-masked]
Cc: [email-masked]; RFC Editor
Subject: Re: [xml2rfc] Keeping some authors off the front page ?

Fair enough.

As long as Alice seemed to be representing a desire by the RFC-Editor for this change I was willing to support it.  I'm clearly on the rough side of consensus here, so I'll drop it.

Nico

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 14 Jun 2011 08:41:46 -0700

> If introducing such enhancement does not cause any major issue i would really appreaciate it.

use the existing "Contributors" section that we've been discussing.

d/

-- 

   Dave Crocker

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 14 Jun 2011 18:03:39 +0200

It makes a sort of distinction between more important authors (listed in the Author's address section) and less important authors (listed in the Contributors list)...i saw people "disappointed" about that...

The problem is usually solved with one author per company in the front page but all of them in the Author's address section (manually edited)

Thanks,
Daniele

-----Original Message-----
From: Dave CROCKER [mailto:[email-masked]] 
Sent: martedì 14 giugno 2011 17.42
To: Daniele Ceccarelli
Cc: [email-masked]; RFC Editor
Subject: Re: [xml2rfc] Keeping some authors off the front page ?

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 14 Jun 2011 09:40:03 -0700

> It makes a sort of distinction between more important authors (listed in the Author's address section) and less important authors (listed in the Contributors list)...i saw people "disappointed" abo…

Ahh, I see.  You want the IETF to change its culture and then to support the 
change formally in its documents.

I, for one, do not.

d/
-- 

   Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Tue, 14 Jun 2011 09:00:14 -0700 (PDT)

> use the existing "Contributors" section that we've been discussing.

AFAIK any Contributors section has to be constructed manually - there's no way
to do it (directly) using something akin to <author> elements.

There are certainly times when it would be easier to work with a bunch of
elements that get turned into a contributor section. And perhaps more
importantly, adding structure to the content is generally a good thing.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 14 Jun 2011 09:48:18 -0700

> to do it (directly) using something akin to <author> elements.

Yeah, and it seems to me worth trying to get xml2rfc to support a <contributors> 
structure.

> importantly, adding structure to the content is generally a good thing.

 From the discussion on this lengthy thread, I think that the construct is a 
variant of the Authors section.

It needs:

1. An opening <text> statement, for introducing the contents.

2. A set of <author> and <text> pairs, where the latter is for commenting on the 
former; that is, for describing their contribution.  (<author> doesn't already 
permit a free-text field of this sort.)

d/
-- 

   Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Tue, 14 Jun 2011 17:55:26 -0700 (PDT)

> permit a free-text field of this sort.)

Agreed on all points. This, incidentally, is why a simpler status indicator on
the author element won't do - there'a a common subset of information, but
contributor sections require additional associated commentary.

				Ned

---

From: Glen Zorn <[email-masked]>
Date: Wed, 15 Jun 2011 09:06:40 +0700

> For what it's worth, i use xml2rfc a lot and the "notfirstpage" option would be *extremely* helpful to allow all the authors being listed in the same section (i.e. "Author's addresses).

I would think that that 1) understanding (by all parties involved) that
the "limit" on the number of authors is a _guideline_, nothing more,
nothing less and 2) ceasing the practice of "piling on" authors to
demonstrate corporate support for a document (a la 3GPP*) would be much
more helpful to everyone.  The first requires that no tool enforces the
limit as if the limit was more than a suggestion (easy to do) but the
second requires self-control and recognition of more than one paradigm
for SDOs (potentially much more difficult).

...

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Jun 2011 05:18:07 -0400

(Sorry -- reading out of order and just spotted this...)

--On Tuesday, June 07, 2011 20:06 +0200 Julian Reschke
<[email-masked]> wrote:

> My preference is not to overload <author>, as there may be
> code out there which assumes that <author> elements indeed
> identity ... authors.
> 
> Instead of that, I'd allow a <contact> element, with the same
> content model as <author>.

But... editors are authors for some purposes and not for others,
so we already have that problem.  And contributors are not much
different.  That said, I can live with <contact>, although we'd
probably want to call it something else since we usually don't
list addresses for contributors.

But that would work for me.

> The other question is whether we need more control on where to
> put these. The way of least resistance would be to
> automatically create a "Contributors" section below the
> Authors section, but I hear people asking for more formatting
> control.

See my earlier note.  I don't think order of sections/ blocks is
really formatting control, but do think that we need a way to
specify where Contributor sections and Index sections (of which
there might, in a better world, be more than one) go.  I suspect
that list might get longer as time goes on.  The SGML-ish
solution to this (not necessarily as good a match to XML) would
be to introduce a trick element such as (in XML syntax):

   <!ELEMENT specialSection  (preamble?,postamble?)>
   <!ATTLIST type  (contrib|index);
             indexname  (%CTEXT;) >

with obvious future extensibility if more of these turn up.

best,
   john

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Jun 2011 11:42:15 +0200

On 2011-06-15 11:18, John C Klensin wrote:
>> My preference is not to overload<author>, as there may be
>> code out there which assumes that<author>  elements indeed
>> identity ... authors.
>>
>> Instead of that, I'd allow a<contact>  element, with the same
>> content model as<author>.
>

Not the way it works now: you can attach "role=editor" to an author, but 
the contact will continue to be considered an author (for the purpose of 
citations, AUTH48, and the RFC Index).

> different.  That said, I can live with<contact>, although we'd

Address information is optional anyway.

>               indexname  (%CTEXT;)>

I'm with you in defining a specific container element.

However: where does the requirement for Index placement come from?

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Jun 2011 09:38:35 -0400

--On Wednesday, June 15, 2011 11:42 +0200 Julian Reschke
<[email-masked]> wrote:

>...
>> But... editors are authors for some purposes and not for
>> others, so we already have that problem.  And contributors
>> are not much
> 
> Not the way it works now: you can attach "role=editor" to an
> author, but the contact will continue to be considered an
> author (for the purpose of citations, AUTH48, and the RFC
> Index).

Citations, yes, at least until and unless we establish a clear
"citations to RFCs" norm that sets whatever rules it sets.  Note
that, in "normal" bibliographic forms, the (relatively recent)
RFC rule that permits 

   Bloggs, F., ed., S. Smith, J. Jones, Some title, ...

is simply not allowed.  It turns into either

  Bloggs, F., etc., Some title...

(which is what used to happen with RFCs) or 

  Smith, S., J. Jones, Some title, edited by F. Bloggs ...

But the common characteristic of all three of those things is
that they are RFC Editor decisions about what to pick up and how
to use it.  Unless things change, those decisions aren't even
going to get reviewed this year.  I think our concern with
XML2RFC ought to be to get the generic markup sufficiently right
and specific to allow those RFC Editor decisions to evolve,
rather than requiring elaborate heuristics or document-searching
if they do.

> Address information is optional anyway.

Sure.  But if one is going to paste information in from
somewhere else (e.g., as part of a reference retrieved from a
library), it may show up -- whether or not to display it should
be a question for the style manual (see above) and/or the output
processor.

>>> The other question is whether we need more control on where
>>> to put these. The way of least resistance would be to
>> See my earlier note.  I don't think order of sections/ blocks
>> is really formatting control, but do think that we need a way
>> to specify where Contributor sections and Index sections (of
>> which there might, in a better world, be more than one) go.
>...

> However: where does the requirement for Index placement come

Have a look at draft-hoffman-3536bis.   An index to terms in a
document like that may be one of the more important types of
index in the RFC Series.  Now, as you are looking, decide how
you feel about its formatting and placement.  If you are nearly
as repelled as I am, the requirement, and/or the requirement for
some additional processing directives, should be clear.  To be
fair to Paul, the decision to let xml2rfc build the index,
rather than building it by hand and putting it in as artwork,
was mine.  Of course, the artwork model would have caused its
own positioning problems, since figures cannot appear in the
<back> element.

And then there is the production rule index for rfc5321bis,
which I can do with your tools, but not with xml2rfc.  If one
also decided to index other things there, like explanations of
commands, one would end up with a need for two separate indexes.
Another problem, but also another symptom that index and <iref>
may need rethinking.

    john

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Jun 2011 15:58:45 +0200

> rather than requiring elaborate heuristics or document-searching

Well, if these tool changes came for free, I'd agree.

Right now we have xml2rfc.tcl (with nobody except Tony being able to add 
things), rfc2629.xslt (by me, willing to experiment), and the new tool 
which is work-in-progress about which I don't know the current status 
(are the developers reading this???).

> be a question for the style manual (see above) and/or the output

That would be inconsistent with how <author> works today. Not sure that 
it makes sense to diverge from that.

> as repelled as I am, the requirement, and/or the requirement for

I'm not repelled at all. (There are lots of other things about the 
RFC/ID format I *am* repelled of :-).

> own positioning problems, since figures cannot appear in the

I don't think that building the index using artwork makes sense, unless 
you can manage to generate it properly including page breaks and page 
numbers.

That being said; the content model for sections inside <back> is the 
same as inside <middle>.

> And then there is the production rule index for rfc5321bis,

URI?

> Another problem, but also another symptom that index and<iref>
> may need rethinking.

In HTTPbis, we put production rules under a common element, such as 
"Grammar productions", and then use subitem for the actual entry...

Best regards, Julian

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 15 Jun 2011 13:34:45 -0700

On 6/15/2011 6:58 AM, Julian Reschke wrote:
> things), rfc2629.xslt (by me, willing to experiment), and the new tool which is
> work-in-progress about which I don't know the current status (are the developers
> reading this???).
>
> That would be inconsistent with how <author> works today. Not sure that it makes
> sense to diverge from that.
>
>> ...
...
>> And then there is the production rule index for rfc5321bis,

(I'm having to force myself away from typing "indices", to conform to the modern 
"spelling".  These inter-generational differences are becoming more and more of 
a pain...)

It probably is worth our considering a set of common indexes for xml2rfc to 
support, but we should be clear about compelling needs and make sure these are 
satisfied.  If their implementation produces more generalized capabilities, 
that's fine, but the real goal should be narrower, I suspect.

The only two indexes that make particular sense for IETF documents are for 
vocabulary and for syntax rules.

I've no idea how to do the latter, given that they are specified inside artwork, 
so that embedding extra xml cruft isn't really possible.

d/

-- 

   Dave Crocker

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Jun 2011 22:41:56 +0200

On 2011-06-15 22:34, Dave CROCKER wrote:
> ...
> (I'm having to force myself away from typing "indices", to conform to
> the modern "spelling". These inter-generational differences are becoming
> more and more of a pain...)
>
>
> It probably is worth our considering a set of common indexes for xml2rfc
> to support, but we should be clear about compelling needs and make sure
> these are satisfied. If their implementation produces more generalized
> capabilities, that's fine, but the real goal should be narrower, I suspect.
>
> The only two indexes that make particular sense for IETF documents are
> for vocabulary and for syntax rules.
>
> I've no idea how to do the latter, given that they are specified inside
> artwork, so that embedding extra xml cruft isn't really possible.
> ...

Oh, that's simple; we just need to allow markup inside <artwork>; 
rfc2629.xslt already supports that.

Best regards, Julian

---

From: [email-masked]
Date: Sat, 25 Jun 2011 16:34:07 -0400

--On Wednesday, 15 June, 2011 22:41 +0200 Julian Reschke
<[email-masked]> wrote:

>> The only two indexes that make particular sense for IETF
>> documents are for vocabulary and for syntax rules.

I believe Dave is correct about that.  I think I could imagine
other cases, but they would be pretty obscure, probably so
obscure as to not be worth the effort.

>> I've no idea how to do the latter, given that they are
>> specified inside artwork, so that embedding extra xml cruft
>> isn't really possible. ...
> 
> Oh, that's simple; we just need to allow markup inside
> <artwork>; rfc2629.xslt already supports that.

Once upon a time, I was involved in a standard that used a lot
of metalanguage, actually more complex than ABNF, and that was
done in SGML.   After experimenting with several variations on
what we would now call "<artwork> with markup", we concluded
that the only thing that would actually work was to define an
element structure that would capture a single rule and actually
separate out all of the terms and operators.  A simplified
version in  more xml-ish form, the result would look something
like

  <production target="digit">
    "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
  </production>

In the original, each term of the RHS actually got its own
element with the operators specified as arguments to that
element.   That permits all sorts of interesting things,
including style sheet (or output processor) decisions as to
whether to use "=" or "::=" (or special typography), "/" or "|"
or "OR" (or special typography), as well as making
cross-reference indices  (I have the same problem Dave does;
have to force myself to write "indexes" every time and, at least
for the present, just stopped).

But, for our purposes, I don't think the extra flexibility is
needed, it is lots more work, and I could live with markup in
artwork.

     john