Subject: Re: [xml2rfc] #106: reference for an STD or BCP that contains multiple RFCs

From: "xml2rfc issue tracker" <[email-masked]>
Date: Fri, 04 Oct 2013 15:54:06 -0000

#106: reference for an STD or BCP that contains multiple RFCs

Comment (by [email-masked]):

 Suggestion below is from an email from John Klensin re: a vocabulary
 enhancement (an aggregate attribute) that would address
   * (i) this ticket: ability to list multiple RFCs within one reference,
 and
   * (ii) ability to use a different anchor than the one in the citation
 libary.

 {{{
 It would allow the right thing to happen if, e.g.,
  (i) <reference> were modified to allow an "aggregate='yes'"
 attribute so that, with that attribute turned on,
   <reference anchor="BCP0101">
      &rfc3777;
      &rfc5633;
      &rfc5680;
      &rfc6859;
   </reference>

 would suppress the individual anchors on output but otherwise do
 the right thing.  And

  (ii) <reference> without "aggregate='no'" (presumably the
 default for backwards compatibility reasons) would interpret
    <reference anchor="SMTP">
       &rfc5321;
    </reference>

 as suppressing the anchor in the citation file with the one
 specified.
 }}}

-- 
------------------------------+--------------------
  Reporter:  [email-masked]  |      Owner:
      Type:  enhancement      |     Status:  new
  Priority:  medium           |  Milestone:
 Component:  Version 2 cli    |    Version:  2.3.11
Resolution:                   |   Keywords:
------------------------------+--------------------

Ticket URL: <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/106#comment:2>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Oct 2013 09:01:05 -0700

This seems like a complex engineering solution. Wouldn't it be far simpler to simply specify the way that the output of a citation to a multi-RFC BCP should look like and make referring to that emit the correct thing?

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 4 Oct 2013 15:29:00 -0700

Making it part of the thing being cited also means that only one person
needs to maintain it and I will not get it wrong for my document.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
> Sent: Friday, October 04, 2013 9:01 AM
> To: xml2rfc issue tracker
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [xml2rfc] #106: reference for an STD or BCP that contains
> multiple RFCs
> 
> This seems like a complex engineering solution. Wouldn't it be far simpler
to
> simply specify the way that the output of a citation to a multi-RFC BCP
> should look like and make referring to that emit the correct thing?
> 
> --Paul Hoffman
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Oct 2013 18:33:19 -0400

--On Friday, October 04, 2013 09:01 -0700 Paul Hoffman
<[email-masked]> wrote:

> This seems like a complex engineering solution. Wouldn't it be
> far simpler to simply specify the way that the output of a
> citation to a multi-RFC BCP should look like and make
> referring to that emit the correct thing?

If that were the only issue, I would agree completely.    There
is also no question that the "aggregate" attribute idea is a
kludge (see below)

However, not everything cited from an RFC is an RFC, STD, or
BCP.  We have other types of multiple reference citations that,
to the degree to which the RFC Editor's future plans are
dependent on metadata and direct production of RFCs from XML
(rather than going through an nroff intermediary and tuning
things there) need better and more explicit tagging than hiding
information in <annotation> and/or <seriesInfo> elements.  The
most obvious examples would be similar to articles in journals
such as:

 []    Smith, J., "The obvious way to make the Internet go
faster", Journal of Translight Physics, vol 10, 1 (April 2014),
pp. 50-35.

Articles or chapters in books:

 []  Einstein, M., "What's a little time between friends", in
Wells, H., ed., Collected works of Albert's Smarter Brother,
Ulm: Unlikely Publishing, 1878.

including the dreaded cross reference within the references:

 []  Einstein, M., "The so-called time paradox or so what if it
runs backwards", in Wells, H., op. cit.

The "one citation, multiple sources" case, possibly mixed with
some of the above:

  [] Dumpty, H., in Carroll, L., "Through the Looking Glass, and
What Alice
Found There", Chapter 6, 1871.  Reprinted in The Complete Works
of Lewis Carroll 196 (1939) and in Gardiner, M., The Annotated
Alice, New York: Clarkson N. Potter, 1960.

And the multiple source one that is similar to the BCP case, but
not identical (and that may or may not be appropriate in RFCs
depending on what the RFC Editor does about the Style Manual but
are presumably open season for I-Ds:

  []  Several DNS tutorials including 

    Rampling, B. and D. Dalan, DNS for Dummies, ...
    Liu, C. and P. Ablitz, DNS and Bind, ...
    Liu, C., Larson, M., and R. Allen, DNS on Windows Server
2003,...

I'd like to see this sorted out in a way that covers all of the
cases not just, e.g., BCPs.

The _right_ solution, IMO, would be to borrow a good information
scientist of two and completely redesign the <reference>
element, possibly deprecating the current one and replacing it
with something completely different.  The "<annotation>" element
idea was a kludge to avoid having to do that while providing
most of the relevant functionality.

Of course, anything that is designed around more tagging to
permit metadata handling and retrieval can be argued to be
overengineering if the goal is simply to produce output
documents that look plausible.  But, if the latter were really
our goal, we should, perhaps, have stuck to format markup.

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Oct 2013 18:40:09 -0400

--On Friday, October 04, 2013 15:29 -0700 Jim Schaad
<[email-masked]> wrote:

> Making it part of the thing being cited also means that only
> one person needs to maintain it and I will not get it wrong
> for my document.

Separate problem, IMO, because, if there is _some_ adequate
mechanism for marking up the aggregate document cases, a logical
next step is to have libraries for BCPs and STDs, not just RFCs,
that would contain the right market.   If you are concerned
about getting, e.g., a multiple-document BCP reference wrong and
are willing to have your references change when the BCPs change,
you probably really want
  
   &bcp0101;

and not any variation on

  <someElement anchor="BCP191">
     &rfc3777;
     &rfc5633;
     &rfc5680;
     &rfc6859;
  </someElement>

That, IMO, is a different problem because, if <annotation>
elements are really a reasonable way to deal with the RFC
numbers and citations, that library could be created today,
using exactly the workaround shown at
http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/106 .

  best,
    john

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Oct 2013 19:26:19 -0700

On Oct 4, 2013, at 3:40 PM, John C Klensin <[email-masked]> wrote:

> that would contain the right market.

Yes, exactly.

>   If you are concerned

Yes, exactly.

> http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/106 .

If you are conflating two problems (multi-document BCPs; multi-document non-RFC references), then please don't. There is a simple solution for the first and way too few examples of the second for us to make a good judgement call.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Sat, 5 Oct 2013 03:13:35 -0500

> If you are conflating two problems (multi-document BCPs; multi-document non-RFC references), then please don't. There is a simple solution for the first and way too few examples of the second for u…

Because we should repeat patterns.

More seriously, :) BCPs *are* collections of documents.  We already
can reference both, BCPs *and* their component documents together and
separately.  What we lack is a way to denote collections (like BCPs)
in the references section.  I see nothing special about BCPs versus
other collections, whether those collections be arbitrary or
standardized.

I.e., we need a referenceable container of references.  Ideally the
container should be just like references as far as a) publishing in
bibxml repos, b) referencing them from xml2rfc documents.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Sat, 05 Oct 2013 10:27:41 +0200

On 2013-10-05 00:33, John C Klensin wrote:
> ...
> ...

+1

> ...
> ...

I disagree with that. There'll always be the case that you want to add 
some prose.

> ...

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Oct 2013 10:17:50 -0400

--On Saturday, October 05, 2013 10:27 +0200 Julian Reschke
<[email-masked]> wrote:

>> ...
>> with something completely different.  The "<annotation>"
>> element idea was a kludge to avoid having to do that while
>> providing most of the relevant functionality.
>> ...
> 
> I disagree with that. There'll always be the case that you
> want to add some prose.

Sorry... misunderstanding, not disagreement.   I would be
violently opposed to eliminating the <annotation> element for
precisely the reason you identify -- adding some explanatory or
qualifying prose.  My objection is to the specific example given
on the ticket page: use of <annotation> to sneak in text that is
not prose at all but a list of subsidiary or associated
references that ought to be appropriated tagged as metadata and
for proper formatting and indexing.  Similar comments appear for
seriesInfo: I think the element is very valuable for its stated
and obvious purpose but that using that element to sneak
information that is irrelevant to that purpose into references
(because it doesn't generate the blank line that <annotation>
does) is a bad idea, especially when that information is really
metadata that should be tagged in some other way.

For those for whom this discussion is getting too abstract,
think about the long term in which we might want to pretty-print
(or pretty-format) RFCs, not just fuss with a few non-ASCII
characters or non-paged layouts.  In that world, normal
publication standards require that titles of journal articles
and book chapters be in quotes and titles of journals and books
be in italics.  That is pretty hopeless, except by human
intervention at the formatting or layout stages (e.g. in our
current world, nroff) if the information that there are journal
or book titles present is hidden away in seriesInfo or
annotation.

    john

---

From: Julian Reschke <[email-masked]>
Date: Sat, 05 Oct 2013 16:25:43 +0200

> metadata that should be tagged in some other way.

Big +1.

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Oct 2013 10:37:23 -0400

> If you are conflating two problems (multi-document BCPs;
> multi-document non-RFC references), then please don't. There
> is a simple solution for the first and way too few examples of
> the second for us to make a good judgement call.

Largely agreeing with Nico, but...

(1) To get to "&bcp0101;", there has to be an underlying
construction for multi-document arrangements.  It can't be just
for BCPs because we have exactly the same issues for STDs.  And,
curiously, they are much harder than conventional multiple
document references because we believe that processing RFC XML
source on the day of publication needs to yield the same result
as processing that same source several years later, so 

    &bcp0101;
gets dragged into the issues of whether the intended reference
was to 
    &bcp0101-20050501;    or
    &bcp0101-20060201;

(2) "way too few examples of the second" is an interesting
comment.  We have several efforts afoot, for different reasons,
to make RFCs more like conventional scholarly and professional
publications.  The issues associated with multi-document
citations and references are very well known in the publications
and information sciences communities, with no shortage of either
examples or of discussions about what the cases are.  IMO,
assuming that the IETF needs to or should start developing
unique and specialized solutions for those issues, avoiding
relevant professional advice and the professional literature,
would become reasonable about the time we start encouraging the
information science community to start developing
transport-level Internet protocols.  :-(

   john

---

From: William Atwood <[email-masked]>
Date: Sat, 05 Oct 2013 10:42:20 -0400

It seems to me that what is needed here is something of the size (and
complexity) of BiBTeX.  Perhaps the best solution is to adopt LaTeX and
BibTeX for RFCs...  (Which may be one of the options that the RFC Editor
is considering; I have not been following that particular stream of
discussion)  :-)

Do we really want to go down that path?

  Bill

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 5 Oct 2013 08:20:40 -0700

> Because we should repeat patterns.

The fact that we should repeat patterns doesn't mean that we need to make the solution for a common problem in RFCs (BCPs) as difficult on authors as the solution for a much rarer problem (other groupings).

> in the references section.  

Yes.

> I see nothing special about BCPs versus

We simply disagree then. To me, the three differences are:
- We know that BCPs are collections of RFCs and nothing else
- We understand how to order RFCs because they are numbered
- Typical readers of RFCs are more likely to care about the contents of a BCP than of an arbitrary grouping
That makes solving the problem for BCPs much easier than for arbitrary groupings. 

> bibxml repos, b) referencing them from xml2rfc documents.

And, as we have seen, we can bikeshed forever about that, and in the meantime references to BCPs continue to suck and be misleading to people who don't understand that a BCP might refer to a group of RFCs.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Sat, 5 Oct 2013 19:20:08 -0500

> And, as we have seen, we can bikeshed forever about that, and in the meantime references to BCPs continue to suck and be misleading to people who don't understand that a BCP might refer to a group…

We're not talking about what color to paint the shed.  We're talking
about how many bikes need to be stored in it.  This isn't a question
of aesthetics; it's a question of architecture.

There is an aesthetics angle too, yes: if we build this shed too small
we're going to have to build another one later, and that means "ugly"
schema for xml2rfc (that's what my comment about repetition was
about).  But this is really an architectural argument: why build N
small buildings when you could more easily, accessibly, cheaply, ...,
build one building large enough for the N purposes?  (You can't
always; if the N purposes are disparate, say, or if the customers
really want N buildings.  But neither of those considerations applies
here.)

You've already missed STDs as another type of collection (see John's
post).  I'm asserting that there are many types of referenceable
document collections.  We have two official types of document
collections in the IETF: STDs and BCPs.  We also have things like
roadmap RFCs (e.g., RFC4514), which work roughly like document
collections.  If we had a big enough bikeshed we might have *lots* of
collections, both, of Internet RFCs as well as of external documents
(e.g., ITU-T, IEEE, ...); I gave examples of quite a few such
collections.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Oct 2013 13:11:50 +0200

On 2013-07-11 01:02, xml2rfc issue tracker wrote:
> Comment (by [email-masked]):
>
>   Of course, that workaround then needs reformatting in the nroff and
>   doesn't permit use of seriesInfo to generate metadata about the RFCs
>   involved, and so on.  So it is better than nothing, but definitely  not a
>   satisfactory solution.

A few comments on the proposal.

In general this seems to be pragmatic, generic, and simple. So +1.

Question: the suggest output is:

   [BCP9]     Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

              Dusseault, L. and R. Sparks, "Guidance on Interoperation
              and Implementation Reports for Advancement to Draft
              Standard", BCP 9, RFC 5657, September 2009.

              Housley, R., Crocker, D., and E. Burger, "Reducing the
              Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
              October 2011.

shouldn't it be something like:

   [BCP9]     "The Internet Standards Process", BCP9.

              Dusseault, L. and R. Sparks, "Guidance on Interoperation
              and Implementation Reports for Advancement to Draft
              Standard", RFC 5657, September 2009.

              Housley, R., Crocker, D., and E. Burger, "Reducing the
              Standards Track to Two Maturity Levels", RFC 6410,
              October 2011.

...so have a title, and not repeat redundant information?

(Minimally the title would be needed for many non-IETF uses cases)

Also: when a reference is nested, should it be available as link target 
inside the document? If so, would it need to repeated outside the 
container, or would something like this:

   [BCP9]     "The Internet Standards Process", BCP9.

              [RFC5657] Dusseault, L. and R. Sparks, "Guidance on
              Interoperation and Implementation Reports for Advancement
              to Draft Standard", RFC 5657, September 2009.

              Housley, R., Crocker, D., and E. Burger, "Reducing the
              Standards Track to Two Maturity Levels", RFC 6410,
              October 2011.

be the preference?

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Sun, 6 Oct 2013 09:51:53 -0500

On Sun, Oct 6, 2013 at 6:11 AM, Julian Reschke <[email-masked]> wrote:
>   [...]

Yes.

> inside the document? If so, would it need to repeated outside the container,
> or would something like this:
>

Yes, the sub-reference anchor needs to be available for referencing
separately from the collection.  Consider an analysis of [IPsec] that
in some places refers to ESP [RFC4303] and in others to IKEv2
[RFC4306] -- surely this must be feasible!

Speaking of which, I want vanity/symbolic reference names so I can
have a reference to [RFC4306] appear as [IKEv2].  Specifically,
<reference> should have an alternate_anchor attribute, but perhaps
also in <references> there should be a way to rename anchors of
<reference>s (because, after all, most often they are external and not
available for editing by the author, not without complicating the
author's life.  Of course, there is a way to do this: with XSLT, but I
think xml2rfc needs to make this user-friendly.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Oct 2013 13:08:34 -0400

--On Sunday, 06 October, 2013 13:11 +0200 Julian Reschke
<[email-masked]> wrote:

>> # 106: reference for an STD or BCP that contains multiple RFCs
>> 
>> 
>>   Of course, that workaround then needs reformatting in the
>>   nroff and doesn't permit use of seriesInfo to generate
>>   metadata about the RFCs involved, and so on.  So it is
>>   better than nothing, but definitely  not a satisfactory
>>   solution.
> 

Yes, but (i) the information that the base document in BCP 9 had
an author, was RFC 2026, etc., is not redundant and gets lost in
your proposed layout.  And (ii) while one could make a title up
or assume that the title of the first document in the set is the
title of the BCP or STD, we have never assigned titles to the
STDs or BCPs themselves and, especially for the latter, doing so
has a record of being controversial [1].  One could imagine
non-IETF situations in which the compendium would be named, have
a date, and maybe an author or editor too, but that is beginning
to sound more like a published complication for which see below.
 
> (Minimally the title would be needed for many non-IETF uses

Certainly true, suggesting that the DTD should be something I
didn't know offhand how to write in DTD-speak but that would
allow
either

  front,seriesInfo*,format*,annotation*

or

  0*1 (front,seriesInfo*,format*,annotation*)
  1* reference

that has some stylistic implications s.t. creating a new
containing element might be a better idea -- I haven't thought
enough about it to have a strong opinion but the example below
may unintentially illustrate the problem.

An arrangement like that, with or without the new element, would
leave the questions of title and information supplied to the
authors and RFC Style Manual, rather than having to build it
into XML2RFC where, IMO, it should be avoided if possible.
 
> Also: when a reference is nested, should it be available as
> link target inside the document? If so, would it need to
> repeated outside the container, or would something like this:
> 
>           Interoperation and Implementation Reports for
>           Advancement to Draft Standard", RFC 5657, 
>           September 2009.
>
>           Housley, R., Crocker, D., and E. Burger, "Reducing 
>             the Standards Track to Two Maturity Levels", 
>             RFC 6410, October 2011.

> be the preference?

This is where I, and probably most of the rest of us, get far
outside our professional knowledge and depth.  I don't recall
ever seeing a reference into a compound one done that way.
Instead, what I have seen would look more like (following your
example as much as possible):

   [RFC5657] Dusseault, L. and R. Sparks, "Guidance on
              Interoperation and Implementation Reports for
              Advancement to Draft Standard", RFC 5657, 
              September 2009.

      Dusseault L. and R. Sparks, op. cit.

but my recollections are a rather poor guide.  Certainly the
construction suggested above would allow, modulo a little
hand-waving:

   <reference anchor="BCP9">
      <front>
         <title>The Internet Standards Process</title>
         <author/><organization/></front>
      <seriesInfo name="BCP" value="9">
      <reference anchor="RFC5657">
         <front>
           <title>Guidance on Interoperation and Implementation

             Reports for Advancement to Draft Standard</title>
           <author initials="L"  ....
         </front>
      </reference>
         ...
   </reference>

but I have no idea what the best way would be to format it.
More generally, another way to accomplish what is needed for BCP
and STD  references, but not the "articles in a journal" and
similar cases would be to have something more like

  [RFC2026] ...
  [RFC5657] ...
  [RFC6410] ...
  
  [BCP9]
     Bradner, ... [RFC2026] op. cit.
     Dusseault, ... [RFC5657] op. cit.
     Housley, ... [RFC6410] op. cit.

However, that would require relaxing the "if it isn't cited from
the text, it cannot appear in the references" rule and doing a
number of interesting (and I assume difficult) things to the DTD
and interpreter to make everything hang together.   So I'm
reluctant to propose going in that direction.

I suggest that for both the stylistic requirements about what
should be present and how it should be formatted and the
questions of what should be either available as a link target or
available as metadata [2], we hand the question off to the RFC
Editor staff.  They presumably know more about these issues than
most of the rest of us and, more important, can reasonably be
expected to find and consult the right experts, figure out what
BibTeX supports and what can be learned from it, and so on.

best,
   john

 --------------------

[1] One way to characterize the rather unpleasant newtrk "ISD"
debate is that it was about whether whether STDs (and BCPs) were
actual documents with titles and content (and RFC content
incorporated by reference) or whether they were a collection of
documents identified only by a reference number.  While moving
toward the former would help clarify the question above, I think
we should probably avoid reopening that debate, especially in
the critical path of xml2rfc.

[2] For example, if one were trying to build a citation index to
RFCs, should a reference to BCP9 count as a citation to RFC
6410?  If the answer is "yes" (as it probably should be), that
creates another version of the time-dependency problem because a
citation of BCP 9 in a document with a 2010 date on it would
presumably not be a citation of RFC 6410.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Oct 2013 19:24:28 +0200

> your proposed layout.  And (ii) while one could make a title up

Unintentionally.

Let's try again:

   [BCP9]     "The Internet Standards Process", BCP 9.

              Bradner, S., "The Internet Standards Process -- Revision
              3", RFC 2026, October 1996.

> has a record of being controversial [1].  One could imagine

Understood, but surely something we'd need for other document 
series/compound documents.

> but I have no idea what the best way would be to format it.

Indeed.

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Oct 2013 14:13:29 -0400

--On Sunday, 06 October, 2013 19:24 +0200 Julian Reschke
<[email-masked]> wrote:

>> Yes, but (i) the information that the base document in BCP 9
>> had an author, was RFC 2026, etc., is not redundant and gets
>> lost in your proposed layout.  And (ii) while one could make
>> a title up
>  > ...
> 
> Unintentionally.
> 
> Let's try again:
> 
> 

Ah. Makes far more sense.  Yes.

>> or assume that the title of the first document in the set is
>> the title of the BCP or STD, we have never assigned titles to
>> the STDs or BCPs themselves and, especially for the latter,
>> doing so has a record of being controversial [1].  One could
>> imagine
> 

Agreed.

>> but I have no idea what the best way would be to format it.

And that brings me back to ...

>> questions of what should be either available as a link target
>> or available as metadata [2], we hand the question off to the
>> RFC Editor staff.  They presumably know more about these
>> issues than most of the rest of us and, more important, can
>> reasonably be expected to find and consult the right experts,
>> figure out what BibTeX supports and what can be learned from
>> it, and so on.

best regards,
   john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 07 Oct 2013 10:43:04 +0900

>                Standards Track to Two Maturity Levels", RFC 6410,

What about the following:

    [BCP9]   "The Internet Stardards Process", BCP9, consisting of
             [RFC2026], [RFC5657] and [RFC6410].

or with some additional information:

    [BCP9]   "The Internet Stardards Process", BCP9, consisting of
             [RFC2026] as updated by [RFC5657] and [RFC6410].

(with or without title), and then the usual forms for the actual RFCs. 
While this may not look as (pseudo-)professional as the "op. cit.", it's 
way easier to follow and easier to create.

"op. cit." makes sense if citations refer e.g. to specific pages, and 
there is a possibility that the same information is repeated dozens of 
times, but not to shave off a few bytes at the cost of having the reader 
go hunt for that "Dusseault L. and R. Sparks" reference.

In more general terms, it may be helpful to check up with somebody with 
professional experience from the publishing industry, and/or with some 
publishing manuals (Chicago Manual of Style,...), but:
1) Different professionals and manauals will give different advice
2) Different communities (starting at sciences vs. humanities, but
    not stopping there) and different publications have developed vastly
    different conventions even for the base cases.
3) Cases such as the ones we are discussing now are in the long tail,
    and so there will be only limited and not necessary definite advice.
4) Publishing is ultimately first and foremost about reaching your
    audience and thinking about your user community. If there's something
    that works better for us and our readers that hasn't appeared in any
    publication up to now, and we use it, there won't be any publishing
    police coming after us. Just happy readers.

As an aside, if we don't want an explicit title, something like

    [BCP9]   "Best Current Practices 9", BCP9, consisting of
             [RFC2026] as updated by [RFC5657] and [RFC6410].

might also work.

> reluctant to propose going in that direction.

Well, the only thing necessary might be to allow references in the 
reference section, in a small free-form text. Metadata generation would 
extract a reference composition graph from there, the logic for "if it 
isn't cited from the text, it cannot appear in the references" would 
work in quite a straightforward way, and the fact that it's free text 
would mean that all kinds of exceptions could be dealt with easily.

Regards,   Martin.