Re: [xml2rfc] xml2rfc Digest, Vol 101, Issue 9

John C Klensin <john-ietf@jck.com> Mon, 15 July 2019 04:37 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90984120046 for <xml2rfc@ietfa.amsl.com>; Sun, 14 Jul 2019 21:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0zpXd0KpF9U for <xml2rfc@ietfa.amsl.com>; Sun, 14 Jul 2019 21:37:16 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54ED9120020 for <xml2rfc@ietf.org>; Sun, 14 Jul 2019 21:37:16 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hmsji-000BmQ-3y; Mon, 15 Jul 2019 00:37:14 -0400
Date: Mon, 15 Jul 2019 00:37:07 -0400
From: John C Klensin <john-ietf@jck.com>
To: xml2rfc@ietf.org
Message-ID: <D6BFA5CE08E512F22AD43083@PSB>
In-Reply-To: <mailman.54.1563044416.29666.xml2rfc@ietf.org>
References: <mailman.54.1563044416.29666.xml2rfc@ietf.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/H5WcXBiAJ_EV-0VNz6TSgQw4coc>
Subject: Re: [xml2rfc] xml2rfc Digest, Vol 101, Issue 9
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 04:37:19 -0000

On 12.07.2019 19:44, Julian Reschke wrote:
>> ...
>> So then who is in charge to decide whether the day of month
>> is inserted?
>> 
>> 1) The author? (in that case, the citation libs would need to
>> drop the date for internet drafts)
>> 
>> 2) The processor? (in which case it'll need an extra signal
>> for April 1st RFCs)
>> 
>> This may have been not so important in the past. But in the
>> v3 world (AFAIU), there will be no manual post-processing
>> step anymore, so whatever the formatter emits will be what
>> people see... ...
> 
> Proposed extension:
> <https://greenbytes.de/tech/webdav/rfc2629xslt.html#ext-rfc262
> 9.date>
> 
> Example:
> <https://greenbytes.de/tech/webdav/rfc2616.html#RFC2324>

I think this (including the proposed extension) is being made
unnecessarily complicated and that 

   x:include-day" ("true", "false") 

as proposed does not do the right thing.

The system clearly knows whether it is generating I-Ds or RFCs.
It clearly has to in order to generate different boilerplate.
So, 

for RFCs:
(i) The front page is always without a day-of-month unless some
attribute or other flag is present (for the April 1 case).

(ii) References use whatever content and format the Style Guide
says what they use.  If it is "Month Year" then maybe an
attribute should permit an exception to that, but I doubt it
will be used very often if ever.

(iii) The Style Guide should be reviewed to make sure that a
reference to a document published in a language other than
English and whose preferred date is not in English (and perhaps
not even in Gregorian calendar) comes out the way the RFC Editor
wants it.  I am largely agnostic as to what that is, but it
should probably be sorted out and specified now because it may
affect the markup.  I would strongly encourage people to think
about this using an example that is not drawn from Latin script
or even a European script.

For I-Ds (and any other non-RFCs of interest):

(i) The front page is "month day, year".  I note that the
submission tool will reject an I-D submission if the day number
is not present.   If the xml2rfc developers want to provide
extra generality by including an attribute to suppress the day,
go for it, but I believe the only thing that could make that
necessary is automatic date (including day number) generation
when <date> is used without all of "year", "month", and "day"
attributes.

(ii) References simply use whatever authors supply.  If a day
number is specified, it appears.  If it isn't, it doesn't.  Note
that this principle is important for another reason and that is
at least one reason why we don't make up date values when the
<date> element is specified without attributes: some journals
publish only once a year and traditional books generally do not
specify even month information.  So what the author specifies,
whether it be a year, a year and month, or a year, month, and
day goes into the output.

(iii) Finally, I think that using different date formats in
different places (I'm talking about the format here, not whether
or not a day number appears) is probably an invitation to
trouble long-term.  Perhaps, with the likely exception of the
RFC header (and maybe footer), it is time to recognize that,
along with other changes for the new format, RFCs are becoming
"international" enough that it would be appropriate to go with
ISO 8601 dates and be done with it, both in whatever in
generated by markup and in Style Guide recommendations about any
dates that might appear in running text.   Or not.

best,
    john