IETF Logo Mail Archive

Re: [Xml-sg-cmt] Prepping an I-D ?

Robert Sparks <rjsparks@nostrum.com> Mon, 09 May 2022 13:49 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: xml-sg-cmt@ietfa.amsl.com
Delivered-To: xml-sg-cmt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799FFC14F74C for <xml-sg-cmt@ietfa.amsl.com>; Mon, 9 May 2022 06:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.932
X-Spam-Level:
X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stneRsSX8xP2 for <xml-sg-cmt@ietfa.amsl.com>; Mon, 9 May 2022 06:49:42 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D64C15E6DA for <xml-sg-cmt@ietf.org>; Mon, 9 May 2022 06:49:29 -0700 (PDT)
Received: from [192.168.1.114] ([47.186.48.51]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 249DnMhX086367 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 9 May 2022 08:49:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1652104164; bh=Hw0wDpabUbAy6GIQrPc6iU54/RjO1CS4rFn82+N0no8=; h=Date:Subject:To:References:From:In-Reply-To; b=wQoLtKAlhjDin2t7GW4ZcWMLlb5BFWs+E+MKqgky23zjE67DJ+xKuSUzDu5zrpl3w UsCaZsH/ZAR81lm+RZyZlDBQHiuYffVh1zeWKAnlBWOFL+G/K9y8omblsgRI6uE4A5 vDhQdekrsKQP34Tydo8/NiHtXu+bjy4uIhMYNt84=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.114]
Message-ID: <9da4eacb-3bdd-f8d6-35f2-c1495a82c6dc@nostrum.com>
Date: Mon, 09 May 2022 08:49:17 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: Julian Reschke <julian.reschke@gmx.de>, xml-sg-cmt@ietf.org
References: <ab19a1b1-9436-1c7a-fae6-14d795fc602d@taugh.com> <5f45341a-51fa-599e-3311-e3c210aa6391@gmx.de>
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <5f45341a-51fa-599e-3311-e3c210aa6391@gmx.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml-sg-cmt/_1QKiTpRdydKkKlQBvH4eL8jNjU>
Subject: Re: [Xml-sg-cmt] Prepping an I-D ?
X-BeenThere: xml-sg-cmt@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Working list for the xml and style guide change management team <xml-sg-cmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml-sg-cmt>, <mailto:xml-sg-cmt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml-sg-cmt/>
List-Post: <mailto:xml-sg-cmt@ietf.org>
List-Help: <mailto:xml-sg-cmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml-sg-cmt>, <mailto:xml-sg-cmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2022 13:49:46 -0000

We need something that will make it easy for authors to provide a 
version of their xml with the includes fully expanded. I was expecting 
we would leverage the preptool for that.

RjS

On 5/7/22 3:43 AM, Julian Reschke wrote:
> Am 07.05.2022 um 04:37 schrieb John R Levine:
>> I ran an I-D through the prep tool to see what would happen.  It sort of
>> worked, but when I tried to render it, I got complaints about missing pn
>> attributes in the generated sections.  As far as I can tell, nobody has
>> noticed this before so rather than fixing it, how about if we say you
>> can't prep a draft?
>
> The preptool step is defined for both RFCs and non-RFCs (see
> https://greenbytes.de/tech/webdav/rfc7998.html#rfc-production-mode-cleanup). 
>
> If the output doesn't render with xml2rfc, we should identify the bug
> and fix it.
>
>> Bonus question: what does the <toc> section do?  It has no effect on the
>> table of contents in rendered versions.  I changed some of the section
>> names in the <toc> section on that prepped draft, and when rendered it
>> still used the real section names.
>>
>> If nothing uses it, how about if we take it out?
>
> By all means, yet (and other atrocitites that were added for similat
> reasons).
>
> Best regards, Julian
>

v2.23.0 | Report a Bug | By Email