[Rfc-markdown] vague dates, was: [xml2rfc] New xml2rfc release: v2.24.0

Julian Reschke <julian.reschke@gmx.de> Sun, 01 September 2019 16:51 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: rfc-markdown@ietfa.amsl.com
Delivered-To: rfc-markdown@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42B712002F; Sun, 1 Sep 2019 09:51:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sQYqQQ89QpWO; Sun, 1 Sep 2019 09:51:34 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 69D01120025; Sun, 1 Sep 2019 09:51:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567356675; bh=kCaZs7ndxP9PTOjLMGsqI7RPRXc/+n9XT83/wUSr03A=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ZfVS+L6vyb9sCfcQe5o6atm5XBrr58qZF4Tmd/AwkO/1NujTCoNsA/Xcnb7DQIQSH vN5dx02Y3Xbmh6iiJI2fKmwYIFKtzQ7RnxADlarcyE2xQpLwVWY8+xtqUmtikGH1h3 oMJDZIlz3CMzybmcR0mRv9r/LpniX1nO8UFQe1R0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.132.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MbfnB-1hncVa25Lh-00J2NR; Sun, 01 Sep 2019 18:51:15 +0200
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
References: <E1hwTDm-00064V-6E@durif.tools.ietf.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <add95758-94ee-00cc-74af-70629c962097@gmx.de>
Date: Sun, 1 Sep 2019 18:51:12 +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: <E1hwTDm-00064V-6E@durif.tools.ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:IHfD2Zbp8fdBDhcqFeYnlsEuEQEXDy10fNROrDfTRxnJevs0PQP tvCslaBFzMY1aI3t1XoVEfLeU512QFieog3OOXHXHi/ID8jbEBSaw4rdlDCAkjyOVGOMKbd 099TobP8DnAlJRIL3aHa/EhY96okeeIuNCF8Ou3LlVpo4D9F7+AQg1AtVejGaR0+XmsRtaQ s6DDSPmzi0MQSUsLOBSEg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Tr4kVaXwi2c=:1dhdq+ptk1kv7OmLpZAmml TurKkcexw9PaiE697BT4qImwQL5MyhVHSrOw+uswBJ1z8TNrMd6tq24uvuJ8gHwoftbMRteGT qc1ZVeTz2gFdE6ZsMmq6yVl/fG/FCQEDcU8Ox0wsQCQ9cHfn/N/QAd/jrz13eFJREaGcN37FG 2R0N09OJie8YFe51Vog1sPeSbZneT19iRfFAqf1gqMz5P9vQvYYwPGBxXi+Y96RgfI/WRwsXe ghXmU22bL/oZ1BlZptJ5eReK2eBXySRo206UWwNSs+7u9u/7QG7p0OONwBaNMgAsWdbDKe6aR bXVkHuOzXViBCjdHAzN72/zWQ4oEjGM2hfCmIISDMFwG0LlG+Hux1mAw9lcDlILk3K5E0oHdp muPZpzHizCAB73AMG+8/S2ncrd5VsjaTe9PtknAFhy4Ea0ILuLiOnDRwYvmLb0NT9OSl0qRP3 0/1fdTzmxUA3VvHGWL+CBAQWfKqJpAby4Slgh/SAF+gXj5QqYS3GWiILV5gRfKyiEFAYVLumP enxkaDH1gXHytBnp2Q2B9Wdg7cDWzVlAEbC9txB8WzW48wMMOeH/EVPsGHoaob5YuOv/LkDRK 1DbdOLn7/XB2iGDsTmO5DUnWharjlFTS1M5oBnYUbolnR179cG/rbYdiqT3guYX2KnBdOsDD6 IUBaRvuA55u/F2P1RcUUir3XXkguTrshtR+YQYE/GevuSTjooFPKjnojPGglEeGa88bVRWVyq eofnIGTAgGiLEJhMybZbMFuMqe1tJP/RZGwQURglln0JgNjNSxOSYerg1mQvVTOSjzbnreWW5 fOn+ofgoW3rdst8dyGU6mmHssQR6z1z9bjGmSL9gkEn760IlXSP1ezPWbSS2wr7paEYM02csI ijWqHySlil2dHkD/FJdifcFtbnZY8K+++s0HhQozAT5W/rkRlYd8hF/HPUPdzbwHBb7tIB3hw A6+ash5x+LSwqIpb+O+15wpdbEhj8zOa9aXn8T+ckR05/vV1K7w4v4IXbBN0OWSAKTddcI41D n8xhiYMNFJlcE7CGNk3Fmgh0GdWoLgXCW+y+iJwSaU2lu/rAPzY/pKkZat0bsZgkrzM/OSqJC GRg/yzmvPMrb9uBHeErhkr/gMsjHrQ+u76gJZj3xQ+CjdnIMIV0Qzb0JW6JmGFjyttU26Sln3 5F5GwcZXSYrwzLwnSMniIIeHShiru6UVuwroGHeYKviVVZMQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/vwZcx-u5M-LMjpedf2efyoVc3QU>
Subject: [Rfc-markdown] vague dates, was: [xml2rfc] New xml2rfc release: v2.24.0
X-BeenThere: rfc-markdown@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "rfc-markdown is a discussion list for people writing I-Ds and RFCs in Markdown and the authors of the tools used for that." <rfc-markdown.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-markdown/>
List-Post: <mailto:rfc-markdown@ietf.org>
List-Help: <mailto:rfc-markdown-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Sep 2019 16:51:37 -0000

On 10.08.2019 17:23, Henrik Levkowetz wrote:
> ...
>    * Tweaked the <date> handling to make year ranges and fuzzy dates possible.
> ...

...as proposed in
<https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-4.1.3.2>.

I believe this is a good change (and I have implemented in rfc2629.xslt,
see
<https://github.com/reschke/xml2rfc/commit/8596c0ffd14a7743621252d0bbfe0ba3acad1e2e>).

That said, we should clarify:

- that this applies only to <date> below <reference> elements
- what should happen when both text content and attributes are present
(rfc2629.xslt only takes the text content when no non-empty attributes
are present).

One comment on
<https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-4.1.3.2>:

>    The text regarding prose text for month and year in bibliographic
>    references is not workable.  How should month and year be combined?
>    Some bibliographic references may have date text which requires year
>    first, others year last, and so on.  Mixing the described fuzziness
>    into the otherwise strict year, month, date format makes little sense
>    when the result of combining the year, month and date attributes
>    cannot be predictably and correctly rendered.

That's not a big issue in practice; just cram everything into the year
attribute, and do not set the others. Yes, this is a hack, but it works,
and has been used in the past (I can provide concrete numbers from
AUTH48 if people want to see them).

Final thoughts:

- in theory this could be used for specifying the dates of April 1st
RFCs (but I believe the approach proposed in
<https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/30> is
better)

- the RFC style guide should be clear about what to do for undated
references, and this ("vague" dates) might be useful for that

Best regards, Julian