IETF Logo Mail Archive

Re: [Rfc-markdown] initials handling, was: [xml2rfc] New xml2rfc release: v2.22.3

"HANSEN, TONY L" <tony@att.com> Tue, 09 April 2019 12:11 UTC

Return-Path: <tony@att.com>
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 E0E011207B7; Tue, 9 Apr 2019 05:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.237
X-Spam-Level:
X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 TzU85blKrysm; Tue, 9 Apr 2019 05:11:31 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D951207AF; Tue, 9 Apr 2019 05:11:30 -0700 (PDT)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x39C5x4Q033593; Tue, 9 Apr 2019 08:11:29 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2rrtyg0dkc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Apr 2019 08:11:29 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x39CBSO5001287; Tue, 9 Apr 2019 08:11:28 -0400
Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x39CBK6m001174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Apr 2019 08:11:23 -0400
Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id A554940002D5; Tue, 9 Apr 2019 12:11:20 +0000 (GMT)
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (unknown [130.9.129.148]) by zlp27127.vci.att.com (Service) with ESMTPS id 9199140002BC; Tue, 9 Apr 2019 12:11:20 +0000 (GMT)
Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.7]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0439.000; Tue, 9 Apr 2019 08:11:20 -0400
From: "HANSEN, TONY L" <tony@att.com>
To: Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc-dev@ietf.org" <xml2rfc-dev@ietf.org>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
CC: "rfc-markdown@ietf.org" <rfc-markdown@ietf.org>
Thread-Topic: [Rfc-markdown] initials handling, was: [xml2rfc] New xml2rfc release: v2.22.3
Thread-Index: AQHU7sZ83tbefHmC8kORj/lmPR6/aKYz9saAgAACnQD//8O9gA==
Date: Tue, 09 Apr 2019 12:11:19 +0000
Message-ID: <561D7097-7155-4DDD-8C5D-FA65663B5105@att.com>
References: <E1hDSIW-0008DY-Hl@durif.tools.ietf.org> <c8d8c9e9-88dd-8c49-c1d4-e0438c56a03c@gmx.de> <f41d8ba2-7078-0ffa-3e41-6f8bc1d0f766@levkowetz.com> <dfcbd237-bbff-867d-b704-cb874c4b2ed3@gmx.de> <b760846d-5183-ad8a-dd42-62a7800bdbf6@levkowetz.com>
In-Reply-To: <b760846d-5183-ad8a-dd42-62a7800bdbf6@levkowetz.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.210.11.203]
Content-Type: text/plain; charset="utf-8"
Content-ID: <42DF2E284471A448ACD8D02DB4BADBAC@LOCAL>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-09_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904090078
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/eJZ7NcTXiKygNZa33yVPMbw4igo>
Subject: Re: [Rfc-markdown] initials handling, was: [xml2rfc] New xml2rfc release: v2.22.3
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: Tue, 09 Apr 2019 12:11:32 -0000

On 4/9/19, 7:47 AM, "Rfc-markdown on behalf of Henrik Levkowetz" <rfc-markdown-bounces@ietf.org on behalf of henrik@levkowetz.com> wrote:

    
    On 2019-04-09 13:37, Julian Reschke wrote:
    > On 09.04.2019 13:21, Henrik Levkowetz wrote:
    >> ...
    >>> Shouldn't the initials handling depend on what RFC the reference appears
    >>> in (as opposed to what RFC is being cited)???
    >>
    >> The RFC-Editor has requested that the rendering should match the front page
    >> of the RFC in question, and provided the information that RFC 1272 and
    >> earlier should be limited to one initial, irrespective of what's given in
    >> the <reference> entry.
    >> ...
    > 
    > Wow, a nice new requirement.
    > 
    > It would be great if changes like these would be communicated by the RFC
    > Editor. (Or did I miss something?)
    
    This came up as a difference between the legacy rendering and the v3 rendering.
    I haven't dug into exactly which heuristics the legacy rendering used to
    make the distinction.  The idea that the reference entries should reflect
    what was actually published isn't new; if anything it's been a consistent
    expectation for a long long time.


How is the requirement to generate a single initial communicated within the XML? By looking at the RFC number? Or by a different attribute specified somewhere? While using the RFC number might seem simpler, I think it's better to be transparent and use an attribute.

	Tony

v2.23.0 | Report a Bug | By Email