Closed ajeanmahoney closed 4 months ago
references for subseries that contain only one RFC look odd because two URLs are included for a single document.
The link for the document is included with the document.
The problem is that the link for the subseries entry is unadorned (and at the wrong end). This is a problem for both the single-document entry and the multi-document entry.
I'm sure we can tweak this some more; my objective was to first no longer lose information (and to stop making Internet Standard documents second class citizens as they no longer get a link).
(You can always tweak the XML to say what you want to have; you don't need a referencegroup for your example. I'd rather keep the referencegroup though.)
Generally speaking, having information in the XML that the renderer then chooses to delete in some of the renderings just because of some style consideration is a non-starter.
Example for better rendering:
[STD72] Internet Standard 72, <https://www.rfc-editor.org/info/std72>.
At the time of writing, this comprises the following document:
Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>.
This actually explains the unfamiliar STD/BCP abbreviation and indicates that the composition of the subseries entry can change over time (e.g., STD96).
@cabo I like your suggestion and the RPC has been discussing it, thanks!
Note that the RPC will open a new issue that will describe the format of subseries references for both the one-rfc and multi-rfc cases.
I'm closing this issue as #1100 now captures more completely how subseries references should look.
Describe the issue
(including @cabo because he opened #1067)
While the fix for #1067 looks good for multiple-RFC subseries references, the references for subseries that contain only one RFC look odd because two URLs are included for a single document.
Previous:
Current:
New:
Code of Conduct