[xml2rfc] day handling in references, was: xml2rfc Digest, Vol 101, Issue 9

Julian Reschke <julian.reschke@gmx.de> Mon, 15 July 2019 08:20 UTC

Return-Path: <julian.reschke@gmx.de>
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 82CE5120074 for <xml2rfc@ietfa.amsl.com>; Mon, 15 Jul 2019 01:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 a9gwDcV8Qh1H for <xml2rfc@ietfa.amsl.com>; Mon, 15 Jul 2019 01:20:04 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEBB12001E for <xml2rfc@ietf.org>; Mon, 15 Jul 2019 01:20:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563178794; bh=uvK4WIRlbx++PO8gSYcxkPnfPrDhmmboGy5T5YYiNjs=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ks90Z3R3B1WRPlGeEQDUpYpztNpFYZBjaEOw0LXFG/sMfmGcvyzpTGF/3U53yr/ce kl14NIdab4d8FKjWfX42gHc1hfdt8UfHvapCIV2GGHth+yPlPEjpbfTCvXE+nn7hBB +HPm7RxrbDcw7ONZpT8gqPCExM6K3XDfe3FB7LF4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.147.104]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LcT2M-1iCspQ2Ih4-00jsxS; Mon, 15 Jul 2019 10:19:54 +0200
To: John C Klensin <john-ietf@jck.com>, xml2rfc@ietf.org
References: <mailman.54.1563044416.29666.xml2rfc@ietf.org> <D6BFA5CE08E512F22AD43083@PSB>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <b1163395-83bc-cdcd-8e16-4a801f1a004c@gmx.de>
Date: Mon, 15 Jul 2019 10:19:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <D6BFA5CE08E512F22AD43083@PSB>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:QNtE9ux5StQWHZP8KTpQFZaFSWPqv42Pc0biIYvbQV6D/nFgoQJ EYAOVo+Qj2SvdinLwXPQH8bklR2a+zsYls51lGWegLcyXwg7k1JA9oYQfBgR0bdSDhJT/nJ 1FO9gCeXn4Pw8dwmAaS/eDBV0LLJWii3urrCekCNYaHYE/PMI/BVny9LxgQX8NQR6tosGeW NAeWH+Hy+xILsfhSo7RKA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Gd4naQo2YkA=:SFJ3s2z/fX/fbhkWdpWnvY fQ9OcooFZFNzHCN6/Ue7HZA6KerjpvAA5iN/Xa4gz+Fuf2S9Rdp2SA1afrf/y1mUKuUHKW7Xn jCp0OWxQwy/y+bLkQ1vBb5hb58Ps+VlAN9ecmlH+7uIqOBLVNAFAIjBsQTVCZn6FPQ2nxVeZf u10lscjs/lbTxzHBS0YYMeTnDQgdkXfUMFS3iLFOxot295LVvlX9BC62N6K6slgsDmn5g4/K3 77pr3k7frLj21sD4pUV4nuyknbg7/ZTqXidzw+KTPPImzRHrRKPkGsZMNrTQhMuH0EH3UFGkR Zxcsqpogu8e+LuC1zPYEuL2fMG6+T9UzObOTgsnC+907NY6NSbd2xgRTHw6k+u2Cf/G5w1dFD dFXbaZjbZKEiQqqZu4YSVNhPqZBm8tVrvIjtVEWv4wP0CIfa2w7IFaboo2661t+oUpi4Avd+M fdQFFlb0ougEDw0VkdBUjTxk9nv6VrXAQKbk7HLzu2pnrJE8jWsbRqXWyfTWm0x7htKfnjdNB /aY2QFjZPpgcyPMkMfAMXvX8jBr2YClz6ojv3Fd+zrBlbvX/4K8RRx2o+HxT32nu2ID6XSvXn B60y7CY66EnnoY118sZW1jVOaI8vD+PBVYrTPwEKIH6CbarMGdtkbm3W0jVgpGKtRlXd9lyrf EIJ1V34bz2VhDYhKYUZf0rkmC6j0j6tK43lDIGFCAHFSTd3cPEo1iuW8FAKAstgNxJ2Jr4bl2 Pr7pTOh+JOQmpERZtRhpFLoeVlRQyUKLwDYQoDm8lkqCFrME6wczlvrVHvK6LEawCIrBDW+1d ytH51JEE8KpPIPSm6PbZu8hTQ6GWDlCfNz/+tiMmYKPMU7ugAOmPv6X06HwUOvTMhT3hRkdrm ZAp18YBq1j72covRcSvTmnnKyteVOeisDw/UCw+0G9dUiqrCAU+wLQYMe9jGDFBfZ8H88vWa/ tvO1r74GOn804vzrboHX/uNzDL7GtWuSuMfkiDOJQDxnY95w98f+GzhW9Re4cGD8xvNJFu0s6 h/R0Fm6giGsvvY8nkImUd3XOWuOH9a85T+x7mlqje3q9EAUIx3yYdp5xG9Nb0hXKonva8OBS5 0eQfibHOoLyPfb90Xh9mjutVHwp0DmElrAb
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/zYr7yWX5Hu--MrLi7EYBFt4nrFs>
Subject: [xml2rfc] day handling in references, was: 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 08:20:07 -0000

On 15.07.2019 06:37, John C Klensin wrote:
>
> 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.

It does allow me to produce the desired output while staying compatible
with what formatting have been doing for many years.

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

Yes.

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

That's exactly what the proposed flag does for the boilerplate.

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

It would be needed when citing April-1st RFCs (*), and that's exactly
the proposal does.

(*) While looking at examples, I found that sometimes April 1st RFCs are
cited without the day information. Would be good to understand whether
there is a rule for that or not.

> (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 bibliographical references, the date information essentially can be
prose already; AFAIU, there are no restrictions about what you can put
into the attributes (I even found a case where somebody used month="1
April" to force the day into the output).

> 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

I don't think that is the case, at least if you also leave out year and
month.

> 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

Well, that's a breaking change.

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

And this is already the case for month and year, so I'm not sure what
this has to do with the question of including the day or not.

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

Not only long-term.

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

Yes. See
<https://greenbytes.de/tech/webdav/rfc7992.html#document-information>
for what the current spec ways about the HTML format (although it omits
the case where no day is given).

Best regards, Julian