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

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

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

> On 12.07.2019 19:10, John C Klensin wrote:
>> ...
>> 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 RFC.
> 
> Well, allow me to concerned about all types, being the author
> on an
> xml2rfc processor :-)
> 
>> ... > 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.
>> ...
> 
> You're losing me. Why is the day of month of any relevance
> when the draft has a version number?

I fear we are not communicating.

Let me give you two reasons.  The second one is the important
one; I wonder whether the first one is enough of a distraction
that I should omit it.

(1) Suppose that there was some external event or announcement
that interacted with the subject matter of an I-D (a product
being shipped or the announcement of a really nasty vunerability
come to mind as possible examples).  It would then be helpful
for the reader to be able to tell, quickly, whether there is any
chance that the I-D might have addressed those issues.
Certainly that date information could be determined by going to
the tracker with the version number and looking up the date
there, but I don't think our goal should be to see how many
hoops (or page clicks) we can get the reader to jump through.  I
hope you agree.

(2) As long as the purpose of posting documents as I-Ds includes
allowing authors or groups to expose ideas to the community for
discussion, editorial decisions about what belongs in those
documents should be in the hands of those authors.  Neither the
community, nor the authors of a production tool that is
recommended by the community for use with I-Ds, should make
stylistic decisions that affect what information is presented
without a compelling reason.   So the question isn't why I might
want to display the day of the month, it is why you (or some
other tool author or specifier) should tell me I can't have it
displayed.  

I note that we do have some requirements about content.  For
legal and related reasons, I-Ds are not allowed to be posted
unless they contain one of more of a selection of specific
statements.  If some authors doesn't agree, they just don't get
to post.  The same comment applies to some extremely basic
format/layout requirements that make the collection more
manageable.  For similar management reasons, there is even
supposed to be a rule about file naming but people ignore it
with impunity.   The community has decided that documents MUST
have Security Considerations sections but, even for that, we
allow versions of I-Ds to say "to be supplied" or equivalent up
to the point that the community, via a relevant Stream, is asked
to process them.   All of those requirements exist for
substantive reasons and there is rough consensus in the
community that they are important.   One thing they have in
common is that they specify information that is required to be
present, not information that is required to be omitted.   

We do have a few rules about what must be omitted or that is not
allowed to appear, but they are tied to IPR, e.g., I'm breaking
assorted rules if I use an I-D to disclose someone else's trade
secrets.  However, that is a little different from a day number.
Actually, IMO, it is a lot different.

As a specific case of more general principles, I imagine that
there is informal community consensus that foul, obscene, or
inherently denigrating language does not belong in I-Ds.
However, even then, I don't believe it is in the community's
interest to have the xml2rfc processor silently remove the
words.  If you did so, I'd assume some authors would claim the
processor and its authors were behaving inappropriately,
possibly by censoring their freedom of expression or possibly by
causing them to look like illiterates by destroying their
sentence structure.    If you wanted to make a case that the
processor, upon discovering such a word, should put up an error
messages about a prohibition on obscenity and then stop, I'd
think that would be a better choice, but I don't think it would
be reasonable for the Tools Team to decide to do that without at
least some evidence of community discussion and consensus.

In any event, the exclusion of a digit or two does not fall into
a foul or obscene language category.   The processor is simply
removing information that I, as author, believe is important
enough to include in the XML and removing it because you someone
decided I didn't need it.  I assume from this thread that you
think it is my obligation to convince you otherwise (that I do
need to have it displayed), perhaps even on a case by case
basis.  I hope we have not reached the stage that the IETF works
that way.

best,
   john