[rfc-i] reference extensions

Paul Hoffman paul.hoffman at vpnc.org
Mon Feb 17 08:50:35 PST 2014

On Feb 17, 2014, at 8:27 AM, Julian Reschke <julian.reschke at gmx.de> 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 work, but both have their faults.
>>>>   The first requires good copying skills and sometimes causes difficult
>>> What exactly do you mean by "good copying skills"? The ability to copy and paste from an XML document? Maybe that's something we can address by just creating easier-to-use libraries.
>> We could do that. How would it possibly be easier than using the new attributes?
> It's easier in that it doesn't require anything new; it also avoids hardwiring knowledge about reference libraries into the processor.

Sorry, I meant easier for the hundreds/thousands of people writing Internet Drafts. Minimizing the work for the people writing the processor at the expense of the people writing drafts is the wrong optimization.

>>>>   o  Thus, the contents of <reference> changes from requiring a <front>
>>>>      element to making the <front> element optional if a "series" is
>>>>      given.
>>> Well, not in the schema that you are using.
>> Please say more.
> There's nothing in the RNG that makes it clear that you need either the series attribute or a <front> element. Everything has become optional.

Got it. I will fix that in the next rev. I figured that describing it in words was more important. However, I'm still interested if people want to see this as an attribute or as an element that would block the use of <front>, <seriesinfo>, and <format> in that <reference>.

> If the series information was a child element instead of an attribute, it would be simple to express the constraint in the grammar (it might be possible with attributes in RNG, but then we'd have the first case of a grammar constraint that's not expressible in the DTD as well).

...which brings us back to the other thread about whether expression in the DTD is necessary.

>> Having a canonical RFC have an inclusion from an external source seems like a very bad idea for stability. Instead, we should keep requiring that the canonical RFC be complete and unchanging.
> Yes, the canonical document needs to be self-contained. Your proposal doesn't solve this, unless you assume that the new notation always identifies immutable information.


> That may be true for RFCs, but it's not true for many other things people want to reference, such as internet drafts.

An Internet Draft with a particular complete filename is a stable reference. The RFC Editor would treat these the same way in v3 as they do now.

--Paul Hoffman

More information about the rfc-interest mailing list