From nobody Sun Feb  3 02:26:51 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF33130EF5 for <xml2rfc-dev@ietfa.amsl.com>; Sun,  3 Feb 2019 02:26:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 noudeeE6Lr1J for <xml2rfc-dev@ietfa.amsl.com>; Sun,  3 Feb 2019 02:26:47 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 A4F0B1277BB for <xml2rfc-dev@ietf.org>; Sun,  3 Feb 2019 02:26:46 -0800 (PST)
Received: from [192.168.178.20] ([91.61.57.163]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LkCU2-1hQxeC1Oby-00cDQl for <xml2rfc-dev@ietf.org>; Sun, 03 Feb 2019 11:26:42 +0100
To: XML Developer List <xml2rfc-dev@ietf.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <b0322182-ada3-bb15-7708-6136c273a4a9@gmx.de>
Date: Sun, 3 Feb 2019 11:26:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:2goRs3GFk2TdyItKKhjQYid0nsBz1LjT5ArMT4X/CUnln2URrpA DHVd01oCmSn43HHaOw26D3IRfIgBEAvdh5+oYsZQWMyiNguDQMP1goFz5DBYPBX0rGAl1GV QuS1sQ4nP5OwW8WsHuYSq9vmmmFx6boKryBV6dEc3lNSxUMUshclvU3DoWZZD5724MPjzcq +wiMSO+gJHwZlUpMpYShg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:MTly44M+PkE=:kLBqralLuZZiRa4ekk20CV i8zpANAARgjcISOXNeU5NmUTOdtlShZrdx2y8NB3mQHLLwH2e/PwqCZ8zBNFfDnno1oayenMe C4RDMXlbL9yxVb+4Pr+H8suI5oeQTebDcDLVR/OVlCHgfxexxgeyrPBxRycuOw+XhrhXpvwZt swGueCoGhWworjh+KP++Y6b6KRds18dIk5uHZUTYtuY/4K1x4Owfy6js+4gdrHpZDrpieTPdg itJnSXfo+ozA5kU1wqkdIComa709Io8si6vkBhu53rmmZSszPUtZhMpYgsYScDslKc5hXS9ib lRYr1HLleZFmxGvl2KBooPhXEp9dB4t7cSXqb4yx0NPp9JpyJmetINmOm3SXZEUV2e+sVv+5w AOMec+L86+f5ubtPr/aaUOkNMFcQIt1zKixpiC/CZEt8GEVAIW0yukRuZ1o7NZbKh50yfVJcG vbWy8IdGaOmZDmeBSesXDHUsuF3FQ9yjcmIOnJTNC0Eg24MYlULNcD6KLOjo3IRCm/OLouUDS wGg3yXIq1P2Y7nV7L5PP1a0Sd9zq3phNWCtlfR2BLcSFDY+Iwzmf9NYL+I5CAcspBa6DGq5Is xTEz5dzvuLgm6NPAX7o0OSK7s/5H4dZMvXt3DZRUQ0SV6d63SPAFwaKh66zB9bfM/oHfvTJgK rxSsHk7QuwxArNI3Nh1hM+liVXuJ79WupOuTWRkkrsaNgEJowN/b6klbjEWRsIz9A1o2cw3tz xerSiuXDMEmdqcFzIJXmz0Eh0/VmJy4KPd2tIRszpepJQNDZXLgb8q0olvmKBVRQWM+Jbv0jk f9gG4uTdgUhfFdI/TiPFtxywgqdqOnSqVHZd0MSb1MBQrkAGWy0l9ofNZ5RvnumlAdO0LJ0H4 sWVTCn9KWBclb5hF6/0lz6v3OeAgyt4nOMDqqiQUKmJuHyqgZcV35LgGSJX5Z+LB2Mh1yPYWk HKhOANbd8HA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/F45jA2KgOP9RVqcz0vj5gK1mI34>
Subject: [xml2rfc-dev] <referencegroup> feedback
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Feb 2019 10:26:49 -0000

<https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-07#section-4.2.20>:

>    This element is a sibling to <reference>, and <reference> is
>    described as being rendered as a <dl> with one set of <dt>, <dd>
>    child elements.

That is only true if you believe in the example instead of the prose, 
which says:

> If the parent of this element is not a <referencegroup>, this element will render as a <dt> <dd> pair with the defined term being the reference "anchor" attribute surrounded by square brackets and the definition including the correct set of bibliographic information as specified by [RFC7322].

The fact that these pairs should be contained in a single <dl> list is 
left to the reader - but may I say self-evident? After all, it is *one* 
list of references.

What *I* do not understand is why we have these special cases at all? 
Why aren't the individual referencegroup members not rendered as 
multiple <dd> element?

Another case of RFC 7992 over-specifying things causing confusion :-)

Best regards, Julian


From nobody Wed Feb  6 13:39:38 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1129B130EE0; Wed,  6 Feb 2019 13:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 a8DaTaG1cNW9; Wed,  6 Feb 2019 13:39:15 -0800 (PST)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8D0130ECD; Wed,  6 Feb 2019 13:39:15 -0800 (PST)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1grUuZ-0001Xw-Ix; Wed, 06 Feb 2019 13:39:15 -0800
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1grUuZ-0001Xw-Ix@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Wed, 06 Feb 2019 13:39:15 -0800
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/FTLUJnWbZVOd259Pj6x7kPFaWaE>
Subject: [xml2rfc-dev] New xml2rfc release: v2.18.0
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2019 21:39:17 -0000

Hi,

This is an automatic notification about a new xml2rfc release, 
v2.18.0, generated when running the mkrelease script.

Release notes:

xml2rfc (2.18.0) ietf; urgency=medium

  This release provides additional support for <referencegroup> rendering, and
  and adds validation of fetched reference files before they are used or put
  in the reference cache.  A warning for un-cited references was added to the
  preptool; this has been present for v2 renderers for a long time, but was
  absent from the v3 specification.  A number of bugs have also been fixed.
  From the commit log:

  * Fixed an issue with the v3 html renderer when given an author without 
    an address entry.  Fixes issue #390.

  * Fixed a bug in the HTML renderer's SVG reading exception code.  Added
    support for a <referencegroup> target attribute, and suppression of target
    URLs for indivudual entries within a <referencegroup>.

  * Adjusted the text rendering of reference annotations to match the html 
    rendering better.  Added support for <referencegroup> target rendering.  
    Suppressed rendering of target URLs for individual entries in a 
    referencegroup.

  * Added a preptool check for reference citations, as earlier provided by v2
    renderers.  Made the reference section numbering code more general, to
    support additional levels in the future.

  * Added an attribute 'target' to <referencegroup>, in order to be able to
    link out to for instance IETF STD and BCP documents.

  * Added ValueError to the exceptions caught on 'import weasyprint' as a 
    workaround for a problem in Python's locale.py file under 3.7.

  * Added the Python version to the version list emitted with --version 
    --verbose.

  * Added validation of included reference files before usage, to prevent
    html files fetched from dns-spoofing captive portals from being used.

 -- Henrik Levkowetz <henrik@levkowetz.com>  06 Feb 2019 13:22:38 -0800

The preferred way to install xml2rfc is by doing 'pip install xml2rfc',
and 'pip install --upgrade xml2rfc' to upgrade.  If there are system-
installed python modules which pip will not upgrade, you may have to
use 'pip install --upgrade --no-deps xml2rfc' and install dependencies
manually.

The new version is also available through SVN checkout, with
  'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.18.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Thu Feb  7 12:08:00 2019
Return-Path: <rjsparks@nostrum.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372ED130EA9 for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP0Cl5TZ4ol4 for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:07:53 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1811A130E86 for <xml2rfc-dev@ietf.org>; Thu,  7 Feb 2019 12:07:53 -0800 (PST)
Received: from unescapeable.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x17K7on8094620 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Feb 2019 14:07:51 -0600 (CST) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549570072; bh=XVnT5iFPX+bLsoIvjO2ax6V3fcFOWCrWjIgDO0VCvHo=; h=Subject:To:References:From:Date:In-Reply-To; b=IIdvU9r9EgunseUSa/LFXAU57FfmmVuIgSf1ONPk0aFTwNVohMC4NVCe70FaqjVG0 BgnDNQcnKZoZp2MHmcotnqgdg3Ht7gnHdB+dt/bmcfw5QBZY7zn8EkOUi3v1ccHXE8 gnbNeXmeZ0l3IY92HZIUxioLoyj7FiteFuWcPPPY=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be unescapeable.local
To: xml2rfc-dev@ietf.org, RFC Interest <rfc-interest@rfc-editor.org>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com>
Date: Thu, 7 Feb 2019 14:07:50 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------C6433D41D050E4CFA6C7DC36"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/EgAnwSN4G_7QQdZwUN-nO4G-P40>
Subject: [xml2rfc-dev] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 20:07:58 -0000

This is a multi-part message in MIME format.
--------------C6433D41D050E4CFA6C7DC36
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

The change proposed in this thread (to allow the preptool to incorporate 
SVG from external files as artwork rather than a data URI) seems right, 
and important.

The IESG is ready to allow v3 submissions into the repository as soon as 
the tooling is ready. The tooling is very close. As noted in the thread, 
our goal is to have the submission tool accept a standalone file (rather 
than solve how to allow submission of multiple components.)

I'm asking that this change be made to the toolchain.

RjS

On 11/20/18 7:10 AM, Andrew G. Malis wrote:
> Henrik,
>
> That makes sense, thanks!
>
> Cheers,
> Andy
>
>
> On Mon, Nov 19, 2018 at 5:56 PM Henrik Levkowetz <henrik@levkowetz.com 
> <mailto:henrik@levkowetz.com>> wrote:
>
>
>     On 2018-11-19 22:50, Jim Schaad wrote:
>     > The answer is yes. But we haven’t worked out what the mechanism is
>     > going to be yet. Another possibility is that something like the
>     > current –exp option will be added to create a single file from
>     > multiple files.
>
>     The new --prep switch does that (and also a lot of normalization).
>
>     So even if we don't add alternative upload options, running
>     xml2rfc --prep
>     on an xml file will result in a complete standalone uploadable xml
>     file.
>
>
>             Henrik
>
>
>     >
>     >
>     > Jim
>     >
>     >
>     >
>     >
>     >
>     > From: Andrew G. Malis <agmalis@gmail.com
>     <mailto:agmalis@gmail.com>>
>     > Sent: Monday, November 19, 2018 12:27 PM
>     > To: Henrik Levkowetz <henrik@levkowetz.com
>     <mailto:henrik@levkowetz.com>>
>     > Cc: ietf@augustcellars.com <mailto:ietf@augustcellars.com>;
>     xml2rfc-dev@ietf.org <mailto:xml2rfc-dev@ietf.org>
>     > Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post
>     preptool
>     >
>     >
>     >
>     > Henrik et al,
>     >
>     >
>     >
>     > Given that we're going to have multiple source files for a draft
>     or RFC (in the example in this email, there would be three files,
>     the draft/rfc xml, plus tcp-header.svg and tcp-header.txt), will
>     there be a mechanism for uploading multiple source files? Or will
>     we be zipping them first into an archive?
>     >
>     >
>     >
>     > Just curious.
>     >
>     >
>     >
>     > Thanks,
>     >
>     > Andy
>     >
>     >
>     >
>     >
>     >
>     > On Mon, Nov 19, 2018 at 1:47 PM Henrik Levkowetz
>     <henrik@levkowetz.com <mailto:henrik@levkowetz.com>
>     <mailto:henrik@levkowetz.com <mailto:henrik@levkowetz.com>> > wrote:
>     >
>     >
>     > On 2018-11-19 18:53, Jim Schaad wrote:
>     >>> -----Original Message-----
>     >>> From: Henrik Levkowetz <henrik@levkowetz.com
>     <mailto:henrik@levkowetz.com> <mailto:henrik@levkowetz.com
>     <mailto:henrik@levkowetz.com>> >
>     >>> Sent: Monday, November 19, 2018 9:32 AM
>     >>> To: Jim Schaad <ietf@augustcellars.com
>     <mailto:ietf@augustcellars.com> <mailto:ietf@augustcellars.com
>     <mailto:ietf@augustcellars.com>> >; xml2rfc-dev@ietf.org
>     <mailto:xml2rfc-dev@ietf.org> <mailto:xml2rfc-dev@ietf.org
>     <mailto:xml2rfc-dev@ietf.org>>
>     >>> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and
>     post preptool
>     >>>
>     >>> Hi Jim,
>     >>>
>     >>> On 2018-11-19 17:58, Jim Schaad wrote:
>     >>> > I have now created a document that uses SVG and has some
>     ASCII art as
>     >>> > a backup and I do not like trying to work with the output that
>     >>> > results.  I also had problems with reading RFC 7991 and
>     getting the
>     >>> > same answer as Henrik did.
>     >>> >
>     >>> > I am not a big fan of the fact that the SVG is going to be
>     encoded
>     >>> > into a data URI and placed in the file post preptool as this
>     is going
>     >>> > to be very hard to try and figure out what the changes are
>     during
>     >>> > AUTH48.  I would also think that the RPC is going to have a
>     hard time
>     >>> > doing anything except ignore the contents of the data URI during
>     >>> > editing.  I am not even sure that I think they are going to
>     be very
>     >>> > happy with having to create and replace the data URI at the
>     point in
>     >>> > time that I decide to do a small change and update the SVG
>     which is
>     >>> embedded there.
>     >>>
>     >>> That makes sense to me.
>     >>>
>     >>> > I would propose that we do the following:
>     >>> >
>     >>> > 1. Add a new element <altArtwork> which contains the same
>     attributes
>     >>> > and content as <artwork> 2.  The it is made "illegal" to
>     have both a
>     >>> > src attribute and text content at the same time on both
>     <artwork> and
>     >>> > <altArtwork>.
>     >>> > 3.  That those places in the grammar where <artwork> occurs
>     it be
>     >>> > replaced with  (artwork, altArtwork+).
>     >>> >
>     >>> > I am not sure if that is legal grammar or not.  The intent
>     is to say
>     >>> > that an altArtwork element can only directly follow from an
>     artwork
>     >>> > element (or an altArtwork element).
>     >>> >
>     >>> > This would result in:
>     >>> >
>     >>> > <figure>
>     >>> >    <name> Packet Layout Diagram</name>
>     >>> >    <artwork src="tcp-header.svg" type="svg"/>
>     >>> >    <altArtwork src="tcp-header.txt" type="ascii-art"/> </figure>
>     >>>
>     >>> I think this would make it valid to have only <altArtwork>,
>     which seems a bit
>     >>> odd -- and how would you distinguish the case where you would
>     want two
>     >>> successive <artwork> elements rendered?
>     >>
>     >> The intent of my grammar was to say that altArtwork could ONLY
>     follow
>     >> artwork. That mean that a bear altArtwork would not be legal.
>     >
>     > Aha, ok.
>     >
>     >> You could still do (artwork, altArtwork, artwork) which would
>     be two
>     >> artworks in a row with the first one having an alternate but
>     not the
>     >> second one.
>     >
>     > Understood.
>     >
>     >>>
>     >>> I wonder if it could be an alternative to instead let artwork
>     either contain text
>     >>> (the compatibility version) or a set of alternative enclosed
>     artwork elements,
>     >>> where each would need to have the type attribute set, and
>     could only hold
>     >>> content of that type.  A formatter could then pick the
>     alternative with the best
>     >>> type for its output format:
>     >>>
>     >>> <figure>
>     >>>   <name> Packet Layout Diagram</name>
>     >>>   <artwork>
>     >>>     <artwork src="tcp-header.svg" type="svg"/>
>     >>>     <artwork src="tcp-header.txt" type="ascii-art"/>
>     >>>   </artwork>
>     >>> </figure>
>     >>
>     >
>     >> I have no problems with this, but worry about the turtles all
>     the way
>     >> down case that this would allow. I had thought about
>     introducing a an
>     >> element that could hold multiple artwork but decided that the way I
>     >> outlined would be fewer changes. If the container would called
>     >> something like artGroup then I would have no problems here.
>     >
>     > Ack.  Or maybe <artgroup> to match <referencegroup>?
>     >
>     >         Henrik
>     >
>     >>>
>     >>> That would make the case of how to handle multiple successive
>     <artwork> in a
>     >>> figure or in text unambiguous, and would avoid the extra
>     <altArtwork>
>     >>> element.
>     >>
>     >> Yeah - but turtles all the way down.
>     >>
>     >> Jim
>     >>
>     >>
>     >>>
>     >>> > This would still allow for a data URI to be used in the original
>     >>> > source file, although why somebody would is unclear.  But
>     preptool
>     >>> > would move it from the src attribute to content of the
>     artwork (or altArtwork)
>     >>> element.
>     >>> > This will be both easier to edit and easier to review for
>     differences
>     >>> > during AUTH48.
>     >>>
>     >>> Ack.  I like it (but would prefer to avoid the parallel
>     <altArtwork> element
>     >>> without any enclosing (grouping) element).
>     >>>
>     >>>
>     >>>
>     >>> Best,
>     >>>
>     >>>      Henrik
>     >>
>     >>
>     >>
>     >
>     > _______________________________________________
>     > xml2rfc-dev mailing list
>     > xml2rfc-dev@ietf.org <mailto:xml2rfc-dev@ietf.org>
>     <mailto:xml2rfc-dev@ietf.org <mailto:xml2rfc-dev@ietf.org>>
>     > https://www.ietf.org/mailman/listinfo/xml2rfc-dev
>     >
>     >
>
>
> _______________________________________________
> xml2rfc-dev mailing list
> xml2rfc-dev@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev

--------------C6433D41D050E4CFA6C7DC36
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>The change proposed in this thread (to allow the preptool to
      incorporate SVG from external files as artwork rather than a data
      URI) seems right, and important.</p>
    <p>The IESG is ready to allow v3 submissions into the repository as
      soon as the tooling is ready. The tooling is very close. As noted
      in the thread, our goal is to have the submission tool accept a
      standalone file (rather than solve how to allow submission of
      multiple components.)</p>
    <p>I'm asking that this change be made to the toolchain.</p>
    <p>RjS<br>
    </p>
    <div class="moz-cite-prefix">On 11/20/18 7:10 AM, Andrew G. Malis
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Henrik,
        <div><br>
        </div>
        <div>That makes sense, thanks!</div>
        <div><br>
        </div>
        <div>Cheers,</div>
        <div>Andy</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Mon, Nov 19, 2018 at 5:56 PM Henrik Levkowetz
          &lt;<a href="mailto:henrik@levkowetz.com"
            moz-do-not-send="true">henrik@levkowetz.com</a>&gt; wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
          On 2018-11-19 22:50, Jim Schaad wrote:<br>
          &gt; The answer is yes. But we haven’t worked out what the
          mechanism is<br>
          &gt; going to be yet. Another possibility is that something
          like the<br>
          &gt; current –exp option will be added to create a single file
          from<br>
          &gt; multiple files.<br>
          <br>
          The new --prep switch does that (and also a lot of
          normalization).<br>
          <br>
          So even if we don't add alternative upload options, running
          xml2rfc --prep<br>
          on an xml file will result in a complete standalone uploadable
          xml file.<br>
          <br>
          <br>
                  Henrik<br>
          <br>
          <br>
          &gt;  <br>
          &gt; <br>
          &gt; Jim<br>
          &gt; <br>
          &gt;  <br>
          &gt; <br>
          &gt;  <br>
          &gt; <br>
          &gt; From: Andrew G. Malis &lt;<a
            href="mailto:agmalis@gmail.com" target="_blank"
            moz-do-not-send="true">agmalis@gmail.com</a>&gt; <br>
          &gt; Sent: Monday, November 19, 2018 12:27 PM<br>
          &gt; To: Henrik Levkowetz &lt;<a
            href="mailto:henrik@levkowetz.com" target="_blank"
            moz-do-not-send="true">henrik@levkowetz.com</a>&gt;<br>
          &gt; Cc: <a href="mailto:ietf@augustcellars.com"
            target="_blank" moz-do-not-send="true">ietf@augustcellars.com</a>;
          <a href="mailto:xml2rfc-dev@ietf.org" target="_blank"
            moz-do-not-send="true">xml2rfc-dev@ietf.org</a><br>
          &gt; Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary
          and post preptool<br>
          &gt; <br>
          &gt;  <br>
          &gt; <br>
          &gt; Henrik et al,<br>
          &gt; <br>
          &gt;  <br>
          &gt; <br>
          &gt; Given that we're going to have multiple source files for
          a draft or RFC (in the example in this email, there would be
          three files, the draft/rfc xml, plus tcp-header.svg and
          tcp-header.txt), will there be a mechanism for uploading
          multiple source files? Or will we be zipping them first into
          an archive?<br>
          &gt; <br>
          &gt;  <br>
          &gt; <br>
          &gt; Just curious.<br>
          &gt; <br>
          &gt;  <br>
          &gt; <br>
          &gt; Thanks,<br>
          &gt; <br>
          &gt; Andy<br>
          &gt; <br>
          &gt;  <br>
          &gt; <br>
          &gt;  <br>
          &gt; <br>
          &gt; On Mon, Nov 19, 2018 at 1:47 PM Henrik Levkowetz &lt;<a
            href="mailto:henrik@levkowetz.com" target="_blank"
            moz-do-not-send="true">henrik@levkowetz.com</a> &lt;mailto:<a
            href="mailto:henrik@levkowetz.com" target="_blank"
            moz-do-not-send="true">henrik@levkowetz.com</a>&gt; &gt;
          wrote:<br>
          &gt; <br>
          &gt; <br>
          &gt; On 2018-11-19 18:53, Jim Schaad wrote:<br>
          &gt;&gt;&gt; -----Original Message-----<br>
          &gt;&gt;&gt; From: Henrik Levkowetz &lt;<a
            href="mailto:henrik@levkowetz.com" target="_blank"
            moz-do-not-send="true">henrik@levkowetz.com</a> &lt;mailto:<a
            href="mailto:henrik@levkowetz.com" target="_blank"
            moz-do-not-send="true">henrik@levkowetz.com</a>&gt; &gt;<br>
          &gt;&gt;&gt; Sent: Monday, November 19, 2018 9:32 AM<br>
          &gt;&gt;&gt; To: Jim Schaad &lt;<a
            href="mailto:ietf@augustcellars.com" target="_blank"
            moz-do-not-send="true">ietf@augustcellars.com</a>
          &lt;mailto:<a href="mailto:ietf@augustcellars.com"
            target="_blank" moz-do-not-send="true">ietf@augustcellars.com</a>&gt;
          &gt;; <a href="mailto:xml2rfc-dev@ietf.org" target="_blank"
            moz-do-not-send="true">xml2rfc-dev@ietf.org</a> &lt;mailto:<a
            href="mailto:xml2rfc-dev@ietf.org" target="_blank"
            moz-do-not-send="true">xml2rfc-dev@ietf.org</a>&gt; <br>
          &gt;&gt;&gt; Subject: Re: [xml2rfc-dev] Alternate artwork
          vocabulary and post preptool<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; Hi Jim,<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; On 2018-11-19 17:58, Jim Schaad wrote:<br>
          &gt;&gt;&gt; &gt; I have now created a document that uses SVG
          and has some ASCII art as<br>
          &gt;&gt;&gt; &gt; a backup and I do not like trying to work
          with the output that<br>
          &gt;&gt;&gt; &gt; results.  I also had problems with reading
          RFC 7991 and getting the<br>
          &gt;&gt;&gt; &gt; same answer as Henrik did.<br>
          &gt;&gt;&gt; &gt;<br>
          &gt;&gt;&gt; &gt; I am not a big fan of the fact that the SVG
          is going to be encoded<br>
          &gt;&gt;&gt; &gt; into a data URI and placed in the file post
          preptool as this is going<br>
          &gt;&gt;&gt; &gt; to be very hard to try and figure out what
          the changes are during<br>
          &gt;&gt;&gt; &gt; AUTH48.  I would also think that the RPC is
          going to have a hard time<br>
          &gt;&gt;&gt; &gt; doing anything except ignore the contents of
          the data URI during<br>
          &gt;&gt;&gt; &gt; editing.  I am not even sure that I think
          they are going to be very<br>
          &gt;&gt;&gt; &gt; happy with having to create and replace the
          data URI at the point in<br>
          &gt;&gt;&gt; &gt; time that I decide to do a small change and
          update the SVG which is<br>
          &gt;&gt;&gt; embedded there.<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; That makes sense to me.<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; &gt; I would propose that we do the following:<br>
          &gt;&gt;&gt; &gt;<br>
          &gt;&gt;&gt; &gt; 1. Add a new element &lt;altArtwork&gt;
          which contains the same attributes<br>
          &gt;&gt;&gt; &gt; and content as &lt;artwork&gt; 2.  The it is
          made "illegal" to have both a<br>
          &gt;&gt;&gt; &gt; src attribute and text content at the same
          time on both &lt;artwork&gt; and<br>
          &gt;&gt;&gt; &gt; &lt;altArtwork&gt;.<br>
          &gt;&gt;&gt; &gt; 3.  That those places in the grammar where
          &lt;artwork&gt; occurs it be<br>
          &gt;&gt;&gt; &gt; replaced with  (artwork, altArtwork+).<br>
          &gt;&gt;&gt; &gt;<br>
          &gt;&gt;&gt; &gt; I am not sure if that is legal grammar or
          not.  The intent is to say<br>
          &gt;&gt;&gt; &gt; that an altArtwork element can only directly
          follow from an artwork<br>
          &gt;&gt;&gt; &gt; element (or an altArtwork element).<br>
          &gt;&gt;&gt; &gt;<br>
          &gt;&gt;&gt; &gt; This would result in:<br>
          &gt;&gt;&gt; &gt;<br>
          &gt;&gt;&gt; &gt; &lt;figure&gt;<br>
          &gt;&gt;&gt; &gt;    &lt;name&gt; Packet Layout
          Diagram&lt;/name&gt;<br>
          &gt;&gt;&gt; &gt;    &lt;artwork src="tcp-header.svg"
          type="svg"/&gt;<br>
          &gt;&gt;&gt; &gt;    &lt;altArtwork src="tcp-header.txt"
          type="ascii-art"/&gt; &lt;/figure&gt;<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; I think this would make it valid to have only
          &lt;altArtwork&gt;, which seems a bit<br>
          &gt;&gt;&gt; odd -- and how would you distinguish the case
          where you would want two<br>
          &gt;&gt;&gt; successive &lt;artwork&gt; elements rendered?<br>
          &gt;&gt; <br>
          &gt;&gt; The intent of my grammar was to say that altArtwork
          could ONLY follow<br>
          &gt;&gt; artwork. That mean that a bear altArtwork would not
          be legal.<br>
          &gt; <br>
          &gt; Aha, ok.<br>
          &gt; <br>
          &gt;&gt; You could still do (artwork, altArtwork, artwork)
          which would be two<br>
          &gt;&gt; artworks in a row with the first one having an
          alternate but not the<br>
          &gt;&gt; second one. <br>
          &gt; <br>
          &gt; Understood.<br>
          &gt; <br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; I wonder if it could be an alternative to instead
          let artwork either contain text<br>
          &gt;&gt;&gt; (the compatibility version) or a set of
          alternative enclosed artwork elements,<br>
          &gt;&gt;&gt; where each would need to have the type attribute
          set, and could only hold<br>
          &gt;&gt;&gt; content of that type.  A formatter could then
          pick the alternative with the best<br>
          &gt;&gt;&gt; type for its output format:<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; &lt;figure&gt;<br>
          &gt;&gt;&gt;   &lt;name&gt; Packet Layout Diagram&lt;/name&gt;<br>
          &gt;&gt;&gt;   &lt;artwork&gt;<br>
          &gt;&gt;&gt;     &lt;artwork src="tcp-header.svg"
          type="svg"/&gt;<br>
          &gt;&gt;&gt;     &lt;artwork src="tcp-header.txt"
          type="ascii-art"/&gt;<br>
          &gt;&gt;&gt;   &lt;/artwork&gt;<br>
          &gt;&gt;&gt; &lt;/figure&gt;<br>
          &gt;&gt; <br>
          &gt; <br>
          &gt;&gt; I have no problems with this, but worry about the
          turtles all the way<br>
          &gt;&gt; down case that this would allow. I had thought about
          introducing a an<br>
          &gt;&gt; element that could hold multiple artwork but decided
          that the way I<br>
          &gt;&gt; outlined would be fewer changes. If the container
          would called<br>
          &gt;&gt; something like artGroup then I would have no problems
          here.<br>
          &gt; <br>
          &gt; Ack.  Or maybe &lt;artgroup&gt; to match
          &lt;referencegroup&gt;?<br>
          &gt; <br>
          &gt;         Henrik<br>
          &gt; <br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; That would make the case of how to handle
          multiple successive &lt;artwork&gt; in a<br>
          &gt;&gt;&gt; figure or in text unambiguous, and would avoid
          the extra &lt;altArtwork&gt;<br>
          &gt;&gt;&gt; element.<br>
          &gt;&gt; <br>
          &gt;&gt; Yeah - but turtles all the way down.<br>
          &gt;&gt; <br>
          &gt;&gt; Jim<br>
          &gt;&gt; <br>
          &gt;&gt; <br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; &gt; This would still allow for a data URI to be
          used in the original<br>
          &gt;&gt;&gt; &gt; source file, although why somebody would is
          unclear.  But preptool<br>
          &gt;&gt;&gt; &gt; would move it from the src attribute to
          content of the artwork (or altArtwork)<br>
          &gt;&gt;&gt; element.<br>
          &gt;&gt;&gt; &gt; This will be both easier to edit and easier
          to review for differences<br>
          &gt;&gt;&gt; &gt; during AUTH48.<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; Ack.  I like it (but would prefer to avoid the
          parallel &lt;altArtwork&gt; element<br>
          &gt;&gt;&gt; without any enclosing (grouping) element).<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; Best,<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt;      Henrik<br>
          &gt;&gt; <br>
          &gt;&gt; <br>
          &gt;&gt; <br>
          &gt; <br>
          &gt; _______________________________________________<br>
          &gt; xml2rfc-dev mailing list<br>
          &gt; <a href="mailto:xml2rfc-dev@ietf.org" target="_blank"
            moz-do-not-send="true">xml2rfc-dev@ietf.org</a> &lt;mailto:<a
            href="mailto:xml2rfc-dev@ietf.org" target="_blank"
            moz-do-not-send="true">xml2rfc-dev@ietf.org</a>&gt; <br>
          &gt; <a
            href="https://www.ietf.org/mailman/listinfo/xml2rfc-dev"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.ietf.org/mailman/listinfo/xml2rfc-dev</a><br>
          &gt; <br>
          &gt; <br>
          <br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
xml2rfc-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:xml2rfc-dev@ietf.org">xml2rfc-dev@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/xml2rfc-dev">https://www.ietf.org/mailman/listinfo/xml2rfc-dev</a>
</pre>
    </blockquote>
  </body>
</html>

--------------C6433D41D050E4CFA6C7DC36--


From nobody Thu Feb  7 12:25:14 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543C812F1AC for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:25:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 3A4fJeIj_vv6 for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:25:11 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 1565F12426A for <xml2rfc-dev@ietf.org>; Thu,  7 Feb 2019 12:25:10 -0800 (PST)
Received: from [192.168.178.124] ([91.61.58.218]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M08ia-1h64pG05Nc-00uLIj; Thu, 07 Feb 2019 21:24:54 +0100
To: Robert Sparks <rjsparks@nostrum.com>, xml2rfc-dev@ietf.org, RFC Interest <rfc-interest@rfc-editor.org>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <dc692905-d51c-e2ea-16e9-58e3a44ac1ba@gmx.de>
Date: Thu, 7 Feb 2019 21:24:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:5ogkZ72e1e42V3guHi+ndW4rpYxlrCFf3z8UPxG6yHKeakqDljd hAxA0uT+IDhTqCKjPkqFieSKs8xHTumL5UjLt9EURy1AS6zczqQ/rAkWpq8MOgupWbEjCxq xqwGbTueVNqToJWJxkjwcoMa6TSp6KTZsFsvf+25g0gNxH7+plNdl1cv3Z5lU0smGj/VhBR F7Gw714It2rUSVbujuE6A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:jgjZoch0krs=:soPuURP156Eyd251Dv/GqE O39KyBWbhrLEnOi4c0QIuqQtTlntklTIcn69ls9deWdPJ6YLN2QOUtnPkkoi21Y4aACEckWQ3 ZTyF43uFNdekF9JSCZaUi3Zehyk2KSEj9i9OLH3Uv9SJabOQ/0hwLrVjI5APwwsfMRqLrYWeL aRSYNbiZaUt+3tZlpd2gBlwAa6kmvyKVetEhV2a4aojnPBNO2wd4anioX8kIM73EnUIRM4au9 H8aPowDyO5mf+F1MB81tZm6vOu8tmrYt+BT9jxCOHB97Z/ggW8lt/IzTiL25HGJ8agyODw4H9 wGvawfsTVJdXWK7+vAxm7lyVGTQMsoY1tk2niv/HpseZtFCHalTqmWZSRD7DDmXXSaCI1bs0H LRfDLfDUePpnSgs1sEd7h0jLMvnsJKgFp1M5F3OLMoht+faYn3Lkr7USzDY+TsSLfGGHLtMwz nOTUYQIeVtqpzeGDc1rHm6LwMGvs31PHoenLntWU6LRr6WkmT57dZeatQGL4F7/LG6mXvCxuh nK5ys313eeBHNIFZWEErUJ4KzBwba3u8hiz0RVg505FBaLrMMXtf0gRSLkqwPxsq5IbsXEMGT +NiqrLnhEHwNOsMCZN+QgNs4g2BW354U1keffEI81JpR0mtEXFDXJmA2ylYgLAsKcM3MNMms5 zExRiIAeH4vbHA6/T+AUTg9CjE89o8XF96z1jORMhO13yROUtFQhxku0oEy56Eft3LyHnUC2B 0hw3ec7x6dQlTSWcEBG5znf+6hhUvpte0gEsw3fORrWEj3uCArv0I1mUC8byH2TM6fZNmrb8o vMinoUD/wH9kbkeJNEkonG7KiRV1vLyibjzIgUQ0+cVsSnU3/LhtLJxA691rcXcy1HwmQHP/r eEhFfgNU+8GXkQMD5GbxzKPXxVVNQwlcQ64MOLpJWF0jUw0SnRwY7fD03UcHIpinmBsbOAUX9 A5Dvj9BsbGQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/kXJ2RaLWSh1w9i1jvUn8r_hokXY>
Subject: Re: [xml2rfc-dev] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 20:25:13 -0000

On 07.02.2019 21:07, Robert Sparks wrote:
> The change proposed in this thread (to allow the preptool to incorporate 
> SVG from external files as artwork rather than a data URI) seems right, 
> and important.
> 
> The IESG is ready to allow v3 submissions into the repository as soon as 
> the tooling is ready. The tooling is very close. As noted in the thread, 
> our goal is to have the submission tool accept a standalone file (rather 
> than solve how to allow submission of multiple components.)
> 
> I'm asking that this change be made to the toolchain.
> 
> RjS

Could you please clarify what you mean by "v3"?

1. The thing described in RFC 7991?

2. The thing described in draft-iab-rfc7991bis-01?

3. The vocabulary that happens to be implemented by the current version 
of xml2rfc?

Best regards, Julian


From nobody Thu Feb  7 12:33:28 2019
Return-Path: <rjsparks@nostrum.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B541293B1 for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level: 
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 TVNuSIi2bGTj for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:33:24 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0D87D12426A for <xml2rfc-dev@ietf.org>; Thu,  7 Feb 2019 12:33:24 -0800 (PST)
Received: from unescapeable.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x17KXIJH098822 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Feb 2019 14:33:19 -0600 (CST) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549571599; bh=16TPfl8UfeNqoUjfBaxoAupr+57+sw0SsDzAoI3ERF0=; h=Subject:To:References:From:Date:In-Reply-To; b=Ei5DUOhk8JmwzP/R2jRWbjD0CkAmKzbkB1YHRAEHqkco59/rmpy2MhJFPYweW0mo0 UgyDaaH6WUhQDKxvGydfPU7uULXOwm0jeOC7nwH10ZRK2ygkWLq4zFq6Afu8Y4YvBU 2ZtBCY3tQoSte6O+SWAzJcetrgQHwS1De/uvWfzI=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be unescapeable.local
To: Julian Reschke <julian.reschke@gmx.de>, xml2rfc-dev@ietf.org, RFC Interest <rfc-interest@rfc-editor.org>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <dc692905-d51c-e2ea-16e9-58e3a44ac1ba@gmx.de>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <3e0c425f-4fd4-a467-a573-1c8a6746bf1e@nostrum.com>
Date: Thu, 7 Feb 2019 14:33:17 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <dc692905-d51c-e2ea-16e9-58e3a44ac1ba@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/zuyqCM0jl3Z3sm5MdccCTATxvUs>
Subject: Re: [xml2rfc-dev] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 20:33:26 -0000

On 2/7/19 2:24 PM, Julian Reschke wrote:
> On 07.02.2019 21:07, Robert Sparks wrote:
>> The change proposed in this thread (to allow the preptool to 
>> incorporate SVG from external files as artwork rather than a data 
>> URI) seems right, and important.
>>
>> The IESG is ready to allow v3 submissions into the repository as soon 
>> as the tooling is ready. The tooling is very close. As noted in the 
>> thread, our goal is to have the submission tool accept a standalone 
>> file (rather than solve how to allow submission of multiple components.)
>>
>> I'm asking that this change be made to the toolchain.
>>
>> RjS
>
> Could you please clarify what you mean by "v3"?
>
> 1. The thing described in RFC 7991?
>
> 2. The thing described in draft-iab-rfc7991bis-01?
>
> 3. The vocabulary that happens to be implemented by the current 
> version of xml2rfc?

Practically, right now, I mean 3.

I do remember that we need to reconcile as implemented with what's in 
the bis draft, but that's not what this message is about.

>
> Best regards, Julian


From nobody Thu Feb  7 12:37:28 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5612E04D for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:37:27 -0800 (PST)
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, URIBL_BLOCKED=0.001] autolearn=ham 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 Wk5AlM0iEEl2 for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:37:24 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAB812426A for <xml2rfc-dev@ietf.org>; Thu,  7 Feb 2019 12:37:24 -0800 (PST)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:60786 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1grqQF-0007Vd-GD; Thu, 07 Feb 2019 12:37:24 -0800
To: Robert Sparks <rjsparks@nostrum.com>, xml2rfc-dev@ietf.org, RFC Interest <rfc-interest@rfc-editor.org>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com>
Date: Thu, 7 Feb 2019 21:37:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6UsUE3HQpmaNbECuRgId3maEMCraAwghn"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: rfc-interest@rfc-editor.org, xml2rfc-dev@ietf.org, rjsparks@nostrum.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/kDu_xNilX-p_K4cco0Y-XNMoIFk>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 20:37:27 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6UsUE3HQpmaNbECuRgId3maEMCraAwghn
Content-Type: multipart/mixed; boundary="0GHuNBr8lpmUUDqbkPMeG0R5hawT2nGMI";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Robert Sparks <rjsparks@nostrum.com>, xml2rfc-dev@ietf.org,
 RFC Interest <rfc-interest@rfc-editor.org>
Message-ID: <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com>
Subject: Re: [rfc-i] Preparing for allowing v3 submissions into the repository
 (was Re: [xml2rfc-dev] Alternate artwork vocabulary and post preptool)
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com>
 <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com>
 <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com>
 <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com>
 <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com>
 <02f101d48051$d5365100$7fa2f300$@augustcellars.com>
 <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com>
 <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com>
 <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com>
In-Reply-To: <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com>

--0GHuNBr8lpmUUDqbkPMeG0R5hawT2nGMI
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Robert,

On 2019-02-07 21:07, Robert Sparks wrote:
> The change proposed in this thread (to allow the preptool to incorporat=
e=20
> SVG from external files as artwork rather than a data URI) seems right,=
=20
> and important.
>=20
> The IESG is ready to allow v3 submissions into the repository as soon a=
s=20
> the tooling is ready. The tooling is very close. As noted in the thread=
,=20
> our goal is to have the submission tool accept a standalone file (rathe=
r=20
> than solve how to allow submission of multiple components.)
>=20
> I'm asking that this change be made to the toolchain.

Ok, I'll coordinate with Jim to make sure to support his original use
case, and make a tentative implementation, using the <artgroup> idea we
landed on in the original thread.  I'll provide the details of that in my=

implementation notes draft, as part of the release notes of the release
where they appear, and in a separate message to the lists this message
goes to.  We can then adjust and iterate.


	Henrik

> RjS
>=20
> On 11/20/18 7:10 AM, Andrew G. Malis wrote:
>> Henrik,
>>
>> That makes sense, thanks!
>>
>> Cheers,
>> Andy
>>
>>
>> On Mon, Nov 19, 2018 at 5:56 PM Henrik Levkowetz <henrik@levkowetz.com=
=20
>> <mailto:henrik@levkowetz.com>> wrote:
>>
>>
>>     On 2018-11-19 22:50, Jim Schaad wrote:
>>     > The answer is yes. But we haven=E2=80=99t worked out what the me=
chanism is
>>     > going to be yet. Another possibility is that something like the
>>     > current =E2=80=93exp option will be added to create a single fil=
e from
>>     > multiple files.
>>
>>     The new --prep switch does that (and also a lot of normalization).=

>>
>>     So even if we don't add alternative upload options, running
>>     xml2rfc --prep
>>     on an xml file will result in a complete standalone uploadable xml=

>>     file.
>>
>>
>>             Henrik
>>
>>
>>     >
>>     >
>>     > Jim
>>     >
>>     >
>>     >
>>     >
>>     >
>>     > From: Andrew G. Malis <agmalis@gmail.com
>>     <mailto:agmalis@gmail.com>>
>>     > Sent: Monday, November 19, 2018 12:27 PM
>>     > To: Henrik Levkowetz <henrik@levkowetz.com
>>     <mailto:henrik@levkowetz.com>>
>>     > Cc: ietf@augustcellars.com <mailto:ietf@augustcellars.com>;
>>     xml2rfc-dev@ietf.org <mailto:xml2rfc-dev@ietf.org>
>>     > Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post=

>>     preptool
>>     >
>>     >
>>     >
>>     > Henrik et al,
>>     >
>>     >
>>     >
>>     > Given that we're going to have multiple source files for a draft=

>>     or RFC (in the example in this email, there would be three files,
>>     the draft/rfc xml, plus tcp-header.svg and tcp-header.txt), will
>>     there be a mechanism for uploading multiple source files? Or will
>>     we be zipping them first into an archive?
>>     >
>>     >
>>     >
>>     > Just curious.
>>     >
>>     >
>>     >
>>     > Thanks,
>>     >
>>     > Andy
>>     >
>>     >
>>     >
>>     >
>>     >
>>     > On Mon, Nov 19, 2018 at 1:47 PM Henrik Levkowetz
>>     <henrik@levkowetz.com <mailto:henrik@levkowetz.com>
>>     <mailto:henrik@levkowetz.com <mailto:henrik@levkowetz.com>> > wrot=
e:
>>     >
>>     >
>>     > On 2018-11-19 18:53, Jim Schaad wrote:
>>     >>> -----Original Message-----
>>     >>> From: Henrik Levkowetz <henrik@levkowetz.com
>>     <mailto:henrik@levkowetz.com> <mailto:henrik@levkowetz.com
>>     <mailto:henrik@levkowetz.com>> >
>>     >>> Sent: Monday, November 19, 2018 9:32 AM
>>     >>> To: Jim Schaad <ietf@augustcellars.com
>>     <mailto:ietf@augustcellars.com> <mailto:ietf@augustcellars.com
>>     <mailto:ietf@augustcellars.com>> >; xml2rfc-dev@ietf.org
>>     <mailto:xml2rfc-dev@ietf.org> <mailto:xml2rfc-dev@ietf.org
>>     <mailto:xml2rfc-dev@ietf.org>>
>>     >>> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and
>>     post preptool
>>     >>>
>>     >>> Hi Jim,
>>     >>>
>>     >>> On 2018-11-19 17:58, Jim Schaad wrote:
>>     >>> > I have now created a document that uses SVG and has some
>>     ASCII art as
>>     >>> > a backup and I do not like trying to work with the output th=
at
>>     >>> > results.  I also had problems with reading RFC 7991 and
>>     getting the
>>     >>> > same answer as Henrik did.
>>     >>> >
>>     >>> > I am not a big fan of the fact that the SVG is going to be
>>     encoded
>>     >>> > into a data URI and placed in the file post preptool as this=

>>     is going
>>     >>> > to be very hard to try and figure out what the changes are
>>     during
>>     >>> > AUTH48.  I would also think that the RPC is going to have a
>>     hard time
>>     >>> > doing anything except ignore the contents of the data URI du=
ring
>>     >>> > editing.  I am not even sure that I think they are going to
>>     be very
>>     >>> > happy with having to create and replace the data URI at the
>>     point in
>>     >>> > time that I decide to do a small change and update the SVG
>>     which is
>>     >>> embedded there.
>>     >>>
>>     >>> That makes sense to me.
>>     >>>
>>     >>> > I would propose that we do the following:
>>     >>> >
>>     >>> > 1. Add a new element <altArtwork> which contains the same
>>     attributes
>>     >>> > and content as <artwork> 2.  The it is made "illegal" to
>>     have both a
>>     >>> > src attribute and text content at the same time on both
>>     <artwork> and
>>     >>> > <altArtwork>.
>>     >>> > 3.  That those places in the grammar where <artwork> occurs
>>     it be
>>     >>> > replaced with  (artwork, altArtwork+).
>>     >>> >
>>     >>> > I am not sure if that is legal grammar or not.  The intent
>>     is to say
>>     >>> > that an altArtwork element can only directly follow from an
>>     artwork
>>     >>> > element (or an altArtwork element).
>>     >>> >
>>     >>> > This would result in:
>>     >>> >
>>     >>> > <figure>
>>     >>> >    <name> Packet Layout Diagram</name>
>>     >>> >    <artwork src=3D"tcp-header.svg" type=3D"svg"/>
>>     >>> >    <altArtwork src=3D"tcp-header.txt" type=3D"ascii-art"/> <=
/figure>
>>     >>>
>>     >>> I think this would make it valid to have only <altArtwork>,
>>     which seems a bit
>>     >>> odd -- and how would you distinguish the case where you would
>>     want two
>>     >>> successive <artwork> elements rendered?
>>     >>
>>     >> The intent of my grammar was to say that altArtwork could ONLY
>>     follow
>>     >> artwork. That mean that a bear altArtwork would not be legal.
>>     >
>>     > Aha, ok.
>>     >
>>     >> You could still do (artwork, altArtwork, artwork) which would
>>     be two
>>     >> artworks in a row with the first one having an alternate but
>>     not the
>>     >> second one.
>>     >
>>     > Understood.
>>     >
>>     >>>
>>     >>> I wonder if it could be an alternative to instead let artwork
>>     either contain text
>>     >>> (the compatibility version) or a set of alternative enclosed
>>     artwork elements,
>>     >>> where each would need to have the type attribute set, and
>>     could only hold
>>     >>> content of that type.  A formatter could then pick the
>>     alternative with the best
>>     >>> type for its output format:
>>     >>>
>>     >>> <figure>
>>     >>>   <name> Packet Layout Diagram</name>
>>     >>>   <artwork>
>>     >>>     <artwork src=3D"tcp-header.svg" type=3D"svg"/>
>>     >>>     <artwork src=3D"tcp-header.txt" type=3D"ascii-art"/>
>>     >>>   </artwork>
>>     >>> </figure>
>>     >>
>>     >
>>     >> I have no problems with this, but worry about the turtles all
>>     the way
>>     >> down case that this would allow. I had thought about
>>     introducing a an
>>     >> element that could hold multiple artwork but decided that the w=
ay I
>>     >> outlined would be fewer changes. If the container would called
>>     >> something like artGroup then I would have no problems here.
>>     >
>>     > Ack.  Or maybe <artgroup> to match <referencegroup>?
>>     >
>>     >         Henrik
>>     >
>>     >>>
>>     >>> That would make the case of how to handle multiple successive
>>     <artwork> in a
>>     >>> figure or in text unambiguous, and would avoid the extra
>>     <altArtwork>
>>     >>> element.
>>     >>
>>     >> Yeah - but turtles all the way down.
>>     >>
>>     >> Jim
>>     >>
>>     >>
>>     >>>
>>     >>> > This would still allow for a data URI to be used in the orig=
inal
>>     >>> > source file, although why somebody would is unclear.  But
>>     preptool
>>     >>> > would move it from the src attribute to content of the
>>     artwork (or altArtwork)
>>     >>> element.
>>     >>> > This will be both easier to edit and easier to review for
>>     differences
>>     >>> > during AUTH48.
>>     >>>
>>     >>> Ack.  I like it (but would prefer to avoid the parallel
>>     <altArtwork> element
>>     >>> without any enclosing (grouping) element).
>>     >>>
>>     >>>
>>     >>>
>>     >>> Best,
>>     >>>
>>     >>>      Henrik
>>     >>
>>     >>
>>     >>
>>     >
>>     > _______________________________________________
>>     > xml2rfc-dev mailing list
>>     > xml2rfc-dev@ietf.org <mailto:xml2rfc-dev@ietf.org>
>>     <mailto:xml2rfc-dev@ietf.org <mailto:xml2rfc-dev@ietf.org>>
>>     > https://www.ietf.org/mailman/listinfo/xml2rfc-dev
>>     >
>>     >
>>
>>
>> _______________________________________________
>> xml2rfc-dev mailing list
>> xml2rfc-dev@ietf.org
>> https://www.ietf.org/mailman/listinfo/xml2rfc-dev
>=20
>=20
>=20
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>=20


--0GHuNBr8lpmUUDqbkPMeG0R5hawT2nGMI--

--6UsUE3HQpmaNbECuRgId3maEMCraAwghn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlxclvwACgkQTptXS4+7
FxpE3w/8DGOGtbn4VTRTbESNy9hJ4ZmNiWipU+HqviC5zxCnnKbr/qgQeyh5H3wD
L8IW1LhJV9xiErtP/XGQhNci6tMVyERDQD/rTuTmR+4fBxYyAcyNMepH8nK+eRfF
WaRcW1lL3KOPi+E6exKlgukw94R51UoZMHD+gbhryT3Uoe3ZguLNV2+/HaA0wPPj
cXet7GG3BAVS/bpq6Ejt81a/P6+IkrBwBqUDrHXpVf4z2Cek2k4ZfSX0U79N01Hw
ge2rf7qQlDifNqCTK90YTE3xVdlms8rQ8sK06N3Jr/6AG1UnP/DfjYdWbHVzZ6VB
B54FTmXyWPoxtjSh0ALtlXn81o63rP/ECE7judCO81WV9fYRK5/6tY7IO8yYub5r
PoOPEbciJt+leJFHWzzf7Lk5+CzYPoa2vuA4xNcIfh24I63GNQyvSghUsxn6QIp+
2Y4G7NwaAHj4begptFJham/N472hJtWcj11T1+je+xBga4F2TyGLEjvYYnkZP29j
5oGWGfXNGSrybFaD3vIPSmoWJOF4fct0JCztw6y0XCSH6yC0dM3wmFBEdGfD5AU4
GqHIyEO9T7HIPJ8ZQQ9BRNvXCGfTj9KjoyuRt68uLtUCpAvk7Zy6r1qGyMZ8efES
1vj6yeLhDaonuW9e9y39hj0NoxW34HZm59YbOTiQ4M42xPW3FsI=
=/5dp
-----END PGP SIGNATURE-----

--6UsUE3HQpmaNbECuRgId3maEMCraAwghn--


From nobody Thu Feb  7 12:38:41 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5244D130DE3 for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 B0LgMEd1HDWW for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 12:38:37 -0800 (PST)
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 3115712F1A5 for <xml2rfc-dev@ietf.org>; Thu,  7 Feb 2019 12:38:37 -0800 (PST)
Received: from [192.168.178.124] ([91.61.58.218]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M2t0Q-1h8orB27iI-00scAH; Thu, 07 Feb 2019 21:38:23 +0100
To: Robert Sparks <rjsparks@nostrum.com>, xml2rfc-dev@ietf.org, RFC Interest <rfc-interest@rfc-editor.org>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <dc692905-d51c-e2ea-16e9-58e3a44ac1ba@gmx.de> <3e0c425f-4fd4-a467-a573-1c8a6746bf1e@nostrum.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <2d703b7c-97cd-6fa3-3d87-11ad5f36d0c8@gmx.de>
Date: Thu, 7 Feb 2019 21:38:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <3e0c425f-4fd4-a467-a573-1c8a6746bf1e@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:QOK9e/8flW5TsPmcs6GHgJDjacTVdJf8LiF5/iB+Nr/yk3/SGdv Sz21nXsNuM4ZNgTG9t1qyhvUzuSB6MZaWVVp+loxUtX6DjcLKOL6JVhJMhJVECKFUh5lMR4 dy2s4KU+/MZJ4ZGqC0s0nwXye4NclZKC4CQ5EEncn/wl24U+FILpp8N1lEFMUwF/BScHWCg XPM3IMpkOVslHKEhpE1EA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:rVptUdP5vQo=:flJMxOwin2xywVZllocg8a nm2QJYVM7izctmKfezPTgsE7vxSdLcBKoqaUwPNwD1O/xPPE0/LFKpUrc22wTEUeUkvMlUDBP bmTo3LLqgRB+gYyWG/aMDSYy6LzuCGDWSylfQX5YBzgTflYrq1sXYtGS0hobHERQovWxw1/2F LkYUCnQqJfcLPz2AFjg8MB5CRZgA6YdkBjWv/+U6VfdNkUwyvr6kC5wfW0AJ2kxqjtGgaZbfu 5bVbrdCvSKZ8ivrzG//nZoiSNoRwytr/q+DvTlz94/k+DPmPpybSzChzr3FGWvK+zKcXCSzXE nWfFbK9cM+Jzv6b8c42uho0oSkm26Xz1HOkyJNf0wIknPBO5b+cyvzxxQb7o14zQRyHMe+GnW znOKsrruxLqIXFTVOAOlt5zCnM7uFYU2UMb4KmAkfjN8CNZ+dy4UVhVIr/KuV9dp2LU2741PJ mfHM4vfpRkDkR5grIN/gbr5ivWFr3WY1o2MQgC8yYK1fuDGEb4KrQA6M6Vo2He/LhSIZz+VoF oY4aUOUWRFOQGMgS5Yr2ql3m0trmqvP5NWSiciiIPzzpsOXqyPmbEtrAGY/StZP+gfyr2b2gs 5LAnMGfb5PzNckNx2WzXEHmHo55E5T58ZHqP34R8ma122uJrqRNsHp4Sv6mZvCKeUroJMR9xa xtZ0c2inLo1klStDjw/C77nXVVwjOp5SHWief4XgwnkIJ8N2ioY3DxFNHClyoUGZgDNsIA39E XI8CkwoECeeOviDCNlEUiCVh2QBtDPr1w0b0sa7VlsDM5bzrxLia/qrRS9AqvfBhmLuKrpTSw 4pb1D5UQrWkm7AC8nOvznJ5zFXj+Lp4+z58Dk0Mgytopt/Kfs4fQihTJ6pzTIetXwRjatNKnY 1KO4zw9+vsqZWZZTqSscW7XLnFPrxRM147928bQn7+UZq2KhD5o6wkYXS+JqfPLIObA8A1VTQ 5Mr75qRkqdA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/58BNjcAzua-kTMlJ-qOauRPiUdw>
Subject: Re: [xml2rfc-dev] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 20:38:39 -0000

On 07.02.2019 21:33, Robert Sparks wrote:
> 
> On 2/7/19 2:24 PM, Julian Reschke wrote:
>> On 07.02.2019 21:07, Robert Sparks wrote:
>>> The change proposed in this thread (to allow the preptool to 
>>> incorporate SVG from external files as artwork rather than a data 
>>> URI) seems right, and important.
>>>
>>> The IESG is ready to allow v3 submissions into the repository as soon 
>>> as the tooling is ready. The tooling is very close. As noted in the 
>>> thread, our goal is to have the submission tool accept a standalone 
>>> file (rather than solve how to allow submission of multiple components.)
>>>
>>> I'm asking that this change be made to the toolchain.
>>>
>>> RjS
>>
>> Could you please clarify what you mean by "v3"?
>>
>> 1. The thing described in RFC 7991?
>>
>> 2. The thing described in draft-iab-rfc7991bis-01?
>>
>> 3. The vocabulary that happens to be implemented by the current 
>> version of xml2rfc?
> 
> Practically, right now, I mean 3.
> 
> I do remember that we need to reconcile as implemented with what's in 
> the bis draft, but that's not what this message is about.
> ...

a) It would be good to know that the actual plan to reconcile things is.

b) As far as I understand, until we have an answer to a), "v3" is a 
moving (and not completely documented) target. As such, accepting 
submissions seems to be premature, unless there's a clarification about 
what it would mean for a submitted document becoming broken after a 
future change in "v3".

Best regards, Julian


From nobody Thu Feb  7 12:56:38 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560DF129C6A; Thu,  7 Feb 2019 12:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Vqc4E9-Uz5K3; Thu,  7 Feb 2019 12:56:27 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 9D044129A85; Thu,  7 Feb 2019 12:56:26 -0800 (PST)
Received: from [192.168.178.124] ([91.61.58.218]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M243n-1h7zcl3ggF-00u4KC; Thu, 07 Feb 2019 21:56:04 +0100
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
References: <E1grUuZ-0001Xw-Ix@durif.tools.ietf.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <e7b09ee3-511f-5db1-6273-0c6a40317752@gmx.de>
Date: Thu, 7 Feb 2019 21:56:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <E1grUuZ-0001Xw-Ix@durif.tools.ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:04puHcZ9henYAzgfEYewROd5KztJEd+Z3E72mHTs9DkZ2qcZ7Pj 5WqtMtjDgR90QqCNTXPyYn8TQlPNxC+ZQUCKF2hRbY+7AsEhyLNppWqwAZS5bFsk6us5aCe swGRzApZp+mPIEhBbZlHgd3Txuhrc8pzqLnefW20u7WSm/x71hYaEXk5rVS173O9ACtDhWP RdMczr9GQElxJ4unPityA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:XDUZKd9dv+k=:6NcXpkcq9BrsGvzWWxLaU+ zaaozD4KdKftVuWTwTqNZjTEKG+h+GyLFFos9MZTJuYpmPWWAKM6ubIzcz3eBovnGTxEL0L5g APoCjz6gcfwhPxb0JnGXeutScxk+0EMaAPAKIJainX2QCS0b0TmnSYDJqVrF+OBQIqWFxKKX1 w/Xx/7/QFBKI0ywpNnxELIq3mqBsjNgUetFQ98jKGAl03C08P6BXXlG03v4IRfqhwtmapZHjM zmZE8D9bK22r4X6TfYMHvF51mc51MIuP6HJMWI4I8h5SijZHHhCeF6hCv76B1p8rakNkvTYpo frfCYNNabvR1KwQPI2K74940KK/Q6CKUGG2KsnYWyVP9kgr3Ie+BEQ1Fya9t0iS8oYmqlioNL 0IByiAS/IoF/dupL6UySFoWEMEBx1E8v2gv9mgjJWn0a28i8vz2VaH+o5cjYftT+ndlChxWK1 ZkUU2rQ/7FCr4wlSp9Ad/3FYh6LPq9nrOhc+zUwF67HdgRGqXxNVdsMXqlqwlYS3M6hO0t1hE DSEI1w3/Rz09mhetAh/5IK4h+QMTh4sjges0P89Upne03ACE4lHsVu8pIve35f4FVfO47vYaG m21RD132ywb1dLgV+ToL13BICFUzhdZHk2n5lH/vEjAODfuqGytEn09BcoQXqfudQDKqN53Pd sy4naIaCKXCa11DYiBNXbqCKOfZ56xQBOYgfdlvAGBC89mx0vKs3Ecj2SbCHqrEwLhGp5D6qf xSVgGCrvkQHh18Ixy7c4G6BJAhGnGvIghOuLyYxPwdO7uuIc0E0lAckw2ju0raWlPGaqrZiea vpqK3ljgaBPQvERp9m9aGekV9VRjrIRu42jW1/WF2BJWadDr9+scZumiMMrxYkVPCPtW3246K OnAFs/mZpMnlMuZIPZSSwKKzEcgMVKN1nHwkXmF9UBCj1ua9nEm7dxo1hJHF1yrnsTXmyJNde tLLo8Uf0DBw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/C4wZzsYQNJc2W4WB489_dCWh2mM>
Subject: [xml2rfc-dev] <referencegroup>, was:  New xml2rfc release: v2.18.0
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 20:56:29 -0000

On 06.02.2019 22:39, Henrik Levkowetz wrote:
> ...
>    * Adjusted the text rendering of reference annotations to match the html
>      rendering better.  Added support for <referencegroup> target rendering.
>      Suppressed rendering of target URLs for individual entries in a
>      referencegroup.
> ...

With that, I'm getting output such as:

>    [STD69]    Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
>               STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009.
> 
>               Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>               Domain Name Mapping", STD 69, RFC 5731,
>               DOI 10.17487/RFC5731, August 2009.
> 
>               Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>               Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
>               August 2009.
> 
>               Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>               Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
>               August 2009.
> 
>               Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>               Transport over TCP", STD 69, RFC 5734,
>               DOI 10.17487/RFC5734, August 2009.

So the links to the RFCs are gone.

This matches slightly more what RFC 7322 says in 
<https://tools.ietf.org/html/rfc7322#section-4.8.6.3>:

>       [STDXXX]  Last name, First initial., Ed. (if applicable),
>                 "RFC Title", Sub-series number, RFC number, Date of
>                 publication.
> 
>                 Last name, First initial., Ed. (if applicable)
>                 and First initial. Last name, Ed. (if applicable),
>                 "RFC Title", Sub-series number, RFC number, Date of
>                 publication.
> 
>                 <http://www.rfc-editor.org/info/std#>

...but it still misses the link to the "aggregate" page.

Now doing this properly (without weird heuristics) requires a vocabulary 
change (see 
<https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/10>, 
raised over two years ago).

If we are in a hurry, and it seems we are, I would suggest to drop 
<referencegroup> for now instead of doing something that is known to be 
broken. And yes, I'm saying this after spending several hours over the 
previous weekend to get <referencegroup> support into rfc2629.xslt.

Best regards, Julian







From nobody Thu Feb  7 13:06:04 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27B1129A85; Thu,  7 Feb 2019 13:06:02 -0800 (PST)
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, URIBL_BLOCKED=0.001] autolearn=ham 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 qo8Vik7wWucM; Thu,  7 Feb 2019 13:06:01 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127CE129284; Thu,  7 Feb 2019 13:06:01 -0800 (PST)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:61070 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1grqrv-0002OU-K2; Thu, 07 Feb 2019 13:06:00 -0800
To: Julian Reschke <julian.reschke@gmx.de>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
References: <E1grUuZ-0001Xw-Ix@durif.tools.ietf.org> <e7b09ee3-511f-5db1-6273-0c6a40317752@gmx.de>
Cc: rfc-markdown@ietf.org
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <25423be3-515b-87ea-dce0-7aac1f3db976@levkowetz.com>
Date: Thu, 7 Feb 2019 22:05:51 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <e7b09ee3-511f-5db1-6273-0c6a40317752@gmx.de>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="irrd2cNKbq7xKkO8k57Ql0sCIgTsdD8D2"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org, julian.reschke@gmx.de
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/dLVVQxPNxA0pExwNG38qkSOexl4>
Subject: Re: [xml2rfc-dev] <referencegroup>, was:  New xml2rfc release: v2.18.0
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 21:06:03 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--irrd2cNKbq7xKkO8k57Ql0sCIgTsdD8D2
Content-Type: multipart/mixed; boundary="DpaXlHDmjqe57xRS3K1e2iAUStqEgAUtd";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Julian Reschke <julian.reschke@gmx.de>, xml2rfc-dev@ietf.org,
 xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-ID: <25423be3-515b-87ea-dce0-7aac1f3db976@levkowetz.com>
Subject: Re: <referencegroup>, was: [xml2rfc-dev] New xml2rfc release: v2.18.0
References: <E1grUuZ-0001Xw-Ix@durif.tools.ietf.org>
 <e7b09ee3-511f-5db1-6273-0c6a40317752@gmx.de>
In-Reply-To: <e7b09ee3-511f-5db1-6273-0c6a40317752@gmx.de>

--DpaXlHDmjqe57xRS3K1e2iAUStqEgAUtd
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On 2019-02-07 21:56, Julian Reschke wrote:
> On 06.02.2019 22:39, Henrik Levkowetz wrote:
>> ...
>>    * Adjusted the text rendering of reference annotations to match the=
 html
>>      rendering better.  Added support for <referencegroup> target rend=
ering.
>>      Suppressed rendering of target URLs for individual entries in a
>>      referencegroup.
>> ...
>=20
> With that, I'm getting output such as:
>=20
>>    [STD69]    Hollenbeck, S., "Extensible Provisioning Protocol (EPP)"=
,
>>               STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009.
>>=20
>>               Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>>               Domain Name Mapping", STD 69, RFC 5731,
>>               DOI 10.17487/RFC5731, August 2009.
>>=20
>>               Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>>               Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
>>               August 2009.
>>=20
>>               Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>>               Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733=
,
>>               August 2009.
>>=20
>>               Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>>               Transport over TCP", STD 69, RFC 5734,
>>               DOI 10.17487/RFC5734, August 2009.
>=20
> So the links to the RFCs are gone.
>=20
> This matches slightly more what RFC 7322 says in=20
> <https://tools.ietf.org/html/rfc7322#section-4.8.6.3>:
>=20
>>       [STDXXX]  Last name, First initial., Ed. (if applicable),
>>                 "RFC Title", Sub-series number, RFC number, Date of
>>                 publication.
>>=20
>>                 Last name, First initial., Ed. (if applicable)
>>                 and First initial. Last name, Ed. (if applicable),
>>                 "RFC Title", Sub-series number, RFC number, Date of
>>                 publication.
>>=20
>>                 <http://www.rfc-editor.org/info/std#>
>=20
> ...but it still misses the link to the "aggregate" page.

Did you provide a target attribute in <referencegroup> in order to give i=
t
an aggregate link to render?


	Henrik

> Now doing this properly (without weird heuristics) requires a vocabular=
y=20
> change (see=20
> <https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/10>,=20
> raised over two years ago).
>=20
> If we are in a hurry, and it seems we are, I would suggest to drop=20
> <referencegroup> for now instead of doing something that is known to be=
=20
> broken. And yes, I'm saying this after spending several hours over the =

> previous weekend to get <referencegroup> support into rfc2629.xslt.
>=20
> Best regards, Julian
>=20
>=20
>=20
>=20
>=20
>=20
>=20


--DpaXlHDmjqe57xRS3K1e2iAUStqEgAUtd--

--irrd2cNKbq7xKkO8k57Ql0sCIgTsdD8D2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlxcna8ACgkQTptXS4+7
FxoJdhAAoSLNHCdVIrCT0e9Qo7o0AX0h49da7Syx1VV4p8e5mvlHFWWwP+0p2AY2
gW0tTRoqqV62k6cQXku/LHQ0kMapVUoJy6Nl20OEdMbe4x0h+P0NdLM/YHHHXv0E
ve2ZZxBM+ASzPxCG2whloZkwle57ibNOAuczeFnQZY2zKlorpXZ7TfDcVSHnZvoV
vGEy4NBEK/6EXFGAaysbRO66TZU2um4/hv3OHzYZ0aDQdmUpMPopcPgmq0+wSpN5
WJmu0hnMGebnC0HHcZXdNSmHWp1BLqOtpAyrXzgoc2aylqiWp6AyIhtMRBv0LFBv
4QeujcuHtxJi7YMEsXz7O0C+7M8tDp0l2ad8mVniHy7slm3D/ls4x9pPQ7uu6JSN
F/Nnp79uP3TgKhxVQN5Vv6uxjn0hQ6t9T5NlCOk/vhJ1MFvYYwFZWzSMU9HBIQJO
CI3LNpHGM/S6EQNNz2+AvuNkR48Os4gOJ0+Kp2YgBxUVKv0zS1wIQis+n+MLMBKg
Bb4vx1VkpZD25777kDf5c/Od2+cM0J0PgAQj9RARWWjPxxxlgXiXPJT8rHbeJCKq
vo9aCHTS9SrjGV6YbJE5xwsEenxnZhEypn8O4SjQnVpvnnVHfUFCt5EFQktYftjl
hyCyjKNBlTQePq7e7pk0MeQgGpFNPmaP1xrtxPUQ0g70daslE1o=
=dWoL
-----END PGP SIGNATURE-----

--irrd2cNKbq7xKkO8k57Ql0sCIgTsdD8D2--


From nobody Thu Feb  7 13:11:41 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10402129A85; Thu,  7 Feb 2019 13:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 SJppACpe-2tC; Thu,  7 Feb 2019 13:11:29 -0800 (PST)
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 D36F5129284; Thu,  7 Feb 2019 13:11:28 -0800 (PST)
Received: from [192.168.178.124] ([91.61.58.218]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LgqQQ-1hUlza19RG-00oDLH; Thu, 07 Feb 2019 22:11:12 +0100
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
References: <E1grUuZ-0001Xw-Ix@durif.tools.ietf.org> <e7b09ee3-511f-5db1-6273-0c6a40317752@gmx.de> <25423be3-515b-87ea-dce0-7aac1f3db976@levkowetz.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <26ead582-fcbe-7748-86b4-f1d6e3f401f6@gmx.de>
Date: Thu, 7 Feb 2019 22:11:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <25423be3-515b-87ea-dce0-7aac1f3db976@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:LKDxCzj1ZqHFSYoMDOdolMIqQrRJgvL2SMLo06nYSpKQG5QR23y jlPpu5ess26OGfWPm0VfQiiP6FiY/4i/NrbuhFThgf2yqfk34V3MIcHFyDX/8rUWeMrkqYJ +sOsSPDve+N3FLrQTYfmZllFDnBGsgagJ8T6Glaz70c5jJ+5grJxvPSR7iGreys9wyoEMQx d2rZtLqZ+0nccDC91Aemw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:HHWU/OaH17Q=:oH4KqVn4gqEHyAQmmd4jqS dInpJGvb0AIhplPCO1SMtJ8TNfMSHzchGayU8wZ7eBc8lyLOkSmNQaUFm2BU6wzgwZ7SrInU7 Sf94iZYyI8Ch9SCEh3+HDgOR6EoEEhJ4k6SsVvrhn7IpNXeer/+8ZjsjZxU7R2yxfLeOrZh1A tXm7ogROOaLNpYgsGlTUyjDoPpqf9SADubypNRMMwB+CEAHV7+HrdXNybELErt17Bn0aW0UcG X0rPx/6mUHEWckT3i1HGv9Fybs0yHxcm/n7qfJBA1LJYscnKiykIsllBDsvA7Yif0ePYirqsy opzETnhlL/rjH2As0s2N+lH+PFQRtlQ2sxkWw7Z22JRfDK0lHI57jZKBjKR18YZf4Xt9hVXLq EqqUGoRgLWIdigX6bzEdEFxSrW99ZQxnPnXI0WQzYQwfFDBEV5K+bjBAPxNEc9xbAtEP8Fzw0 oHwLMFb4UEhaDClgUB1qbJKufMskrKWKTg7hlftzBtwg77Z4/kBmU4JSXKIeYebt3/RdSgzZD Zq1c5BgxrIGVOOMoaxvkuJq9Nv0ZqoVSKdf/y5b/qQf1UecU26PSUGPzxhQKFBGVmM6dyWAsy LMUUZ8L0VMlmdjLQbF3KSlZKR6GSkX0xVm8ewi7zsJUEfVV7lJARbpuyO8tPEsUNSAQU/1j3B MaNZXPBd/Nznu37UtAIlUEwwbBx8QCWBDIUtxussdmBcVT+ucr7D/k/Rkv6y0EfEqUhu/JsP4 UBcByapjTmxiW+/RFZMmztTJMpdFS7YOVGtD8ELbIyOl5ETxpax0a031Dfgf/z1xKWW2k8jUu UjJCkuBpcoI6g/qBIv9DgJhNH/Eh/V6taXPpFfHk5f8X5m0177+KoyFaWdYyNSDPO/DPqnhVZ DIEG9nicZ0DVRacIylua7xqIwk0hqEboTkmXThfwwBfD7sVZYR1RRyelLfde/7HEWwR29YK/+ 7uk3ZPUncxQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/qlEOWFujMIK4FPnLtEXwu5mdCSc>
Subject: Re: [xml2rfc-dev] [Rfc-markdown] <referencegroup>, was:  New xml2rfc release: v2.18.0
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 21:11:31 -0000

On 07.02.2019 22:05, Henrik Levkowetz wrote:
> 
> On 2019-02-07 21:56, Julian Reschke wrote:
>> On 06.02.2019 22:39, Henrik Levkowetz wrote:
>>> ...
>>>     * Adjusted the text rendering of reference annotations to match the html
>>>       rendering better.  Added support for <referencegroup> target rendering.
>>>       Suppressed rendering of target URLs for individual entries in a
>>>       referencegroup.
>>> ...
>>
>> With that, I'm getting output such as:
>>
>>>     [STD69]    Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
>>>                STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009.
>>>
>>>                Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>>>                Domain Name Mapping", STD 69, RFC 5731,
>>>                DOI 10.17487/RFC5731, August 2009.
>>>
>>>                Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>>>                Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
>>>                August 2009.
>>>
>>>                Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>>>                Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
>>>                August 2009.
>>>
>>>                Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
>>>                Transport over TCP", STD 69, RFC 5734,
>>>                DOI 10.17487/RFC5734, August 2009.
>>
>> So the links to the RFCs are gone.
>>
>> This matches slightly more what RFC 7322 says in
>> <https://tools.ietf.org/html/rfc7322#section-4.8.6.3>:
>>
>>>        [STDXXX]  Last name, First initial., Ed. (if applicable),
>>>                  "RFC Title", Sub-series number, RFC number, Date of
>>>                  publication.
>>>
>>>                  Last name, First initial., Ed. (if applicable)
>>>                  and First initial. Last name, Ed. (if applicable),
>>>                  "RFC Title", Sub-series number, RFC number, Date of
>>>                  publication.
>>>
>>>                  <http://www.rfc-editor.org/info/std#>
>>
>> ...but it still misses the link to the "aggregate" page.
> 
> Did you provide a target attribute in <referencegroup> in order to give it
> an aggregate link to render?
> ...

In fact I did not. Thanks for the explanation.

FWIW, xml2rfc (--v3 --text) renders that as "URL: <...>" - why the 
"URL:" prefix?

Best regards, Julian


From nobody Thu Feb  7 13:35:33 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38122129C6A; Thu,  7 Feb 2019 13:35:26 -0800 (PST)
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, URIBL_BLOCKED=0.001] autolearn=ham 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 uqKs5tbIvsMt; Thu,  7 Feb 2019 13:35:23 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7E4129A87; Thu,  7 Feb 2019 13:35:23 -0800 (PST)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:61313 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1grrKM-00068y-1j; Thu, 07 Feb 2019 13:35:22 -0800
To: Julian Reschke <julian.reschke@gmx.de>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
References: <E1grUuZ-0001Xw-Ix@durif.tools.ietf.org> <e7b09ee3-511f-5db1-6273-0c6a40317752@gmx.de> <25423be3-515b-87ea-dce0-7aac1f3db976@levkowetz.com> <26ead582-fcbe-7748-86b4-f1d6e3f401f6@gmx.de>
Cc: rfc-markdown@ietf.org
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <c92e498c-6a20-ca03-c20f-dab62a11ec1d@levkowetz.com>
Date: Thu, 7 Feb 2019 22:35:14 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <26ead582-fcbe-7748-86b4-f1d6e3f401f6@gmx.de>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uUm53r2MivEgPQaD3kbbSswQ3n4FMeLS4"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org, julian.reschke@gmx.de
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/O87Y9HjnHt430YAMxlUsUZfy-qY>
Subject: Re: [xml2rfc-dev] [Rfc-markdown] <referencegroup>, was:  New xml2rfc release: v2.18.0
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 21:35:26 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--uUm53r2MivEgPQaD3kbbSswQ3n4FMeLS4
Content-Type: multipart/mixed; boundary="gWQivDihfH7C3HwH7oGHHM3ljGQi78E2i";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Julian Reschke <julian.reschke@gmx.de>, xml2rfc-dev@ietf.org,
 xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-ID: <c92e498c-6a20-ca03-c20f-dab62a11ec1d@levkowetz.com>
Subject: Re: [Rfc-markdown] <referencegroup>, was: [xml2rfc-dev] New xml2rfc
 release: v2.18.0
References: <E1grUuZ-0001Xw-Ix@durif.tools.ietf.org>
 <e7b09ee3-511f-5db1-6273-0c6a40317752@gmx.de>
 <25423be3-515b-87ea-dce0-7aac1f3db976@levkowetz.com>
 <26ead582-fcbe-7748-86b4-f1d6e3f401f6@gmx.de>
In-Reply-To: <26ead582-fcbe-7748-86b4-f1d6e3f401f6@gmx.de>

--gWQivDihfH7C3HwH7oGHHM3ljGQi78E2i
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 2019-02-07 22:11, Julian Reschke wrote:
> On 07.02.2019 22:05, Henrik Levkowetz wrote:
>>=20
>> On 2019-02-07 21:56, Julian Reschke wrote:
>>> On 06.02.2019 22:39, Henrik Levkowetz wrote:
>>>> ...
>>>>     * Adjusted the text rendering of reference annotations to match =
the html
>>>>       rendering better.  Added support for <referencegroup> target r=
endering.
>>>>       Suppressed rendering of target URLs for individual entries in =
a
>>>>       referencegroup.
>>>> ...
>>>
>>> With that, I'm getting output such as:
>>>
>>>>     [STD69]    Hollenbeck, S., "Extensible Provisioning Protocol (EP=
P)",
>>>>                STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009.
>>>>
>>>>                Hollenbeck, S., "Extensible Provisioning Protocol (EP=
P)
>>>>                Domain Name Mapping", STD 69, RFC 5731,
>>>>                DOI 10.17487/RFC5731, August 2009.
>>>>
>>>>                Hollenbeck, S., "Extensible Provisioning Protocol (EP=
P)
>>>>                Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732=
,
>>>>                August 2009.
>>>>
>>>>                Hollenbeck, S., "Extensible Provisioning Protocol (EP=
P)
>>>>                Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5=
733,
>>>>                August 2009.
>>>>
>>>>                Hollenbeck, S., "Extensible Provisioning Protocol (EP=
P)
>>>>                Transport over TCP", STD 69, RFC 5734,
>>>>                DOI 10.17487/RFC5734, August 2009.
>>>
>>> So the links to the RFCs are gone.
>>>
>>> This matches slightly more what RFC 7322 says in
>>> <https://tools.ietf.org/html/rfc7322#section-4.8.6.3>:
>>>
>>>>        [STDXXX]  Last name, First initial., Ed. (if applicable),
>>>>                  "RFC Title", Sub-series number, RFC number, Date of=

>>>>                  publication.
>>>>
>>>>                  Last name, First initial., Ed. (if applicable)
>>>>                  and First initial. Last name, Ed. (if applicable),
>>>>                  "RFC Title", Sub-series number, RFC number, Date of=

>>>>                  publication.
>>>>
>>>>                  <http://www.rfc-editor.org/info/std#>
>>>
>>> ...but it still misses the link to the "aggregate" page.
>>=20
>> Did you provide a target attribute in <referencegroup> in order to giv=
e it
>> an aggregate link to render?
>> ...
>=20
> In fact I did not. Thanks for the explanation.
>=20
> FWIW, xml2rfc (--v3 --text) renders that as "URL: <...>" - why the=20
> "URL:" prefix?

A tentative implementation.  I tried it both with and without, and in the=

<referencegroup> case it seemed to read better with.  I'm happy to adjust=

based on feedback and consensus.


	Henrik


--gWQivDihfH7C3HwH7oGHHM3ljGQi78E2i--

--uUm53r2MivEgPQaD3kbbSswQ3n4FMeLS4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlxcpJIACgkQTptXS4+7
Fxo6RRAArE0okkjVBnwSe6PAJrYQ+fB8NsN2veTab9n8Jg7YWFgiaCqBgvzH7LhJ
y6CcosGJwoOgm90OtodoxmzIVug+wHQ7qnxdZKOyqXpJ3H85dwTatqtoypLTRhEE
tF/S+aErBywaZ9jSDL8L5rd7vBoxIhY9Sx9iL1eAiYsqcdGu6qoAegMQBf1AhK1G
Et3jkQztKDMzCdCj8TJmVosZyLJ1Pof5HaaXZhvYiYAYC0K8+1rjahb4wXYu81v8
quZdjelH/XYdL8Df3yBk4GfKmXKh0qaJI7wb3BOg+XRnJNw9R/aZMunEQZPBA9qq
oj8ro3FJprANGtxy0Ja67npPNONL94tVGX1/1VmaicX0tBFl+79j8q4RY4bwdOSe
bHvqXffWPICmaXgrcGV26Xoj4gdwPYn6r2/EJQQ3OZAYx39ZtIALVk0Cqslk0xu3
HnJh3pGGJKWsuRFNgaaYVrYXnSDW7YZxlGw50PFU+gDxeF7Jx27VJr4r1Wk39hhm
WcZ+s7USfIMEutv/FThSJSMJ93JgxJUjyFpQQxcwVWiuYj1NY+540HUaKu8x3MKe
0nWPZK0uRrsREZcfQWlB7xYYlo9NDzQDtPZufqKDffbnz7ft1l2DUT88pC+j/cFn
el4zqnzcaDGvZ5x6/DBFqMN8sYWSy12zbld85Eea92mD2giSFA8=
=on4l
-----END PGP SIGNATURE-----

--uUm53r2MivEgPQaD3kbbSswQ3n4FMeLS4--


From nobody Thu Feb  7 16:00:25 2019
Return-Path: <pusateri@bangj.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D87130F01 for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 16:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 KDwCJJXc6L1v for <xml2rfc-dev@ietfa.amsl.com>; Thu,  7 Feb 2019 16:00:21 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7DE0130ED0 for <xml2rfc-dev@ietf.org>; Thu,  7 Feb 2019 16:00:21 -0800 (PST)
Received: from butte.mountain2sea.com (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 518AD262E6 for <xml2rfc-dev@ietf.org>; Thu,  7 Feb 2019 19:00:20 -0500 (EST)
From: Tom Pusateri <pusateri@bangj.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <EB75B4B7-2512-46ED-986E-B3F57700E858@bangj.com>
Date: Thu, 7 Feb 2019 19:00:19 -0500
To: xml2rfc-dev@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/kXmjT5SZbZQWR8i8PyTeqeNjfZ4>
Subject: [xml2rfc-dev] v3 HTML experimental output
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Feb 2019 00:00:24 -0000

I know this is totally a preference and in no way a bug but I wanted to =
give an opinion on the v3 html output when using a v3 xml file with =
xml2rfc (v2.18.0).

Note: I did use v2tov3 conversion after running kramdown-rfc2629 so the =
intermediate xml file may need some hand adjustments still that I =
haven=E2=80=99t figured out.

Likes:

The general layout is nice.
The default fonts are a good choice.
The default font sizes seem appropriate.

Suggestions:

1. It would be nice if links to other RFCs would just go directly to the =
RFC instead of the reference section. This multi-step process doesn=E2=80=99=
t seem to serve any purpose.

2. Links directly to sections of other RFCs don=E2=80=99t seem to happen =
automatically in the v2tov3 conversion. That is ok but would be a nice =
feature. I know it=E2=80=99s only based on heuristics and can=E2=80=99t =
be done in all cases but if it can, it should be.

3. The Table of Contents on the right side is very nice but in my =
opinion, it shouldn=E2=80=99t scroll. It should extend as far down as it =
needs to. Scroll bars within scroll bars are evil.

4. reference indentations seem to be inconsistent between RFC=E2=80=99s =
and drafts because of the width I assume. RFC references are indented =
whereas internet draft references are not. The square bracket starts at =
the beginning of the line.


Anyway, nice job with this.

Thanks,
Tom



From nobody Sat Feb  9 02:20:23 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468AF130F2F for <xml2rfc-dev@ietfa.amsl.com>; Sat,  9 Feb 2019 02:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 oyDO8NZYE3PX for <xml2rfc-dev@ietfa.amsl.com>; Sat,  9 Feb 2019 02:20:20 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 C19A0124B0C for <xml2rfc-dev@ietf.org>; Sat,  9 Feb 2019 02:20:19 -0800 (PST)
Received: from [192.168.178.124] ([84.171.154.1]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LpbfG-1hLRth2TLS-00fV18; Sat, 09 Feb 2019 11:19:51 +0100
To: Henrik Levkowetz <henrik@levkowetz.com>, Robert Sparks <rjsparks@nostrum.com>, xml2rfc-dev@ietf.org, RFC Interest <rfc-interest@rfc-editor.org>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de>
Date: Sat, 9 Feb 2019 11:19:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:isyLH/ksfLs62DV37qi+3QPiZ/leqMl/dgaI/yDPChQA7n5aIKn orC1lwpqKN0hvnIGfxRgnz4LAcyuWY9oXsBlePR7SQGlq1j82LCNNoP2hgJWJMAiMTpBOZw t5prU4yul8sQRjjkZZnveLGiwnSJpZmR5riyuw2dhrGc4sq/tQGYk6dzKppS2DLIPbmGupB fiWMnwdvm+GJ7ANk/JAbg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:zNUXsi1W/Zs=:HmtU5LgGsiqFuxAicdcGq0 dafoTbFXvKocoHxRlJR0vUAZZqqTEkgnvQnS+PfshZZnXNcpb/1U4hSIOBJ1Wk+SUUMnQOCZd V/PkUfqZM/NlhcbJxLmUb4q3UUAsTa1SQ4f8bJmYcthBBF/iqgzh38hP8RPGwAT94ybNBRrhF jgA48VQyIqsxCLi4jUEuSxVGyH64C3ku0Icik/2c8X3IIcJuTxkpKZIMBM/PFdW7EskecTRYt 7Xy/tUow3hIFBuhAw/gBtkSGXxmtlWmIg+PYJyt42n+juPSLLIRUGlbh253z+5OVMEjBQ9Sj4 +YG2+lUV0YUwDVYF2Sp/xYtPx2BkEkycY4PgzvKdsn9JQxZoVp+cTqcL5jV+qYpbBIwGBWqXM 8hz6u9RPu4uU0T5W4ZO5BzGbeXdNcbMN9WzJ6dp+t9m7zFjXnVBNAOx8z6jPEVdaQvnNOM4DD 8/SnmQbgV8ucbtJ+SyCA42hDvOk+b0sFbPc0ymYEVSaUIRjRANokvEYcIez/WcWZpbxrhejok jpG2XdR+MbBtna806Lhc3F069Qlzb+pUDxHrCgR2GtvCx7+ekv/J/e4DWymSgLLbbPRLAfXN7 tfzEyUb8Wp1FmVP3Fk87dbunObyYJ/vXrB8koAZi03XJGOHdDm69MV/dcEIcIRH3c2Dha99h3 kLbp8VPjT4nrvUKq+plLBRnYZUBe1bnR4Bem1EUNkOlqF1CoE7JJJ+3c15nY5ERXf67Gq2RKV x6ULxrR/JRHC3DlltZnXgf9vgK9zqRBiWcSgDFMulZtoAjg1Y5gmPoaEkAa6n4VnufdZbQmkt PKAW9QPxjooodW+5zl/pRXG2LUGLnXPkUoNxXjSLxHwkGmGdYV5uOQNIsloEcsgb7CuwP54eD GFynile53n2OzfGiUGF1KBXGM79cDj7Frs2NjJqAkR1a03+eexHoadnayw3ns1/eiRV0ENG/K eiN5Ey9EZcg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/m1FtFTGNfpaMqCixddqm6cVCwYw>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Feb 2019 10:20:22 -0000

On 07.02.2019 21:37, Henrik Levkowetz wrote:
> Hi Robert,
> 
> On 2019-02-07 21:07, Robert Sparks wrote:
>> The change proposed in this thread (to allow the preptool to incorporate
>> SVG from external files as artwork rather than a data URI) seems right,
>> and important.
>>
>> The IESG is ready to allow v3 submissions into the repository as soon as
>> the tooling is ready. The tooling is very close. As noted in the thread,
>> our goal is to have the submission tool accept a standalone file (rather
>> than solve how to allow submission of multiple components.)
>>
>> I'm asking that this change be made to the toolchain.
> 
> Ok, I'll coordinate with Jim to make sure to support his original use
> case, and make a tentative implementation, using the <artgroup> idea we
> landed on in the original thread.  I'll provide the details of that in my
> implementation notes draft, as part of the release notes of the release
> where they appear, and in a separate message to the lists this message
> goes to.  We can then adjust and iterate.
> 
> 
> 	Henrik
> ...

Hm.

It's a bit unfortunate to complicate the grammar that much for this 
case. I don't believe we need that.

Why don't we simply do something like

<artwork>
   <text-equivalent>

   </text-equivalent>
   <svg:svg>
     ...
   </svg:svg>
<artwork>

Best regards, Julian


From nobody Sat Feb  9 02:31:29 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AFA130F35 for <xml2rfc-dev@ietfa.amsl.com>; Sat,  9 Feb 2019 02:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 hJNDcSCkuBHL for <xml2rfc-dev@ietfa.amsl.com>; Sat,  9 Feb 2019 02:31:26 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 924E7130F2F for <xml2rfc-dev@ietf.org>; Sat,  9 Feb 2019 02:31:25 -0800 (PST)
Received: from [192.168.178.124] ([84.171.154.1]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M8e5P-1h5HlY343X-00wCzD; Sat, 09 Feb 2019 11:30:59 +0100
From: Julian Reschke <julian.reschke@gmx.de>
To: Henrik Levkowetz <henrik@levkowetz.com>, Robert Sparks <rjsparks@nostrum.com>, xml2rfc-dev@ietf.org, RFC Interest <rfc-interest@rfc-editor.org>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de>
Message-ID: <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de>
Date: Sat, 9 Feb 2019 11:30:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:KojRcl2544ZQjlmhdI39N4VzInuHrmgc6MeAAK31wvCyjNeXFHC sh0k2PUK4CGQKdcfQfFobm1R97sqTklDAreOKLnZvhzdQo7p+QRPOhPT9UhUdPoJoViIrEh OZhkJnESyNs7NxxebMeZ1iQhdFRqWBYOyuew+l0Q/cQkt07+7GuYZvm2nxJX7TgX41FWexf bfwYdecBUvB9cscJbF6fQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:BgAQNZh0HlE=:tCVsd1wOJ/e8oKrzws/KFP d2SVzdF7KkDKA0c6p/jfhjC/1r6F1da52cu/oDbLBpLtpGcE6eRlEELBWBsFki9O9Rnovu0Xj MJV+nGpbc4OI5MPL6ryHdO36z3Y9ln5ObSMnAJBncj4QLgYKHAwa8xHlap2Sb0FgJ08bWvDju 0cXdy/tH64keCPjp1ZHq1Wsh+gNuSvsMlSXLX+rJstIDaYXT57z+0c9p+aRcmBTvRz2CsHZhN BwLb0zKrHYsIqHoOvh5ZNb1ErBTtEtptA9m+mJ93rH6BpcRTXcGCSS7vAEOn0UhQ+Hv64T+x8 r2ytutqL96cPEfWZjx2Ycc5w8SS+Q+kWBJVZxOHqyA18s4Ul7Zt3CkgHsQ6v0y+b0wFsGuFMa ET6csRJ+bGbWNV0vQN2n8IadOZaItyPJS1U0tB2XRIqaiGnJYqiNE9JTUFPMk01d4rAm3sBm3 tR1hzIKNQekIhxxLips9HV6LUJeBQvOPkWzUciBzewoVlKjp0UJCl1+k0OwEzfBlFLeJksn65 SmkEEyAJa1ppHY/U5G3a9oz7CTpsFAQbB20JLnqh+d05Wm1nBfmK4iMv24f6CIaLh4lKkWIHB MfQ10xglEDWkY+Zbf5xNWo+snNMpdRZM1vchqRMQWYJDgneD9NinSicGjsO2Bsvg1Cq0gilN3 AGcbrnn3GoZWJ4ge068kyBqg/WO6V/9j60S3iQF9d0Hjyy9VsJtMUG1Ummd9wAFdKcIga9f+p LixU7dXy02N9N6A4COu6dru2D/IdihBmYn7aROHw+410aMe2M8k3auauxEDMuJHJLUgdGo4OE gWtu9WpD+qt3BTNM8J+/UrrVuIXxfXoR+JtRLdHOE1LVS0Ucgguv9ahRpk2MY/uhYKtj3Jp6Q kqRbtxlQ06OYRNnkVNwCZNNVhPfbtkbBit/+uj0G099EIgWJOo8OVGW9xv1d1eiTISBveFqMq PrWEMfsmVmQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/wLcbivXxHa6S5fPJzt8ZJS51wuE>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Feb 2019 10:31:28 -0000

On 09.02.2019 11:19, Julian Reschke wrote:
> On 07.02.2019 21:37, Henrik Levkowetz wrote:
>> Hi Robert,
>>
>> On 2019-02-07 21:07, Robert Sparks wrote:
>>> The change proposed in this thread (to allow the preptool to incorporate
>>> SVG from external files as artwork rather than a data URI) seems right,
>>> and important.
>>>
>>> The IESG is ready to allow v3 submissions into the repository as soon as
>>> the tooling is ready. The tooling is very close. As noted in the thread,
>>> our goal is to have the submission tool accept a standalone file (rather
>>> than solve how to allow submission of multiple components.)
>>>
>>> I'm asking that this change be made to the toolchain.
>>
>> Ok, I'll coordinate with Jim to make sure to support his original use
>> case, and make a tentative implementation, using the <artgroup> idea we
>> landed on in the original thread.  I'll provide the details of that in my
>> implementation notes draft, as part of the release notes of the release
>> where they appear, and in a separate message to the lists this message
>> goes to.  We can then adjust and iterate.
>>
>>
>>     Henrik
>> ...
> 
> Hm.
> 
> It's a bit unfortunate to complicate the grammar that much for this 
> case. I don't believe we need that.
> 
> Why don't we simply do something like
> 
> <artwork>
>    <text-equivalent>
> 
>    </text-equivalent>
>    <svg:svg>
>      ...
>    </svg:svg>
> <artwork>

Or even:

<artwork>
   <svg:svg>
     <svg:desc>
text equivalent
     </svg:desc>
     ...
   </svg:svg>
<artwork>

See 
<https://www.w3.org/TR/SVGTiny12/struct.html#TitleAndDescriptionElements>.

Best regards, Julian


From nobody Sun Feb 10 15:27:51 2019
Return-Path: <mt@lowentropy.net>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EF912958B for <xml2rfc-dev@ietfa.amsl.com>; Sun, 10 Feb 2019 15:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=RpYPrZvj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jPkhg/Zg
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 MzY9cwDXahyj for <xml2rfc-dev@ietfa.amsl.com>; Sun, 10 Feb 2019 15:27:48 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E97129284 for <xml2rfc-dev@ietf.org>; Sun, 10 Feb 2019 15:27:47 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0C380218B7 for <xml2rfc-dev@ietf.org>; Sun, 10 Feb 2019 18:27:46 -0500 (EST)
Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Sun, 10 Feb 2019 18:27:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:date:in-reply-to:references:subject; s=fm1; bh=0RO HtaJ1ikE5y2OcCf52uuJgwjTs6VQGPvro+OLeVrg=; b=RpYPrZvjFVKWwXubohM MDY/YAOOJl98FMSEjjC8PZ72uaEpRqbKR5u+UYgePWHeGCl7AJvTKQr2yNJCCREC 2XMGdNLMKDvsidjmf2WJITX4bWf5ESElyEFatY1N9TU8gkhbnt+1dwktS9DCyNcQ ciVkahPPZtfo1RDNE4Zrz0woRyhpgjAyKqQyaRKQssLYJYAOscysmJIIy1i5yPhC Aqji/tyvE504V4IkywimwhMTtViU3AWQ+fLzzNdAUePsk/mV+kirqfIt79sA9DX+ qQvYPjTv3LSe5zBFR1qUAieHi0IxXE5BxLGFzc9dl26kpb5LXjs+qzulbZvD/bT0 P6Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=0ROHtaJ1ikE5y2OcCf52uuJgwjTs6VQGPvro+OLeV rg=; b=jPkhg/ZgcetAYvNX8WrHCuhWoO5d93b+/zZoTw1RHvTDKU/6TZlq0K+YI eHlz04IGqex+oiW5QqdtQ3201FxkR2WQm0OFhmBIVe76UOaHU/xdyk66l+GQsF1r l9gQ8+96NttE27Kgc225Gup47Mdp2wN7mugqJsmQaRf4sCKxZz9UO95RR83Qsrsq 8kDQMXKC/vOk6qTUN7k8gGXDc93ckEWAo5S0VxyptSG8QrtiUwYMiR6HhiRmr22m 70UAKylvW/x7ydjXOMx6R2/xHhTMNmC9fyRcRDBK46O7R7wMCB6bZyqTigaoTqUb oxMdIJTPx8p3da9TwVf6Be4J3R1SQ==
X-ME-Sender: <xms:cbNgXM1oKyLlvjEM2tt9Wo64bC5TATpZAAttS4smw6O019WGnbyhbw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleejgddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucgoteefjeefqddtgeculdehtddmnecujfgurhepkffhvfgggfgtofffjghfufesth ejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpeiffedrohhrghenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghr ufhiiigvpedt
X-ME-Proxy: <xmx:cbNgXHAOAe8MtLWdZAmLz1_RazML1C4E6di2u2MhCbRxRaodq3zizw> <xmx:cbNgXAfkrDVMLNq_SojGUGvDtZrHnIl4tDU6j1ewFRFt1KkCzDEJrg> <xmx:cbNgXKy1t9SgvQmbOT0O3BT3wmk-mypKW-2vbukjlx8GYL7MFPOSRQ> <xmx:crNgXJrVVykbSlijzed9qI_2-vc8dssOSQtqxlWW_n-03bFGsRm-2Q>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id B6D0A9E567; Sun, 10 Feb 2019 18:27:45 -0500 (EST)
Message-Id: <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com>
From: Martin Thomson <mt@lowentropy.net>
To: xml2rfc-dev@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1
Date: Mon, 11 Feb 2019 10:27:45 +1100
In-Reply-To: <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/1N71sEnaUJSfP3i1Hx3dMVPeNX4>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Feb 2019 23:27:50 -0000

On Sat, Feb 9, 2019, at 21:30, Julian Reschke wrote:
> Or even:
> 
> <artwork>
>    <svg:svg>
>      <svg:desc>
> text equivalent
>      </svg:desc>
>      ...
>    </svg:svg>
> <artwork>

>From testing, whitespace is erased from this element in some tools.  Nothing specifies whitespace preservation, so that's unsurprising.  A specific element is probably best.

SVG2 provides some hints: https://www.w3.org/TR/SVG2/struct.html#DescriptionAndTitleElements


From nobody Sun Feb 10 21:36:16 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFA9130FDA for <xml2rfc-dev@ietfa.amsl.com>; Sun, 10 Feb 2019 21:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 IrQ2youc8x3c for <xml2rfc-dev@ietfa.amsl.com>; Sun, 10 Feb 2019 21:36:12 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 EB105130FE5 for <xml2rfc-dev@ietf.org>; Sun, 10 Feb 2019 21:36:10 -0800 (PST)
Received: from [192.168.178.124] ([91.61.62.95]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LgIWi-1hP9tt31Fc-00nfA6; Mon, 11 Feb 2019 06:36:01 +0100
To: Martin Thomson <mt@lowentropy.net>, xml2rfc-dev@ietf.org
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de>
Date: Mon, 11 Feb 2019 06:35:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:U2F4ja67ghvA8bOkjtYQwQ3wVNJYCTAQuZt4PsPUGHa60lq50Ao cm5Uhakm1ruZR79TldQzC0ZcpBVVxoZ7WCNDauXbhic5o1xpaw1TxFsaRNoVU9vSNQ7XIPL uGtJTr9Xx/f7gzFcFdemltFHPstaC6Vr2PJQZhu10xNZKcX2tR1h01O3QRp5LC0TY5ZsLWQ gM6O7ndwAIfpa/HTFOqmw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:MUe1X285ljk=:7iF8KiW8a0NiSHt676vng/ QoaJOSwF9N4LAsaTGqS/9mcu4U3+FdW7G198NFekfNZXJ1cLgXguaJofoEqddBJUx97kZ7WLK wXuD0VfFI+50Hp7fSlBWj5hvzikApor8Luopk68WVuT4cd4T779MuruMrJ51i8FdKeYGwk4jo sxIN8nSeSZmZo+wjidnn9oOpgABNlZ7hsdJHYRpP4CWMUzne2gtyQb0GlVOOBWpR5FUosN7Ll 9nJFE6sIgO020/gt/1XOtONX/aQ/FrM+CJct4SfbqVvk58XX5yihIltg85dQ1g6TPk0s2pAwm fH/XZDgStYzYFuz3/riPovOP9YnGhrvXVev+qHe/LtbjMx78u4M+nvhH/x6Z/+6Sm0KJG795O pYsWhkfTLta9m0ccNVCE9RBW0Ldq7qrSRD37ytmmteqW8zYZ1BCgfwWNO2eHgzFbiAeY+s+WP aD8emtxHyf9MC89Hgx4qRjAjdEeZRsSxySAif7PH7E6YSdRVu+4T0nT1uZdXz8jkovIFa9jyW ISXF8Kjrb51tFT4l9u+ZFpOghpyolxU+3yGfLhEx6f9gsVTmrC6xVfHzekF+OMlWhQ884aCk5 zR8Gq5vx6raXOYhZhcEBuw5qoqOIBklSUNUeh7dt7MIrxkwlaL9IbGL0Nh+etzy8YhvVPbitl p6VF3ilttZ2CErmGsQmUfa4weFD4FM6USZX7YfMjctnWI/nWnYA59ZRCNCGxNuQH9E+hj4eMg CsUn81Kd630pKO6ICR5oYq6LL/hIQXJEHFyL1iFx0BuLVnyvi7DiegFxDhmZ8FPT0c9PaxAeX Ks/3h9pZ1fsiQMzwKcyJ6Swp1Ac9Z/gXAU4p9rASIxpcoowumVKWDQBo9dhEhrX3IG1k7qaD/ OqhaIeZ0OREO8GriytOOHuwbvzwpPJiKJC4QwHc9OcrGw7ehf7bC2iGH9Xui3MnFdJdqAoniW s6lzjgF9ILQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/eK71AYBAFFDpHGHW3FcKvWnwbWI>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 05:36:15 -0000

On 11.02.2019 00:27, Martin Thomson wrote:
> On Sat, Feb 9, 2019, at 21:30, Julian Reschke wrote:
>> Or even:
>>
>> <artwork>
>>     <svg:svg>
>>       <svg:desc>
>> text equivalent
>>       </svg:desc>
>>       ...
>>     </svg:svg>
>> <artwork>
> 
>>From testing, whitespace is erased from this element in some tools.  Nothing specifies whitespace preservation, so that's unsurprising.  A specific element is probably best.
> 
> SVG2 provides some hints: https://www.w3.org/TR/SVG2/struct.html#DescriptionAndTitleElements

xml:space comes to mind.

That said, what will be more common? Plain text equivalent authored as 
part of the RFC source, or as part of the SVG source?

In the former case, it would be annoying to have it reside in the SVG, 
so my first proposal (side-by-side sibling element to SVG) would work 
better...

Best regards, Julian


From nobody Sun Feb 10 22:06:22 2019
Return-Path: <mt@lowentropy.net>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B71012894E for <xml2rfc-dev@ietfa.amsl.com>; Sun, 10 Feb 2019 22:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=YcG2uEmt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NwZNrZP5
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 X8L4JwW82Bbf for <xml2rfc-dev@ietfa.amsl.com>; Sun, 10 Feb 2019 22:06:19 -0800 (PST)
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 C0DDF124BAA for <xml2rfc-dev@ietf.org>; Sun, 10 Feb 2019 22:06:19 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 665882D6E; Mon, 11 Feb 2019 01:06:16 -0500 (EST)
Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Mon, 11 Feb 2019 01:06:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:date:subject:in-reply-to:references; s=fm1; bh=qzz qUiYZbemcKhdRgcJRaRRbDi2TLfajqh5L3jeSU8c=; b=YcG2uEmtNYxQH8WOXc9 7PmOUbYpIfUfw/xRmjuLn6bwMOCCzqrRZBiS0RbbhUWO5n1bFtvMuqBv3WV+C5PR uAy+MlbHXFbagzluyK1eR06EdXjQbq8xnH+EeTcUJ0w8oGP/74DEq4JA9DbjUnHw 0Vl73dwvG5JTwYx/hunHRseokGTq4Lixmh/Qm3N/BSDknxosSA2jlBewETg3BoLD L9cChhxxEeCaHEoBTMecw9Q4zfxCrIsFOyNSqLr7+DATylWJj9yAI1Q1wif5vK5w VleSVdLVLDwwPVJYWEsfpHhBWVM48H+NST9PvVun9qhHuyU8712R0ebP2DWCHUI4 ebA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=qzzqUiYZbemcKhdRgcJRaRRbDi2TLfajqh5L3jeSU 8c=; b=NwZNrZP5RMiiyDr+nZgicWAHbB/ZXyJ36tipf3rSPVr3RxWY8UjzA7dkR mhdO337/cYtU6f3CV6yMf3WW2pC0txon8oqdZNSFAvJx78Tse5pD5gKWUuicjeoE TqRSndr6woN8KXsv/MEXe0RTP+bT43P49uyhBI9n3LD1CwV6Azmkny3/+ijiBP7t Ibp6cqlDYl/vFEk6zRVeNfZDFINPlDSlg9Wiua+VSEReKVCoYIjgZ+rhicRXZIB3 FjnAfCgFJszgSfLv0OR16dwf6yG10yQusfMHXM6NExXIosvV/XT0dPVeiVrmiBJQ BcwApBB2mGGIC3L8zp2rBiPejUJUQ==
X-ME-Sender: <xms:1xBhXKvkFIjSDmJrz95A_I_2nfb_ISH3kDu7MMmMTEKqYyEdCriARA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleejgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof ffufgjfhesthejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceo mhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:1xBhXBVXv_h0FLE6tFum5zouOGE0hBtsKZLxoKRdTFGg_dN15-RDfw> <xmx:1xBhXK4jb0DjDCtTkpwZYMjBpFcRoNdbElGoS3CtTC59jj-1cRAlCg> <xmx:1xBhXFbumVt754yNJi0g0LN3cl6uMOkDD5KLkh5Oyh_OPT5D-ZSyTA> <xmx:2BBhXD9lU1KHohYed4Du8MK6xfiobbO0dpmCiqCLIu1jz_C0tIWj6w>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 72E939E524; Mon, 11 Feb 2019 01:06:15 -0500 (EST)
Message-Id: <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com>
From: Martin Thomson <mt@lowentropy.net>
To: Julian Reschke <julian.reschke@gmx.de>, xml2rfc-dev@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-950b8783
Date: Mon, 11 Feb 2019 17:06:15 +1100
In-Reply-To: <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com> <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/xQTRfgOpZN1bWwWfm6C_HjTyEdw>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 06:06:21 -0000

On Mon, Feb 11, 2019, at 16:35, Julian Reschke wrote:
> That said, what will be more common? Plain text equivalent authored as 
> part of the RFC source, or as part of the SVG source?

I tend to do ASCII art inline, but a separate file for SVG seems most likely, due to SVG tools being better at handling that.  That suggests SVG link, text fallback.  But I can equally see both being external.  If "artwork" could be either inlined or externally sourced for both types, that would be ideal.  Of course, limitations in a tool can be worked around if it comes to that.


From nobody Sun Feb 10 23:12:45 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDBB12D826 for <xml2rfc-dev@ietfa.amsl.com>; Sun, 10 Feb 2019 23:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 G6HuOxTc42yh for <xml2rfc-dev@ietfa.amsl.com>; Sun, 10 Feb 2019 23:12:42 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143C312008A for <xml2rfc-dev@ietf.org>; Sun, 10 Feb 2019 23:12:42 -0800 (PST)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:59060 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1gt5lg-0001Eu-Fr; Sun, 10 Feb 2019 23:12:40 -0800
To: Martin Thomson <mt@lowentropy.net>, Julian Reschke <julian.reschke@gmx.de>, xml2rfc-dev@ietf.org
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com> <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de> <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com>
Date: Mon, 11 Feb 2019 08:12:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UoEj3HacCbCgCjRhw0LdEiGD5alwl6CFU"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de, mt@lowentropy.net
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/RBbsDJjw_yXJCFnVPEX05wfBK9A>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 07:12:44 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UoEj3HacCbCgCjRhw0LdEiGD5alwl6CFU
Content-Type: multipart/mixed; boundary="VKAEU26W31jrGv71utTUrGOJbUap070PF";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Martin Thomson <mt@lowentropy.net>, Julian Reschke
 <julian.reschke@gmx.de>, xml2rfc-dev@ietf.org
Message-ID: <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into
 the repository (was Re: Alternate artwork vocabulary and post preptool)
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com>
 <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com>
 <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com>
 <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com>
 <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com>
 <02f101d48051$d5365100$7fa2f300$@augustcellars.com>
 <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com>
 <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com>
 <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com>
 <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com>
 <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de>
 <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de>
 <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com>
 <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de>
 <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com>
In-Reply-To: <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com>

--VKAEU26W31jrGv71utTUrGOJbUap070PF
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Martin,

On 2019-02-11 07:06, Martin Thomson wrote:
> On Mon, Feb 11, 2019, at 16:35, Julian Reschke wrote:
>> That said, what will be more common? Plain text equivalent authored as=
=20
>> part of the RFC source, or as part of the SVG source?
>=20
> I tend to do ASCII art inline, but a separate file for SVG seems most
> likely, due to SVG tools being better at handling that.  That
> suggests SVG link, text fallback.  But I can equally see both being
> external.  If "artwork" could be either inlined or externally sourced
> for both types, that would be ideal.

That is already the plan with the proposal worked out in November, quoted=

in Robert's original post, which I'm implementing.  No worries needed.

	Henrik


--VKAEU26W31jrGv71utTUrGOJbUap070PF--

--UoEj3HacCbCgCjRhw0LdEiGD5alwl6CFU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlxhIFoACgkQTptXS4+7
Fxri0RAA0pfCokRE43SprvdIXpJDX0hdaeqUsj1akSvADM72rbyEJtDy6bbe0wDv
Iny+31Cjz7A42mJg2r1nZEbtR0wbAv1/UTEPBhlMbPAcCqa4fEYbRzAlrphD7o7W
JrfIzoMb2KzChqe/9zAtECn3pnSuZde08LHL0qLa64AF1RmY6XxOttmn0L04iHoO
ovennc2rrZ9aRxK1YLUNEIv2eM6DDA6CLkjmJBgVPPEHEkoCND2SQGPGH4j77z1B
Z8XQlAYHmjYmshgAViO6l5GK4BCcLOvj6bcdDdbHWEJqizcFnMFtIiw7qovHC42p
gQIeK+lO0y9EYkBdlv7Xt7LzHs3Mnso9Uw6UNAUaWHnf0d6v4wcI5HgeigpZ+W99
qoZdBqJlt72IMQ/Tp6/mLAyc5axwzUULXEIaEIkDNz3fnl1tM81fvnQGOOE3InOk
5DuLXif5Ngu7syw9laTNUBL+oWk+Th59Z1T5QzGlRqFDDAI5Yjr1+J8f++zgt7pw
adNrVN9mzrtXZ66sRu+FlXgCw4jOwLOCUfdGjfzGuWqtS0G62Iwoa2srEzy7p3uv
lYZ5wT1da1EGp2HWbV7Riqs0aQgxazrHvOdu5c5SkjRbo7WnNk3psbJ1LY/qbK5C
k25RMITXJ4ITj6HEPYTJJYBFeq09AUbWbzI/dLdATDM4Lx1I+HM=
=6Pu/
-----END PGP SIGNATURE-----

--UoEj3HacCbCgCjRhw0LdEiGD5alwl6CFU--


From nobody Mon Feb 11 00:45:38 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF3E131024 for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 00:45:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 t3fxRstIuoze for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 00:45:33 -0800 (PST)
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 BC847130E11 for <xml2rfc-dev@ietf.org>; Mon, 11 Feb 2019 00:45:32 -0800 (PST)
Received: from [192.168.178.124] ([91.61.62.95]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LqQzp-1hWYlL1lvF-00e4XX; Mon, 11 Feb 2019 09:45:24 +0100
To: Martin Thomson <mt@lowentropy.net>, xml2rfc-dev@ietf.org
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com> <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de> <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <b836fe74-789c-ad8c-3bb6-20fe5681885a@gmx.de>
Date: Mon, 11 Feb 2019 09:45:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:ZO7uwU580BZF5Y+oJxCgJdgs/p/OQktQDcyUvOOb6TYp7ThRS5F NVlqF/HHPlk1kqBa/ec2b/Vl7M8UHJBRfRHni/sgL6H7u+oob/ujM0I8xMYZAaSXWO2GSGI iahQbBzOFjWqLjQoU1m40/xDYyryV69yc9xYtDJdyh2H7NY80bnKgx9JRnoQFONsv13bBsh EDwTIJTe1UJh5+/oGwV0w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:EJSw6SDR4gc=:le+gWyiuweduCoIatc20LW ATfMUfapo8tt9GLNWQLvAM+T+at94iizZ9P0h4kIcPH8uqTqeYMuhFW+lKy+HuQiHdk99BKqp YTx+3ONVCdCntl3yGurhqWi0zRQJyH3HnhlR4dbF6lcq8TixrjTPKXL0sIYZ4U/XQosUkQdYg hjw6CcV9xha7Q7s5WoIUmyPUhZYQN2iLSqLkj0vr6oOgVL3sZGkP5odRrb/P9nz95I5Yh5qx8 DFEtKFAuPlLuycRFkEy+9kaFm4iyr3wWVVq8QQNVFri8OgjtCFZIxflCSyb8ZUlqTEUvA1XcK 0edVEDzjqewqvjjWYU9mCo4vHcbNH8iEyKfdBvLbz1R6W+pEcI8OaXmFjUMPiCbQOVKG4YJQ7 PlvPlDHrgR3JQRn0RM9JWQPuazUhKIZQa9C8+fk3L6wxWbISH046g0/EYeazeujjYVZdvym83 LS4ZVtRL3DXTgTzN0x/JwN+h/PA+ty9er/osXlG/yfplYMQhmMFMWmTNJwZarHiBZSvVqeuZA XnRoV8Y81MclKieJ0mChwYgn71xafrDqmOBiLhWSRFLaNSQbIRZytS/BFj7CCUBCRkguTuuNH SVfxqH+1Oa3KzykT5V0zhsqsiG9uZF4Yz+Inmwe60L3PgzZvaCrOf2dydW0Ze+beaUm8eLSQG t/cquoPiT1rQNcJlIufn0x7Zi8pQT9KeVdwEEcQh1OuYNDeWyuGnxcrxgv6fo1b/CqThJKSoQ W/JUhRDu2k3Z00gu/V5zMi9x5AuZFh3K4S9YlpG5bEEkyFWYEOx2bGkETmq7+RIDSU01xYUZq JKecofLdhnJXuoEZR4JVnUdqHMIJwj4LkcMJi12f2EWcof5dePJORaEv4z0X08f5PaqSyj6Dt Or2YaASfU/U86+6Gy+40LW5K5AsYeslpqkglW7sfhvUZloaZS/XOJ+y5TNotUd6k/eZyQU9dm 1qoPx7dBQTw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/8BhVJzIfT27t1GsZipnotvDAPVk>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 08:45:35 -0000

On 11.02.2019 07:06, Martin Thomson wrote:
> On Mon, Feb 11, 2019, at 16:35, Julian Reschke wrote:
>> That said, what will be more common? Plain text equivalent authored as
>> part of the RFC source, or as part of the SVG source?
> 
> I tend to do ASCII art inline, but a separate file for SVG seems most likely, due to SVG tools being better at handling that.  That suggests SVG link, text fallback.  But I can equally see both being external.  If "artwork" could be either inlined or externally sourced for both types, that would be ideal.  Of course, limitations in a tool can be worked around if it comes to that.

Well, we can always externalize everything using xi:include...



From nobody Mon Feb 11 00:49:39 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DC2130ECE for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 00:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 qoT8IkpIiSHV for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 00:49:36 -0800 (PST)
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 7DCBA130E11 for <xml2rfc-dev@ietf.org>; Mon, 11 Feb 2019 00:49:35 -0800 (PST)
Received: from [192.168.178.124] ([91.61.62.95]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MSdNs-1gTqfP0YzM-00RYeL; Mon, 11 Feb 2019 09:49:17 +0100
To: Henrik Levkowetz <henrik@levkowetz.com>, Martin Thomson <mt@lowentropy.net>, xml2rfc-dev@ietf.org
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com> <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de> <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com> <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de>
Date: Mon, 11 Feb 2019 09:49:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:UMpPHFnIZ6WRwtp/FNm69HUuL6BUeHEIPsfGGnGMrhDQDJLIu7m YZQ8k1lDjomYaHhoJ6fcJiRR4sWRHkvXDv45AKjnaJUWDq6ObobFTRyvlF3coO4DElYDBMc HIHxb7k+eangBsQRo3m9pj4axS0ig8djhpW5ws+oqKqpMWjVowJQvwi9ac6RWMzgUH4R4o1 VV601aVZ8FH1jJlNGIb6Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:iK3mHC1sCWA=:usdxvS4AqRDmvnYA6zALRD ChGmBIapLyeLj1EaCZyFyzzxuUnTyM+Xa0X/g0bPT0dUOrIcjh5NFAbnGk7UKUDGI7D0NSZX4 sttMtt9kk2BL2vdYuJNJhnzsg9OPqmvmhuGx9lu7xjHrR4FBnZwDNrAZSl8OFXf3SqfsbWq/x w1uEIFEM9FrL9Xgldtdnvn2i2awd3QDlgxCoGpi/gDuewLDlg3jiMhnQ/I4B+krcK5YE8+9eU 1KRvebKXSq0FYGXJvSITCwXIlHbRmTaVtRUMITQWQbDa4aZJqCZL12v+XrX6exv9ujCKnZRaO Cea50s9MuGviQx6SHuaz0YEyjBT912O9C8xN5QFiBPshb2SGTCEd2jmn1ELxtNr7Ld19KMZlt F+dyYRmCvjKWsZDqyOtazTX7Dt9JGzfY80GpcLwyB5nJaZ5Bk25xMqLyw3UVaYdGC/ti0sQmA rp2wd+8GysNsnlLBYGegb5vKKRdS6HYd98Bk3uUQjVHhOoD82qX88SVzTwGsvmV4bWdTpVRXn 94VUqcSc4inZdsrRd/rQ2HAcnxGYg3AvWehqtruNihqrd075UbnNlmNOx6HQUVViuRaLdyDJ6 umiDDeMjq7X1LwyaKnwt7QLHwhowQyav6USFoqFJbPZ576PkmdMPbYeiotvE41TU5iUy6eCpD ZP/PDDP7ZxDDGSaibujElHWsErtoq/+bdOnNNq+ellatNcBZtEsuCyBckPYg6CNAN3lV8dwsk DjPFoWYDPB1GkgFFRfe7ZTmnru7v/r0Ze7CBqtqwGJSWOfcDkV0aQb9InFFygnIy6eWiBmmtR Xztvxk2OMH5YvR3y0kNRtbo4aBf1FpbkfD4L46yGuuM2aVgh0zcToKsTo4bXWMos2MBKl9rNm CsCkoz2+AV3E7ZrABLeglIwOV4kBge+rG5ouC2eKgDlb6mR6ylTeRoSNVuguSRV4pCdytIStn SCHBCwcLu3A==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/0tr5TNgmcv781CbbNxyvD76YYjY>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 08:49:38 -0000

On 11.02.2019 08:12, Henrik Levkowetz wrote:
> Hi Martin,
> 
> On 2019-02-11 07:06, Martin Thomson wrote:
>> On Mon, Feb 11, 2019, at 16:35, Julian Reschke wrote:
>>> That said, what will be more common? Plain text equivalent authored as
>>> part of the RFC source, or as part of the SVG source?
>>
>> I tend to do ASCII art inline, but a separate file for SVG seems most
>> likely, due to SVG tools being better at handling that.  That
>> suggests SVG link, text fallback.  But I can equally see both being
>> external.  If "artwork" could be either inlined or externally sourced
>> for both types, that would be ideal.
> 
> That is already the plan with the proposal worked out in November, quoted
> in Robert's original post, which I'm implementing.  No worries needed.

Once again: can we please consider something simpler? The proposal IMHO 
complicates the grammar in a way that is not needed.

I think the simplest possible fix is something like:

> <artwork>
>   <text-equivalent>
> 
>   </text-equivalent>
>   <svg:svg>
>     ...
>   </svg:svg>
> <artwork> 

Best regards, Julian


From nobody Mon Feb 11 03:04:49 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A10E130E8A for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 03:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 naVDzNW570Kx for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 03:04:45 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 EB2C7130E7F for <xml2rfc-dev@ietf.org>; Mon, 11 Feb 2019 03:04:44 -0800 (PST)
Received: from [192.168.1.81] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LqW8j-1hWarp2Rc1-00e2c2; Mon, 11 Feb 2019 12:04:24 +0100
From: Julian Reschke <julian.reschke@gmx.de>
To: Henrik Levkowetz <henrik@levkowetz.com>, Martin Thomson <mt@lowentropy.net>, xml2rfc-dev@ietf.org
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com> <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de> <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com> <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com> <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de>
Message-ID: <f11d2176-e5da-a5ac-9b3d-05a0a0533e61@gmx.de>
Date: Mon, 11 Feb 2019 12:04:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:cKFg5kGLCgUQ8a2mZwSXZPtpD8TtLCew/cRBJsoq01Tkrpw/7Ly hTNvrU1icF7JBqui4aslEEiWEwTF+g0H4UwSxKct7QQjzriWe7Bo2LuUijx40fI47DrKDGZ 3HoweXdB11pRIiCikgL9k4Hq4T1UnYu57CNz/rir1siBu5OsUa07HTLY42GxY/2/WHsvTg4 fG0BitNiiC2Lv91fL3AzA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:xUgyl5IvnIg=:qJuPf9+6vHypIhtKNcpdtb prRl4PFYzgGPDQBYPuKPqN7WToS0keMR1iVmh+HrUiDkkFu3eGlDpR23cIzzBhUotab4wiZYM aIbe9qscGL/+U828PTigOxvFXrwlHs13Gl3ug1Laut9AlK3IKL9wpYfzVGX9gFr2jvJ2XVgvU brTgrIZoFU9VOhzDop/3N23bPsI1I+a69TIe/iDVXabw9cPEWghT9415WbhsKaMxaOcyTKvM+ 3vixcEEbsfHRtr23HsAuB0C2pUN+OlSBZz1NznBy3/m8qE8vpg3m+HswYX2mmQ86mW87QuF/Z I/m44VtptrrQyIS8A5COH8LGQawpPAwjaapgZVBxtu4MMJ7hm8+QKudby65GUNs9qyUROGo7L kUPRrfvzexQrTc5G//Skph2cBQFfzKRGe8evfajCErOtt8OFaFaMbZgxywxMbVHNOcTXrxP9T yFsZHqpiewGMaaF0SzyaJGMmqIEM47ih/hWybGQNR5zsTCJLqZKjNb7UmlfpayOPNo2P/MnJs FcB3WJqJAyeizId9RIkS5Oi3eS52qkR6kt84B96GAWZ3of87J1CxWMAsB5CGjNdbqhOJJG2Bi vmwg5h64Xm5gEBVfXzaZymzLU3SVw7//SFwgZos2uHnfDJ9wVKHr9vMLpPBC9M3ogRAigKPwP 1j72L0Km3es4LLopQryzLRaAEFmOEUJz8VLhKbYRnIE/EEVWg63akkW96qvV+UPQ9sRi2g2iW BDg96oRMj3a08oqZPyUCuCjLDws0n2GcYPo8/46cl9mLL+lRcciHdgqOsSjFHA+Ptd8wEvrFO 28PiJ8DJLhMAKlp4noVqMcrrGoTvELVGzCsw+EjOBGkbhH1kGDXUgNiQqpK8sa0dC/hrOi0mz mQG9sehEC7+Lxrv3LsvWcH0lTBFsMRYgCfF3OtUUerpxpecanm+yKodi6WQ5+gKOoQXSxFQUP AEY//m7oINw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/oypWWWOdD_BdOG7TvUhJC_nfHBc>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 11:04:48 -0000

On 11.02.2019 09:49, Julian Reschke wrote:
> On 11.02.2019 08:12, Henrik Levkowetz wrote:
>> Hi Martin,
>>
>> On 2019-02-11 07:06, Martin Thomson wrote:
>>> On Mon, Feb 11, 2019, at 16:35, Julian Reschke wrote:
>>>> That said, what will be more common? Plain text equivalent authored as
>>>> part of the RFC source, or as part of the SVG source?
>>>
>>> I tend to do ASCII art inline, but a separate file for SVG seems most
>>> likely, due to SVG tools being better at handling that.  That
>>> suggests SVG link, text fallback.  But I can equally see both being
>>> external.  If "artwork" could be either inlined or externally sourced
>>> for both types, that would be ideal.
>>
>> That is already the plan with the proposal worked out in November, quoted
>> in Robert's original post, which I'm implementing.  No worries needed.

FWIW, if you are referring to the mail dated Feb 7, I have no idea which 
of the solutions discussed in the thread he was responding to is the one 
you have chosen.

> Once again: can we please consider something simpler? The proposal IMHO 
> complicates the grammar in a way that is not needed.
> 
> I think the simplest possible fix is something like:
> 
>> <artwork>
>>   <text-equivalent>
>>
>>   </text-equivalent>
>>   <svg:svg>
>>     ...
>>   </svg:svg>
>> <artwork> 
> ...

Expanding on that a bit...:

This change would only affect code pieces that actually are about the 
alternative text representation. Everything else would remain unaffected.

The other proposals that I have seen do a much more intrusive change to 
the grammar, affecting how <artwork> is nested etc. Please reconsider this.

Best regards, Julian


From nobody Mon Feb 11 03:21:58 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BD5130E8D for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 03:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 8XmCehgc0rH4 for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 03:21:55 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F2B130E8C for <xml2rfc-dev@ietf.org>; Mon, 11 Feb 2019 03:21:55 -0800 (PST)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:60611 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1gt9eq-0004Jr-SW; Mon, 11 Feb 2019 03:21:54 -0800
To: Julian Reschke <julian.reschke@gmx.de>, Martin Thomson <mt@lowentropy.net>, xml2rfc-dev@ietf.org
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com> <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de> <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com> <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com> <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <c16b9fbe-b2b0-e181-aafb-5b98930e1403@levkowetz.com>
Date: Mon, 11 Feb 2019 12:21:45 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KvdTMAQOrv7QqwEBT1tITXFihfiSjc73W"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, mt@lowentropy.net, julian.reschke@gmx.de
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/huPcakP_HNnrbNgdC3NanKxBQr0>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 11:21:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--KvdTMAQOrv7QqwEBT1tITXFihfiSjc73W
Content-Type: multipart/mixed; boundary="UEghXOs6HhX5XHuIN1fpDPs7OKIrKKdaJ";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Julian Reschke <julian.reschke@gmx.de>, Martin Thomson
 <mt@lowentropy.net>, xml2rfc-dev@ietf.org
Message-ID: <c16b9fbe-b2b0-e181-aafb-5b98930e1403@levkowetz.com>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into
 the repository (was Re: Alternate artwork vocabulary and post preptool)
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com>
 <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com>
 <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com>
 <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com>
 <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com>
 <02f101d48051$d5365100$7fa2f300$@augustcellars.com>
 <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com>
 <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com>
 <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com>
 <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com>
 <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de>
 <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de>
 <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com>
 <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de>
 <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com>
 <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com>
 <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de>
In-Reply-To: <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de>

--UEghXOs6HhX5XHuIN1fpDPs7OKIrKKdaJ
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On 2019-02-11 09:49, Julian Reschke wrote:
> On 11.02.2019 08:12, Henrik Levkowetz wrote:
>> Hi Martin,
>>=20
>> On 2019-02-11 07:06, Martin Thomson wrote:
>>> On Mon, Feb 11, 2019, at 16:35, Julian Reschke wrote:
>>>> That said, what will be more common? Plain text equivalent authored =
as
>>>> part of the RFC source, or as part of the SVG source?
>>>
>>> I tend to do ASCII art inline, but a separate file for SVG seems most=

>>> likely, due to SVG tools being better at handling that.  That
>>> suggests SVG link, text fallback.  But I can equally see both being
>>> external.  If "artwork" could be either inlined or externally sourced=

>>> for both types, that would be ideal.
>>=20
>> That is already the plan with the proposal worked out in November, quo=
ted
>> in Robert's original post, which I'm implementing.  No worries needed.=

>=20
> Once again: can we please consider something simpler? The proposal IMHO=
=20
> complicates the grammar in a way that is not needed.

I'm working on what was agreed on in November:

<artgroup>
  <artwork>
  </artwork>
  <artwork>
  </artwork>
</artgroup>

>=20
> I think the simplest possible fix is something like:
>=20
>> <artwork>
>>   <text-equivalent>
>>=20
>>   </text-equivalent>
>>   <svg:svg>
>>     ...
>>   </svg:svg>
>> <artwork>=20

I don't see how it would be simpler.  The only I see with this is that it=

reopens the discussion that ended in an acceptable solution in November.

Regards,

	Henrik


--UEghXOs6HhX5XHuIN1fpDPs7OKIrKKdaJ--

--KvdTMAQOrv7QqwEBT1tITXFihfiSjc73W
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlxhWskACgkQTptXS4+7
FxoyEg//cKUvjYgMdTnfyhSYFZu2sW9HK9GlOc7cMqRm8x1yl+IiuNuWJX6JnXs9
ei7DwwHng+LGpsKbiudi9Kc1yQiVRot6+xQe96td+KXoPylWZRVF5ShobM/OK9kS
7DQazLL3ZEvei90q70XGwgK3nSHatdF5/432kQem1zNpiO/kXBRE66BYx3aya7tm
ZoRycMB8sqaswRITjT2tARuqtFGCYwtR6W8Wv/HKRMxa/WMFDHsUnx5aDNNfjb0K
mRG4YZSu6XFbbGO5/1iSjd+ifgWIJbvXNxmJM6H7a6itZR5vmOuxl1Cd6vkF760k
K8IxSq70K8EKnbruWtybJPXn0+fHNOqq2lhrhtSkI4GIYn80NyIDpV5Q1vOV4uhI
RBzPO7QaX6HhfibtUoNOpfawQmQNwZNQJ3V1NCjxLer44fhnNGeMwLP8B7TL4jJM
h5XXMt3ndBGzkZuwEcELRZ4oBcdCS1f/hSeFyMNxQcA70SO/B/oGh1dGiubxd8sC
pz99f6GuuXgOmWg74TetoTxR0KdPJis4b9/yWB6UiX7k31hfboiUI5HRQ61SFKgQ
FWIvKSpldpEPHCNx8tlsf54FsQVyj01O/HLE0QttEEFobwbRBsyZNvQLfST1pUIe
4lUF9kq8WS3J+1pE1UOBHRD3G7yC6pJAY5IJXvwljgTMmraTxEg=
=QTrG
-----END PGP SIGNATURE-----

--KvdTMAQOrv7QqwEBT1tITXFihfiSjc73W--


From nobody Mon Feb 11 04:19:35 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EE7130E8A for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 04:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 1-hJf0cR4AUS for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 04:19:33 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 7C8791286D8 for <xml2rfc-dev@ietf.org>; Mon, 11 Feb 2019 04:19:32 -0800 (PST)
Received: from [192.168.1.81] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M6ioC-1hGMHF1eHU-00wTm9; Mon, 11 Feb 2019 13:19:13 +0100
To: Henrik Levkowetz <henrik@levkowetz.com>, Martin Thomson <mt@lowentropy.net>, xml2rfc-dev@ietf.org
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com> <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de> <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com> <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com> <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de> <c16b9fbe-b2b0-e181-aafb-5b98930e1403@levkowetz.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <bf22d92e-088f-8ef8-f5cb-2ada2ecde0e2@gmx.de>
Date: Mon, 11 Feb 2019 13:19:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <c16b9fbe-b2b0-e181-aafb-5b98930e1403@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:9+PhnMoNiuULpAUz0e8iR6ic6/YDV6NAVcPGsRqQUzXO/FaYAan j9iBUEylyBxEi4a5ldDDkeCSaE0a/2rhC6xVsGUl/1k3bL+KhMVesoM22obRVnctN0QMMNr YLCq9De7Yp7nIkEI02Eot3l4lCEX69oBozKU9EMzFgmOWjGF9+poa4Oklje3jr8Pq/r1j6h h9Pw66orm9Jd4/zCQmSHQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Avx1nhJs8P8=:oisdJxuKFULi7Vo3Bveibt 6XfjYBuKf0vyDisxdJri4gwQiOAML3O3AwF8oXRa5jpS7qCC+IquaXgBhcYTclvMvugx3ID01 MQBQC71a3Til36b8jnL5nBa63rHe8YXHliFL1IjQ8QZEcHLy4ucqfhPQfGctvUI7J/lYy3Mc9 7ULpRZTfcGbnJXd0MNhBdeTL/Ce92uR1z9M5PKeHoBHKKvxn9J+7OhXDtirSKNfLOUy0r8Beu x1cs33OM3RCvlp54fvNR03itcOHBjWVO0GSTNS8RhYiPf9yw6QW3iL5HervuTOOk75PWABM/+ hWkdXB1dUXCj1GXRV4sxbVi/pl1UhAEnoz8ZxsVeWk4UxtB5sIonJa24KYQZijcVw8h1P4gqI hYMjJlHN5LerfAaJkNi3992NcBSkqDMr6KRY4H3Co+PWzWdm4vArsArrdk/Y+9+tZN0bVwBxk OryhfonDc9pyIiHSfw7MjoAHNeBG1iytg1yxeuUjXehtr/V1a+xH61P2eBWGEt6n5escYMjXC BH/WHPTxP3ZmT7FJEaIazxmtnF6X6cHZebPClMNqNBa2pB2Qa4fwSx+Dis55vC00Fwygf36TD is/w3lEOHUAWUSPh91N8jSVZA5l7wI0bW7MBq+1rB+bhu0oLgpMAgxYJ3s9NSuKspxzn+A1gF SIPdRMQTb78QdP8cH4EctV8uUZmRsnPYt2C/gJtFJBU3nbTG/fWME12YX+0vBQ6/8yyGUiEIl 6FEHyXKiYkvuUZb+IQnBYEjRFd2lEH8SSDNwZjJJnwboBBgnWnmAvvGs3KhlR7uGolLHd4QGe MYlrEzApFHDCfDgCabQVv6JNxwgp/mZdB6hbmImndKHsyc2kFDdiWHo2vSrzeUmXIHhSW21aU Q3eAkNgQ4WnDisbkYUMHwVJxnIz0sjFW4z0/ML5OqvTG8DTkVfDWnbeQoHDuUKnLNiU7PsVPf i7w0Qc3wh6w==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/Bj8-LxwJQ3qJjg6UDSUj60o6wOU>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 12:19:34 -0000

On 11.02.2019 12:21, Henrik Levkowetz wrote:
> 
> On 2019-02-11 09:49, Julian Reschke wrote:
>> On 11.02.2019 08:12, Henrik Levkowetz wrote:
>>> Hi Martin,
>>>
>>> On 2019-02-11 07:06, Martin Thomson wrote:
>>>> On Mon, Feb 11, 2019, at 16:35, Julian Reschke wrote:
>>>>> That said, what will be more common? Plain text equivalent authored as
>>>>> part of the RFC source, or as part of the SVG source?
>>>>
>>>> I tend to do ASCII art inline, but a separate file for SVG seems most
>>>> likely, due to SVG tools being better at handling that.  That
>>>> suggests SVG link, text fallback.  But I can equally see both being
>>>> external.  If "artwork" could be either inlined or externally sourced
>>>> for both types, that would be ideal.
>>>
>>> That is already the plan with the proposal worked out in November, quoted
>>> in Robert's original post, which I'm implementing.  No worries needed.
>>
>> Once again: can we please consider something simpler? The proposal IMHO
>> complicates the grammar in a way that is not needed.
> 
> I'm working on what was agreed on in November:
> 
> <artgroup>
>    <artwork>
>    </artwork>
>    <artwork>
>    </artwork>
> </artgroup>

How does a processor decide which of the enclosed artwork elements to 
render? What's the algorithm?

>> I think the simplest possible fix is something like:
>>
>>> <artwork>
>>>    <text-equivalent>
>>>
>>>    </text-equivalent>
>>>    <svg:svg>
>>>      ...
>>>    </svg:svg>
>>> <artwork>
> 
> I don't see how it would be simpler.  The only I see with this is that it
> reopens the discussion that ended in an acceptable solution in November.

I just explained why it's simpler, didn't I?

<artgroup> requires changes all over the place as it fundamentally 
changes the grammar. For instance, it creates new issues with 
referenceability: what if prose has an <xref> to an <artwork> element 
which will not actually be output by the renderer (such as the plain 
text variant in HTML, or the SVG variant in plain text?).

Yes, questions like this can be solved, but they need to, and I just 
don't see why we need this complexity if a much simpler approach is 
available.

Best regards, Julian



From nobody Mon Feb 11 21:43:14 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5126812D4EF for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 21:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 dYbGBTpakwfq for <xml2rfc-dev@ietfa.amsl.com>; Mon, 11 Feb 2019 21:43:10 -0800 (PST)
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 49EDC12D4E6 for <xml2rfc-dev@ietf.org>; Mon, 11 Feb 2019 21:43:09 -0800 (PST)
Received: from [192.168.178.124] ([91.61.59.165]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LynHb-1h7XdR2wsB-0169WT; Tue, 12 Feb 2019 06:37:34 +0100
From: Julian Reschke <julian.reschke@gmx.de>
To: Henrik Levkowetz <henrik@levkowetz.com>, Martin Thomson <mt@lowentropy.net>, xml2rfc-dev@ietf.org
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com> <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de> <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com> <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com> <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de> <c16b9fbe-b2b0-e181-aafb-5b98930e1403@levkowetz.com> <bf22d92e-088f-8ef8-f5cb-2ada2ecde0e2@gmx.de>
Message-ID: <d5951af0-9b65-ec24-9dc2-98559a111ae6@gmx.de>
Date: Tue, 12 Feb 2019 06:37:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <bf22d92e-088f-8ef8-f5cb-2ada2ecde0e2@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:BU5YBHu++EWwAGw4h2fPNlo75YrPicTnu6yIJGEmin88m9QCX0A QXBaOKJjNoGEjfJOTxb2ffLdHu0/ci6KUIfej5eGdygCTTve7SfoD3BI5/dpVYQyAmxNsxH swRW/oIjQmtSC0CmIbNoFM7XM6COtE+dIojnsCF3qn+mqjoHorK56NEMbkn3QaE1DEWy+I5 fE33Ho9HkHVBR3/dEK5dQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:HW+WSDOZBJI=:FSpHucippzqVHZV6YX/VfP M/UpiQSY8tGekdhzu7O5QDlLT6Wn329QM6jgKgjR7X4Cv/9lxuXtpIjPtt+0mNdECWLSG/jzR /zD8fT3/c87RAfCPbU1/VW5kkV/SLta0Zgy1Mc3UZGBnJShIz9+PvciszMBjyEkNCTi4F5Nyo WB35l9adB1NXlI0z/kRZVgGOYJVJ4ryx1k6Cs47iaRamuBQCf3s9AEmJbcz9ZcqSKzynvixlx 5PuMM8JJXiilqBaPlWBfT15FSkl5pYzCEmd2UUj3uMRaxc+R423Y4R9OzTu8/ikdN2zAfuGeH O8SXtFBwSCwi80YZyeLdrQEnYUPiqIOeFe7RbJm1qAvDmSXCaUdAof7rubSZf4fY9tx7qOl6V 51Q1Ga8qG2v+UJXVG8v2tWlDgiDKZIl04YoUQmET5NBOc05I4RJEHbX8hFeEY6t4NxC0Wmvdc s7NNvC40KrjPsVV7bpq1kp1PcCaOUOt2DqfJxYvs7cZuI+t3YZng8vOASaiL+vcACbWhyN2HR X1ac4ec36qeJvCBYRPzQ3PkYl+kjhJysgbm+MZ25LszRvteMj8u9PBJc+m8+n/MyzY7nz4hfP zmQBS+Lwh7LugMRI+u0QqMbtqagbcPq2nfl8MDhJewAehKqgUZLe/ZubcC8WpmFg/j0T2zknt DeErtVsnOAE2n0PFWHGVCepj1iXP95dDQt36FyzMGqk9YxF5QLGIqQSXqC2R4JZSuEKBkENNU Gp4vhtH3jL9ZnkjIDDNFWFfcVhigComgZWBSDoC6V1IjtvPj7SIaIKikKRKRttQp/RYDcDjW0 FhuNMwq/UTqTPNKydfffoXcm4yhXjS42yniyIbcd08a0TjuNJyE4rwArVSmLsVmw9yuM9a08P 0mS4tcho0r+MwMhZoPjAVAO2+e/Q8dbjKe3qLojrSCewI+13+LOonoctqArE6YioJcdialUcm 3bsthIikbHg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/sEIQbocmCPO5eA7PmGB3yQwoYlw>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2019 05:43:12 -0000

On 11.02.2019 13:19, Julian Reschke wrote:
> ...
> I just explained why it's simpler, didn't I?
> 
> <artgroup> requires changes all over the place as it fundamentally 
> changes the grammar. For instance, it creates new issues with 
> referenceability: what if prose has an <xref> to an <artwork> element 
> which will not actually be output by the renderer (such as the plain 
> text variant in HTML, or the SVG variant in plain text?).
> 
> Yes, questions like this can be solved, but they need to, and I just 
> don't see why we need this complexity if a much simpler approach is 
> available.
> 
> Best regards, Julian

Another one: will the insertion of the artwork element affect numbering 
of artwork elements, thus affecting the supposed-to-be-stable anchors in 
HTML output?

Best regards, Julian


From nobody Thu Feb 14 06:20:46 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD7B13106D; Thu, 14 Feb 2019 06:20:35 -0800 (PST)
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, URIBL_BLOCKED=0.001] autolearn=ham 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 BvWrSQ-oYnYx; Thu, 14 Feb 2019 06:20:33 -0800 (PST)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D342130F0E; Thu, 14 Feb 2019 06:20:33 -0800 (PST)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1guHsP-0006fN-5z; Thu, 14 Feb 2019 06:20:33 -0800
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1guHsP-0006fN-5z@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Thu, 14 Feb 2019 06:20:33 -0800
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/bTx03xas9efpPwR-HbQp7C6MaAU>
Subject: [xml2rfc-dev] New xml2rfc release: v2.19.0
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2019 14:20:36 -0000

Hi,

This is an automatic notification about a new xml2rfc release, 
v2.19.0, generated when running the mkrelease script.

Release notes:

xml2rfc (2.19.0) ietf; urgency=medium

   **Changed handling of alternative artwork**

   The way <artwork> has been specified to handle the presence of both
   SVG artwork and text fallback (in Section 2.5 of [RFC7991]) has the
   result that any SVG content has to be placed as a data: URL in the
   "src" attribute when an ascii-art fallback is present.  This makes
   the SVG effectively uneditable once the preptool has been run, even
   if the SVG artwork was originally provided as a regular SVG XML file
   external to the document XML file.

   In order to be able to more easily deal with alternative instances of
   artwork, and in the future possibly deal smoothly with a wider number
   of alternative artwork formats than is currently provided for, a new
   element <artset> could be introduced, presenting a set of alternative
   artwork executions.  This would let the renderer pick the most
   appropriate <artwork> instance for its format from the alternatives
   present within an <artset> element, based on the "type" attribute of
   each enclosed <artwork> element.

   If more than one <artwork> element is found within an <artset>
   element, with the same "type" attribute, the renderer could select
   the first one, or possibly choose between the alternative instances
   based on the output format and some quality of the alternative
   instances that made one more suitable than the other for that
   particular format, such as size, aspect ratio, or whatnot.

   Implementation:  Xml2rfc as of version 2.18.0 implements this, with a
      preference list when rendering to HTML and PDF of ( "svg",
      "binary-art", "ascii-art" ), while the text renderer uses the list
      ( "ascii-art", ) -- i.e., one entry only.  The Relax-NG compact
      schema used for <artset> is this::

        artset =
          element artset {
            attribute xml:base { text }?,
            attribute xml:lang { text }?,
            attribute anchor { xsd:ID }?,
            attribute pn { xsd:ID }?,
            artwork*
          }

      The <artset> element can occur anywhere an <artwork> element can
      occur.  The first anchor on an <artwork> element within an
      <artset> element will be promoted to the <artset> element if it
      has none; apart from that, anchors on <artwork> elements within an
      <artset> element will be removed by the preptool.

   Additionally, this release contains some other fixes and changes.  From
   the commit log:

  * Normalized the expansion of <xref> to be more consistent conceptually 
    and across renderings.  Added back rendering support for format='none'.

  * Added another exception class to the import exception catch for pango,
    to avoid a crash in some environments.

  * Applied a patch from rjs@nostrum.com to improve the xml2rfc description.

  * Disallow lxml 4.3.1, as it can cause segfaults with some Python 
    versions.  Fixes issue #393.

  * Put back LICENCE which has been lost from the source distribution tarball
    at some point.

  * Adjusted the <xref format="counter"/> output for appendices.

  * Added code to remove any usage of Unicode U+2028 LINE SEPARATOR from the
    text output also in legacy mode.

  * Fixed a problem with the text format rendering of <xref> for an appendix.

  * Added a get_element_tags() method in BaseV3Writer, and commented out 
    some debug code.

  * Removed a warning about missing country that would appear even if no 
    <address> or <postal> was supplied.

 -- Henrik Levkowetz <henrik@levkowetz.com>  12 Feb 2019 16:43:44 +0000

The preferred way to install xml2rfc is by doing 'pip install xml2rfc',
and 'pip install --upgrade xml2rfc' to upgrade.  If there are system-
installed python modules which pip will not upgrade, you may have to
use 'pip install --upgrade --no-deps xml2rfc' and install dependencies
manually.

The new version is also available through SVN checkout, with
  'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.19.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Sat Feb 16 14:24:22 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456D7130FFE; Sat, 16 Feb 2019 14:24:15 -0800 (PST)
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, URIBL_BLOCKED=0.001] autolearn=ham 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 c-CHOs9hDhi6; Sat, 16 Feb 2019 14:24:13 -0800 (PST)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA436130FFB; Sat, 16 Feb 2019 14:24:13 -0800 (PST)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1gv8NZ-0004SO-GT; Sat, 16 Feb 2019 14:24:13 -0800
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1gv8NZ-0004SO-GT@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Sat, 16 Feb 2019 14:24:13 -0800
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/G3N7HwCCPWErNrHTDYPpN6RNGKA>
Subject: [xml2rfc-dev] New xml2rfc release: v2.19.1
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Feb 2019 22:24:15 -0000

Hi,

This is an automatic notification about a new xml2rfc release, 
v2.19.1, generated when running the mkrelease script.

Release notes:

xml2rfc (2.19.1) ietf; urgency=medium

  This is a small bugfix release.  From the commit log:

  * Removed some linux-specific code.

  * Fixed a problem with the handling of comments and PIs inside text 
    blocks.

 -- Henrik Levkowetz <henrik@levkowetz.com>  16 Feb 2019 22:21:25 +0000

The preferred way to install xml2rfc is by doing 'pip install xml2rfc',
and 'pip install --upgrade xml2rfc' to upgrade.  If there are system-
installed python modules which pip will not upgrade, you may have to
use 'pip install --upgrade --no-deps xml2rfc' and install dependencies
manually.

The new version is also available through SVN checkout, with
  'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.19.1'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Wed Feb 20 12:58:43 2019
Return-Path: <pusateri@bangj.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA70A130DC4 for <xml2rfc-dev@ietfa.amsl.com>; Wed, 20 Feb 2019 12:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Xk4ES04HHCDU for <xml2rfc-dev@ietfa.amsl.com>; Wed, 20 Feb 2019 12:58:39 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9B1129A85 for <xml2rfc-dev@ietf.org>; Wed, 20 Feb 2019 12:58:39 -0800 (PST)
Received: from [10.10.56.118] (unknown [72.235.180.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 6B5E028049; Wed, 20 Feb 2019 15:58:37 -0500 (EST)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <CA1153A5-9A91-451E-8B7A-E88A954C11E5@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2FFB3F3B-0B69-457A-B2A5-9575DAD33186"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 20 Feb 2019 10:58:34 -1000
In-Reply-To: <1811BFA4-FDE1-4844-B704-BA770E75E889@tzi.org>
Cc: xml2rfc-dev@ietf.org
To: Carsten Bormann <cabo@tzi.org>
References: <7AA856E3-834F-4E78-A5E8-02BB55D35D35@bangj.com> <CAA=duU2hP__MOJEEmRmm01R8KJ6Yi_kmC3+Lo-D2eCPDOTPLhg@mail.gmail.com> <16D888A3-0AAF-432C-9C43-BB7F2DA3BCAA@bangj.com> <54352830-048F-4EA9-907A-302646E703DA@tzi.org> <22C3BD1A-7393-472D-A519-4800981DCDDF@bangj.com> <1811BFA4-FDE1-4844-B704-BA770E75E889@tzi.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/eYshhOPZ77Mwwruv94TrOgNVGJ0>
Subject: Re: [xml2rfc-dev] v3 XML template feature request
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 20:58:42 -0000

--Apple-Mail=_2FFB3F3B-0B69-457A-B2A5-9575DAD33186
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jan 28, 2019, at 8:44 PM, Carsten Bormann <cabo@tzi.org> wrote:
>=20
> On Jan 29, 2019, at 00:12, Tom Pusateri <pusateri@bangj.com> wrote:
>>=20
>> Carsten,
>>=20
>> I=E2=80=99ve tried TextMate 2 on macOS, vim, and Sublime Text. All =
have Markdown modes but the distinctions between sections, subsections,  =
and paragraphs just aren=E2=80=99t enough for me.
>=20
> I=E2=80=99m not working daily with these but some of these may have =
parameters for making the distinction stand out more.
>=20
>> Yes, agree that XML is too much noise but the whitespace distinctions =
in Markdown and the terse separators are not sufficient separators for =
me. Collapsing would also be nice but that=E2=80=99s not an option for =
Markdown in any editor I=E2=80=99ve seen.
>=20
> Markdown-mode in Emacs certainly does collapsing (TAB key).
> (Unfortunately, that does not tolerate the way kramdown usually takes =
anchors on sections.)
>=20
>> AsciiDoc doesn=E2=80=99t seem any better in this sense.
>>=20
>> Yes, JSON is probably not the right thing but whitespace based =
formatting is not either.
>=20
> Clearly, a lot of people think the markdown syntax works well=E2=80=A6
> Maybe it also helps to use =E2=80=9Csetext=E2=80=9D style headers, as =
in
>=20
> Introduction
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> As opposed to the terser =E2=80=9Catx=E2=80=9D style:
>=20
> # Introduction
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20

As a follow-up, there has arisen another reason that makes =
kramdown-rfc2629, mmark.nl <http://mmark.nl/>, and any other tools that =
the RFC editor isn=E2=80=99t using less than ideal.

During an AUTH48 stage of publication for a draft I was a co-author that =
used kdramdown-rfc2629, we got back from the RFC editor an edited XML =
version that they wanted us to modify. Since the source was in Markdown, =
by them switching the source to XML, we now lost all edit history moving =
forward. We put their XML version in our github repository but now all =
future edits have to use their XML file.

Separately, they continue to email back and forth edits and so trying to =
keep a repository of XML changes alone is a problem=E2=80=A6

Tom



--Apple-Mail=_2FFB3F3B-0B69-457A-B2A5-9575DAD33186
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jan 28, 2019, at 8:44 PM, Carsten Bormann &lt;<a =
href=3D"mailto:cabo@tzi.org" class=3D"">cabo@tzi.org</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"">On Jan 29, 2019, at 00:12, Tom Pusateri &lt;<a =
href=3D"mailto:pusateri@bangj.com" class=3D"">pusateri@bangj.com</a>&gt; =
wrote:<br class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D"">Carsten,<br class=3D""><br class=3D"">I=E2=80=99ve tried =
TextMate 2 on macOS, vim, and Sublime Text. All have Markdown modes but =
the distinctions between sections, subsections, &nbsp;and paragraphs =
just aren=E2=80=99t enough for me.<br class=3D""></blockquote><br =
class=3D"">I=E2=80=99m not working daily with these but some of these =
may have parameters for making the distinction stand out more.<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">Yes, =
agree that XML is too much noise but the whitespace distinctions in =
Markdown and the terse separators are not sufficient separators for me. =
Collapsing would also be nice but that=E2=80=99s not an option for =
Markdown in any editor I=E2=80=99ve seen.<br class=3D""></blockquote><br =
class=3D"">Markdown-mode in Emacs certainly does collapsing (TAB =
key).<br class=3D"">(Unfortunately, that does not tolerate the way =
kramdown usually takes anchors on sections.)<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">AsciiDoc doesn=E2=80=99t =
seem any better in this sense.<br class=3D""><br class=3D"">Yes, JSON is =
probably not the right thing but whitespace based formatting is not =
either.<br class=3D""></blockquote><br class=3D"">Clearly, a lot of =
people think the markdown syntax works well=E2=80=A6<br class=3D"">Maybe =
it also helps to use =E2=80=9Csetext=E2=80=9D style headers, as in<br =
class=3D""><br class=3D"">Introduction<br class=3D"">=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<br class=3D""><br class=3D"">As opposed to the terser =
=E2=80=9Catx=E2=80=9D style:<br class=3D""><br class=3D""># =
Introduction<br class=3D""><br class=3D"">Gr=C3=BC=C3=9Fe, Carsten<br =
class=3D""><br class=3D""></div></div></blockquote><br =
class=3D""></div><div>As a follow-up, there has arisen another reason =
that makes kramdown-rfc2629, <a href=3D"http://mmark.nl" =
class=3D"">mmark.nl</a>, and any other tools that the RFC editor isn=E2=80=
=99t using less than ideal.</div><div><br class=3D""></div><div>During =
an AUTH48 stage of publication for a draft I was a co-author that used =
kdramdown-rfc2629, we got back from the RFC editor an edited XML version =
that they wanted us to modify. Since the source was in Markdown, by them =
switching the source to XML, we now lost all edit history moving =
forward. We put their XML version in our github repository but now all =
future edits have to use their XML file.</div><div><br =
class=3D""></div><div>Separately, they continue to email back and forth =
edits and so trying to keep a repository of XML changes alone is a =
problem=E2=80=A6</div><div><br class=3D""></div><div>Tom</div><div><br =
class=3D""></div><br class=3D""></body></html>=

--Apple-Mail=_2FFB3F3B-0B69-457A-B2A5-9575DAD33186--


From nobody Wed Feb 20 13:04:04 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDCD12D4E7 for <xml2rfc-dev@ietfa.amsl.com>; Wed, 20 Feb 2019 13:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 NDoBOnAvLzPZ for <xml2rfc-dev@ietfa.amsl.com>; Wed, 20 Feb 2019 13:04:01 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 EFE9C128AFB for <xml2rfc-dev@ietf.org>; Wed, 20 Feb 2019 13:03:57 -0800 (PST)
Received: from [192.168.178.124] ([84.171.147.151]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LtEtL-1h3HJ52AzD-012nqi; Wed, 20 Feb 2019 22:03:44 +0100
To: Tom Pusateri <pusateri@bangj.com>, Carsten Bormann <cabo@tzi.org>
Cc: xml2rfc-dev@ietf.org
References: <7AA856E3-834F-4E78-A5E8-02BB55D35D35@bangj.com> <CAA=duU2hP__MOJEEmRmm01R8KJ6Yi_kmC3+Lo-D2eCPDOTPLhg@mail.gmail.com> <16D888A3-0AAF-432C-9C43-BB7F2DA3BCAA@bangj.com> <54352830-048F-4EA9-907A-302646E703DA@tzi.org> <22C3BD1A-7393-472D-A519-4800981DCDDF@bangj.com> <1811BFA4-FDE1-4844-B704-BA770E75E889@tzi.org> <CA1153A5-9A91-451E-8B7A-E88A954C11E5@bangj.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <b7538db8-baaf-7185-7c30-f903908de8ec@gmx.de>
Date: Wed, 20 Feb 2019 22:03:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CA1153A5-9A91-451E-8B7A-E88A954C11E5@bangj.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:GfoI1FPogZHTn+734zngPe2FM/CQFdw2W4kQawWnw9Du0eDA1Bb N/+kMTVgdsFYnqwdGEaCFUL9b52p+SAjckCvYRH3BfPGck9Y/8Eo83TyPGDbKKuQondJFMJ uBv1l3SYE66frfsPq6wdA7o2F0U6Ed/U7jPtkdpX3+3aAFZo+F6O+zT88c64a3HH4esGUij nrLD2XZQDMLU29G/g+ivQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:8cTJr2HgDeE=:Z2dlr1s+yI5bmM0driwu8Y ixI0EqdO6PXXJ22PEcux0Xr0URKE6ORfGdruCFkquKD5Y37rKPcEIEhbkS88kdhsgJ8/I9HsR 3NByClpByjeLRVbPKGsDuAjNKGx6p+pKhwc2KkXr+5PhXQQ337i8GAWp2iireGmMr9qB7jYHd jZBehiLq3rEhDnO+YOwurhPp2YWPIXkCxRmtyWqQluqFwhWY68n0D8o1i2PKS6UOXINFRcKJ+ ierodWn3URZtf7upruU02zkb1TQHemFe34J+RmGbzKiu0DTABHcRtxsiyUHZfsfifeBvOVjBu BGBVrSo2VbxrZsQIoYr1ppBmlJMREypg12yNcTkGdQHmGIMJkbgvwzr/QG4bRNqpOo2kitEbk ZoRNuhUXeQC+lPJPf1CBjakiBdsG1wIQptPQBRb5Ea8qY++S+iyY5TS7Xk9jgryg1PEJYbfim E8mtqs3XQsHgvfU43DxVlTbRo0c3Y1FVHX0hxT6SXSPABNOksot8/W0gHwkF097ZsMnpASZ8s I7MMpWylXq6PD78OwNJN9kvGGzH2GpRwUGrAPt/7XQm5iAa4f/0r4blh7ZdAMr1WCjPr7Gx3w eP796k28SZ91hHAMpFTYB5TwUal0mlGlZNZtmESxGIKE8dkQ85O04NobLG7anfZiPBpCdr8zh rYsceenaSXjnGkRXydOBRfMhWitDSYCpTj+Jw396wCDC2+sQuCxfl32F1s8rX8WSgmvTnaJew lMePtUyyHEm8h126ntsxuh1rsGnx7ZOPYMlmv9GGE+bTCzXTatNFg0vk60cW2jc9dhjRDM+YU 6VqYU5GuILrElFR65M1LR/ibAia65/d20OUe0TyQqEP/S1ZApW5xhne2KExK4/hZa6aUhpQ1A 3XlcMK5s1WXO6xc8sHLwVytu4jNk6vC2bfefaepEPRWQFQrh0xdvhPFL4Aol99Kb5ajqIsEWv leNLMZfD7Jw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/xRbqW9LSdsBq0pGyS9um5gAn2wI>
Subject: Re: [xml2rfc-dev] v3 XML template feature request
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 21:04:03 -0000

On 20.02.2019 21:58, Tom Pusateri wrote:
> ...
> As a follow-up, there has arisen another reason that makes 
> kramdown-rfc2629, mmark.nl <http://mmark.nl>, and any other tools that 
> the RFC editor isn’t using less than ideal.
> 
> During an AUTH48 stage of publication for a draft I was a co-author that 
> used kdramdown-rfc2629, we got back from the RFC editor an edited XML 
> version that they wanted us to modify. Since the source was in Markdown, 
> by them switching the source to XML, we now lost all edit history moving 
> forward. We put their XML version in our github repository but now all 
> future edits have to use their XML file.
> 
> Separately, they continue to email back and forth edits and so trying to 
> keep a repository of XML changes alone is a problem…
> ...

You could replay all editorial changes in the markdown source.

Best regards, Julian (yes; I've done that before)


From nobody Wed Feb 20 15:56:01 2019
Return-Path: <ietf@augustcellars.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6A2130E58 for <xml2rfc-dev@ietfa.amsl.com>; Wed, 20 Feb 2019 15:56:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 rAzJgd1BHnzt for <xml2rfc-dev@ietfa.amsl.com>; Wed, 20 Feb 2019 15:55:57 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264D1130E2F for <xml2rfc-dev@ietf.org>; Wed, 20 Feb 2019 15:55:57 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Feb 2019 15:55:49 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Julian Reschke' <julian.reschke@gmx.de>, 'Henrik Levkowetz' <henrik@levkowetz.com>, 'Martin Thomson' <mt@lowentropy.net>, <xml2rfc-dev@ietf.org>
References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <CAA=duU3fm2RndMLa2_Ve14TTOr8+sBy4RqMTx1=bLWcru_nAaw@mail.gmail.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> <CAA=duU1A6vZCu95H4+VNoZFseQX_EuOsELEWzNkoo06+TE70WA@mail.gmail.com> <87d4d97e-895a-60af-1000-da0d3b0d4a86@nostrum.com> <30331fdb-f251-1832-9a83-9ba90fccd6c6@levkowetz.com> <17f4d963-22b2-aea6-e4d5-708e5463cd03@gmx.de> <f9fae5da-c416-0f69-6dbf-6f6a4c8c51c8@gmx.de> <1549841265.459295.1655094368.4678F636@webmail.messagingengine.com> <8d5b8c13-50cf-99cd-0301-ddc69931c942@gmx.de> <1549865175.1196409.1655262320.60204ABE@webmail.messagingengine.com> <03353990-6d40-85ab-b914-210fca26814a@levkowetz.com> <ffbdcb63-6f5e-15c0-c90f-ef797f6dacba@gmx.de> <c16b9fbe-b2b0-e181-aafb-5b98930e1403@levkowetz.com> <bf22d92e-088f-8 ef8-f5cb-2ada2ecde0e2@gmx.de>
In-Reply-To: <bf22d92e-088f-8ef8-f5cb-2ada2ecde0e2@gmx.de>
Date: Wed, 20 Feb 2019 15:55:49 -0800
Message-ID: <02cf01d4c977$cffd9260$6ff8b720$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKLEbo+pzPHjNpzoGOJ/fuKthp+uAJvt3qQAiazKCECmis6ygGDH8tGAMtkcjQBjLf0ZQJh2AivAk4AGBkBru0HygI//VdBAniaKTMBhiAVJgJRpCcfAbVqOU8CoozhgAG+nLVDAfo4qeMB9LKSBqNcxYCQ
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/vJGWz9m6RVDBrDzbcBudwf8eDds>
Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions into the repository (was Re: Alternate artwork vocabulary and post preptool)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 23:56:00 -0000

> -----Original Message-----
> From: xml2rfc-dev <xml2rfc-dev-bounces@ietf.org> On Behalf Of Julian
> Reschke
> Sent: Monday, February 11, 2019 4:19 AM
> To: Henrik Levkowetz <henrik@levkowetz.com>; Martin Thomson
> <mt@lowentropy.net>; xml2rfc-dev@ietf.org
> Subject: Re: [xml2rfc-dev] [rfc-i] Preparing for allowing v3 submissions
into
> the repository (was Re: Alternate artwork vocabulary and post preptool)
> 
> On 11.02.2019 12:21, Henrik Levkowetz wrote:
> >
> > On 2019-02-11 09:49, Julian Reschke wrote:
> >> On 11.02.2019 08:12, Henrik Levkowetz wrote:
> >>> Hi Martin,
> >>>
> >>> On 2019-02-11 07:06, Martin Thomson wrote:
> >>>> On Mon, Feb 11, 2019, at 16:35, Julian Reschke wrote:
> >>>>> That said, what will be more common? Plain text equivalent
> >>>>> authored as part of the RFC source, or as part of the SVG source?
> >>>>
> >>>> I tend to do ASCII art inline, but a separate file for SVG seems
> >>>> most likely, due to SVG tools being better at handling that.  That
> >>>> suggests SVG link, text fallback.  But I can equally see both being
> >>>> external.  If "artwork" could be either inlined or externally
> >>>> sourced for both types, that would be ideal.
> >>>
> >>> That is already the plan with the proposal worked out in November,
> >>> quoted in Robert's original post, which I'm implementing.  No worries
> needed.
> >>
> >> Once again: can we please consider something simpler? The proposal
> >> IMHO complicates the grammar in a way that is not needed.
> >
> > I'm working on what was agreed on in November:
> >
> > <artgroup>
> >    <artwork>
> >    </artwork>
> >    <artwork>
> >    </artwork>
> > </artgroup>
> 
> How does a processor decide which of the enclosed artwork elements to
> render? What's the algorithm?
> 
> >> I think the simplest possible fix is something like:
> >>
> >>> <artwork>
> >>>    <text-equivalent>
> >>>
> >>>    </text-equivalent>
> >>>    <svg:svg>
> >>>      ...
> >>>    </svg:svg>
> >>> <artwork>
> >
> > I don't see how it would be simpler.  The only I see with this is that
> > it reopens the discussion that ended in an acceptable solution in
> November.
> 
> I just explained why it's simpler, didn't I?
> 
> <artgroup> requires changes all over the place as it fundamentally changes
> the grammar. For instance, it creates new issues with
> referenceability: what if prose has an <xref> to an <artwork> element
which
> will not actually be output by the renderer (such as the plain text
variant in
> HTML, or the SVG variant in plain text?).
> 
> Yes, questions like this can be solved, but they need to, and I just don't
see
> why we need this complexity if a much simpler approach is available.

I think that easier is sometimes in the eye of the beholder.   I would not
like to see <text-equivalent> here because that would indicate something
completely different for me.  

One the questions that I raised as part of the original discussions was the
question of are there potentially going to be other formats that need to be
inserted, in which case the more uniform the better.  One possible format
that I was thinking about at the time was a more friendly version for
someone who was blind which was an actual text description of the picture
rather than something which is ASCII art.  This would be something along the
lines of:

This is a protocol flow diagram.  There are three vertical lines from left
to right for the 'client', the 'authorization server (AS)' and the 'resource
server (RS)'.  The first horizontal line gores from 'client' to 'RS' and has
the comment 'client asks to get resource foo'.   And so forth.

Having to add a new element to this object in the RNG every time something
is added seems to be potentially more work in the future and thus maybe even
worse than adding the extra semantics now.

Jim

> 
> Best regards, Julian
> 
> 
> _______________________________________________
> xml2rfc-dev mailing list
> xml2rfc-dev@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev


From nobody Tue Feb 26 13:24:07 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D6D129A87; Tue, 26 Feb 2019 13:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 2gnVZyRDPmqW; Tue, 26 Feb 2019 13:24:03 -0800 (PST)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7168E12941A; Tue, 26 Feb 2019 13:24:03 -0800 (PST)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1gykCp-0004a5-4w; Tue, 26 Feb 2019 13:24:03 -0800
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1gykCp-0004a5-4w@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Tue, 26 Feb 2019 13:24:03 -0800
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/PDBFf11w4ipg6IMCjDg0tSzUet0>
Subject: [xml2rfc-dev] New xml2rfc release: v2.20.0
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2019 21:24:05 -0000

Hi,

This is an automatic notification about a new xml2rfc release, 
v2.20.0, generated when running the mkrelease script.

Release notes:

xml2rfc (2.20.0) ietf; urgency=medium

  This release changes the rendering of <xref> elements with text content by
  v3 formatters, and reintroduces <xref format="none"> under v3 in order to
  properly cover the combinatorial space of rendering of <xref> with and
  without text content.  It fixes a number of issues, including a somewhat
  unexpected issue with namespace normalization, and improves the rendering
  output in some edge cases.  More details from the commit log:

  * Removed namespace cleanup and normalisation during the v2v3 conversion, 
    as it can have negative effects for inlined <svg> when the SVG namespace is 
    specified in multiple places.

  * Changed handling of reference//author entries with fullname but without
    initials and surname in order to derive those the same way for references
    as it's done in other places.

  * Dropped support for Py34.  Support is now Py27 (untill end 2019), and
    Python 3.5 - 3.7.

  * Tweaked the CSS for bcp14 keyword elements.

  * Fixed a problem where a temporary valuable name stomped on a 
    method-wide name.

  * Fixed a problem where <xref> "relative" attributes were treated as 
    fragment identifiers instead of as relative URL paths.

  * Improved the placeholder text emitted by the v3 text renderer for 
    artwork without ascii-art.

  * Removed stripping of the now (again) functional <xref> format value "none"
    from the v2v3 converter.

  * Tweaked the rendering of <xref> having both derivedContent (section 
    information, for instance) and text content, to generate hyperlinks to the 
    xref target for both of them.  Simplified the html renderer by eliminating 
    extra code for <relref>, now covered by the generic <xref> code.

  * Fixed a problem with a missing hash character between path and fragment 
    identifiers in derivedLink generation.

  * Added a conversion of <relref> elements to the generic <xref> form to 
    preptool.  Tweaked a debug print statement.

  * Added An SVG diagram of the processing flow for v2 and v3 documents, used
    by xml2rfc3.rst, to doc/

  * Added an rST-formatted Introduction to xml2rfc version 3 to doc/

 -- Henrik Levkowetz <henrik@levkowetz.com>  26 Feb 2019 13:22:09 -0800

The preferred way to install xml2rfc is by doing 'pip install xml2rfc',
and 'pip install --upgrade xml2rfc' to upgrade.  If there are system-
installed python modules which pip will not upgrade, you may have to
use 'pip install --upgrade --no-deps xml2rfc' and install dependencies
manually.

The new version is also available through SVN checkout, with
  'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.20.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Wed Feb 27 05:15:13 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAE0130FCA; Wed, 27 Feb 2019 05:15:11 -0800 (PST)
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, URIBL_BLOCKED=0.001] autolearn=ham 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 pskhc5SGM6OJ; Wed, 27 Feb 2019 05:15:08 -0800 (PST)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD741130FC5; Wed, 27 Feb 2019 05:15:08 -0800 (PST)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1gyz3E-0002n4-NM; Wed, 27 Feb 2019 05:15:08 -0800
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1gyz3E-0002n4-NM@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Wed, 27 Feb 2019 05:15:08 -0800
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/kHWm5kxi_GtkfNQ2CykIx3WQOUg>
Subject: [xml2rfc-dev] New xml2rfc release: v2.20.1
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 13:15:12 -0000

Hi,

This is an automatic notification about a new xml2rfc release, 
v2.20.1, generated when running the mkrelease script.

Release notes:

xml2rfc (2.20.1) ietf; urgency=medium

  * Handle initials==Null return value from short_author_name_parts().  
    Fixes issue #397

 -- Henrik Levkowetz <henrik@levkowetz.com>  27 Feb 2019 13:11:06 +0000

The preferred way to install xml2rfc is by doing 'pip install xml2rfc',
and 'pip install --upgrade xml2rfc' to upgrade.  If there are system-
installed python modules which pip will not upgrade, you may have to
use 'pip install --upgrade --no-deps xml2rfc' and install dependencies
manually.

The new version is also available through SVN checkout, with
  'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.20.1'

Regards,

	Henrik
	(via the mkrelease script)