Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates

[John C Klensin <[e-mail]>]

--On Friday, July 12, 2019 15:40 +0200 Julian Reschke
<[e-mail]> wrote:

> On 12.07.2019 15:16, Henrik Levkowetz wrote:
>> Hi John,
>> 
>> On 2019-07-11 23:51, John C Klensin wrote:
>>> Hi.
>>> 
>>> I happened to look today at the reference produced for an
>>> I-D by xml2rfc (at least by the online version at
>>> https://xml2rfc.tools.ietf.org/ )
>>> 
>>> The XML for the relevant cited I-D says (irrelevant material
>>> elided and the identity of the I-D changed to avoid
>>> distractions):
>>> 
>>>    <reference <reference anchor="ID.draft-ietf-foo-bar"
>>> 	 target="https://datatracker.ietf.org/doc/draft-ietf-foo-ba
>>> 	 r/"> ...
>>>      <date month="June" day="12" year="2019" />
>>>      </front>
>>>    </reference>
>>> 
>>> The output is "June 2019".
>> 
>> After looking through various output formats, my conclusion
>> here is that this is the output from the v2 text formatter,
>> not the v3 text formatter.  The v3 text formatter renders the
>> date with day, month, and year if all 3 are given.  So going
>> forward, it seems that this has already been addressed
>> (assuming we leave the v2 formatter untouched at this late
>> stage in its life cycle). ...
> 
> Hmmm.
> 
> That seems to be a rather big change to be introduced without
> notice.
> 
> I think the first thing that needs to happen is the RFC Style
> Guide
> would need to say how to handle the format. Right now it says
> "year
> month", and this is what tools have been generating for ages.
> 
> Heather?

Julian (and others),

Please go back and look at the note that started this thread,
where I explicitly said I was concerned about I-Ds and not final
format RFCs. 

The details of RFC formats have _always_ been different than I-D
requirements, with the most obvious example being different
boilerplate.  We do not obscure information in I-Ds by claiming
all other I-Ds are works in progress.  For I-Ds, whatever the
nits checker may find (or thinks it finds) notwithstanding, we
do not try to enforce references to most recent version in I-Ds
(because the earlier version might be intentional.  In the
document header, I-Ds show full dates, show "(if approved)" on
the update line, show the status as "Intended", and don't show
an ISSN.  And I-Ds show a full (with day number) date and an
expiration date (also a full date) while RFCs (at least April 1
documents aside) show only month and year.

<rant TL:DR-version: Citing the RFC Style Guide is irrelevant or
worse where this issue is concerned>

One of the strong advantages of generic markup over the old
methods of preparing I-Ds in ASCII text editors or in nroff is
that most of those differences can be accomplished by using
different style sheets or otherwise in processing for the two
output styles.

For the text of a reference, the easiest workaround for me (see
the exchange with  Brian) when I think the date is important is
to simply generate the text file for posting and then spend two
minutes with a text editor patching the dates back in.   Unless
the intent of being able to use I-Ds to get a preliminary
concept document out there has been lost and the IETF has
developed a serious attack of form over content, those RFC style
requirements or recommendations don't constrain I-Ds.

In particular, at your behest, I went back and looked at
https://tools.ietf.org/html/draft-flanagan-7322bis-03#section-4.8.6.2.
It (and its predecessors) say exactly what I expected them to
say: they talk about RFCs and not about I-Ds.  The only thing
that most current draft says about I-Ds appears in the last
paragraph of Section 1:

	"All RFCs begin as Internet-Drafts (also referred to as
	I-Ds), and a well-written and properly constructed
	Internet-Draft [ID-GUIDE] provides a strong basis for a
	good RFC."

There is also the statement in Section 4.8.6 about normative
references to I-Ds, but that has nothing to do with this
discussion.  Curiously 4.8.6.4 _requires_ that the full draft
name, including the number, appear when (informative) references
to I-Ds appear in RFCs, but not only is this something else that
is not being enforced for I-Ds by xml2rfc or the submission
tool, but the example at the end of that section doesn't bear
"work in progress" and hence does not conform to the _current_
style guide for RFCs but anticipates a change that it makes.   

That proposed change is, by the way, interesting in another way,
which is that it removes a requirement that is rather clearly
specified in RFC 2026 Section 2.2.  Although I believe that
requirement is badly in need of adjustment to avoid silly states
with historical references rather than references to I-Ds that
are even possibly still under development, there is no "updates
2026" in that I-D and we don't make changes that modify BCPs
(especially, IMO, that BCP) in an Informational RFC, especially
one that will not be processed in the IETF Stream. 

</rant>

So, this request is about one thing and one thing only.  If the
author or editor of an I-D decides that it is important to
communicate some information to the reader because that
information will be --in his or her judgment or the judgment of
a relevant WG-- useful to readers in understanding what is going
on, then, as long as the markup is correct enough to get through
the processor, xml2rfc should not discard that information.  If
the IESG wants to constrain those choices, then the ID-guide
should be opened and modified if there is community consensus
for doing so.   

But this has nothing to do with the RFC Style Guide.   I'd hope
the different style sheets/ processors would smooth out any
details there, but, if the RFC Editor says "you must remove all
day attributes from dates in references before the document is
handed off to the RFC Editor", I'll deal with that issue when
the time comes.   Heather has already said, several times,
things equivalent to "if you want documents to go through the
production process quickly, don't say 'the RFC Editor will fix
that'".   I've got that and figured out long ago (while Jon
Postel was still the RFC Editor) that the more I can get a
document --editorially and structurally-- into RFC Editor form
before it is handed off, the faster things will go and the less
aggravated I and the RFC Editor staff will get during Last Call.
So, great advice, but it doesn't have anything to do with this
request either.

best,
    john