Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Martin Björklund <mbj+ietf@4668.se> Tue, 31 March 2020 15:04 UTC

Return-Path: <mbj+ietf@4668.se>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9523A228D for <netmod@ietfa.amsl.com>; Tue, 31 Mar 2020 08:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.799
X-Spam-Level: *
X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=ExYGNXik; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MBHZp3jh
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 hM6yNkTVYKAg for <netmod@ietfa.amsl.com>; Tue, 31 Mar 2020 08:04:55 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FEA3A2288 for <netmod@ietf.org>; Tue, 31 Mar 2020 08:04:55 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 3D77FA8E; Tue, 31 Mar 2020 11:04:54 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 31 Mar 2020 11:04:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= afH7/4IXJh+MN/Vkmnm/Y6ECynNlepwnVAD46FE/h4E=; b=ExYGNXikFVWu3AKy Aym4gc6Nt7gRQ+FrRbfrDkL/TbK4LwFCVJkjkEFIazdnVdmW0A6joPsQe7wVYmoW 1yrSrI0nhlah2fW3bpe3Dbf+r0a4DAZ4ePWqYIgQwzYQdrJSOdp2ZGox/5G2z1qX ErSgbMgd/EFwqVbVRlAJKXV31qDD9par3wneQuwxwv/SP9OjPzGZu5zt1z8N1R8M bcy2+EOEzw4GBYbZBOWku3C82yHD4PduJYsbysQBP+6M0xZPrb+qJ+mPSGCyoHJe 0nvd/tPr6mEGsqCBKkg29jY9d2ygzln/iCkOYnHhBL4E9DH3dP973qC0OZJIy8m6 k4gqQw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=afH7/4IXJh+MN/Vkmnm/Y6ECynNlepwnVAD46FE/h 4E=; b=MBHZp3jhdSsl/GdrnLx7vZT+NweyDbtDJs9tXqiQYn7M0s0CZ2aekJfDo LrYACaTjavH1R/oilNpy9ooL32XCdBeJ4Ccfcw89ibQjIUQtYUXHAXPA/uTou62V TpIGHeMFu9G+40TxIoAiel9s8/tPwnyCv95C7q1DakScoBvXsdQ+17o7zUtjs0kk 0CF2XTdMZEWDdPnCYgS42aeQxyOTRbC5UI1QQ3x6uSOm338rjgDkCUdIQSwHTv8E p1v6x1j0nagtF+75KKQhcmfpOCwn+aZRt+1xalJ6EA1hBihdeJn70SiWqQMvQass yLko3LRbEZfCxuwSKyT7GhyvMY9Vg==
X-ME-Sender: <xms:FFyDXhTI-rfgVW5-xNHCN1JgnYt7pPn2i5infeQkTMGzI3sq4d1oxg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivghtfh drohhrghdprhhftgdqvgguihhtohhrrdhorhhgnecukfhppeduheekrddujeegrdegrdeg geenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsg hjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:FFyDXoZeS9PeFwFi06egQzJCF9Jjq6XqNpFghRd_jljH3_AsSRwEDA> <xmx:FFyDXhdZ0vbkIT_PqPrdk5vjRV10pTCalhkJa3FUrQ7SR3kTQCqV_g> <xmx:FFyDXi-UMMmsPvMbe6Rvh9DggezZnm0yMIXMa32d68aTmqbMrif05g> <xmx:FVyDXsoURj7NrAGD5zrjp6JrM9I0TYTzbG9V8F4ti3y9owKxCJXAUg>
Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 948B8328005E; Tue, 31 Mar 2020 11:04:51 -0400 (EDT)
Date: Tue, 31 Mar 2020 17:04:49 +0200 (CEST)
Message-Id: <20200331.170449.1892418214423395231.id@4668.se>
To: auerswal@unix-ag.uni-kl.de
Cc: cabo@tzi.org, kent@watsen.net, balazs.lengyel=40ericsson.com@dmarc.ietf.org, netmod@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <3e2333ce-d20a-60f7-3578-5199720a03d6@unix-ag.uni-kl.de>
References: <5F251832-0C47-4254-8A6E-8DEEA6CC7FBC@tzi.org> <DE6D0F27-B4DB-423E-80D7-63DA7F3D394A@tzi.org> <3e2333ce-d20a-60f7-3578-5199720a03d6@unix-ag.uni-kl.de>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/0ttMgw2pOd4gd1wlhrX7dSqRskc>
Subject: Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2020 15:04:57 -0000

Hi,

Version 1.2 of rfcstrip (https://github.com/mbj4668/rfcstrip) can
extract from the "artwork" element, and performs artwork unfolding, if
needed.

See below for some details.


Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:
> Hi all,
> 
> On 31.03.20 09:36, Carsten Bormann wrote:
> > On 2020-03-31, at 09:22, Carsten Bormann <cabo@tzi.org> wrote:
> >
> >> On 2020-03-31, at 01:47, Kent Watsen <kent@watsen.net> wrote:
> >>>
> >>> I thought someone said that `xml2rfc` was going to support a “markers”
> >>> attribute for the <sourcecode> element, but I don’t see that here yet:
> >>> https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/blob/master/draft-iab-rfc7991bis.xml#L8514.
> >>
> >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-3.1.22
> >>
> 
> Thanks for the additional info.  The proposal states:
> 
>     Proposal:  Add an attribute 'markers' for <sourcecode>, to control
>        the emission of <CODE BEGINS> and <CODE ENDS>.  If markers="true"
>        and the "name" attribute is set, the filename will also be
>        emitted, as specified in [RFC8407] for YANG modules.
> 
> Thus the `file' part of the  <CODE ...> markers seems to be optional
> there, too, unless the code in question is a YANG module.  In RFC8407
> it
> is recommended (SHOULD) to add a file name specification to the
> <CODE BEGINS> marker, so it is still kind of optional.
> 
> I try to understand if the omission of a file name for the code in
> draft-ietf-netmod-artwork-folding-12 was "wrong" or just "not great",
> and what the current practice is.  It did result in Martin's
> `rfcstrip'
> not extracting it from the text version.

Right.  Without a file name to extract to, rfcstrip doesn't extract.

> Martin's `rfcstrip' could not extract `rfcfold' from the XML version
> either,  because the XML uses `artwork' instead of `sourcecode'.

Version 1.2 of rfcstrip handles this (with option -a).

> Adjusting the code to expect the `artwork' tag confirms this.  I used
> 
>     sed -i 's,//sourcecode\[,//artwork[,' rfcstrip
> 
> to try this out.  (Note that I do not suggest to apply this change to
> Martin's `rfcstrip', but rather want to show what I did.)
> 
> > Oh, and you can find examples for markers=“true” in the published RFCs
> > rfc8650.xml
> 
> RFC 8650 "Dynamic Subscription to YANG Events and Datastores over
> RESTCONF" contains a YANG module inside a <CODE ...> section with
> file name specification on the following line in the text rendering.
> 
> Since the code of Martin's `rfcstrip' that recognizes a <CODE ...>
> section requires the keyword `file' on the same line as `<CODE
> BEGINS>',
> I take a closer look at how it handles this RFC.
>
> Martin's rfcstrip does not recognize this <CODE ...> section in the
> text rendering, because the keyword `file' is not on the same line as
> `<CODE BEGINS>'.  It still extracts the YANG module via the "type 3"
> code path for YANG modules without <CODE ...> markers from the text
> rendering.

Right.  I think the filename on a separate line was invented by the
RFC editor when the name of the file was too long.

> Martin's `rfcstrip' extracts the YANG module with the specified name
> from the XML version of the RFC.  It extracts two of the many JSON
> examples from the XML version as well.  The examples do not use
> <CODE ...> markers in the text rendering.
> 
> One of the HTML renderings displays the file name on the same line
> as the <CODE BEGINS> marker
> (https://www.rfc-editor.org/rfc/rfc8650.html#name-yang-module), the
> other shows it on the
> following line (https://tools.ietf.org/html/rfc8650), as does the
> text rendering (https://tools.ietf.org/rfc/rfc8650.txt).  The PDF
> rendering shows the file name specification on the same line as
> <CODE BEGINS> (https://tools.ietf.org/pdf/rfc8650.pdf).
> 
> As far as I understand it, the XML version of the RFC is authoritative
> and tools are supposed to work on the XML, not renderings created from
> XML.  [I am not sure about the exact RFC number where this change from
> text to XML takes effect.]
> 
> > rfc8652.xml
> > rfc8675.xml
> > rfc8676.xml
> 
> The above RFCs contain YANG modules.  They specify file names for the
> respective <CODE ...> sections.
> 
> > rfc8681.xml
> 
> RFC 8681 "Sliding Window Random Linear Code (RLC) Forward Erasure
> Correction (FEC) Schemes for FECFRAME" does not contain a YANG module.
> It contains C code.  It does not specify a file name for any of the
> two code sections.
> 
> > rfc8682.xml
> 
> RFC 8682 "TinyMT32 Pseudorandom Number Generator (PRNG)" contains C
> code
> inside a <CODE ...> section without specifying a file name.  The
> preceding text does suggest a file name.
> 
> > rfc8695.xml
> 
> RFC 8695 is another YANG module RFC giving a file name for the
> <CODE ...> section.
> 
> > rfc8696.xml
> 
> RFC 8696 "Using Pre-Shared Key (PSK) in the Cryptographic Message
> Syntax
> (CMS)" contains an ASN.1 module inside a <CODE ...> section without
> file
> name.
> 
> > rfc8748.xml
> 
> RFC 8748 "Registry Fee Extension for the Extensible Provisioning
> Protocol (EPP)" contains an XML schema inside <CODE ...> markers
> without
> giving a file name.
> 
> It seems to me that <CODE BEGINS> ... <CODE ENDS> sections without
> file
> name specification are common for both older RFCs in text format and
> newer RFCs in XML format.  Even for YANG modules it seems to be
> recommended, but not required, to specify a file name.  Thus I would
> not
> have called the <CODE ...> line of
> draft-ietf-netmod-artwork-folding-12
> "messed up," but do think that adding a file name improves it. :-)
> 
> The empty line after <CODE BEGINS> in
> I-D.ietf-netmod-artwork-folding-12
> looks like a potential problem, because the first line of a shell
> script
> on Unix-like systems needs to specify the interpreter, but Martin's
> `rfcstrip' correctly handles this by skipping leading and trailing
> empty
> lines inside the <CODE BEGINS> ... <CODE ENDS> section.
> 
> I think I do have a better understanding of the use of <CODE ...>
> markers and the possible issues. :-)

:)


/martin



> 
> Thanks,
> Erik
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod