[rfc-i] reference extensions

Julian Reschke julian.reschke at gmx.de
Sun Feb 16 23:18:57 PST 2014

On the proposed <reference> changes 

>    This section describes one of the larger changes in the design of v3,
>    namely the additions to make using references easier.  Most
>    references in most recent RFCs are just to RFCs; sometimes they are
>    Internet Drafts as work-in-progress; much less often they are
>    pointers to standards of other SDOs, research articles, or just plain
>    URLs.  There have been many complaints about how difficult it is for
>    people who don't have strong XML skills to use references when making
>    Internet Drafts.

True, but then creating RFC references already is easy compared to the 
other series, as we *do* have preformatted entries.

>    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.

>    XML errors; the second prevents you from changing the anchor name
>    and, less importantly, also requires that you be online when you run
>    the xml2rfc processor.

Unless there's a cache. But yes.

Another drawback is that the document isn't self-contained anymore.

>    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.

If automatic validation remains a goal, this probably needs to be a new 
child element that can be used in place of <front>. Another alternative 
would be to keep <front> and to leverage <seriesInfo>.

That being said, this proposal tries to address a problem that is not 
specific to <reference>s; inclusion of external content. I'd prefer to 
come up with something which works for other content as well, such as by 
defining a generic inclusion mechanism (such as XInclude or a subset of it).

It also does *not* address other problems with <reference>, such as the 
naming constraint on anchors (which makes it impossible to use a label 
such as [3GPP], nor the reference-to-a-document-series problem.

Best regards, Julian

More information about the rfc-interest mailing list