[rfc-i] Proposal for v3 to simplify most referneces

Michael Richardson mcr+ietf at sandelman.ca
Mon Feb 10 07:36:17 PST 2014

Paul Hoffman <paul.hoffman at vpnc.org> wrote:
    > The two popular methods now for references to RFCs are entering the
    > whole reference by hand (hopefully getting all the fiddly bits of
    > <front> and <seriesinfo> correct), or using XML entities that call out
    > the xml.resource.org. Both have their faults. The first requires good
    > copying skills and sometimes causes difficult XML errors; the second
    > prevents you from changing the anchor name and also requires that you
    > be online when you run the xml2rfc processor.

While I agree with everything you propose, the python xml2rfc processor
caches all those references locally (rather aggressively, with little obvious
way to time them out...), and once you run it once, you can operate without
network.  So the offline argument is not as strong as it used to be.

    > The <reference> element can take another optional attribute: "rfc",
    > "fyi", "id" "bcp", or "std". Each takes a string that is a number. If
    > "bcp" or "std" are given, an additional optional "expanded" attribute
    > can be given: it is a comma-separated list of numbers. At the same
    > time, the contents of <reference> goes from requiring <front> to making
    > <front> optional.

okay.... so does the References section get a fully expanded output
(the reference.XXXX.xml file gets sucked in at some point), or is it
truncated if the user is offline?

    > This would make it much easier to create RFCs that have the desired
    > anchor names. It would also prevent the RFC Editor from having to check
    > and/or replace the <reference> contents for Internet Drafts that come
    > to them. (Ideas for simplifying references to documents from outside
    > the IETF can be handled at a different time.)

I agree.

A *concern* that I have is that referencing RFCs is really easy, but
getting a reference constructed to other documents is sometimes quite

Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20140210/25c6372b/attachment.sig>

More information about the rfc-interest mailing list