
From nobody Sun Sep  1 03:41:12 2019
Return-Path: <trac@tools.ietf.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD3912011E for <xml2rfc@ietfa.amsl.com>; Sun,  1 Sep 2019 03:41:10 -0700 (PDT)
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, SPF_HELO_NONE=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 RbXTvP9Oy7Lh for <xml2rfc@ietfa.amsl.com>; Sun,  1 Sep 2019 03:41:09 -0700 (PDT)
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 10070120052 for <xml2rfc@ietf.org>; Sun,  1 Sep 2019 03:41:09 -0700 (PDT)
Received: from localhost ([::1]:57281 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1i4NI0-0001pv-JM; Sun, 01 Sep 2019 03:41:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "xml2rfc issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Cc: xml2rfc@ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: julian.reschke@gmx.de
X-Trac-Project: xml2rfc
Date: Sun, 01 Sep 2019 10:40:54 -0000
X-URL: http://tools.ietf.org/tools/xml2rfc/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/403#comment:1
Message-ID: <084.393d1e83623036b2f6a1c64ed434203b@tools.ietf.org>
References: <069.e2f39b44150eb14a42542b1878514edc@tools.ietf.org>
X-Trac-Ticket-ID: 403
In-Reply-To: <069.e2f39b44150eb14a42542b1878514edc@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: julian.reschke@gmx.de, xml2rfc@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/vMCIO8_uaLm3jIGIA3vlPK0sekM>
Subject: Re: [xml2rfc] #403 (Version_3_cli_txt): HTAB in artwork/sourcecode is accepted
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Sep 2019 10:41:11 -0000

#403: HTAB in artwork/sourcecode is accepted


Comment (by julian.reschke@gmx.de):

 The example file (elements.xml) apparently was fixed in
 <https://trac.tools.ietf.org/tools/xml2rfc/trac/changeset/3236/trunk/cli/tests/input/elements.xml>.

 I haven't checked whether xml2rfv now also rejects TABs in sourcecode.

-- 
------------------------------------+--------------------
  Reporter:  julian.reschke@gmx.de  |      Owner:
      Type:  defect                 |     Status:  new
  Priority:  medium                 |  Milestone:
 Component:  Version_3_cli_txt      |    Version:  2.22.*
Resolution:                         |   Keywords:
------------------------------------+--------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/403#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>


From nobody Sun Sep  1 09:51:50 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42B712002F; Sun,  1 Sep 2019 09:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQYqQQ89QpWO; Sun,  1 Sep 2019 09:51:34 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D01120025; Sun,  1 Sep 2019 09:51:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567356675; bh=kCaZs7ndxP9PTOjLMGsqI7RPRXc/+n9XT83/wUSr03A=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ZfVS+L6vyb9sCfcQe5o6atm5XBrr58qZF4Tmd/AwkO/1NujTCoNsA/Xcnb7DQIQSH vN5dx02Y3Xbmh6iiJI2fKmwYIFKtzQ7RnxADlarcyE2xQpLwVWY8+xtqUmtikGH1h3 oMJDZIlz3CMzybmcR0mRv9r/LpniX1nO8UFQe1R0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.132.77]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MbfnB-1hncVa25Lh-00J2NR; Sun, 01 Sep 2019 18:51:15 +0200
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
References: <E1hwTDm-00064V-6E@durif.tools.ietf.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <add95758-94ee-00cc-74af-70629c962097@gmx.de>
Date: Sun, 1 Sep 2019 18:51:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <E1hwTDm-00064V-6E@durif.tools.ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:IHfD2Zbp8fdBDhcqFeYnlsEuEQEXDy10fNROrDfTRxnJevs0PQP tvCslaBFzMY1aI3t1XoVEfLeU512QFieog3OOXHXHi/ID8jbEBSaw4rdlDCAkjyOVGOMKbd 099TobP8DnAlJRIL3aHa/EhY96okeeIuNCF8Ou3LlVpo4D9F7+AQg1AtVejGaR0+XmsRtaQ s6DDSPmzi0MQSUsLOBSEg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Tr4kVaXwi2c=:1dhdq+ptk1kv7OmLpZAmml TurKkcexw9PaiE697BT4qImwQL5MyhVHSrOw+uswBJ1z8TNrMd6tq24uvuJ8gHwoftbMRteGT qc1ZVeTz2gFdE6ZsMmq6yVl/fG/FCQEDcU8Ox0wsQCQ9cHfn/N/QAd/jrz13eFJREaGcN37FG 2R0N09OJie8YFe51Vog1sPeSbZneT19iRfFAqf1gqMz5P9vQvYYwPGBxXi+Y96RgfI/WRwsXe ghXmU22bL/oZ1BlZptJ5eReK2eBXySRo206UWwNSs+7u9u/7QG7p0OONwBaNMgAsWdbDKe6aR bXVkHuOzXViBCjdHAzN72/zWQ4oEjGM2hfCmIISDMFwG0LlG+Hux1mAw9lcDlILk3K5E0oHdp muPZpzHizCAB73AMG+8/S2ncrd5VsjaTe9PtknAFhy4Ea0ILuLiOnDRwYvmLb0NT9OSl0qRP3 0/1fdTzmxUA3VvHGWL+CBAQWfKqJpAby4Slgh/SAF+gXj5QqYS3GWiILV5gRfKyiEFAYVLumP enxkaDH1gXHytBnp2Q2B9Wdg7cDWzVlAEbC9txB8WzW48wMMOeH/EVPsGHoaob5YuOv/LkDRK 1DbdOLn7/XB2iGDsTmO5DUnWharjlFTS1M5oBnYUbolnR179cG/rbYdiqT3guYX2KnBdOsDD6 IUBaRvuA55u/F2P1RcUUir3XXkguTrshtR+YQYE/GevuSTjooFPKjnojPGglEeGa88bVRWVyq eofnIGTAgGiLEJhMybZbMFuMqe1tJP/RZGwQURglln0JgNjNSxOSYerg1mQvVTOSjzbnreWW5 fOn+ofgoW3rdst8dyGU6mmHssQR6z1z9bjGmSL9gkEn760IlXSP1ezPWbSS2wr7paEYM02csI ijWqHySlil2dHkD/FJdifcFtbnZY8K+++s0HhQozAT5W/rkRlYd8hF/HPUPdzbwHBb7tIB3hw A6+ash5x+LSwqIpb+O+15wpdbEhj8zOa9aXn8T+ckR05/vV1K7w4v4IXbBN0OWSAKTddcI41D n8xhiYMNFJlcE7CGNk3Fmgh0GdWoLgXCW+y+iJwSaU2lu/rAPzY/pKkZat0bsZgkrzM/OSqJC GRg/yzmvPMrb9uBHeErhkr/gMsjHrQ+u76gJZj3xQ+CjdnIMIV0Qzb0JW6JmGFjyttU26Sln3 5F5GwcZXSYrwzLwnSMniIIeHShiru6UVuwroGHeYKviVVZMQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/xTWRCfoGVzrnvQ3SAK5uW6oTdFE>
Subject: [xml2rfc] vague dates, was:  New xml2rfc release: v2.24.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Sep 2019 16:51:37 -0000

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

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

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

That said, we should clarify:

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

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

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

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

Final thoughts:

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

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

Best regards, Julian


From nobody Sun Sep  1 19:11:16 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4DF1200E6 for <xml2rfc@ietfa.amsl.com>; Sun,  1 Sep 2019 19:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 crs1_ed5DUd4 for <xml2rfc@ietfa.amsl.com>; Sun,  1 Sep 2019 19:11:11 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA35A12001B for <xml2rfc@ietf.org>; Sun,  1 Sep 2019 19:11:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2E25060945 for <xml2rfc@ietf.org>; Sun,  1 Sep 2019 22:11:10 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3OEFr0QgUmZg for <xml2rfc@ietf.org>; Sun,  1 Sep 2019 22:11:03 -0400 (EDT)
Received: from lx140e.htt-consult.com (ip70-161-203-70.hr.hr.cox.net [70.161.203.70]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A931B6081A for <xml2rfc@ietf.org>; Sun,  1 Sep 2019 22:10:56 -0400 (EDT)
To: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com>
Date: Sun, 1 Sep 2019 22:10:52 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/H415v0u169FPSZlstFBg2Gc6gJc>
Subject: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 02:11:14 -0000

Are there references for NIST FIPS202 and SP800-185?

I went browsing https://xml2rfc.tools.ietf.org/ and did not find much of 
anything for NIST docs.  (NIST-500?).

Right now I am having to include:

<reference anchor="NIST.FIPS.202" 
target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">
     <front>
     <title>SHA-3 Standard:  Permutation-Based Hash and 
Extendable-Output Functions</title>
     <author initials="M." surname="Dworkin" fullname="Morris J. Dworkin">
     <organization>National Institute of Standards and 
Technology</organization>
     </author>
     <date month="August" year="2015"/>
     </front>
     <seriesInfo name="FIPS" value="PUB 202"/>
     <seriesInfo name="DOI" value="10.6028/nist.fips.202"/>
</reference>
<reference anchor="NIST.SP.800_185" 
target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf">
     <front>
     <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and 
ParallelHash</title>
     <author initials="J." surname="Kelsey" fullname="John Kelsey">
     <organization>National Institute of Standards and 
Technology</organization>
     </author>
     <author initials="S." surname="Change" fullname="Shu-jen Change">
     <organization>National Institute of Standards and 
Technology</organization>
     </author>
     <author initials="R." surname="Perlner" fullname="Ray Perlner">
     <organization>National Institute of Standards and 
Technology</organization>
     </author>
     <date month="December" year="2016"/>
     </front>
     <seriesInfo name="Special Publication" value="SP 800-185"/>
     <seriesInfo name="DOI" value="10.6028/nist.sp.800-185"/>
</reference>

thanks


From nobody Mon Sep  2 00:47:14 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345F41200F8 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 00:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 sE70oFnfU3ty for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 00:47:10 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4256E1200E9 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 00:47:10 -0700 (PDT)
Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MMcD2JYdzyVf; Mon,  2 Sep 2019 09:47:08 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com>
Date: Mon, 2 Sep 2019 09:47:07 +0200
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
X-Mao-Original-Outgoing-Id: 589103226.200201-283bb42f4b035b5c9c3d4979827e5e81
Content-Transfer-Encoding: quoted-printable
Message-Id: <B345B8F3-E21D-42D0-8D10-D90E1FCB80B6@tzi.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com>
To: Robert Moskowitz <rgm@htt-consult.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/lEVoNgFg45lTxkFurtSItr2cIGo>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 07:47:13 -0000

> On Sep 2, 2019, at 04:10, Robert Moskowitz <rgm@htt-consult.com> =
wrote:
>=20
> Are there references for NIST FIPS202 and SP800-185?

These have DOIs.  So in kramdown-rfc, you could reference these as

{{!NIST.FIPS.202=3DDOI.10.6028/nist.fips.202}} and =
{{?NIST.SP.800_185=3DDOI.10.6028/nist.sp.800-185}} (where ! is for =
normative and ? is for informative).  You can of course also put these =
into the YAML prefix.

With stand_alone: yes, kramdown-rfc does the external loading.  With =
stand_alone: no (i.e., load the references from XML), kramdown-rfc =
generates this XML for the above input:

In the document subset:

<!ENTITY DOI.10.6028_nist.fips.202 SYSTEM =
"https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/n=
ist.fips.202.xml?anchor=3DNIST.FIPS.202">
<!ENTITY DOI.10.6028_nist.sp.800-185 SYSTEM =
"https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/n=
ist.sp.800-185.xml?anchor=3DNIST.SP.800_185">

In the references section, normative part:
&DOI.10.6028_nist.fips.202;
In the references section, informative part:
&DOI.10.6028_nist.sp.800-185;

In the (no longer so self-explanatory :-) text:
<xref target=3D"NIST.FIPS.202"/> and <xref target=3D"NIST.SP.800_185"/> =
(where ! is for normative and ? is for informative).  You can of course =
also put these into the YAML prefix.

Gr=C3=BC=C3=9Fe, Carsten


>=20
> I went browsing https://xml2rfc.tools.ietf.org/ and did not find much =
of anything for NIST docs.  (NIST-500?).
>=20
> Right now I am having to include:
>=20
> <reference anchor=3D"NIST.FIPS.202" =
target=3D"http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">
>     <front>
>     <title>SHA-3 Standard:  Permutation-Based Hash and =
Extendable-Output Functions</title>
>     <author initials=3D"M." surname=3D"Dworkin" fullname=3D"Morris J. =
Dworkin">
>     <organization>National Institute of Standards and =
Technology</organization>
>     </author>
>     <date month=3D"August" year=3D"2015"/>
>     </front>
>     <seriesInfo name=3D"FIPS" value=3D"PUB 202"/>
>     <seriesInfo name=3D"DOI" value=3D"10.6028/nist.fips.202"/>
> </reference>
> <reference anchor=3D"NIST.SP.800_185" =
target=3D"http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800=
-185.pdf">
>     <front>
>     <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and =
ParallelHash</title>
>     <author initials=3D"J." surname=3D"Kelsey" fullname=3D"John =
Kelsey">
>     <organization>National Institute of Standards and =
Technology</organization>
>     </author>
>     <author initials=3D"S." surname=3D"Change" fullname=3D"Shu-jen =
Change">
>     <organization>National Institute of Standards and =
Technology</organization>
>     </author>
>     <author initials=3D"R." surname=3D"Perlner" fullname=3D"Ray =
Perlner">
>     <organization>National Institute of Standards and =
Technology</organization>
>     </author>
>     <date month=3D"December" year=3D"2016"/>
>     </front>
>     <seriesInfo name=3D"Special Publication" value=3D"SP 800-185"/>
>     <seriesInfo name=3D"DOI" value=3D"10.6028/nist.sp.800-185"/>
> </reference>
>=20
> thanks
>=20
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc
>=20
>=20


From nobody Mon Sep  2 04:28:12 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCCD120142 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 04:28:09 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 DBysXuw2afVe for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 04:28:07 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC52712013D for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 04:28:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6D0656080C; Mon,  2 Sep 2019 07:28:06 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 96mzTJOkUggs; Mon,  2 Sep 2019 07:28:02 -0400 (EDT)
Received: from lx140e.htt-consult.com (ip70-161-203-70.hr.hr.cox.net [70.161.203.70]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id B78DF620EE; Mon,  2 Sep 2019 07:27:56 -0400 (EDT)
To: Carsten Bormann <cabo@tzi.org>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <B345B8F3-E21D-42D0-8D10-D90E1FCB80B6@tzi.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <5df02043-b500-7ba5-124c-60f41f4f2968@htt-consult.com>
Date: Mon, 2 Sep 2019 07:27:54 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <B345B8F3-E21D-42D0-8D10-D90E1FCB80B6@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/KsiqkrDVduv580y8AZZBLwNMXuI>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 11:28:10 -0000

On 9/2/19 3:47 AM, Carsten Bormann wrote:
>
>> On Sep 2, 2019, at 04:10, Robert Moskowitz <rgm@htt-consult.com> wrote:
>>
>> Are there references for NIST FIPS202 and SP800-185?
> These have DOIs.  So in kramdown-rfc, you could reference these as
>
> {{!NIST.FIPS.202=DOI.10.6028/nist.fips.202}} and {{?NIST.SP.800_185=DOI.10.6028/nist.sp.800-185}} (where ! is for normative and ? is for informative).  You can of course also put these into the YAML prefix.
>
> With stand_alone: yes, kramdown-rfc does the external loading.  With stand_alone: no (i.e., load the references from XML), kramdown-rfc generates this XML for the above input:
>
> In the document subset:
>
> <!ENTITY DOI.10.6028_nist.fips.202 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202">
> <!ENTITY DOI.10.6028_nist.sp.800-185 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/nist.sp.800-185.xml?anchor=NIST.SP.800_185">
>
> In the references section, normative part:
> &DOI.10.6028_nist.fips.202;
> In the references section, informative part:
> &DOI.10.6028_nist.sp.800-185;
>
> In the (no longer so self-explanatory :-) text:
> <xref target="NIST.FIPS.202"/> and <xref target="NIST.SP.800_185"/> (where ! is for normative and ? is for informative).  You can of course also put these into the YAML prefix.
>
>

Now I am trying to translate this into what I do in xml for rfcs.

In the body I have:

<xref target="RFC7748">RFC 7748</xref>

And it the reference section:

<?rfc include="reference.RFC.7748.xml"?>

So I guessed:

<xref target="DOI.10.6028_nist.sp.800-185">NIST SP 800-185</xref>

<?doi include="DOI.10.6028_nist.sp.800-185"?>


But that did not work.

I then tried ?rfc rather than ?doi and got the same error:

Error: Unable to parse the XML document: 
draft-moskowitz-hip-new-crypto-00.xml
  draft-moskowitz-hip-new-crypto-00.xml: Line 320: Unable to resolve 
external request: "DOI.10.6028_nist.sp.800-185"

Note that for rfcs and drafts, I do not need any entity includes in the 
document subset..

thanks


From nobody Mon Sep  2 04:37:43 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F3112018B for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 04:37:37 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvAFXBApuW2n for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 04:37:35 -0700 (PDT)
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 EA7281201E0 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 04:37:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567424235; bh=sQ5QMktVbep36ChWWExt5v4gULqyVK5+WEcpPbRHGo8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=eA/zCpdazR7xPAhIngmkbPTNGrmc8eK9BAapMTnLryqvRd+hWDtpihy6tS67FKZ64 8Xwi9P64h7lcnWrqjRIkFG6he2NJd9PM5khuaoJWmEH6FZHxqBWM7/vVUJD6nFFhA+ 5BYIISRDqTx28gvC5RfIxjzWFHofQ0KayMV++oHM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MOSNd-1i8J1K2fET-005tV9; Mon, 02 Sep 2019 13:37:15 +0200
To: Robert Moskowitz <rgm@htt-consult.com>, Carsten Bormann <cabo@tzi.org>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <B345B8F3-E21D-42D0-8D10-D90E1FCB80B6@tzi.org> <5df02043-b500-7ba5-124c-60f41f4f2968@htt-consult.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <9552b18a-5514-3090-f1dd-f8d4785bb4bb@gmx.de>
Date: Mon, 2 Sep 2019 13:37:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <5df02043-b500-7ba5-124c-60f41f4f2968@htt-consult.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:n0AcwMYT9zsVW6Gtf+o8tjCfk1up3gvlKdiL+u8HU1y7CIbN/N3 iyRbmrGhkkjj+wMPI89dKkcaQj8eKmTQ2r6HNWB4RZnwsCPJlj9O/s8+pHqk6eSAwX8WWPg YpnNb8Jv94levzt7RqHWclExRm9aSZLD/hEoRWhHAnpegYZM4ZBNb6VawjWYJGh/aFpsl3P 1bCu+cvQe6iUHqf9+eiZQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:F6KuhbQl5wk=:pA6cMIutge8g24jSRO6Y+0 BrBrgAoCclk0Gx9Ew8ejBrfYRgYLYB3WeQS8YIhi59EkcWLPEEi3McQiGixPxBLuLwmsl0DLQ F5/+0MdgcQPZ8DF0lzTw85w0O8shuvyZ+xPwofZ3eWb3rZcHem3x1plhLHMrRJuCiNhdNS5t9 +QakJC4CPtxPEEkM0S3mKp+6ocSl6pNesd0+Dn3Q3/UrrdKsEpARGW9Kg8u/1nPqv5sVbrjX3 32O83R6V0p6zL3DJ6HL4lLg8YzGdlu9VuU5DXdJpyykWBAiwoOUsGGK4/gDUa7W2oPeGZMubt W5PpVclEYhosL4PsT4CaykQyipwLYaMsJEykE7gL67SaU4BOwDHpr01aATXPRwWQJhK163os+ xgYq3TC0vrR1Ytcty3AeF8sfv6ZQsuwHl7vrDNAPtYoU2nzYxkgvcRFO2oHw/3GDlfamv4I0X 0PR+wxc0QtiGcVc5MZGae+MpeXyrE8teFVjaZGP2Rsahq9BWPYZ5SH7zb85RMjfVUch0bfOac JT0ewNW3J4afNUV18qZIsNXWeRHB/036J6+hH8xKPzYrM6c6shAbzjZVcMGHgGLDDsF5NjwdW HaMQQi+5hArbvwo85Wo4p2qL+fs86sAmViYxI64XIEhR8U32nQVJcYlfTnjKVxxwAkY4ueR1Q ClDZ79vKDA1UC/Je9alVzMnQb870JGFFfkBv+lyNrzOG6LDTtoY9d5+KeG3GLlNy7xQT6ft3S 2oJ9fgM+AkctWU1jjIDShplQ6+VoMuYKnUGvn2BXg/E8+5BDbwl2JWQra1G6ShwhlTKJDGLgD epEPG/a9QYAr+DsRYquTrknmKM8J2XwRop4VhS1SD6PrY6Ov6l8q+Ia3eoKwgOOAlXOTzeY2y cWnItOe++6Jiz7KvALHzxap3pY58BvQvc9Wv1Kv0qej8e6guf2BmV0t6GxzRJoI+h+vco+FKF JD/VLDXSqayIhjFpDyHZ6R3qdCxKDeCColH4IZIIls8txcXBpENNOLimtbsK2odTnR/UXOBiX 0jDPjgkkh/bNehyT3TSh5hy28Izz6CH/3kpvICLB0H13Zr9E2kQPAqesQC6m0wEHPlNM2E/DN jdPY1UWdCYMWiGwOWwOLaEOxPEOlSGfAa9qhS3C7LitnnuGzNVXbqXIydX+raYEKEVPEYmuo3 3vUrSLYKOCFQn1l0YNGzkJvUslBlzCLX7N+8erSt2i8VFYSw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/61WDKhenTA3tRL_pPDYhxtM_ugE>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 11:37:41 -0000

On 02.09.2019 13:27, Robert Moskowitz wrote:
>
>
> On 9/2/19 3:47 AM, Carsten Bormann wrote:
>>
>>> On Sep 2, 2019, at 04:10, Robert Moskowitz <rgm@htt-consult.com> wrote=
:
>>>
>>> Are there references for NIST FIPS202 and SP800-185?
>> These have DOIs.=C2=A0 So in kramdown-rfc, you could reference these as
>>
>> {{!NIST.FIPS.202=3DDOI.10.6028/nist.fips.202}} and
>> {{?NIST.SP.800_185=3DDOI.10.6028/nist.sp.800-185}} (where ! is for
>> normative and ? is for informative).=C2=A0 You can of course also put t=
hese
>> into the YAML prefix.
>>
>> With stand_alone: yes, kramdown-rfc does the external loading.=C2=A0 Wi=
th
>> stand_alone: no (i.e., load the references from XML), kramdown-rfc
>> generates this XML for the above input:
>>
>> In the document subset:
>>
>> <!ENTITY DOI.10.6028_nist.fips.202 SYSTEM
>> "https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.602=
8/nist.fips.202.xml?anchor=3DNIST.FIPS.202">
>>
>> <!ENTITY DOI.10.6028_nist.sp.800-185 SYSTEM
>> "https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.602=
8/nist.sp.800-185.xml?anchor=3DNIST.SP.800_185">
>>
>>
>> In the references section, normative part:
>> &DOI.10.6028_nist.fips.202;
>> In the references section, informative part:
>> &DOI.10.6028_nist.sp.800-185;
>>
>> In the (no longer so self-explanatory :-) text:
>> <xref target=3D"NIST.FIPS.202"/> and <xref target=3D"NIST.SP.800_185"/>
>> (where ! is for normative and ? is for informative).=C2=A0 You can of
>> course also put these into the YAML prefix.
>>
>>
>
> Now I am trying to translate this into what I do in xml for rfcs.
>
> In the body I have:
>
> <xref target=3D"RFC7748">RFC 7748</xref>
>
> And it the reference section:
>
> <?rfc include=3D"reference.RFC.7748.xml"?>
>
> So I guessed:
>
> <xref target=3D"DOI.10.6028_nist.sp.800-185">NIST SP 800-185</xref>
>
> <?doi include=3D"DOI.10.6028_nist.sp.800-185"?>
> ...

The *rfc* include directive takes a URI, just see those that Carsten poste=
d.

Best regards, Julian


From nobody Mon Sep  2 05:05:19 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3E3120123 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 05:05:18 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 UD9AHHA784J8 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 05:05:15 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D46412011C for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 05:05:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0B03460945; Mon,  2 Sep 2019 08:05:14 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3p8kSKe5Dfzk; Mon,  2 Sep 2019 08:05:09 -0400 (EDT)
Received: from lx140e.htt-consult.com (ip70-161-203-70.hr.hr.cox.net [70.161.203.70]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 05EE96080C; Mon,  2 Sep 2019 08:05:08 -0400 (EDT)
To: Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <cabo@tzi.org>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <B345B8F3-E21D-42D0-8D10-D90E1FCB80B6@tzi.org> <5df02043-b500-7ba5-124c-60f41f4f2968@htt-consult.com> <9552b18a-5514-3090-f1dd-f8d4785bb4bb@gmx.de>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <5e1be54b-53c5-55fa-1906-459ef335afd3@htt-consult.com>
Date: Mon, 2 Sep 2019 08:05:03 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <9552b18a-5514-3090-f1dd-f8d4785bb4bb@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/7oD4zq9RxSD3aNU7av0XwTrDvNs>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 12:05:18 -0000

On 9/2/19 7:37 AM, Julian Reschke wrote:
> On 02.09.2019 13:27, Robert Moskowitz wrote:
>>
>>
>> On 9/2/19 3:47 AM, Carsten Bormann wrote:
>>>
>>>> On Sep 2, 2019, at 04:10, Robert Moskowitz <rgm@htt-consult.com> 
>>>> wrote:
>>>>
>>>> Are there references for NIST FIPS202 and SP800-185?
>>> These have DOIs.  So in kramdown-rfc, you could reference these as
>>>
>>> {{!NIST.FIPS.202=DOI.10.6028/nist.fips.202}} and
>>> {{?NIST.SP.800_185=DOI.10.6028/nist.sp.800-185}} (where ! is for
>>> normative and ? is for informative).  You can of course also put these
>>> into the YAML prefix.
>>>
>>> With stand_alone: yes, kramdown-rfc does the external loading.  With
>>> stand_alone: no (i.e., load the references from XML), kramdown-rfc
>>> generates this XML for the above input:
>>>
>>> In the document subset:
>>>
>>> <!ENTITY DOI.10.6028_nist.fips.202 SYSTEM
>>> "https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202"> 
>>>
>>>
>>> <!ENTITY DOI.10.6028_nist.sp.800-185 SYSTEM
>>> "https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/nist.sp.800-185.xml?anchor=NIST.SP.800_185"> 
>>>
>>>
>>>
>>> In the references section, normative part:
>>> &DOI.10.6028_nist.fips.202;
>>> In the references section, informative part:
>>> &DOI.10.6028_nist.sp.800-185;
>>>
>>> In the (no longer so self-explanatory :-) text:
>>> <xref target="NIST.FIPS.202"/> and <xref target="NIST.SP.800_185"/>
>>> (where ! is for normative and ? is for informative).  You can of
>>> course also put these into the YAML prefix.
>>>
>>>
>>
>> Now I am trying to translate this into what I do in xml for rfcs.
>>
>> In the body I have:
>>
>> <xref target="RFC7748">RFC 7748</xref>
>>
>> And it the reference section:
>>
>> <?rfc include="reference.RFC.7748.xml"?>
>>
>> So I guessed:
>>
>> <xref target="DOI.10.6028_nist.sp.800-185">NIST SP 800-185</xref>
>>
>> <?doi include="DOI.10.6028_nist.sp.800-185"?>
>> ...
>
> The *rfc* include directive takes a URI, just see those that Carsten 
> posted.

Hmm.  I am missing what the URI is in what Carsten posted.

I tried

reference.DOI.10.6028

Is in

     <?rfc include="reference.DOI.10.6028"?>

But that is not it.

Line 310: Unable to resolve external request: "reference.DOI.10.6028"

With RFCs, I can access the listing by browsing to:

https://xml2rfc.tools.ietf.org/public/rfc/bibxml/

I cannot do that with

https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/

I get "Invalid DOI or type"




From nobody Mon Sep  2 05:11:25 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BA5120119 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 05:11:24 -0700 (PDT)
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, SPF_HELO_NONE=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 YzLyymDbYGnl for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 05:11:21 -0700 (PDT)
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 7798B120089 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 05:11:21 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53963 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 1i4lB0-0004r6-NN; Mon, 02 Sep 2019 05:11:20 -0700
To: Robert Moskowitz <rgm@htt-consult.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com>
Date: Mon, 2 Sep 2019 14:11:02 +0200
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: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UPhUajfKrQe1uO3q80seVhK3hRmX2CITh"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, rgm@htt-consult.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/_QmGAULhaphsufZAWp_zlAK7f4Q>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 12:11:24 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UPhUajfKrQe1uO3q80seVhK3hRmX2CITh
Content-Type: multipart/mixed; boundary="DQPg6a6giaonRFjlJH265GHrMXoPsuIla";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Robert Moskowitz <rgm@htt-consult.com>,
 "xml2rfc@ietf.org" <xml2rfc@ietf.org>
Message-ID: <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com>
Subject: Re: [xml2rfc] references for NIST
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com>
In-Reply-To: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com>

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

Hi Bob,

On 2019-09-02 04:10, Robert Moskowitz wrote:
> Are there references for NIST FIPS202 and SP800-185?
>=20
> I went browsing https://xml2rfc.tools.ietf.org/ and did not find much o=
f=20
> anything for NIST docs.  (NIST-500?).

Based on your input below, I've just added (with minor tweaks) these to
the reference library on xml2rfc.tools.ietf.org, in the bibxml2 directory=
:

	reference.NIST.FIPS.202.xml
	reference.NIST.SP.800-185.xml

Best regards,

	Henrik


>=20
> Right now I am having to include:
>=20
> <reference anchor=3D"NIST.FIPS.202"=20
> target=3D"http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">
>      <front>
>      <title>SHA-3 Standard:  Permutation-Based Hash and=20
> Extendable-Output Functions</title>
>      <author initials=3D"M." surname=3D"Dworkin" fullname=3D"Morris J. =
Dworkin">
>      <organization>National Institute of Standards and=20
> Technology</organization>
>      </author>
>      <date month=3D"August" year=3D"2015"/>
>      </front>
>      <seriesInfo name=3D"FIPS" value=3D"PUB 202"/>
>      <seriesInfo name=3D"DOI" value=3D"10.6028/nist.fips.202"/>
> </reference>
> <reference anchor=3D"NIST.SP.800_185"=20
> target=3D"http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.=
800-185.pdf">
>      <front>
>      <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and=20
> ParallelHash</title>
>      <author initials=3D"J." surname=3D"Kelsey" fullname=3D"John Kelsey=
">
>      <organization>National Institute of Standards and=20
> Technology</organization>
>      </author>
>      <author initials=3D"S." surname=3D"Change" fullname=3D"Shu-jen Cha=
nge">
>      <organization>National Institute of Standards and=20
> Technology</organization>
>      </author>
>      <author initials=3D"R." surname=3D"Perlner" fullname=3D"Ray Perlne=
r">
>      <organization>National Institute of Standards and=20
> Technology</organization>
>      </author>
>      <date month=3D"December" year=3D"2016"/>
>      </front>
>      <seriesInfo name=3D"Special Publication" value=3D"SP 800-185"/>
>      <seriesInfo name=3D"DOI" value=3D"10.6028/nist.sp.800-185"/>
> </reference>
>=20
> thanks
>=20
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc
>=20


--DQPg6a6giaonRFjlJH265GHrMXoPsuIla--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl1tBtYACgkQTptXS4+7
Fxri5RAAtT5ALcF2woRqzHUITr3GFLM82o7D+vahHI/ejdZB4lv0OpLAaqlnGw1i
IDuTRlDBrdX65o/JP1/HnoOn5eFVukLx+8ubBmrxtiwvUHdUXjsM4Pmq63qLxkBh
jH7jZqZChBXqBZT4XhvKdupqekcrB2u8MRHo1RYeSXM+ZOgLggwUwIjcyq5xjTdK
buck0jh0ujPvQ4aGu3zavHC4xg0XehehiS3cPEYCUtMYDikx1kK6Lx0sKosGLm0P
6B+q/ldy9KohjVrO3LTDDc4CIidIB1jKd+VXr+/gNRWGYu0AWwZvRdniot/tNpMH
hOAN1wWhl/FF9IQ9+/t94QR0hR9OCMjzERh8KVbJhBR2EHl1th3IrShXieAtttgw
y50UntBkr9a29ZLPXDFfP0o+swTT3/iYnXXmbY627W+fxE+5BjduU9n1OBp2IS2V
8y4ijm5E3lSDFAfBlSeSJ/8qfJoKT+VSCMPM+fY3Jb1w7ePbpDp4Ia9gGiNCuyR5
ZWlheoG+a9w6iCifwkIwVdRyWhPFVk8huEiyHYp3I7o7wc8GH93Idk6HlEN6+8Oa
TT1oqUBvmONIzBS49hO8pMVn2/+AgEVEtYq3yNVxaT1tM81Je1NdZpRUXTmV/jN9
IR9cR53y79Uy4iw8dvZftbo4QWZC2CNRmhNfJeteq6a/MO6Wh4s=
=Jvhe
-----END PGP SIGNATURE-----

--UPhUajfKrQe1uO3q80seVhK3hRmX2CITh--


From nobody Mon Sep  2 05:20:14 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7D2120119 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 05:20:12 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6D1vPxcpuZx for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 05:20:10 -0700 (PDT)
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 12F2D120073 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 05:20:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567426788; bh=SeswV6eGkqkx8LRjtL9O7z2zh0h7X46fCRwNAWm1+3Q=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ckgvJ8ihwsFZx8CJ0cwSqj3RenvpIC291WUHUx/dmfA11Qp/9EehOEaDcGTr1XpbA 7hI50IgF5m5hrn/fI/UE5e3zE71bIEUoNDEud69j1+T9QuMCOeLIYQ7QN9myWH0jmp U+B+W7llH+qmcU3GMHRg1/gkhss9Q0cjzTNBySCk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MAQMg-1huLB03AXS-00Bakc; Mon, 02 Sep 2019 14:19:48 +0200
To: Robert Moskowitz <rgm@htt-consult.com>, Carsten Bormann <cabo@tzi.org>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <B345B8F3-E21D-42D0-8D10-D90E1FCB80B6@tzi.org> <5df02043-b500-7ba5-124c-60f41f4f2968@htt-consult.com> <9552b18a-5514-3090-f1dd-f8d4785bb4bb@gmx.de> <5e1be54b-53c5-55fa-1906-459ef335afd3@htt-consult.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <e74d07ee-ff0e-be08-735b-b33430d5f470@gmx.de>
Date: Mon, 2 Sep 2019 14:19:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <5e1be54b-53c5-55fa-1906-459ef335afd3@htt-consult.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:uKtJ2FdPyFAINNNoABxXthX+gwwzyfuJD1HO5wKa015zn/59cSo BsD/pQWaI7DSqUYBA03qq+Szvp1lH7lW6HYfmYDSb2QKvCXozKs3aMcBVNhLkuJsrqGumbj j9KjKTQCHmXhgZj+YHwBohEhxcLkw6pLkNiCUs8hpNCr6tpvmwUaZMav7bvj4DCTDXeMBIY qPiG9rES8l9XvsLEFrOCQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:D/13KVRxe2M=:ijnk9Ed0hi7nqhI+7pX/PV nuXmBT62BQPAVi9Hae4FgaM2YHWo5Ok6swdoowB+00BG0DDRjDRdixoXG6WH7DpKzgOl5wzdW oQ596kdGZ/p+17aosW8XCv0TylWJtW+flG+5F4hF5/2LMmkfoVtcOI9M81h+ehfuovjEUbwE5 6QCfcVfFCnma41HWY0JH8OfewX1lTyygZ4KGWV4SDh8snFhZ0Pmdx73WBpWYsNKNfXZLv7cY7 snjtWN3NyYvDJwOAQNVtmGjbbQdqgzrX5egk1DG9Doq3fE+bEI9Gujv3/K7FOYTNNOugFMcPj auqOleqzNQOeegcAZF3c4RfzyKpj92D27zuU6ofBvLpsB23mNI+1C1hiyKEIZ52/c1JGF69lU x+vn1AxjBV+i0zQhs8O4nSUrKcYH7Cs1mi4soVrRf7kJ2ufu3LKgX7TbgeDUioSRppq+siown VdNoceGh1a+LPddRyPJY+/qNOPgwTEhz0GoUc2LJMFeEnUgm5HJEs3bzBlI3CbPRYMTHCU2A2 xojwSkwXbipwM0j9SWInIn3FrYtzw/YF2XJcXq3eMj0LXo6Vfsd9oMyMNqQIOaze9JNZDHbu2 xdMFQyCGGVh7oMptWlcFYHTX/sAKFeHQ70rcO1vm8kDAUBcACr2iGLeosdqcVfzMoKoQz9+Lc sh3tRHGfnw3Ass0BIDf5Y8lMlNt3OjZpK56vtSbhaBW3ooqklC7vf+WkfgNHnAkMkSQxWPP2F CHqKfNJ0lQQAmucBhWY2BcWM9rnw6ZQJxbjF31YtHJcgM6og0PepRYcsXa1U9r+daR1DDVvvX 8xisAmwYDMmUztUtUNP4APiRmvZh4/SlgmalJKm2eoImDo9pF1d7r0Qlw04kaXwlKWK2kfnqw hwtuT+mbQDvfC8tjbaPu1L1xHMPER+euuoU6GBTAJGvPQN9EteBWJrCWcsLK9qAAFT1Tf4wIU ZWLElefzAYJLvljSiyP7H3hT/LqOnNZRM0MZs+l4W2Elh960Eu1tdygHcXx4iePbcGBa4O/1O w2He/Lz1layU0poReTSJ911bqICsLY4T1hns8bYfHyjOp0ITcETM6lAd5lF8KPv2psmsCO1El gFDAeE6r2D9PA9ZJkiZa6WNvd1zuZMewZ0pmNZ265SU6rqrJEQ+zxSmHi9S8+lWak3pj/GWRd /9lX4oNXbKMwHkJu5Mq+tnDuWAvEgCw8EaW/OnDFGS7oVriA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/CPLYlSncu_OpSo8OiWFg6V_iq4c>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 12:20:13 -0000

On 02.09.2019 14:05, Robert Moskowitz wrote:
>
>
> On 9/2/19 7:37 AM, Julian Reschke wrote:
>> On 02.09.2019 13:27, Robert Moskowitz wrote:
>>>
>>>
>>> On 9/2/19 3:47 AM, Carsten Bormann wrote:
>>>>
>>>>> On Sep 2, 2019, at 04:10, Robert Moskowitz <rgm@htt-consult.com>
>>>>> wrote:
>>>>>
>>>>> Are there references for NIST FIPS202 and SP800-185?
>>>> These have DOIs.=C2=A0 So in kramdown-rfc, you could reference these =
as
>>>>
>>>> {{!NIST.FIPS.202=3DDOI.10.6028/nist.fips.202}} and
>>>> {{?NIST.SP.800_185=3DDOI.10.6028/nist.sp.800-185}} (where ! is for
>>>> normative and ? is for informative).=C2=A0 You can of course also put=
 these
>>>> into the YAML prefix.
>>>>
>>>> With stand_alone: yes, kramdown-rfc does the external loading.=C2=A0 =
With
>>>> stand_alone: no (i.e., load the references from XML), kramdown-rfc
>>>> generates this XML for the above input:
>>>>
>>>> In the document subset:
>>>>
>>>> <!ENTITY DOI.10.6028_nist.fips.202 SYSTEM
>>>> "https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6=
028/nist.fips.202.xml?anchor=3DNIST.FIPS.202">
>>>>
>>>>
>>>> <!ENTITY DOI.10.6028_nist.sp.800-185 SYSTEM
>>>> "https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6=
028/nist.sp.800-185.xml?anchor=3DNIST.SP.800_185">
>>>>
>>>>
>>>>
>>>> In the references section, normative part:
>>>> &DOI.10.6028_nist.fips.202;
>>>> In the references section, informative part:
>>>> &DOI.10.6028_nist.sp.800-185;
>>>>
>>>> In the (no longer so self-explanatory :-) text:
>>>> <xref target=3D"NIST.FIPS.202"/> and <xref target=3D"NIST.SP.800_185"=
/>
>>>> (where ! is for normative and ? is for informative).=C2=A0 You can of
>>>> course also put these into the YAML prefix.
>>>>
>>>>
>>>
>>> Now I am trying to translate this into what I do in xml for rfcs.
>>>
>>> In the body I have:
>>>
>>> <xref target=3D"RFC7748">RFC 7748</xref>
>>>
>>> And it the reference section:
>>>
>>> <?rfc include=3D"reference.RFC.7748.xml"?>
>>>
>>> So I guessed:
>>>
>>> <xref target=3D"DOI.10.6028_nist.sp.800-185">NIST SP 800-185</xref>
>>>
>>> <?doi include=3D"DOI.10.6028_nist.sp.800-185"?>
>>> ...
>>
>> The *rfc* include directive takes a URI, just see those that Carsten
>> posted.
>
> Hmm.=C2=A0 I am missing what the URI is in what Carsten posted.
>
> I tried
>
> reference.DOI.10.6028
>
> Is in
>
>  =C2=A0=C2=A0=C2=A0 <?rfc include=3D"reference.DOI.10.6028"?>
>
> But that is not it.
>
> Line 310: Unable to resolve external request: "reference.DOI.10.6028"
>
> With RFCs, I can access the listing by browsing to:
>
> https://xml2rfc.tools.ietf.org/public/rfc/bibxml/
>
> I cannot do that with
>
> https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/
>
> I get "Invalid DOI or type"

<?rfc
include=3D"https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI=
.10.6028/nist.fips.202.xml?anchor=3DNIST.FIPS.202"?>

<?rfc
include=3D"https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI=
.10.6028/nist.sp.800-185.xml?anchor=3DNIST.SP.800_185"?>

Best regards, Julian


From nobody Mon Sep  2 05:23:11 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCC5120143 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 05:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 QiPtjQXl0_iK for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 05:23:07 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C45120073 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 05:23:07 -0700 (PDT)
Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MTkd3fXpzySM; Mon,  2 Sep 2019 14:23:05 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_5E2791F9-63BD-48FD-8409-38232B1C5B15"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com>
Date: Mon, 2 Sep 2019 14:23:05 +0200
Cc: Robert Moskowitz <rgm@htt-consult.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
X-Mao-Original-Outgoing-Id: 589119783.720921-c3533acf1e01b99f473d4b43d5d20651
Message-Id: <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com>
To: Henrik Levkowetz <henrik@levkowetz.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/fboMOHL3cYCqYOqYBJXeYcl8DyQ>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 12:23:10 -0000

--Apple-Mail=_5E2791F9-63BD-48FD-8409-38232B1C5B15
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Sep 2, 2019, at 14:11, Henrik Levkowetz <henrik@levkowetz.com> wrote:
>=20
> Based on your input below, I've just added (with minor tweaks) these =
to
> the reference library on xml2rfc.tools.ietf.org, in the bibxml2 =
directory:
>=20
> 	reference.NIST.FIPS.202.xml
> 	reference.NIST.SP.800-185.xml

Give a man a fish=E2=80=A6

        <?rfc =
include=3D"reference.DOI.10.6028/nist.fips.202.xml?anchor=3DNIST.FIPS.202=E2=
=80=9D?>

Note that the text from the =E2=80=9Creference. to the ? is the DOI and =
the text from the ?anchor=3D to the =E2=80=9C is the anchor name that =
you use with target=3D in <xref.
(You get to choose anchor names with DOI and IANA references only, =
currently.)

Now, of course, the DOI-generated reference could be as broken as the =
DOI owner wants, but this should help people who want to build RFCs with =
references outside the IETF (almost all of which now have DOIs) directly =
from XML.

Gr=C3=BC=C3=9Fe, Carsten


--Apple-Mail=_5E2791F9-63BD-48FD-8409-38232B1C5B15
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEcr05t4NZlx5Xee/8VkscnDT509sFAl1tCacACgkQVkscnDT5
09tIzA//TLMqx3nAgyy/L6+KHbpg7QCHyL2ZLtoqWJm+Bv5SeaPQs9dfJwx1D+wU
8nkJmf+NQjnzz+T384ieY6ZpG2dTLQnYgZB7eSVGk5ejYoNUHOFctmM8YdkLMFgF
KjKI2NM0Dbwq8XJuLSrKm+lBJq13Z7ebfaJu3/ioeFvinJ3OoIUcJRBGnFEgc/JN
UyPPfkWmzLOIlMmJZt+phmR7WWQvBBuQitRZn7o1IkdfzQHIoTVOzWqIpBgKJ1WC
iIJpWHyZgsdhP2gwSatbneqPv2X2gIVmVIUG/p5fBtwEF9TbALw0ocQbCpEI18Hx
g0hzr2HJVU0AT+UPFLabmlZGSlKNwRYuEzpwpSNDazC0AEcja962usLTdwEsU9nl
ruUrkfxVs/Lr8v8iZsdWEGrBGRVOvYisjy6womKSJmKFgUwkw0WvMv9LlbJf0mWn
GXq/tB74jVV+OxmLFqu4jdc/h3DgszY6Q+SO+Uub9A8o9rQz8wlcup1uCJOASEb7
/vjfv0qjPXgzqOUkecWS84ZDtes1UlQ2wcT/FeswXcR8SBYaO3jnlYAaCitStjFk
twAhWaIwYjn3UEIMahPrtdeynk4/R/grDNZBiHBQJJ7zQNoIbqviiJRxt7wCwUQn
T/Yjd1aXtjUMgA8W6mdicPw/Xww2Z/fYgTVw0H8DwuuJ0D1Gc8I=
=qj3H
-----END PGP SIGNATURE-----

--Apple-Mail=_5E2791F9-63BD-48FD-8409-38232B1C5B15--


From nobody Mon Sep  2 06:05:46 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED07412012A for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 06:05:44 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 0nvMkCAA6Vk8 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 06:05:43 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831F6120110 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 06:05:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1138F60945; Mon,  2 Sep 2019 09:05:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GR80dQqn8hN4; Mon,  2 Sep 2019 09:05:37 -0400 (EDT)
Received: from lx140e.htt-consult.com (ip70-161-203-70.hr.hr.cox.net [70.161.203.70]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id E60656080C; Mon,  2 Sep 2019 09:05:36 -0400 (EDT)
To: Carsten Bormann <cabo@tzi.org>, Henrik Levkowetz <henrik@levkowetz.com>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com>
Date: Mon, 2 Sep 2019 09:05:32 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/R8avsvKDuFKpXGGY8b5PL1DnspA>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 13:05:45 -0000

On 9/2/19 8:23 AM, Carsten Bormann wrote:
> On Sep 2, 2019, at 14:11, Henrik Levkowetz <henrik@levkowetz.com> wrote:
>> Based on your input below, I've just added (with minor tweaks) these to
>> the reference library on xml2rfc.tools.ietf.org, in the bibxml2 directory:
>>
>> 	reference.NIST.FIPS.202.xml
>> 	reference.NIST.SP.800-185.xml
> Give a man a fish…

I like the occasional fish.

Is Henrik's tweak the way for all such references?  Do I need to get a 
new version of xml2rfc for the tweak,

or is Carsten's reply the general way for all such references that have 
a DOI?


>          <?rfc include="reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202”?>

I am getting the errorr:

  <string>: Line 181: IDREF attribute target references an unknown ID 
"NIST.SP.800-185"

With:

<xref target="NIST.SP.800-185">NIST SP 800-185</xref>

     <?rfc 
include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185”?>

> Note that the text from the “reference. to the ? is the DOI and the text from the ?anchor= to the “ is the anchor name that you use with target= in <xref.
> (You get to choose anchor names with DOI and IANA references only, currently.)
>
> Now, of course, the DOI-generated reference could be as broken as the DOI owner wants, but this should help people who want to build RFCs with references outside the IETF (almost all of which now have DOIs) directly from XML.

Is there a way to textually see the xml that the DOI owner built?

thanks


From nobody Mon Sep  2 06:29:04 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FA112013D for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 06:29:02 -0700 (PDT)
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, SPF_HELO_NONE=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 A5l9zvwQ0khz for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 06:29:00 -0700 (PDT)
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 DF9491200A3 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 06:29:00 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:55133 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 1i4mOC-0003iH-2B; Mon, 02 Sep 2019 06:29:00 -0700
To: Robert Moskowitz <rgm@htt-consult.com>, Carsten Bormann <cabo@tzi.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <342e3210-831f-6286-04be-9d08550d964d@levkowetz.com>
Date: Mon, 2 Sep 2019 15:28:52 +0200
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: <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="51JLaKLEFhA9WJi3lq7H9jihlsKLNwkt7"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, cabo@tzi.org, rgm@htt-consult.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/Qwg_X8TNLq2AS_R3Zj_IYq461Z4>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 13:29:02 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--51JLaKLEFhA9WJi3lq7H9jihlsKLNwkt7
Content-Type: multipart/mixed; boundary="wCADUJ7VNAx3WJbDtMtG1lwWQg2jhFbAu";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Robert Moskowitz <rgm@htt-consult.com>, Carsten Bormann <cabo@tzi.org>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
Message-ID: <342e3210-831f-6286-04be-9d08550d964d@levkowetz.com>
Subject: Re: [xml2rfc] references for NIST
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com>
 <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com>
 <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org>
 <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com>
In-Reply-To: <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com>

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

Hi Robert,

On 2019-09-02 15:05, Robert Moskowitz wrote:
>=20
>=20
> On 9/2/19 8:23 AM, Carsten Bormann wrote:
>> On Sep 2, 2019, at 14:11, Henrik Levkowetz <henrik@levkowetz.com> wrot=
e:
>>> Based on your input below, I've just added (with minor tweaks) these =
to
>>> the reference library on xml2rfc.tools.ietf.org, in the bibxml2 direc=
tory:
>>>
>>> 	reference.NIST.FIPS.202.xml
>>> 	reference.NIST.SP.800-185.xml
>> Give a man a fish=E2=80=A6
>=20
> I like the occasional fish.
>=20
> Is Henrik's tweak the way for all such references?

Both work.  Carsten's depend on what's in the DOI database, which means t=
hat
manually putting a reference in place may give more complete information =
in
some cases.

> Do I need to get a new version of xml2rfc for the tweak,

Nope, it should be ready to use the same way you use other references
pulled from the xml2rfc.tools.ietf.org reference library.

> or is Carsten's reply the general way for all such references that have=
=20
> a DOI?

Carsten's approach is good, and of course immediately available without
manual intervention if a DOI is available.  I think it's to some extent
a matter of preference.

>=20
>>          <?rfc include=3D"reference.DOI.10.6028/nist.fips.202.xml?anch=
or=3DNIST.FIPS.202=E2=80=9D?>
>=20
> I am getting the errorr:
>=20
>   <string>: Line 181: IDREF attribute target references an unknown ID=20
> "NIST.SP.800-185"
>=20
> With:
>=20
> <xref target=3D"NIST.SP.800-185">NIST SP 800-185</xref>
>=20
>      <?rfc=20
> include=3D"reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=3DNIST.SP.8=
00-185=E2=80=9D?>
>=20
>> Note that the text from the =E2=80=9Creference. to the ? is the DOI an=
d the text from the ?anchor=3D to the =E2=80=9C is the anchor name that y=
ou use with target=3D in <xref.
>> (You get to choose anchor names with DOI and IANA references only, cur=
rently.)
>>
>> Now, of course, the DOI-generated reference could be as broken as the =
DOI owner wants, but this should help people who want to build RFCs with =
references outside the IETF (almost all of which now have DOIs) directly =
from XML.
>=20
> Is there a way to textually see the xml that the DOI owner built?

This is built from the DOI owner's provided information by a script on th=
e
tools server (written by Tony? or Carsten?):

http://xml2rfc.tools.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.6028=
/nist.fips.202.xml?anchor=3DNIST.FIPS.202



Best regards,

	Henrik


--wCADUJ7VNAx3WJbDtMtG1lwWQg2jhFbAu--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl1tGRQACgkQTptXS4+7
FxqKjw/+MbzS6qluTVeqhQgtXng4/AgIaXhgOgJgelRYV2YUKa78iqh8aiISlMnW
dnBVqxvn7RDH3KjVOJxvhB8FzdeWEKOVRV8OEEbBlU8qW1K6f03rwhmQvSclHrmV
5mPOusQ/AlcevCbTaTUaVkIKKY7vAfiI1zJnjVLWcTLMXEX1WFKOu7eMBigGxeAh
ezERQky0I+V6N59NUkQ7qqQhSKJ9pM5QtUd5mJJjx3UDd4iWdrFxx1wCkK5sKN7/
hqhQgWyNO6oPFRABF7Y/JTOyJK1/VP1G5bE4u8zusT5POybtfm90B8fiexSu312W
fhWk5PVDNuwqEqX8BdPCsz+dPTmQaCsroA0ttw5wtDk41VE4UmsMj0KLjlTuhvOB
LfDkTnuG7xflqJGRwlibpTMaL88Lxac8YRKL2Fcezhcu3Sfwb0XJaN5iYqBF25MO
re7BH5um+KVJxQO4cOn9bYI/YAFSEFJTiV0OYzRDUOZ0Bh13vRBizRm5BERuYit9
1A7nNl80QkJi1vkHlnJxF0tRYvIQhgHqHX7IRoduE751J4DLp13bmS3H8A9LWbjK
baGqj8c96Coab4NtI7/tb5B3e3ei4ZlFmXXKcizdJyWmTd+rg5/DG3NmoxJ3+6r+
MrhXK9HnddlIMLhv/BgWf7/8qZ0l8OJkn7cyuV68xOefOxmhY58=
=S/J7
-----END PGP SIGNATURE-----

--51JLaKLEFhA9WJi3lq7H9jihlsKLNwkt7--


From nobody Mon Sep  2 06:31:33 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30984120145 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 06:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 Wg5OoWifGhMF for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 06:31:28 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73406120170 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 06:31:28 -0700 (PDT)
Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MWFV4085z10jP; Mon,  2 Sep 2019 15:31:26 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com>
Date: Mon, 2 Sep 2019 15:31:25 +0200
Cc: Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
X-Mao-Original-Outgoing-Id: 589123883.812969-4749fa0e41e4906d378e639ccdfb0daf
Content-Transfer-Encoding: quoted-printable
Message-Id: <58511543-8B76-4AF9-8D30-C7CAD9E6D66A@tzi.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com>
To: Robert Moskowitz <rgm@htt-consult.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/oln6KZz3OCCv6DhGBIoKNin08X4>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 13:31:31 -0000

> On Sep 2, 2019, at 15:05, Robert Moskowitz <rgm@htt-consult.com> =
wrote:
>=20
>=20
>=20
> On 9/2/19 8:23 AM, Carsten Bormann wrote:
>> On Sep 2, 2019, at 14:11, Henrik Levkowetz <henrik@levkowetz.com> =
wrote:
>>> Based on your input below, I've just added (with minor tweaks) these =
to
>>> the reference library on xml2rfc.tools.ietf.org, in the bibxml2 =
directory:
>>>=20
>>> 	reference.NIST.FIPS.202.xml
>>> 	reference.NIST.SP.800-185.xml
>> Give a man a fish=E2=80=A6
>=20
> I like the occasional fish.
>=20
> Is Henrik's tweak the way for all such references?  Do I need to get a =
new version of xml2rfc for the tweak,

Henrik only gave you those two fish.

> or is Carsten's reply the general way for all such references that =
have a DOI?
>=20
>=20
>>         <?rfc =
include=3D"reference.DOI.10.6028/nist.fips.202.xml?anchor=3DNIST.FIPS.202=E2=
=80=9D?>

Yes.

(Please fix the closing double quote character smartly auto-broken by my =
mailer, though.)

>=20
> I am getting the errorr:
>=20
>  <string>: Line 181: IDREF attribute target references an unknown ID =
"NIST.SP.800-185"
>=20
> With:
>=20
> <xref target=3D"NIST.SP.800-185">NIST SP 800-185</xref>
>=20
>     <?rfc =
include=3D"reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=3DNIST.SP.800-=
185=E2=80=9D?>

Is that still the double quote character?
I don=E2=80=99t see anything else wrong here.

>> Note that the text from the =E2=80=9Creference. to the ? is the DOI =
and the text from the ?anchor=3D to the =E2=80=9C is the anchor name =
that you use with target=3D in <xref.
>> (You get to choose anchor names with DOI and IANA references only, =
currently.)
>>=20
>> Now, of course, the DOI-generated reference could be as broken as the =
DOI owner wants, but this should help people who want to build RFCs with =
references outside the IETF (almost all of which now have DOIs) directly =
from XML.
>=20
> Is there a way to textually see the xml that the DOI owner built?

I usually work with JSON:

$ curl -LHAccept:application/citeproc+json =
http://doi.org/10.6028/NIST.SP.800-185

{=E2=80=9Cinstitution":{"name":"National Institute of Standards and =
Technology","place":["Gaithersburg, MD"],"department":["Information =
Technology =
Laboratory"],"acronym":["NIST"]},"indexed":{"date-parts":[[2019,6,22]],"da=
te-time":"2019-06-22T11:03:11Z","timestamp":1561201391547},"publisher-loca=
tion":"Gaithersburg, MD","reference-count":0,"publisher":"National =
Institute of Standards and =
Technology","funder":[{"DOI":"10.13039\/100007764r","name":"Information =
Technology =
Laboratory","doi-asserted-by":"publisher","award":[]}],"content-domain":{"=
domain":[],"crossmark-restriction":false},"DOI":"10.6028\/nist.sp.800-185"=
,"type":"report","created":{"date-parts":[[2016,12,22]],"date-time":"2016-=
12-22T18:52:43Z","timestamp":1482432763000},"source":"Crossref","is-refere=
nced-by-count":4,"title":"SHA-3 derived functions: cSHAKE, KMAC, =
TupleHash and =
ParallelHash","prefix":"10.6028","author":[{"given":"John","family":"Kelse=
y","sequence":"first","affiliation":[]},{"given":"Shu-jen","family":"Chang=
e","sequence":"additional","affiliation":[]},{"given":"Ray","family":"Perl=
ner","sequence":"additional","affiliation":[]}],"member":"4068","published=
-online":{"date-parts":[[2016,12]]},"container-title":[],"original-title":=
[],"deposited":{"date-parts":[[2018,3,6]],"date-time":"2018-03-06T10:06:39=
Z","timestamp":1520330799000},"score":1.0,"subtitle":[],"short-title":[],"=
issued":{"date-parts":[[2016,12]]},"references-count":0,"URL":"http:\/\/dx=
.doi.org\/10.6028\/NIST.SP.800-185","relation":{}}

or use some JSON pretty printer such as jq with that:

$ curl -LHAccept:application/citeproc+json =
http://doi.org/10.6028/NIST.SP.800-185 | jq

{
  "institution": {
    "name": "National Institute of Standards and Technology",
    "place": [
      "Gaithersburg, MD"
    ],
    "department": [
      "Information Technology Laboratory"
    ],
    "acronym": [
      "NIST"
    ]
  },
  "indexed": {
    "date-parts": [
      [
        2019,
        6,
        22
      ]
    ],
    "date-time": "2019-06-22T11:03:11Z",
    "timestamp": 1561201391547
  },
  "publisher-location": "Gaithersburg, MD",
  "reference-count": 0,
  "publisher": "National Institute of Standards and Technology",
  "funder": [
    {
      "DOI": "10.13039/100007764r",
      "name": "Information Technology Laboratory",
      "doi-asserted-by": "publisher",
      "award": []
    }
  ],
  "content-domain": {
    "domain": [],
    "crossmark-restriction": false
  },
  "DOI": "10.6028/nist.sp.800-185",
  "type": "report",
  "created": {
    "date-parts": [
      [
        2016,
        12,
        22
      ]
    ],
    "date-time": "2016-12-22T18:52:43Z",
    "timestamp": 1482432763000
  },
  "source": "Crossref",
  "is-referenced-by-count": 4,
  "title": "SHA-3 derived functions: cSHAKE, KMAC, TupleHash and =
ParallelHash",
  "prefix": "10.6028",
  "author": [
    {
      "given": "John",
      "family": "Kelsey",
      "sequence": "first",
      "affiliation": []
    },
    {
      "given": "Shu-jen",
      "family": "Change",
      "sequence": "additional",
      "affiliation": []
    },
    {
      "given": "Ray",
      "family": "Perlner",
      "sequence": "additional",
      "affiliation": []
    }
  ],
  "member": "4068",
  "published-online": {
    "date-parts": [
      [
        2016,
        12
      ]
    ]
  },
  "container-title": [],
  "original-title": [],
  "deposited": {
    "date-parts": [
      [
        2018,
        3,
        6
      ]
    ],
    "date-time": "2018-03-06T10:06:39Z",
    "timestamp": 1520330799000
  },
  "score": 1,
  "subtitle": [],
  "short-title": [],
  "issued": {
    "date-parts": [
      [
        2016,
        12
      ]
    ]
  },
  "references-count": 0,
  "URL": "http://dx.doi.org/10.6028/NIST.SP.800-185",
  "relation": {}
}

You can see the bibxml that the doilit tool generates from that:

$ doilit -x=3DNIST.SP.800-185 10.6028/NIST.SP.800-185
<reference anchor=3D=E2=80=9CNIST.SP.800-185" >
  <front>
    <title>SHA-3 derived functions: cSHAKE, KMAC, TupleHash and =
ParallelHash</title>
    <author initials=3D"J." surname=3D"Kelsey" fullname=3D"John Kelsey">
      <organization></organization>
    </author>
    <author initials=3D"S." surname=3D"Change" fullname=3D"Shu-jen =
Change">
      <organization></organization>
    </author>
    <author initials=3D"R." surname=3D"Perlner" fullname=3D"Ray =
Perlner">
      <organization></organization>
    </author>
    <date year=3D"2016" month=3D"December"/>
  </front>
  <seriesInfo name=3D"National Institute of Standards and Technology" =
value=3D"report"/>
  <seriesInfo name=3D"DOI" value=3D"10.6028/nist.sp.800-185"/>
</reference>

(Assuming you have installed kramdown-rfc, whose doilit tool the bibxml =
web service uses.)
Or right from the bibxml web service:

$ curl =
https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/ni=
st.sp.800-185.xml?anchor=3DNIST.SP.800-185
<reference anchor=3D=E2=80=98NIST.SP.800-185' >
  <front>
    <title>SHA-3 derived functions: cSHAKE, KMAC, TupleHash and =
ParallelHash</title>
    <author initials=3D"J." surname=3D"Kelsey" fullname=3D"John Kelsey">
      <organization></organization>
    </author>
    <author initials=3D"S." surname=3D"Change" fullname=3D"Shu-jen =
Change">
      <organization></organization>
    </author>
    <author initials=3D"R." surname=3D"Perlner" fullname=3D"Ray =
Perlner">
      <organization></organization>
    </author>
    <date year=3D"2016" month=3D"December"/>
  </front>
  <seriesInfo name=3D"National Institute of Standards and Technology" =
value=3D"report"/>
  <seriesInfo name=3D"DOI" value=3D"10.6028/nist.sp.800-185"/>
</reference>

(You can look at that URL in the browser, too, but many browsers need a =
=E2=80=9Cview source=E2=80=9D here.)

Gr=C3=BC=C3=9Fe, Carsten


From nobody Mon Sep  2 06:31:53 2019
Return-Path: <trac@tools.ietf.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE100120142 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 06:31:51 -0700 (PDT)
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, SPF_HELO_NONE=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 nec290f-4mlC for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 06:31:50 -0700 (PDT)
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 934EE1200A3 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 06:31:50 -0700 (PDT)
Received: from localhost ([::1]:51491 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1i4mQv-0006rA-Vs; Mon, 02 Sep 2019 06:31:49 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "xml2rfc issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Cc: xml2rfc@ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: henrik@levkowetz.com
X-Trac-Project: xml2rfc
Date: Mon, 02 Sep 2019 13:31:49 -0000
X-URL: http://tools.ietf.org/tools/xml2rfc/
X-Trac-Ticket-URL: /ticket/421#comment:1
Message-ID: <085.5f8acd31a8b9c3d29900987fcce0b810@tools.ietf.org>
References: <070.3d8e972f20dc85fe0674858561f6081b@tools.ietf.org>
X-Trac-Ticket-ID: 421
In-Reply-To: <070.3d8e972f20dc85fe0674858561f6081b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/cBRWBcJ7wD0BFaMDLlkTsrmLLy0>
Subject: Re: [xml2rfc] #421 (Version 2 cli): Duplicate displayreference names are allowed
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 13:31:52 -0000

#421: Duplicate displayreference names are allowed

Changes (by henrik@levkowetz.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Fixed in [3264]:

 Added a test, with error exit, for duplicate <displayreference>
 replacement terms.  Fixes issue #421.

-- 
-------------------------------------+----------------------------------
  Reporter:  ietf@augustcellars.com  |      Owner:  henrik@levkowetz.com
      Type:  defect                  |     Status:  closed
  Priority:  medium                  |  Milestone:
 Component:  Version 2 cli           |    Version:  2.24.*
Resolution:  fixed                   |   Keywords:
-------------------------------------+----------------------------------

Ticket URL: </ticket/421#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>


From nobody Mon Sep  2 07:44:28 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E345120019 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 07:44:26 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 SSautrtMkja3 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 07:44:23 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC18120110 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 07:44:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2757660945; Mon,  2 Sep 2019 10:44:21 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NQfgVK39UAmh; Mon,  2 Sep 2019 10:44:17 -0400 (EDT)
Received: from lx140e.htt-consult.com (ip70-161-203-70.hr.hr.cox.net [70.161.203.70]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9F3656080C; Mon,  2 Sep 2019 10:44:16 -0400 (EDT)
To: Carsten Bormann <cabo@tzi.org>
Cc: Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <58511543-8B76-4AF9-8D30-C7CAD9E6D66A@tzi.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <22b431c4-881c-d08a-0fa1-09fba410d659@htt-consult.com>
Date: Mon, 2 Sep 2019 10:44:12 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <58511543-8B76-4AF9-8D30-C7CAD9E6D66A@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/IKGxA0oQtbpkd8Vq49eGsIY2ztY>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 14:44:26 -0000

On 9/2/19 9:31 AM, Carsten Bormann wrote:
>
>> On Sep 2, 2019, at 15:05, Robert Moskowitz <rgm@htt-consult.com> wrote:
>>
>>
>>
>> On 9/2/19 8:23 AM, Carsten Bormann wrote:
>>> On Sep 2, 2019, at 14:11, Henrik Levkowetz <henrik@levkowetz.com> wrote:
>>>> Based on your input below, I've just added (with minor tweaks) these to
>>>> the reference library on xml2rfc.tools.ietf.org, in the bibxml2 directory:
>>>>
>>>> 	reference.NIST.FIPS.202.xml
>>>> 	reference.NIST.SP.800-185.xml
>>> Give a man a fish…
>> I like the occasional fish.
>>
>> Is Henrik's tweak the way for all such references?  Do I need to get a new version of xml2rfc for the tweak,
> Henrik only gave you those two fish.
>
>> or is Carsten's reply the general way for all such references that have a DOI?
>>
>>
>>>          <?rfc include="reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202”?>
> Yes.
>
> (Please fix the closing double quote character smartly auto-broken by my mailer, though.)
>
>> I am getting the errorr:
>>
>>   <string>: Line 181: IDREF attribute target references an unknown ID "NIST.SP.800-185"
>>
>> With:
>>
>> <xref target="NIST.SP.800-185">NIST SP 800-185</xref>
>>
>>      <?rfc include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185”?>
> Is that still the double quote character?
> I don’t see anything else wrong here.

The way I am reading the error (compared to my earlier errors), the 
problem is with the anchor=

It does not like my xref target, and I can't see the difference. Both 
say NIST.SP.800-185



>
>>> Note that the text from the “reference. to the ? is the DOI and the text from the ?anchor= to the “ is the anchor name that you use with target= in <xref.
>>> (You get to choose anchor names with DOI and IANA references only, currently.)
>>>
>>> Now, of course, the DOI-generated reference could be as broken as the DOI owner wants, but this should help people who want to build RFCs with references outside the IETF (almost all of which now have DOIs) directly from XML.
>>


From nobody Mon Sep  2 08:01:27 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42F12022A for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 08:01:16 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-ud_yLCg4Ea for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 08:01:14 -0700 (PDT)
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 489D712013D for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 08:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567436442; bh=wpTZlplN87I+v+9qv/chgm6fPk4p0nGSy0QbOWp3AYQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=UtJuDVmVTzj66ciZvHNBtpz703NhDaqwKVGhoHmAgnhXmPjvTWf7cJr0u7XXlmFXX RpD3FlC4bPdmcMIK8z2VPxW5GZ+n7BXTczQLqoitB6LE4aA2vprQFnKcP+7hoOu1HJ wioJkSmN2MJUJWkfg7UommSxMUpcNnEO8NOOlnwA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M4b1y-1i4FK80vCw-001iuQ; Mon, 02 Sep 2019 17:00:42 +0200
To: Robert Moskowitz <rgm@htt-consult.com>, Carsten Bormann <cabo@tzi.org>, Henrik Levkowetz <henrik@levkowetz.com>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de>
Date: Mon, 2 Sep 2019 17:00:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:BcaXG/4UUl8ZB6dP9avky5wozOr+ddofk0WGeiLbr/2WwY98CbV cwdLBzW84B+clRNswte4gPDmJrc/JGCf3dy01q8QksBOPP5EJ+0QXSNgcXboUYGKRXkjkCO JwBFxrbQzWUtl75Nk8Jc/L8PwRBb9HnwV7YjKTSb9P+uexu2lGnw/NZiAYAf2UjKqbpoM2w DHQr7nSCkE9tpfoaax0Zw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7sKccUTsN0o=:VvZ1FgGnV2x3p9kJzltPp9 69AyopIo2UilFa1ySOHQHcsSJE1SkuhQFv9+g4xrJzuWdF0Z/2PFnRjyO9bGM44Vkhoasu/g7 Fd3mq4hKqCg6hkeO+QGs51seFZXcIQlBRFeM3X1GRebDrqO9XBOznCOQCZH8g6o45z//qXxhz sujTXfkju3WVtz8sKgkL7NGAGxPA+3NeZYA0+lWm2Eh1PSXl05VJoOdUi3hkdP8A/4w1765fV 8vLsrgDkbA4+VAbeVMlMkdeqoGcLssaUAxF+ELaDNFdehj1k/UcWFrdg4rQBjHrjbH2AnZKR1 7wVqdoYKnjdv6x3faTSBd35D7txA5z6Ral3Jro7+yXcqEdmoh4BsJblcG4Ncc4Y4/KtF/XUZ7 VLlGPD41IXxTibv3yZkTuiD4T53RBdD9QFeYOV1b+Zst3tjtBew+KMXYeHMY8tVPcQp7b6sU3 R7MkvXsKMPO9lkkRBQZyis6Ud8aeBBoqyxBiwY4KGcMDIEzT9vH8Y1XLOHBzKP0O28z0T6ygc WD9YC3dvcfcPXwsVm2lTAzbr1tgbQ6c6wK9/J5zOIK3VCTKdMxjhkAHLHk2sgGdRccImb2Xnr M0tI+Rah151nrmHwlExnJOlWqrsfb49xEjH/NIO4vOeyie11BPk7yJaUnzFFD+cskburIvB9f gqUqmfvcUtRA4aub5+O7S0ykiXX8UYyap5R/JAoZvkyYpkqv68ANR8jZZz/tLPL3KAEdSI8cC ITedJKgiybjOfqJBBGmnNJXD7MPqWVSkFCw8SwDRkqslvW0JsEKiZzSg5DxbngS8B5WVuLm8q MW/n6NUjAkWxnPrxMbgjXrY+ELht96yc7Ea9qArHxEXxogoBc8rjwrNgvaIfg/oAfNj+5aZNQ +OXY1e0iB+INQAJ5gxQZ3WAmq7z2JC2ZO+Jmem6X2Jj2kIfhx/A0O800bFnF7J+QVcxEU6mpV V8QqUQlzyiVbl5PpbhVUqFSLKI0r2o9bHwC4W70tnk2I7wCO0+fETk/NwnL5red6s1UScB+3e 5/zgTRA13BLyn/97nOwUEuF7h/CdmQUN7YrGJmyDzY2WbqdGxe6FoXmSVLRYmTO6S2hCHFyj6 C4C1GofmLQFirCaKcXIyiljdEpzd8EMrFweBxgxHcgqLybg4Wb7laXBVIAWQHrr+3jE8L+v/N m1Vmjk4nyr9ow6ard36xpGxn2Y79uRsiirSY2l2in63m1UHQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/YPyoeCRD8cRFsSD_CMcgAu4DE0k>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 15:01:19 -0000

On 02.09.2019 15:05, Robert Moskowitz wrote:
> ...
> I like the occasional fish.
>
> Is Henrik's tweak the way for all such references?=C2=A0 Do I need to ge=
t a
> new version of xml2rfc for the tweak,
>
> or is Carsten's reply the general way for all such references that have
> a DOI?
>
>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <?rfc
>> include=3D"reference.DOI.10.6028/nist.fips.202.xml?anchor=3DNIST.FIPS.2=
02=E2=80=9D?>
>
> I am getting the errorr:
>
>  =C2=A0<string>: Line 181: IDREF attribute target references an unknown =
ID
> "NIST.SP.800-185"
>
> With:
>
> <xref target=3D"NIST.SP.800-185">NIST SP 800-185</xref>
>
>  =C2=A0=C2=A0=C2=A0 <?rfc
> include=3D"reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=3DNIST.SP.80=
0-185=E2=80=9D?>

You might need a new version of xml2rfc (I believe there was a problem
with the cache not using the query parm in the key).

Or try:

   xml2rfc --clear-cache

> ...

Best regards, Julian


From nobody Mon Sep  2 08:30:10 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCA3120088 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 08:30:09 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 yaoUc044ukuZ for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 08:30:06 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30F312026E for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 08:30:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id C018260945; Mon,  2 Sep 2019 11:30:05 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5xFyp-GksGjs; Mon,  2 Sep 2019 11:30:00 -0400 (EDT)
Received: from lx140e.htt-consult.com (ip70-161-203-70.hr.hr.cox.net [70.161.203.70]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 430096080C; Mon,  2 Sep 2019 11:30:00 -0400 (EDT)
To: Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <cabo@tzi.org>, Henrik Levkowetz <henrik@levkowetz.com>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com>
Date: Mon, 2 Sep 2019 11:29:58 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/BEhQzNrrVcaW8NtELHycfeYga1o>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 15:30:10 -0000

On 9/2/19 11:00 AM, Julian Reschke wrote:
> On 02.09.2019 15:05, Robert Moskowitz wrote:
>> ...
>> I like the occasional fish.
>>
>> Is Henrik's tweak the way for all such references?  Do I need to get a
>> new version of xml2rfc for the tweak,
>>
>> or is Carsten's reply the general way for all such references that have
>> a DOI?
>>
>>
>>>          <?rfc
>>> include="reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202”?> 
>>>
>>
>> I am getting the errorr:
>>
>>   <string>: Line 181: IDREF attribute target references an unknown ID
>> "NIST.SP.800-185"
>>
>> With:
>>
>> <xref target="NIST.SP.800-185">NIST SP 800-185</xref>
>>
>>      <?rfc
>> include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185”?> 
>>
>
> You might need a new version of xml2rfc (I believe there was a problem
> with the cache not using the query parm in the key).
>
> Or try:
>
>   xml2rfc --clear-cache

I am running the current version

$ xml2rfc --version
xml2rfc 2.25.0

and

$ xml2rfc --clear-cache
$ xml2rfc draft-moskowitz-hip-new-crypto-00.xml
Error: Unable to validate the XML document: 
draft-moskowitz-hip-new-crypto-00.xml
  <string>: Line 181: IDREF attribute target references an unknown ID 
"NIST.SP.800-185"

Now what to try?


Perhaps I need to be using python3?  :)

I was told on the Fedora list to run

python3 -m pip install --user xml2rfc

Should I?



From nobody Mon Sep  2 08:34:11 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF83120088 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 08:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 OPQmxYsU__uH for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 08:34:08 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B69120024 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 08:34:08 -0700 (PDT)
Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MYz26xChzywJ; Mon,  2 Sep 2019 17:34:06 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com>
Date: Mon, 2 Sep 2019 17:34:06 +0200
Cc: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
X-Mao-Original-Outgoing-Id: 589131243.2618099-37187d45db496cbbc3d6cfb031433b71
Content-Transfer-Encoding: quoted-printable
Message-Id: <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de> <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com>
To: Robert Moskowitz <rgm@htt-consult.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/TmHWaHquNWyDxqqTUGP5WKyV3B8>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 15:34:10 -0000

Send XML.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Mon Sep  2 08:53:39 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9FF120086 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 08:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level: 
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.789, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT4TpVpIlN8Q for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 08:53:35 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E163120088 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 08:53:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9CE8060945; Mon,  2 Sep 2019 11:53:33 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UgeDNfQEgRmJ; Mon,  2 Sep 2019 11:53:22 -0400 (EDT)
Received: from lx140e.htt-consult.com (ip70-161-203-70.hr.hr.cox.net [70.161.203.70]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id B08986080C; Mon,  2 Sep 2019 11:53:21 -0400 (EDT)
To: Carsten Bormann <cabo@tzi.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de> <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com> <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com>
Date: Mon, 2 Sep 2019 11:53:18 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org>
Content-Type: multipart/mixed; boundary="------------A6FCE481052569B0FF07E366"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/76w5Z3Nnl8N3Gp7tv3s54OkUbVY>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 15:53:38 -0000

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



On 9/2/19 11:34 AM, Carsten Bormann wrote:
> Send XML.
>
> Grüße, Carsten
>
>
Here it is.

It is still very drafty on content,,,



--------------A6FCE481052569B0FF07E366
Content-Type: text/xml;
 name="draft-moskowitz-hip-new-crypto-00.xml"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="draft-moskowitz-hip-new-crypto-00.xml"

﻿<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="std" docName="draft-moskowitz-hip-new-crypto-00" ipr="trust200902">

<front>
<title abbrev="HIP New Crypto">New Cryptographic Algorithms for HIP</title>
	<author fullname="Robert Moskowitz" initials="R" surname="Moskowitz">
    <organization>HTT Consulting</organization>
    <address>
      <postal> 
	    <street></street>
        <city>Oak Park</city>
        <region>MI</region>
        <code>48237</code>
        <country>USA</country>
      </postal>
      <email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Stuart W. Card" initials="S." surname="Card">
	<organization>AX Enterprize</organization>
	<address>
	  <postal>
	    <street>4947 Commercial Drive</street>
	    <city>Yorkville</city>
	    <region>NY</region>
	    <code>13495</code>
	    <country>USA</country>
	  </postal>
	  <email>stu.card@axenterprize.com</email>
	</address>
	</author>
	<author fullname="Adam Wiethuechter" initials="A." surname="Wiethuechter">
	<organization>AX Enterprize</organization>
	<address>
	  <postal>
	    <street>4947 Commercial Drive</street>
	    <city>Yorkville</city>
	    <region>NY</region>
	    <code>13495</code>
	    <country>USA</country>
	  </postal>
	  <email>adam.wiethuechter@axenterprize.com</email>
	</address>
	</author>
<date year="2019" />
   <area>Internet</area>
   <workgroup>HIP</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>HIP</keyword>
<abstract>
<t>
	This document provides new cryptographic algorithms to be used with 
	HIP.  The Edwards Elliptic Curve and the Keccak sponge functions 
	are the main focus. The HIP parameters and processing instructions 
	impacted by these algorithms are defined.
</t>
</abstract>
</front>
<middle>   
<section title="Introduction">
<t> 
	This document adds new cryptographic algorithms for <xref 
	target="RFC7401">HIPv2</xref>. This includes:
	<list style="symbols">
    <t>
		Asymmetric cryptography based the Edwards Elliptic Curve 
		used in Host Identities (HI) and for Base Exchange (BEX) 
		signatures.
    </t>
	<t>
		Hashes used in Host Identity Tag (HIT) generation, and 
		whereever else hashes are needed.
	</t>
	<t>
		Keyed hashes used for KEYMAT generation and packet MACing 
		operations.
	</t>
	<t>
		AEAD and stream ciphers to use in HIP and HIP enabled secure 
		communication protocols.
	</t>
	</list>
</t> 
<t>
	The hashes and encryption are all built on the <xref 
	target="Keccek">Keccek</xref> sponge function.
</t>
<t>
	These additions reflect selection of advances in the field of 
	cryptography that would best benefit HIP, particularly in 
	constrained devices and communications.
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
	<section title="Requirements Terminology">
	<t>
		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 
		"MAY", and "OPTIONAL" in this document are to be interpreted as 
		described in BCP 14 <xref target="RFC2119" /> <xref 
		target="RFC8174" /> when, and only when, they appear in all 
		capitals, as shown here.
	`</t>
	</section>
	<section title="Definitions">
	<t>
		<list style="hanging">
		<t hangText="KECCEK (KECCAK Message Authentication Code):">
			The family of all sponge functions with a KECCAK-f 
			permutation as the underlying function and multi-rate 
			padding as the padding rule.
		</t>
		<t hangText="KMAC (KECCAK Message Authentication Code):">
			A PRF and keyed hash function based on KECCAK.
		</t>
		<t hangText="cSHAKE (The customizable SHAKE function):">
			Extends the SHAKE scheme to allow users to customize their 
			use of the function.
		</t>
		<t hangText="SHAKE (Secure Hash Algorithm KECCAK):">
			A secure hash that allows for an arbitrary output length.
		</t>
		<t hangText="PRF (Pseudorandom Function):">
			A function that can be used to generate output from a 
			random seed such that the output is computationally 
			indistinguishable from truly random output.
		</t>
		<t hangText="capacity:">
			In the sponge construction, the width of the underlying 
			function minus the rate.
		</t>
		<t hangText="rate:">
			In the sponge construction, the number of input bits 
			processed per invocation of the underlying function.
		</t>
		<t hangText="XOF (eXtendable-Output Function):">
			A function on bit strings (also called messages) in which 
			the output can be extended to any desired length.
		</t>
		</list>
	</t>
	</section>
</section>
<section anchor="HIP_param" title="HIP Parameter values for new Crytpo">
	<t>
		HIP parameters carry information that is necessary for 
		establishing and maintaining a HIP association.  For example, 
		the device's public keys as well as the signaling for negotiating 
		ciphers and payload handling are encapsulated in HIP 
		parameters.  Additional information, meaningful for end hosts 
		or middleboxes, may also be included in HIP parameters.  The 
		specification of the HIP parameters and their mapping to HIP 
		packets and packet types is flexible to allow HIP extensions to 
		define new parameters and new protocol behavior.
	</t>
<section anchor="ecdh" title="Elliptic Curves for Diffie-Hellman">
	<t>
		Elliptic curves Curve25519 and Curve448 <xref 
		target="RFC7748">RFC 7748</xref>) are specified here for use in 
		the HIP Diffie-Hellman exchange.
	</t>
	<t>
		Curve25519 and Curve448 are already defined in Section 5.2.1 of 
		<xref target="I-D.ietf-hip-dex"> </xref>, using the HIP-DEX 
		CKDF.  Here they are defined for using the new KMAC <xref 
		target="NIST.SP.800-185">NIST SP 800-185</xref> derived KDF in 
		section n.n.
	</t>
<section anchor="Diffie_Hellman" title="DIFFIE_HELLMAN">
	<t>
		The DIFFIE_HELLMAN parameter may be included in selected HIP 
		packets based on the DH Group ID selected.  The DIFFIE_HELLMAN 
		parameter is defined in Section 5.2.7 of <xref target="RFC7401" 
		/>.
	</t>
	<t>
		The following Elliptic Curves are defined here:
	</t>
    <figure>
      <artwork>
Group                              KDF              Value

Curve25519 [RFC7748]               KKDF             13
Curve448   [RFC7748]               KKDF             14
      </artwork>
    </figure>

	<t>
		A new KDF for KEYMAT, Section 6.5 of <xref target="RFC7401"/> 
		and Section n.n of <xref target="I-D.ietf-hip-dex"> </xref> 
		using Keccek is defined below.
	</t>
</section>
</section>
<section anchor="eddsa" title="Edward Digital Signature Algorithm">
	<t>
		Edwards-Curve Digital Signature Algorithm (EdDSA) (<xref 
		target="RFC8032">RFC 8032</xref>) are specified here for use as 
		Host Identities (HIs).
	</t>
<section anchor="hit_suite_list" title="HIT_SUITE_LIST">
	<t>
		The HIT_SUITE_LIST parameter contains a list of the supported 
		HIT suite IDs of the Responder. Based on the HIT_SUITE_LIST, 
		the Initiator can determine which source HIT Suite IDs are 
		supported by the Responder. The HIT_SUITE_LIST parameter is 
		defined in Section 5.2.10 of <xref target="RFC7401" />.
	</t>
	<t>
		The following HIT Suite IDs are defined for Hierarchical HITs, 
		and the relationship between the four-bit ID value used in the 
		OGA ID field and the eight-bit encoding within the 
		HIT_SUITE_LIST ID field is clarified:
	</t>
	<figure>
        <artwork>
HIT Suite              Four-bit ID    Eight-bit encoding

EDDSA22519/hier/SHAKE128      4             0x40
EDDSA448/hier/SHAKE256        5             0x50
        </artwork>
	</figure>

	<t>
		Note that the Hierarchical HIP HIT Suite ID allows the devices 
		to use the hierarchical RVS discovery and authentication 
		services to validate the peer and discover available services. 
		The Responder SHOULD respond with a HIP hierarchical HIT suite 
		ID when the HIT of the Initiator is a HIP hierarchical HIT.
	</t>
</section>
</section>
</section>
<section anchor="CLIENT_INFO" title="CLIENT_INFO">
	<figure>
        <artwork>
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Type              |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  /                      Client Information                       /
  /                                                               /
  /                               +-------------------------------+
  /                               |            Padding            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Type           [TBD-IANA]
  Length         length in octets, excluding Type, Length, and
                 Padding
  Client         The information required by the HDA in the format
  Information    required by the HDA.
        </artwork>
	</figure>
<t>
	This parameter contains client information to include in the HIT 
	registration.  The specific content and format is set by the HDA.
</t>
</section>

<section anchor="IANA" title="IANA Considerations">
    <t>
	  IANA will need to make the following changes to the "Host 
	  Identity Protocol (HIP) Parameters" registries:
    </t>
    <t>
      <list style="hanging">
        <t hangText="HIT Suite ID:">
		  This document defines the new HIT Suite "Hierarchy with 
		  ECDSA/SHA256" (see <xref target="hit_suite_list" />).
        </t>
        <t hangText="CLIENT_INFO:">
		  This document defines the new CLIENT_INFO parameter (see 
		  <xref target="CLIENT_INFO" />).  The parameter value will be
		  assigned by IANA.
        </t>
      </list>
    </t>
</section>
<section title="Security Considerations">
<t>
	TBD
</t>
</section>
<section title="Acknowledgments">
<t>
	TBD
</t>
</section>
</middle>
<back>
<references title="Normative References">
	<?rfc include="reference.RFC.2119.xml"?>
	<?rfc include="reference.RFC.8174.xml"?>
	<?rfc include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185”?>
</references>
<references title="Informative References">
	<?rfc include="reference.RFC.7401.xml"?>
	<?rfc include="reference.RFC.7748.xml"?>
	<?rfc include="reference.RFC.8032.xml"?>
	<?rfc include="reference.I-D.ietf-hip-dex.xml"?>
<reference anchor="Keccek" target="https://keccak.team/index.html">
  <front>
    <title>The Keccek</title>
<author fullname="Guido Bertoni" initials="G." surname="Bertoni"> 
	<address/> 
</author> 
<author fullname="Joan Daemen" initials="J." surname="Daemen"> 
	<organization>Radboud University</organization>
	<address/> 
</author> 
<author fullname="Michaël Peeters" initials="M." surname="Peeters"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<author fullname="Gilles Van Assche" initials="G." surname="Van Assche"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<author fullname="Ronny Van Keer" initials="R." surname="Van Keer"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<date/>
</front>
</reference>
</references>
</back>
</rfc>

--------------A6FCE481052569B0FF07E366--


From nobody Mon Sep  2 09:42:30 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1E2120098 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 09:42:28 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjvyFWiu02EZ for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 09:42:26 -0700 (PDT)
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 4B9E312004E for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 09:42:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567442531; bh=I54ag4Qy+ShaNsXWaOKq7poOp3cExombXBmRDmEPiCk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VoFjxx5D0IC6yU1C2pMS+YewJgKGqMlV4O575rmzWczH7NMopVvlY7e41uijXfsjL DmYJc4iTU+RV2+b29sys/XAprgkUkKo1tET+iim7imAtpVsV6IGgGLb822D9e0piFv XgR90UiiOkae5KUYCgfzdXJazpL1c01ZEttBDu70=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.155.110]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M42nY-1i4pP91CO8-0004QB; Mon, 02 Sep 2019 18:42:11 +0200
To: Robert Moskowitz <rgm@htt-consult.com>, Carsten Bormann <cabo@tzi.org>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de> <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com> <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org> <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <510ad07e-8ff9-bc73-ef3a-4fdef6e5a26a@gmx.de>
Date: Mon, 2 Sep 2019 18:41:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:ROPlUmtJACDZYM8xigB729tuJpXLh81yiwyxsMza9y/M3ZA+n67 ApGkQnpAHxdWzRLB08E3hRhcOyrE8mS2C8BBA/74cRX5E+WuP9bdXhPxL7WJziD7UE8IY8c ZqsB0Zi+hwYkBm51jqSCEiu+v0zaG9At+n1XgOMgJdkii0/jjVsr0kaPmJTrJuw6Xky5SvK zf04K0JAslapU1gc0ghjg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:z16zRS+1KXY=:AURjdsNHKVsNs3THmDyISZ ZINrqhLScpnX+jQiarPPcblAlAIBhV7GEE83bc+dujN8V5BiPFBcYujBXEs4w+SAJxIZNOhgS dYlY1HpRNCAINARmrPi/czby9MGk9Ss9KPLmWX3lqj4OP8a9L5/8wXxBiaUhzoR4DM4Rm9cNt Fb5sE0+1MLe4xlBnQLWJVNwrS5q4MeungiU7WjvR0RJTO2iO/QzJ1E8PV+fYuHH1XQ7nZywF7 J9tisVoWPswp8kG99aUshUk+U91Z5bTyYwz1wpbMl7YJr/5qohB9nKc+2kDzGg1fP7LanDv4v 3d1PBFV0CcLk/RANvdpp1pWXCqet0CXbf1Q5bXgtkOEYNlmoLOsFm5ID9IOdm5CKQJzVzUlg6 s9FHSp6rkFiBu98xUT8SDkJkDNjfGA6SgKBBQTOUiV0xEGM1MmLMKI6CDo/I8jj81Os8k4yix XpiGVWmK6gPUvyftET3KoNuJta+pQHCIGPMi3P0pZx3mHWfeTL5RXQXUJ2xMaaonPx0zVO7wv SN8YiiBrr6dxyGb4X1OmoSxykROKvbc9RRbuayEQGiJOPyQrTlHmCX4lDpwmjKd12WdJFZJXt Na8Wu4CJGrIjHH5pGRka446p/bPuQ7wMzS5Bc7uRbA6LOPOJxPn/t13zWgQYlJZcove8nVbLf Qd15NbhvE4P6Dg7dSAyC0JBAM9XRzrMmnA7wZFFvPo2DQYo6g5pig/Dda08rhfoo1piVLMI9U PeBqFWDUEdD9CZMXn/NpZsTiSYRj8iIKWbK+zq1XZ/56KSYndY9IvSJaNHIiUkm71es/nIdQZ Yf/WhSy07JSqT7p+imQkUhaMs+lbR5F7d8nMcoUwzEeAyHMayFko00KsGjUQyOIS50RGFyRiG +E7BfwazHrFmjKOFc+6pHXKwBXwwt/XP7vu1yM/QU5YoMXeIND90qJMb0uZIwJ5F/ucsnZzje r/obvjTmXM/JxbjdAP5Jv5XyRwpIt7MUQ6JmlBvnaY3x2vWu30Wa4yeGzB1skMQj3mFWTQXyc jdpbajvXvwW3MaqIj9gvDmtK8Rm4H4oHb9jr6DkVAw/wG6Pp+WAXN+rE2ctMdcOmYuhCKQmqP gj/dsvhb0BU9k+H0B4c/whY4pQZdK09tFAdPzvTJbNDwVSounhmJI4+SuVhsq/RwSBm1371uv tkky2Tz3Zzm6LxgxGBmXbDIZJDo/NvuLMUBCudTOfC8BbdgA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/oHsLZuS3kxpSCxy8XEORYpHme8I>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 16:42:28 -0000

On 02.09.2019 17:53, Robert Moskowitz wrote:
>
>
> On 9/2/19 11:34 AM, Carsten Bormann wrote:
>> Send XML.
>>
>> Gr=C3=BC=C3=9Fe, Carsten
>>
>>
> Here it is.
>
> It is still very drafty on content,,,

rfc2629.xslt reports:

> WARNING: unmatched quote in: reference.DOI.10.6028/NIST.SP.800-185.xml?a=
nchor=3DNIST.SP.800-185=E2=96=92 (at line 307)

Best regards, Julian


From nobody Mon Sep  2 10:02:12 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855831200A1 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 10:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 PwC83JQkbX1k for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 10:02:08 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4743612004E for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 10:02:08 -0700 (PDT)
Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MbwZ2pZtzykL; Mon,  2 Sep 2019 19:02:06 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com>
Date: Mon, 2 Sep 2019 19:02:05 +0200
Cc: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
X-Mao-Original-Outgoing-Id: 589136523.302846-36b98533bd79222cb688ddfd2ddde350
Content-Transfer-Encoding: quoted-printable
Message-Id: <14C25E85-0D7E-4B71-8076-79017272E8A8@tzi.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de> <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com> <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org> <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com>
To: Robert Moskowitz <rgm@htt-consult.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/5SsuXKb8ZnoXevtdMpF7GkQdc7M>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 17:02:11 -0000

Yes, there is a double quote problem in the line:

	<?rfc =
include=3D"reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=3DNIST.SP.800-=
185=E2=80=9D?>

Sorry about that.  If I fix that to

	<?rfc =
include=3D"reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=3DNIST.SP.800-=
185"?>

I get the next error:

 draft-moskowitz-hip-new-crypto-00.xml: Line 311: Unable to resolve =
external request: =
"reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=3DNIST.SP.800-185"

Which is weird because I can resolve

$ curl =
https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/NI=
ST.SP.800-185.xml?anchor=3DNIST.SP.800-185

(And, also,        =20
<?rfc =
include=3D"reference.DOI.10.6028/nist.fips.202.xml?anchor=3DNIST.FIPS.202"=
?>
works.)

There must be something broken with the PI style of referencing in =
xml2rfc that works with the Entity style (which is the only one I use =
now and then).

Henrik: Any idea?  Any sensitivity of the code that adds bibxml7?

Gr=C3=BC=C3=9Fe, Carsten


> On Sep 2, 2019, at 17:53, Robert Moskowitz <rgm@htt-consult.com> =
wrote:
>=20
>=20
>=20
> On 9/2/19 11:34 AM, Carsten Bormann wrote:
>> Send XML.
>>=20
>> Gr=C3=BC=C3=9Fe, Carsten
>>=20
>>=20
> Here it is.
>=20
> It is still very drafty on content,,,
>=20
>=20
> <draft-moskowitz-hip-new-crypto-00.xml>


From nobody Mon Sep  2 10:06:35 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222A6120143 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 10:06:33 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQURc98ySQuH for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 10:06:31 -0700 (PDT)
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 E4BEE120110 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 10:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567443963; bh=vzCW5Fvw42obeUMtLy97dHuvVHxDpHRPGFeoiHIcn4s=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=RrTigfihxhQ4Wt3UVlHhMGTkIC05bTtWHF/waionTFaeh9gyzChDRdFJIO7h3ShYI jy0zbsHqg7gMSCilHgvAca2XcHF65RROIZ1BonBNnZC1+lRp75F/zGo3aeqrmgKqdY RD5Deg9HAqHPNZAjUdh4wMpx4q9qu/7Ti4WlzrJk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.155.110]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lkzph-1icnU73gOb-00alIo; Mon, 02 Sep 2019 19:06:02 +0200
To: Carsten Bormann <cabo@tzi.org>, Robert Moskowitz <rgm@htt-consult.com>
Cc: Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de> <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com> <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org> <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com> <14C25E85-0D7E-4B71-8076-79017272E8A8@tzi.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <8052a7ae-07fe-eb86-28f6-776777bad040@gmx.de>
Date: Mon, 2 Sep 2019 19:06:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <14C25E85-0D7E-4B71-8076-79017272E8A8@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:pwplmmU2DHFOExizmGHII+spfUNbmNmU1UsYCINr78anSP+NVQd XKZlRtqLAqFSmdd0ZxZeQ4DXa0EhrwEI/gVoxoc806oQMt5YJe+UQ+jpMVa148dUliDiA2Y qkG2OrC7hSo4XNH32jDkGdfaESlwb9QZ6HT6BsUhQNVjhMv8W7Qc3T87erZu0V2aZpn6aQS 7nwemwzLzBXxWZ2Vt/CBw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:0ZKHTvMGnrk=:51QEgPKH3wmZub2RuUg4Pm 4HhFMDqPpuFUeNPIZFPzT4ocmMmCZX2NhO3x1FrOyRcurbO4jgBnpvck3GNSIb2/3BQF3njLf //xoURew9TYgoQovHmA1DNPzxtiKs+WFBj4juhn4f5mD0keE6RGreLmzMB33yBu5RhjTATzb1 MBn+AafNgvFDGQLTiwQoJLwJ+r+snw9amb611W7jvTHUoQX4TtvRladnlny+EPQjyI2Q9qiP5 xPzJ8pM40Tc/obNn9Big3aYML5GRA+8x30QKziFIbfaW8s3pzECRrbjwAAOlorXd4oOFSCLVN 0eksR2sui4gJpZjd5eD+aJhdpEh4ffXFXXRlfM3XoDJWqvg0mLVwV9AwkVlC1kRFFnSiVjlD3 jriucbnXCZFa7+EZPjQLoAjF3cpe3iHUf/2hhadve4Ctk/oM4mivglvrsbSeFdh4GwbSPPNWA jMCiFaR7J9Mw1rb52KIQreh3DzkrGJ3FeTjlas2DTk9TGdml1XXeWBG5UjIMufaaHbW+1C2Lg DG92V1VHLuvJhrfXG2puRfc2BffefIxw8BaMWId5o9A3N4idBAYn17cusJglrjWTzuOYGIRUq nnFXOjbjXmfxI4LT7cMzHsQAkt57atW07J+8PWJTKOGhQj1jTLuui5rUgJTML7pwPX2ukvPQn LvFfAUYPt7e83YfVHH1R6aKmOhjHkqr/vgnjgQWmz9+D3dgot76j3k8DcAT3Ej6JUJxW/3QBT t+1cs/xETREFGwubLoqBRZVCchqWCUvGRjZ73aGanF6GndN7lezLqxUyE61cZ9JXxAdd/N02V WMxXur7Em3xV+fZM8cFd4vxAwKjvAYSaPnj2heM8C0jLYQo0hQTL2dBBRB/88V1IusAI61sb0 JgeR554SOf/Uqycc5ld42aHG4nqHDp9dGAMuHofppc/xSIHQhtu26GSrJWXGgNxH3hfQn0OOm G8rEJU+gRjqFl0fg9SnDxU+AwU0NDfYsyByce1DD4FPwude50UQs1GehK8AcB93WVpADTsRhj 3w5ySOg2rHiJ6shllUNFhLQ2u5Tzee4JikhT79INFIuy0kCo+A0SSzaibsSIExeiMVo9hEZls xEb7QIOhyO4hD10A4RGlwSim2RcPYjZG+suTlCShvmOFlPrJhr0YJUAlzmXUXhQBjyWwlZO7h TG+sTGgUWnjwX1vq50c8+Ey4ooWbyf1yzjAvIusk5azicKeg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/OZ0726w6HLmPMzwf0nlhLV5GU1U>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 17:06:33 -0000

On 02.09.2019 19:02, Carsten Bormann wrote:
> Yes, there is a double quote problem in the line:
>
> 	<?rfc include=3D"reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=3DNIS=
T.SP.800-185=E2=80=9D?>
>
> Sorry about that.  If I fix that to
>
> 	<?rfc include=3D"reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=3DNIS=
T.SP.800-185"?>
>
> I get the next error:
>
>   draft-moskowitz-hip-new-crypto-00.xml: Line 311: Unable to resolve ext=
ernal request: "reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=3DNIST.SP=
.800-185"
>
> Which is weird because I can resolve
>
> $ curl https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.1=
0.6028/NIST.SP.800-185.xml?anchor=3DNIST.SP.800-185
>
> (And, also,
> <?rfc include=3D"reference.DOI.10.6028/nist.fips.202.xml?anchor=3DNIST.F=
IPS.202"?>
> works.)
>
> There must be something broken with the PI style of referencing in xml2r=
fc that works with the Entity style (which is the only one I use now and t=
hen).
>
> Henrik: Any idea?  Any sensitivity of the code that adds bibxml7?
> ...

Using the full URI should work...

Best regards, Julian


From nobody Mon Sep  2 11:57:40 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A980D12004F for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 11:57:38 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 j2_WHOg0trwr for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 11:57:37 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DCB12004E for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 11:57:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E62BD60945; Mon,  2 Sep 2019 14:57:34 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DsHdHWXOOcoq; Mon,  2 Sep 2019 14:57:28 -0400 (EDT)
Received: from lx140e.htt-consult.com (ip70-161-203-70.hr.hr.cox.net [70.161.203.70]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 8ECB46080C; Mon,  2 Sep 2019 14:57:27 -0400 (EDT)
To: Carsten Bormann <cabo@tzi.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de> <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com> <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org> <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com> <14C25E85-0D7E-4B71-8076-79017272E8A8@tzi.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <f43a8674-95ec-18e9-0a69-5001709868a3@htt-consult.com>
Date: Mon, 2 Sep 2019 14:57:22 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <14C25E85-0D7E-4B71-8076-79017272E8A8@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/yoVyShqxbzsiBa6BSZJ9oMO4JNc>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 18:57:39 -0000

On 9/2/19 1:02 PM, Carsten Bormann wrote:
> Yes, there is a double quote problem in the line:
>
> 	<?rfc include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185”?>
>
> Sorry about that.  If I fix that to

ARGH!!!  I hate that. I have trouble see the difference, some cut and 
paste did me in...

>
> 	<?rfc include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185"?>
>
> I get the next error:
>
>   draft-moskowitz-hip-new-crypto-00.xml: Line 311: Unable to resolve external request: "reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185"

Yes, why once " is fixed do we get this error.

>
> Which is weird because I can resolve
>
> $ curl https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185
>
> (And, also,
> <?rfc include="reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202"?>
> works.)
>
> There must be something broken with the PI style of referencing in xml2rfc that works with the Entity style (which is the only one I use now and then).
>
> Henrik: Any idea?  Any sensitivity of the code that adds bibxml7?

Weird.   I am heading for the airport (been visiting family in Virginia 
Beach), don't know how much more I will get done today.

>
> Grüße, Carsten
>
>
>> On Sep 2, 2019, at 17:53, Robert Moskowitz <rgm@htt-consult.com> wrote:
>>
>>
>>
>> On 9/2/19 11:34 AM, Carsten Bormann wrote:
>>> Send XML.
>>>
>>> Grüße, Carsten
>>>
>>>
>> Here it is.
>>
>> It is still very drafty on content,,,
>>
>>
>> <draft-moskowitz-hip-new-crypto-00.xml>
>


From nobody Mon Sep  2 11:58:10 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAE712004F for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 11:58:08 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 WzF7B1Dak4M3 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 11:58:06 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F49D120077 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 11:58:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A9C3360945; Mon,  2 Sep 2019 14:58:05 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Zpr2XHRAVIM3; Mon,  2 Sep 2019 14:58:00 -0400 (EDT)
Received: from lx140e.htt-consult.com (ip70-161-203-70.hr.hr.cox.net [70.161.203.70]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A75416080C; Mon,  2 Sep 2019 14:57:59 -0400 (EDT)
To: Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <cabo@tzi.org>
Cc: Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de> <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com> <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org> <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com> <14C25E85-0D7E-4B71-8076-79017272E8A8@tzi.org> <8052a7ae-07fe-eb86-28f6-776777bad040@gmx.de>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <d000b6ef-6da6-dff1-e622-c2150d0ef64e@htt-consult.com>
Date: Mon, 2 Sep 2019 14:57:58 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <8052a7ae-07fe-eb86-28f6-776777bad040@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/NxoPoCP85MwwnrnqLl488lJHClE>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 18:58:08 -0000

On 9/2/19 1:06 PM, Julian Reschke wrote:
> On 02.09.2019 19:02, Carsten Bormann wrote:
>> Yes, there is a double quote problem in the line:
>>
>>     <?rfc 
>> include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185”?>
>>
>> Sorry about that.  If I fix that to
>>
>>     <?rfc 
>> include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185"?>
>>
>> I get the next error:
>>
>>   draft-moskowitz-hip-new-crypto-00.xml: Line 311: Unable to resolve 
>> external request: 
>> "reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185"
>>
>> Which is weird because I can resolve
>>
>> $ curl 
>> https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185
>>
>> (And, also,
>> <?rfc 
>> include="reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202"?>
>> works.)
>>
>> There must be something broken with the PI style of referencing in 
>> xml2rfc that works with the Entity style (which is the only one I use 
>> now and then).
>>
>> Henrik: Any idea?  Any sensitivity of the code that adds bibxml7?
>> ...
>
> Using the full URI should work...

And should not be required.



From nobody Mon Sep  2 12:32:55 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FC9120090 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 12:32:53 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6jvENJhS3Y0 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 12:32:52 -0700 (PDT)
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 EF3B9120077 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 12:32:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567452743; bh=kduLKhS90p4Se+b6cYJlMGfH570hq4Iypd0PSrBhRZs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=D5fRfJ4ZTf+Osi3tLtgAW4f0NrgzhmGtDSAGJPCmpyps1y0Ntnc2nPrFfMves+Tzi 4j1oO+B5Ys9JQv7/WLcDwBAZNN66/GUrDZyCj/VHrMas2UWksa53ngzlnq3toGc8WX 0H1Nx84DEQRI/SDaoiKbDA8DG/ASMFMdLnLNhUng=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.155.110]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LwF9u-1iFMDJ0SIo-0180mL; Mon, 02 Sep 2019 21:32:23 +0200
To: Robert Moskowitz <rgm@htt-consult.com>, Carsten Bormann <cabo@tzi.org>
Cc: Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de> <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com> <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org> <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com> <14C25E85-0D7E-4B71-8076-79017272E8A8@tzi.org> <8052a7ae-07fe-eb86-28f6-776777bad040@gmx.de> <d000b6ef-6da6-dff1-e622-c2150d0ef64e@htt-consult.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <36405e86-c3e7-2477-0ebb-8c034943cd8b@gmx.de>
Date: Mon, 2 Sep 2019 21:32:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <d000b6ef-6da6-dff1-e622-c2150d0ef64e@htt-consult.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:MkGb4G6JrkYfVKiYYlVvN66wTKQqpta6GAtz0wglMyR+C0EIGT6 /kS4D+Q3GLUWCoI5gGymZW+SitpQn3d9x32JpHjcFtnhltUwtZuRoz0T5NEUbG9bMVR9gMa WWDkxwqzZYKwycCMlNU+/OXvMtpCQyJ6pALdVn+s+WugmXm7URxHUucOjyLmyJIaWU6sa2A Xo1nYo4uNSN8wWH5xiB4g==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7M5KgXYkLFI=:asKxSIpsV356L0bE4C1JxP JgzKcrxLTUL2RMwjyfm+gBiqgTqIuA7BN0j7IrCZhY4H4rfDE9nMrvEyR7z/iGoxNwA1PQcnf qivbF63WMisOce4QX+hmLy4sPzD8rjMJpleXt8xiSAWzbP3Di/r71OWZGwwc2qrOv78OP5y2c A/BlOoeAzrTuHJtrOn0cA6COQjfArbILbmjeQbUX+yn7vQo4dtQxdQp7dXQzNY+aEGAG1eh8T ZStGr7jnl5O8ABhAHEJXQ7mCrZKRObxsqJYFxsLYQ+JhTEsQpj+T9mPJIYlAgEbVLeUNFJR8O TroS2RypK6e5HGl8d6dMBQLmElZgRCMApoSI0Zg7k4ZBHDKmc6VFBesq27VCgjc56saGeBIbA VlUyVTswVfzEbq6YTzU4Kj4iQT+PZMggIJHmAT71GpyJqnRwUgODyIpusz8cioLMPEAsfAbzs gnVq7ArdoJ2/CaBHl2ziquWzaWwT1X668n/tuAD4oNOv9Jd6NRe4Q6t1hnRfxszTeng0qKfU5 eVO2Q1FA+mU8SOEOsZzrzGcRU9YsdYbUBSfm6bEJir34MhlmYTmwIGjLlc4mWHCiRHJU33qc8 d5KlJZ2AT9sX2HJaoCMjjpyXNHqB5vPKNBKdFenYjQndBK7m1D1Cp8Subz2K+aOm2608PEbCP BcDZw3gGUxTq2q4g05ZRMP3OMaxQx3LwO0+Jmb80TJNGWI/chrbMo0QARworvlKVOoZCHSQDC 7/2RWbfV5HLV4fNdoonPoQ0ZR3j0uu8yjCAO88zwOkTJ5cp53gHgl154jG6pgMd6bd+uDLEJC 70w31eyYq/YwFOwDd0Zt881d57CACQvHHYCQ+pWx96woEHdRfRVdhYj1nmkSB7BM+dIbPQxOg ygo+0gnawa8/TTutfl8twK8tbBItaGSJBzk5VK8A947/f4GYTWwv3XnpdMaKQh7QU0fXOjy2a FalQN19BKwyc5r+9s39Wmzsz4asRGoM7D6zpn5ZsM2YIqafA8pg8ZEPwKOCMFbOYxsBg251vd k/XLdZTArtd0pHwd0fBtwyinaXAE1qaGzU/R10WN9Hcj0stgoFq68othTFUHHap1M8uhBrs2z iO4bgXF3HgwejiSExmru6N0ir6ORNDTUAdUZp05xeaekA7SxjepnufkJrwGgoHBXaU/BT3Wci q+6OBDbbS0ElwwyleJW5xO/BzLVNSCvYH41Kqp5gYoQqtxAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/wXqFqz0RkebfwRy7YAZj21rxB6k>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 19:32:54 -0000

On 02.09.2019 20:57, Robert Moskowitz wrote:
> ...
>> Using the full URI should work...
>
> And should not be required.

I have to disagree with that. These are heuristics in URI resolution. Do
not rely on it. If you know the URI, use it. If only to avoid
unnecessary round trips.

Best regards, Julian


From nobody Mon Sep  2 13:09:52 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2309C120090 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 13:09:51 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 Fc5iUZDa8EvM for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 13:09:49 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF7212003E for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 13:09:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CDC6B60945; Mon,  2 Sep 2019 16:09:46 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NXFfZP4p2ZDB; Mon,  2 Sep 2019 16:09:40 -0400 (EDT)
Received: from lx140e.htt-consult.com (250.sub-174-226-8.myvzw.com [174.226.8.250]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 146D86080C; Mon,  2 Sep 2019 16:09:38 -0400 (EDT)
To: Carsten Bormann <cabo@tzi.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <82917fcc-2801-a417-4c35-e8ef0f059590@htt-consult.com> <d1d69960-c676-b1ec-11fc-b79a4d443855@levkowetz.com> <EEB566B4-E5C4-4621-A45B-3770CAE2464E@tzi.org> <df76ae71-954b-ce74-f0fa-ba4a3e31ccbc@htt-consult.com> <da25a0b0-be77-782c-6eec-34121cd714a4@gmx.de> <d1fe020a-a978-46fc-25e9-268b1a99d3fb@htt-consult.com> <1176D078-53E0-47DF-8A28-5DF32CC73375@tzi.org> <ec8a35be-3d0d-e7be-2f31-ae25016819a4@htt-consult.com> <14C25E85-0D7E-4B71-8076-79017272E8A8@tzi.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <a3beaa91-827b-290d-8cbe-308345fb5682@htt-consult.com>
Date: Mon, 2 Sep 2019 16:09:28 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <14C25E85-0D7E-4B71-8076-79017272E8A8@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/iBA5re7NIXvtNZGRtwTJI_rzgtI>
Subject: Re: [xml2rfc] references for NIST
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 20:09:51 -0000

On 9/2/19 1:02 PM, Carsten Bormann wrote:
> Yes, there is a double quote problem in the line:
>
> 	<?rfc include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185”?>
>
> Sorry about that.  If I fix that to
>
> 	<?rfc include="reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185"?>
>
> I get the next error:
>
>   draft-moskowitz-hip-new-crypto-00.xml: Line 311: Unable to resolve external request: "reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185"
>
> Which is weird because I can resolve
>
> $ curl https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185

     <?rfc 
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185"?>


Works, but IMHO, the full URI should not be needed.

> (And, also,
> <?rfc include="reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202"?>
> works.)

<?rfc 
include="reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202"?>

Did not work for me:

Error: Unable to parse the XML document: 
draft-moskowitz-hip-new-crypto-00.xml
  draft-moskowitz-hip-new-crypto-00.xml: Line 346: Unable to resolve 
external request: 
"reference.DOI.10.6028/nist.fips.202.xml?anchor=NIST.FIPS.202"


>
> There must be something broken with the PI style of referencing in xml2rfc that works with the Entity style (which is the only one I use now and then).
>
> Henrik: Any idea?  Any sensitivity of the code that adds bibxml7?
>
> Grüße, Carsten
>
>
>> On Sep 2, 2019, at 17:53, Robert Moskowitz <rgm@htt-consult.com> wrote:
>>
>>
>>
>> On 9/2/19 11:34 AM, Carsten Bormann wrote:
>>> Send XML.
>>>
>>> Grüße, Carsten
>>>
>>>
>> Here it is.
>>
>> It is still very drafty on content,,,
>>
>>
>> <draft-moskowitz-hip-new-crypto-00.xml>
>


From nobody Mon Sep  2 19:43:10 2019
Return-Path: <randy@psg.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F7012003F for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 19:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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 uwSkI1ykk0Q1 for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 19:43:07 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBA212001E for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 19:43:07 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1i4ymf-0004U5-H8 for xml2rfc@ietf.org; Tue, 03 Sep 2019 02:43:05 +0000
Date: Mon, 02 Sep 2019 19:43:05 -0700
Message-ID: <m2ftlecd6u.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: XML2RFC Interest Group <xml2rfc@ietf.org>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/SjXy2l6rhAmtv9ibh3Vz2dgYuAY>
Subject: [xml2rfc] txt to xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 02:43:10 -0000

is there a hack to turn a draft.txt into draft.xml?

randy, still googling


From nobody Mon Sep  2 20:04:05 2019
Return-Path: <randy@psg.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AB01201CE for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 20:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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 P051RMM1Hyot for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 20:03:50 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9DA12021C for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 20:03:49 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1i4z6g-0004Wg-Ao for xml2rfc@ietf.org; Tue, 03 Sep 2019 03:03:47 +0000
Date: Mon, 02 Sep 2019 20:03:46 -0700
Message-ID: <m2ef0ycc8d.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: XML2RFC Interest Group <xml2rfc@ietf.org>
In-Reply-To: <m2ftlecd6u.wl-randy@psg.com>
References: <m2ftlecd6u.wl-randy@psg.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/O8Rc-Z9lcYnODIqjux75bLsg8HI>
Subject: Re: [xml2rfc] txt to xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 03:04:03 -0000

and https://xml2rfc.tools.ietf.org/ yields

Traceback (most recent call last):
  File "/usr/local/bin/id2xml", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3250, in <module>
    @_call_aside
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3234, in _call_aside
    f(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3263, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 585, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 598, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 786, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'id2xml==1.4.5.dev0' distribution was not found and is required by the application


From nobody Mon Sep  2 21:30:42 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77541200EC for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 21:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CC8UEhSEiIXx for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 21:30:39 -0700 (PDT)
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 A18C91200E6 for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 21:30:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567485018; bh=DJP9vnZObfSU68NluhOc5MvrFkk1xTwAy73EE9q0VUI=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=HT8gByvQAzFS0uqlINV0qjl2wKmkoGM9R9grrTP1OyuaO6/5YSTy+FalL3XTwKYVo ACka4fHJdviwI+AWLgKfXZ44q+09sIRCPe1n4UuFIP2pG4O2VUujTxlVia6sU/p234 g8p5EZDTZKsKTCAp9KTczc9qMK0P5xCUeK98fbQc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([91.61.49.180]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N9dsb-1iGbWx2CO5-015Z9Z; Tue, 03 Sep 2019 06:30:18 +0200
To: Randy Bush <randy@psg.com>, XML2RFC Interest Group <xml2rfc@ietf.org>
References: <m2ftlecd6u.wl-randy@psg.com> <m2ef0ycc8d.wl-randy@psg.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <ddbf5c49-956d-8b86-63a8-b2651dbb724c@gmx.de>
Date: Tue, 3 Sep 2019 06:30:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <m2ef0ycc8d.wl-randy@psg.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:EVFyprCGcQPJRMCHGj2m0gngEqon+W5d/Dpms44JUv5LW5wUCGJ uhJXwMx+JXWFnLQhBFjhs5f5u/z3MISQjqH2/ONgwHF2WpwHPcRlyG3gidOKiTkM9Ahy2Cy N0HLArMssrU1hVUMgLfFb810v91CMcYo+RSpxkko5gbwu/mjxaXS9HBa55ZZYI/WF2xyd+y v7ye3l8Wkf6I90JRT0RzQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:ZoP8agTfOKA=:bpAdBITlTbWiJXntLcnuU8 gnUcmzy3cIexveqIAbNlJTAqefxFl/aKF/fhBkPWv9wRFk+AyKts6LviS0sfAHCiJ+oGWLwCL mSyflT/hGjITvbBNfsaH17npppGDw7xN6D62U9tcV65xd6sMqXb96tRFPmfkWNPUXD4x1nBBw xr5/jL+8phhfQcJaR4Bqj7CdXqV5qZ18JICpnPFkeSaWKT9urIBUtMXEQ7v+KRSON2PObUw9U 2dWhX2QPFKwUPUuEjBtr2w2/4fT8yyCyGnq7Z2xpEFf+t6n9aNV+bMk+D/NH93ho+R8rt5R3I MM0X7BT57UGrijtSMKgN75L/4tndHF/oh8DjKDEzzlGh8a688fuXMLRuo3dNy0k9Ur2oZ6Wpq Myyy4Q0vYZGTxGYTTKShuIihZ82IoHMNTCPSG06QY++JBuPbrrVM2YiNWbFWjvHvGL6F54A3U FhCVVWjajJVQKyPLNZ5mfg2UPToBO566Be7IgvhtjRXANpbxT61FEoLIFK96uomjFIqPLB0z2 GgJ/B9Tl4QSCLr1wEwD1rSIEDenUKw6QBkbrlb5JMmaTKA/kBh9hVKNeM0JLhAemnCWP3LbIt BWWmLPSRfVEp/ziRn0KUJSxmmBaGXOg/VZW/ZvSbS7rBfH0pRSLaIw10GFbpeY2dIiEpRqEoL h2S5pL5q1XKclmm9MZtSr+uEabodXemaIyHBQAV/UVQJxUPL5qibTcvG+kefl9zU1FELRDSWY gfBg1x1uvfml5XzlMyUlKa8puA2GBa5X0i18t4oTvKjYl/vp6fbVcp0VsgX6w7yKzIeeWzYRQ cQtGhCbdBy3DSGJJo0gvQim3muoHd3wUXJKyWzwCPFe834kA1HMx58R56ZZLXBE3W33tbrHDp 38EL+tLpDCCGu/Rv1eaCL3PSRx1piNZ2pRnI8Vp8FdvF6negndrcA/30mGZSYowKzfGdoVyMf h/VwTCU3n5Vcxdbl75UmJ0AOVRo5e4CRF7753+3WhgW1sPp2W8Q7NOAuZSmLGPdNPywKs63oK DOoID2yRi3uCcqBT47DyO+YJVLPPdD/ZbRL+rFrxBaMiZbfO1BoeHwnV08+yjHbKAl0vbhRyg GwSKNDEW3yIXqOvu6YbnnL7aiTtLtaYgUQFe+hxp6fCgGWh78wROHKiZrMhZMOXA7azxMSzOj mDJoJ7BXMWIm95b6LL3cwETj4OxO/FC8i4ScLY6bjEAKlvMg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/ey9DN25WdTSFTb-9ZTY7vtR2Gx0>
Subject: Re: [xml2rfc] txt to xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 04:30:41 -0000

On 03.09.2019 05:03, Randy Bush wrote:
> and https://xml2rfc.tools.ietf.org/ yields
>
> Traceback (most recent call last):
>    File "/usr/local/bin/id2xml", line 6, in <module>
>      from pkg_resources import load_entry_point
>    File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 3250, in <module>
>      @_call_aside
>    File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 3234, in _call_aside
>      f(*args, **kwargs)
>    File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 3263, in _initialize_master_working_set
>      working_set =3D WorkingSet._build_master()
>    File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 585, in _build_master
>      return cls._build_from_requirements(__requires__)
>    File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 598, in _build_from_requirements
>      dists =3D ws.resolve(reqs, Environment())
>    File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 786, in resolve
>      raise DistributionNotFound(req, requirers)
> pkg_resources.DistributionNotFound: The 'id2xml=3D=3D1.4.5.dev0' distrib=
ution was not found and is required by the application

You can try a local install:

   pip install id2xml

This got me version 1.4.4, which might explain what's wrong on the web
page...

Best regards, Julian

PS: if you need the XML for a past RFC, let me know; I might have it.


From nobody Mon Sep  2 23:38:52 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6996F1200FB for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 23:38:51 -0700 (PDT)
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, SPF_HELO_NONE=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 lPkXFehxknHR for <xml2rfc@ietfa.amsl.com>; Mon,  2 Sep 2019 23:38:49 -0700 (PDT)
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 65CF91200CC for <xml2rfc@ietf.org>; Mon,  2 Sep 2019 23:38:49 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:52135 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 1i52Sm-0007Us-4A; Mon, 02 Sep 2019 23:38:48 -0700
To: Randy Bush <randy@psg.com>, XML2RFC Interest Group <xml2rfc@ietf.org>
References: <m2ftlecd6u.wl-randy@psg.com> <m2ef0ycc8d.wl-randy@psg.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <38c22104-9ae0-21d7-3ad8-6bced42c4b6b@levkowetz.com>
Date: Tue, 3 Sep 2019 08:38:27 +0200
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: <m2ef0ycc8d.wl-randy@psg.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2Ug5ncXd0KCTLl7hEDDlsIVhIxNLUmrjw"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, randy@psg.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/mLyTo-UXjnCuyy7ZFTufp1vDJJQ>
Subject: Re: [xml2rfc] txt to xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 06:38:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2Ug5ncXd0KCTLl7hEDDlsIVhIxNLUmrjw
Content-Type: multipart/mixed; boundary="HhNMaxClGgkbM1kb16NwltmDsjIeDWhlS";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Randy Bush <randy@psg.com>, XML2RFC Interest Group <xml2rfc@ietf.org>
Message-ID: <38c22104-9ae0-21d7-3ad8-6bced42c4b6b@levkowetz.com>
Subject: Re: [xml2rfc] txt to xml
References: <m2ftlecd6u.wl-randy@psg.com> <m2ef0ycc8d.wl-randy@psg.com>
In-Reply-To: <m2ef0ycc8d.wl-randy@psg.com>

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

Hi Randy,

Yes, id2xml is the answer to your previous question.

As for the traceback below: Uh, oh!  Ok, fixed.  Thanks for the alert!

Best regards,

	Henrik

On 2019-09-03 05:03, Randy Bush wrote:
> and https://xml2rfc.tools.ietf.org/ yields
>=20
> Traceback (most recent call last):
>   File "/usr/local/bin/id2xml", line 6, in <module>
>     from pkg_resources import load_entry_point
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 3250, in <module>
>     @_call_aside
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 3234, in _call_aside
>     f(*args, **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 3263, in _initialize_master_working_set
>     working_set =3D WorkingSet._build_master()
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 585, in _build_master
>     return cls._build_from_requirements(__requires__)
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 598, in _build_from_requirements
>     dists =3D ws.resolve(reqs, Environment())
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.p=
y", line 786, in resolve
>     raise DistributionNotFound(req, requirers)
> pkg_resources.DistributionNotFound: The 'id2xml=3D=3D1.4.5.dev0' distri=
bution was not found and is required by the application
>=20
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc
>=20


--HhNMaxClGgkbM1kb16NwltmDsjIeDWhlS--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl1uCmMACgkQTptXS4+7
FxqK8xAApDBuRRqPBZANQzabGqpqQo7pPuzIxdC+4w5A0mxqPeqjbPJmglfPgOv6
gxVbeXYUyhMvnin3Q3AdUIuHAdAHcFomjUtvkIuhOxbiWEncYWPrMwX3L6CLv+F3
ti/8cN2r0lq7lFAEEDhkDE2qQNGYnNwjd/8PzPWySNCmgZ5YrdJIfCqy0Z25t8xh
zWgE/kAO2nqA3CSqcjPfQQTbafBReWLPs5U1+qLTzcs00WKVmGvf492LtaGNd2MH
o+wFY0Ft3ZlzB4eG3DjfpPfXWORjTPQkVAG7b/pCYOPf+XjOfDuTHj0i+bwv+Ut3
3pRnPujliE8FthS3gslxNsvPzI/colOINs/qn0fnyxMWmJyOZ2AHI7/MNsVSL9ic
HkHQgsEJKwQF2oRHPLA1SrjD69UQ2GSKPl0qHjsZssnUy8bVyvEu2UbuoANT6vO4
W4uorXwURfLbRI3r/DeryjiMdHFvv28kftBkq464Aa5lMT1Ac3XjSjt4IAAwRujW
7bmodQRIqF4FdMkAVEjNMtyMsObjmy8tbu0BlmEq6nsgLAag/xUrg4yuudEYBJ1B
Tf0fzQ9H0vwys5JJzykPiBquxqlH0WGr/VV6uv1DjeNMIHLWMgTivtm+JRQEXpGC
pCraA3lohDJAbu6jIxiCtvOadul28m5f2IB8SBlyllu1DW64XLU=
=xIf2
-----END PGP SIGNATURE-----

--2Ug5ncXd0KCTLl7hEDDlsIVhIxNLUmrjw--


From nobody Tue Sep  3 02:54:27 2019
Return-Path: <trac@tools.ietf.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92FD12006F for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 02:54:24 -0700 (PDT)
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, SPF_HELO_NONE=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 un-yDZ7JZrcS for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 02:54:23 -0700 (PDT)
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 108EB120041 for <xml2rfc@ietf.org>; Tue,  3 Sep 2019 02:54:23 -0700 (PDT)
Received: from localhost ([::1]:48559 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1i55W2-0007SJ-Er; Tue, 03 Sep 2019 02:54:22 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "xml2rfc issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Cc: xml2rfc@ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: julian.reschke@gmx.de
X-Trac-Project: xml2rfc
Date: Tue, 03 Sep 2019 09:54:20 -0000
X-URL: http://tools.ietf.org/tools/xml2rfc/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/422
Message-ID: <069.7c3f3bee603cd2ce5e2ad5a0e7845cb9@tools.ietf.org>
X-Trac-Ticket-ID: 422
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: julian.reschke@gmx.de, xml2rfc@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/KzEJlo8AvhZN_zYe2v77IjKMGg0>
Subject: [xml2rfc] #422 (Version_3_cli_txt): xref format=title for references "[" and "]"
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 09:54:25 -0000

#422: xref format=title for references "[" and "]"

 ...as seen in elements.xml's output:

 {{{

    *  No text and format="title": Sections 3.2 and 3.3 of [The Use of
       Non-ASCII Characters in RFCs].
 }}}

 As per RFC 7991
 (<https://greenbytes.de/tech/webdav/rfc7991.html#element.xref.attribute.format>),
 I don't see why the square brackets are inserted here (same in HTML
 output).

 (and yes, for default and counter formats, this is correct)

-- 
-----------------------------------+--------------------
 Reporter:  julian.reschke@gmx.de  |      Owner:
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  Version_3_cli_txt      |    Version:  2.25.*
 Keywords:                         |
-----------------------------------+--------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/422>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>


From nobody Tue Sep  3 03:15:33 2019
Return-Path: <trac@tools.ietf.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A471412004D for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 03:15:31 -0700 (PDT)
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, SPF_HELO_NONE=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 LSKOEisk6Ok2 for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 03:15:30 -0700 (PDT)
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 015F7120026 for <xml2rfc@ietf.org>; Tue,  3 Sep 2019 03:15:29 -0700 (PDT)
Received: from localhost ([::1]:49047 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1i55qT-0008A0-9l; Tue, 03 Sep 2019 03:15:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "xml2rfc issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Cc: xml2rfc@ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: henrik@levkowetz.com, julian.reschke@gmx.de
X-Trac-Project: xml2rfc
Date: Tue, 03 Sep 2019 10:15:29 -0000
X-URL: http://tools.ietf.org/tools/xml2rfc/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/419#comment:3
Message-ID: <084.70443407c08af6f659f3e125714fbcbc@tools.ietf.org>
References: <069.d5d30ff1a5db56e9a2891f7905ff7012@tools.ietf.org>
X-Trac-Ticket-ID: 419
In-Reply-To: <069.d5d30ff1a5db56e9a2891f7905ff7012@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/7XqAziQNiQYQ9oaFQw8cmttY6I4>
Subject: Re: [xml2rfc] #419 (Version 2 cli): Error: Invalid attribute displayFormat for element xref
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 10:15:32 -0000

#419: Error: Invalid attribute displayFormat for element xref


Comment (by julian.reschke@gmx.de):

 I missed that relref's displayFormat maps to xref's sectionFormat.

 Sorry for the noise.

-- 
------------------------------------+----------------------------------
  Reporter:  julian.reschke@gmx.de  |      Owner:  henrik@levkowetz.com
      Type:  defect                 |     Status:  new
  Priority:  medium                 |  Milestone:
 Component:  Version 2 cli          |    Version:  2.24.*
Resolution:                         |   Keywords:
------------------------------------+----------------------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/419#comment:3>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>


From nobody Tue Sep  3 03:16:02 2019
Return-Path: <trac@tools.ietf.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1520112004D for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 03:16:02 -0700 (PDT)
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, SPF_HELO_NONE=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 WjURq1-Wcr67 for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 03:16:00 -0700 (PDT)
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 D43D7120026 for <xml2rfc@ietf.org>; Tue,  3 Sep 2019 03:16:00 -0700 (PDT)
Received: from localhost ([::1]:49063 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1i55qy-0003lH-Fw; Tue, 03 Sep 2019 03:16:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "xml2rfc issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Cc: xml2rfc@ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: henrik@levkowetz.com, julian.reschke@gmx.de
X-Trac-Project: xml2rfc
Date: Tue, 03 Sep 2019 10:16:00 -0000
X-URL: http://tools.ietf.org/tools/xml2rfc/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/419#comment:4
Message-ID: <084.934c0199251efe56974706438616c788@tools.ietf.org>
References: <069.d5d30ff1a5db56e9a2891f7905ff7012@tools.ietf.org>
X-Trac-Ticket-ID: 419
In-Reply-To: <069.d5d30ff1a5db56e9a2891f7905ff7012@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/YAwJwEzbcBpVM1db6bgtRYgwa3Q>
Subject: Re: [xml2rfc] #419 (Version 2 cli): Error: Invalid attribute displayFormat for element xref
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 10:16:02 -0000

#419: Error: Invalid attribute displayFormat for element xref

Changes (by julian.reschke@gmx.de):

 * status:  new => closed
 * resolution:   => invalid


-- 
------------------------------------+----------------------------------
  Reporter:  julian.reschke@gmx.de  |      Owner:  henrik@levkowetz.com
      Type:  defect                 |     Status:  closed
  Priority:  medium                 |  Milestone:
 Component:  Version 2 cli          |    Version:  2.24.*
Resolution:  invalid                |   Keywords:
------------------------------------+----------------------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/419#comment:4>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>


From nobody Tue Sep  3 07:35:02 2019
Return-Path: <trac@tools.ietf.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F68120838 for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 07:34:57 -0700 (PDT)
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, SPF_HELO_NONE=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 ls_ggYoskadG for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 07:34:54 -0700 (PDT)
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 E712312083F for <xml2rfc@ietf.org>; Tue,  3 Sep 2019 07:34:54 -0700 (PDT)
Received: from localhost ([::1]:54287 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1i59tW-00060D-0N; Tue, 03 Sep 2019 07:34:54 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "xml2rfc issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Cc: xml2rfc@ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: julian.reschke@gmx.de
X-Trac-Project: xml2rfc
Date: Tue, 03 Sep 2019 14:34:53 -0000
X-URL: http://tools.ietf.org/tools/xml2rfc/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/423
Message-ID: <069.706ba22edb3c9904737bc5d0a762d20d@tools.ietf.org>
X-Trac-Ticket-ID: 423
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: julian.reschke@gmx.de, xml2rfc@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/h156o9RAJ3kV3xfy230xRBiLhg8>
Subject: [xml2rfc] #423 (Version_3_cli_txt): formatting issues with many "obsoletes"
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 14:35:00 -0000

#423: formatting issues with many "obsoletes"

 TXT output (v3):

 {{{

 HTTP Working Group                                      R. Fielding, Ed.
 Internet-Draft                                                     Adobe
 Obsoletes7230,7231,7232,7233,7235,7538,7615 (if       M. Nottingham, Ed.
            approved)                                              Fastly
 Intended status: Standards Track                      J. F. Reschke, Ed.
 Expires: 6 March 2020                                         greenbytes
                                                         3 September 2019
 }}}

 HTML output repeats "obsoletes" for each RFC, but then appends "(if
 approved)" only to last instance.

-- 
-----------------------------------+--------------------
 Reporter:  julian.reschke@gmx.de  |      Owner:
     Type:  defect                 |     Status:  new
 Priority:  medium                 |  Milestone:
Component:  Version_3_cli_txt      |    Version:  2.25.*
 Keywords:                         |
-----------------------------------+--------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/423>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>


From nobody Tue Sep  3 09:57:03 2019
Return-Path: <trac@tools.ietf.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E880120043 for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 09:57:02 -0700 (PDT)
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, SPF_HELO_NONE=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 l-wwzJQVJ9bE for <xml2rfc@ietfa.amsl.com>; Tue,  3 Sep 2019 09:57:00 -0700 (PDT)
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 DDA5C120071 for <xml2rfc@ietf.org>; Tue,  3 Sep 2019 09:57:00 -0700 (PDT)
Received: from localhost ([::1]:57006 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1i5C72-0008EV-BF; Tue, 03 Sep 2019 09:57:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "xml2rfc issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Cc: xml2rfc@ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: henrik@levkowetz.com
X-Trac-Project: xml2rfc
Date: Tue, 03 Sep 2019 16:57:00 -0000
X-URL: http://tools.ietf.org/tools/xml2rfc/
X-Trac-Ticket-URL: /ticket/423#comment:1
Message-ID: <084.85f8977670daf4881f74169b5a3fd7e3@tools.ietf.org>
References: <069.706ba22edb3c9904737bc5d0a762d20d@tools.ietf.org>
X-Trac-Ticket-ID: 423
In-Reply-To: <069.706ba22edb3c9904737bc5d0a762d20d@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/UFClxFx6oQiN5tBix0T6h0MqltU>
Subject: Re: [xml2rfc] #423 (Version_3_cli_txt): formatting issues with many "obsoletes"
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 16:57:02 -0000

#423: formatting issues with many "obsoletes"

Changes (by henrik@levkowetz.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Fixed in [3268]:

 Fixed broken rendering of Obsoletes: and Updates:, broken in different
 ways in v3 HTML and v3 text output.  Fixes issue #423.

-- 
------------------------------------+--------------------
  Reporter:  julian.reschke@gmx.de  |      Owner:
      Type:  defect                 |     Status:  closed
  Priority:  medium                 |  Milestone:
 Component:  Version_3_cli_txt      |    Version:  2.25.*
Resolution:  fixed                  |   Keywords:
------------------------------------+--------------------

Ticket URL: </ticket/423#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>


From nobody Tue Sep  3 12:58:24 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85574120047; Tue,  3 Sep 2019 12:58:06 -0700 (PDT)
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, SPF_HELO_NONE=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 rT-EMGBZ6ZDZ; Tue,  3 Sep 2019 12:58:04 -0700 (PDT)
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 A2AA6120043; Tue,  3 Sep 2019 12:58:04 -0700 (PDT)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1i5EwG-00014Q-GV; Tue, 03 Sep 2019 12:58:04 -0700
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1i5EwG-00014Q-GV@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Tue, 03 Sep 2019 12:58:04 -0700
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/DImq6v3MC6maEN8ame3EWozmCYM>
Subject: [xml2rfc] New xml2rfc release: v2.26.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 19:58:07 -0000

Hi,

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

Release notes:

xml2rfc (2.26.0) ietf; urgency=medium

  * Fixed a broken rendering of Obsoletes: and Updates:, broken in different 
    ways in v3 HTML and v3 text output.  Fixes issue #423.

  * Added an alternative style sheet from Martin Thomson (reachable with
    --css=mt) and rewrote the code to read in alternative style sheets to look
    in more places. Also added a mt.js file to go with the mt.css file, and
    tweaked the html renderer to load an alternative .js file if an
    alternative .css file is set and a matching .js exists.

  * Fixed an issue with nested <ul> with emtpy="true".

  * Added a test, with error exit, for duplicate <displayreference> 
    replacement terms.  Fixes issue #421.

  * Changed the rendering of Internet-Draft references to follow
    draft-flanagan-7322bis-03 (RFC Style Guide bis) more closely.

  * Made the address pane for authors' addresses wider, to accomodate very 
    long email addresses.  Changed the bottom margin for some styles used by 
    figures in order to get the same caption placement for figures and tables.

  * Removed the computed <dl><dd> text mode indentation, and replaced it 
    with a fixed indentation of 3.

  * Added an example section using <aside> to element.xml.  Updated the 
    <xref> examples that use the section attribute.

  * Updated the prepping and rendering of <xref> with section settings to
    better handle sectionFormat="bare", and changed the handlin of the
    metadata.js script in HTML output.

  * Added a minified version of the metadata.js script, updated the help text
    for the --external-css switch, and changed the default for the
    --metadata-js-url switch to use the minified metadata.js file, and changed
    the metadata_js_url setting for invocation of xml2rfc renderers as library
    modules to use the minified metadata.js

  * Updated metadata.js with a new copy received from the RFC Editor staff.

  * Added a warning for mismatch between <rfc number="..."> and 
    <seriesInfo name="RFC" value="...">.

  * Modified the v2v3 conversion code to deal correctly with multiple 
    instances of <artwork> within an unlabelled Figure.  Modified the converter 
    to avoid some lxml-related issues under python 3.x.

  * Updated XmlRfc.__init__() with a new keyword argument to set source 
    file, needed when using the v2v3 converter as a library function (such as 
    from id2xml in v3 mode).

  * Incorporated a new updated copy of the original CSS stylesheet received 
    from the original contractor.

 -- Henrik Levkowetz <henrik@levkowetz.com>  03 Sep 2019 12:56:52 -0700

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.26.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Tue Sep  3 13:55:46 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657CC12004E; Tue,  3 Sep 2019 13:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 w0BmzoI3VJAp; Tue,  3 Sep 2019 13:55:29 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095ED120045; Tue,  3 Sep 2019 13:55:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 7F23A62117; Tue,  3 Sep 2019 16:55:27 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i15umDch2Clw; Tue,  3 Sep 2019 16:55:23 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id DF1D5620EE; Tue,  3 Sep 2019 16:55:20 -0400 (EDT)
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
References: <E1i5EwG-00014Q-GV@durif.tools.ietf.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <1d7e7040-d294-a5e0-ddac-399bf84578bb@htt-consult.com>
Date: Tue, 3 Sep 2019 16:55:12 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <E1i5EwG-00014Q-GV@durif.tools.ietf.org>
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/w9PmsvaA3bnMZqKJxReWVmGI1bo>
Subject: Re: [xml2rfc] New xml2rfc release: v2.26.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 20:55:31 -0000

On 9/3/19 3:58 PM, Henrik Levkowetz wrote:
> Hi,
>
> This is an automatic notification about a new xml2rfc release,
> v2.26.0, generated when running the mkrelease script.
>
> Release notes:
>
> xml2rfc (2.26.0) ietf; urgency=medium
>
>
>    * Fixed an issue with nested <ul> with emtpy="true".
>
>

Gee, I hope this is not the way it is spelled in the code...

:)



From nobody Tue Sep  3 14:17:42 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F087120098; Tue,  3 Sep 2019 14:17:36 -0700 (PDT)
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, SPF_HELO_NONE=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 tcEZldUPe63E; Tue,  3 Sep 2019 14:17:35 -0700 (PDT)
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 3B555120052; Tue,  3 Sep 2019 14:17:35 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57680 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 1i5GB9-0001ak-Qc; Tue, 03 Sep 2019 14:17:33 -0700
To: Robert Moskowitz <rgm@htt-consult.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
References: <E1i5EwG-00014Q-GV@durif.tools.ietf.org> <1d7e7040-d294-a5e0-ddac-399bf84578bb@htt-consult.com>
Cc: rfc-markdown@ietf.org
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <e48065b9-7639-854c-5e00-c9e28cd62740@levkowetz.com>
Date: Tue, 3 Sep 2019 23:17:20 +0200
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: <1d7e7040-d294-a5e0-ddac-399bf84578bb@htt-consult.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xIMkHmPDKLoHb4lhBthCejigQpJv55Wpr"
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, rgm@htt-consult.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/oresJoMr5s3YTOKKSKvUcpcnjeI>
Subject: Re: [xml2rfc] New xml2rfc release: v2.26.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 21:17:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--xIMkHmPDKLoHb4lhBthCejigQpJv55Wpr
Content-Type: multipart/mixed; boundary="LTpoDggGHQol53lXGIPSpW7Nf5mWojiSK";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Robert Moskowitz <rgm@htt-consult.com>, xml2rfc-dev@ietf.org,
 xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-ID: <e48065b9-7639-854c-5e00-c9e28cd62740@levkowetz.com>
Subject: Re: [xml2rfc] New xml2rfc release: v2.26.0
References: <E1i5EwG-00014Q-GV@durif.tools.ietf.org>
 <1d7e7040-d294-a5e0-ddac-399bf84578bb@htt-consult.com>
In-Reply-To: <1d7e7040-d294-a5e0-ddac-399bf84578bb@htt-consult.com>

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

Hi Bob,

On 2019-09-03 22:55, Robert Moskowitz wrote:
>=20
>=20
> On 9/3/19 3:58 PM, Henrik Levkowetz wrote:
>> Hi,
>>
>> This is an automatic notification about a new xml2rfc release,
>> v2.26.0, generated when running the mkrelease script.
>>
>> Release notes:
>>
>> xml2rfc (2.26.0) ietf; urgency=3Dmedium
>>
>>
>>    * Fixed an issue with nested <ul> with emtpy=3D"true".
>>
>>
>=20
> Gee, I hope this is not the way it is spelled in the code...
>=20
> :)

 :-D



--LTpoDggGHQol53lXGIPSpW7Nf5mWojiSK--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl1u2GAACgkQTptXS4+7
Fxqmfg/+MICYIoAyFWUP5OJw+KvfyEWopE20PH3S3RJCp6fywzp19DjeCSYSxGJE
DNVV7NDmR7Eefb5YeDo3zteLSrwL5g6vRG+C25ysOdef5e2BCaHbkXvE2ohVuEhy
5ecTdDM9WvarkcW2QY+6Hu/Eq5iosKhzWSyBkLbXxlhtsk1lAwECmfLMD0259mqI
C+TjbI+4DfYE090pRP3Hlz7uJ4EntEsaVyir65GmKqeGOqtEUl+kmSASya9mt24S
n6xVPPUnc/kKQR+yYVhbB6u11RKZwXFBcKzlDl0RzwESUue4rzCmS34S1dccpexi
AgppQWw77G/vvtgwcdx0SatD2rVY930Hmhhwl+dy+MOlSZM0o7EyYrB6mDabvBQr
fQEhbDeYqxwj2xpKI+akRa9Cji9VUN0gr3hP5u1I2cmwLA5em2cbo98WU9NOinYD
JtWBHir4LdT602r0cBXuw3gXMb8WzUrZvPx+a2IPrRHMj7hwZlMHDgn6mNlGlv1u
R1vKNIjACDxrij80GADF0RdCxKKnzU++Nn5K61INrQlrsTGzeMypM0yMZ9Uf77c3
4gqm/OGkyo7v4MuBQfZqyW7NTdRKuazVq16GSpSfWECXW/T960y/qg2M2dmt3S4y
GgElmvCSkt+eCYq5xH/s3SUhyYwMjC7O/0cc3nRpj7ik/J+Ecyw=
=H4Rx
-----END PGP SIGNATURE-----

--xIMkHmPDKLoHb4lhBthCejigQpJv55Wpr--


From nobody Mon Sep  9 10:04:27 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291EB120853; Mon,  9 Sep 2019 10:04:14 -0700 (PDT)
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, SPF_HELO_NONE=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 hWZFvwGnHHGm; Mon,  9 Sep 2019 10:04:12 -0700 (PDT)
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 0870312084D; Mon,  9 Sep 2019 10:04:12 -0700 (PDT)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1i7N5H-0002eM-SS; Mon, 09 Sep 2019 10:04:11 -0700
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1i7N5H-0002eM-SS@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Mon, 09 Sep 2019 10:04:11 -0700
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/X3v8qTp0bek93FOngs7Mq4XMOto>
Subject: [xml2rfc] New xml2rfc release: v2.27.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 17:04:18 -0000

Hi,

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

Release notes:

xml2rfc (2.27.0) ietf; urgency=medium

  * Added a test for handling of &wj; and &nbsp; during text linebreaking.

  * Corrected the line break handling for &wj; and &zwsp; and changed to
    using a unicode private use code for internal "don't break" handling,
    in order to make use of &wj; possible in the XML source input.

  * Added country name aliases for South Korea.

  * In text renderer: Reverted 'Internet Draft' to 'Internet-Draft' for
    series name rendering.  Stripped empty parts from Updates: and
    Obsoletes: lists.  Added removal of U+2060 (word joiner) before
    emitting rendered text.

  * Adjusted the preptool inserted reference target value for 
    Internet-Drafts to include a trailing '.txt' to avoid 404s

  * Added U+2060 (word joiner) to the list of code points that should not
    trigger non-ASCII warnings

  * Added an --id-is-work-in-progress switch to let the RPC automatically
    add a <refcontent> element indicating "Work in Progress" for
    Internet-Drafts.

  * In HTML output, removed blank items from Updates and Obsoletes lists, 
    and reverted 'Internet Draft' in reference rendering to 'Internet-Draft'.

  * Added entity definitions for &wj; and &zwsp;

  * Fixed pyflakes issue; a variable name mismatch.

  * Updated the installation instructions emitted when --pdf is specified 
    without having the necessary libraries in place to also include 
    instructions for Noto font installation.

  * Fixed an issue with the ToC generation where sections without numbers 
    might still be rendered with the whitespace intended to go between number 
    and section title.

  * Fixed an issue with the HTML ToC where sections without numbers might 
    still be rendered with the whitespace intended to go between number and 
    section title.

  * Removed pilcrows from print layout to avoid spurious extra lines for 
    paragraphs where the pilcrow would not fit at the end of the last line.

  * Fixed an insufficient test for URL vs. local file when handling the 
    --metadata-js-url switch.

  * Tweaked the CSS for print to avoid reference entries beginning on a new 
    line, below the reference tag.

 -- Henrik Levkowetz <henrik@levkowetz.com>  09 Sep 2019 15:07:36 +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.27.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Mon Sep  9 13:08:06 2019
Return-Path: <lists@digitaldissidents.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E7D1200B8 for <xml2rfc@ietfa.amsl.com>; Mon,  9 Sep 2019 13:08:04 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 ozA17C-qe804 for <xml2rfc@ietfa.amsl.com>; Mon,  9 Sep 2019 13:07:59 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD22120048 for <xml2rfc@ietf.org>; Mon,  9 Sep 2019 13:07:58 -0700 (PDT)
Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <lists@digitaldissidents.org>) id 1i7Pwb-0002Cy-J8 for xml2rfc@ietf.org; Mon, 09 Sep 2019 22:07:56 +0200
To: xml2rfc@ietf.org
From: Niels ten Oever <lists@digitaldissidents.org>
Openpgp: preference=signencrypt
Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA==
Message-ID: <2cca546d-72cb-4776-f47d-b850376925c5@digitaldissidents.org>
Date: Mon, 9 Sep 2019 22:07:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------662193517036D11BC9FF8A3C"
Content-Language: en-US
X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 4d750f0dfeade416e964e97bdf7c10c4
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/anBhA47-DPoVcTFsqhX79qH0Y78>
Subject: [xml2rfc] new build errors
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 20:08:05 -0000

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

Hi all,

I caught another weird one that I did not know how to handle, especially since I did not change much in the draft. 

Any advice would be much appreciated! 

Attached the markdown file just in case.

Cheers,

Niels

$ make
xml2rfc draft-political.xml --html
Traceback (most recent call last):
  File "/usr/bin/xml2rfc", line 11, in <module>
    load_entry_point('xml2rfc==2.25.0', 'console_scripts', 'xml2rfc')()
  File "/usr/lib/python3/dist-packages/xml2rfc/run.py", line 482, in main
    htmlwriter.write(filename)
  File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line 1430, in write
    self._build_document()
  File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line 1376, in _build_document
    self.write_reference_list(references[0])
  File "/usr/lib/python3/dist-packages/xml2rfc/writers/legacy_html.py", line 569, in write_reference_list
    initials, surname = short_author_name_parts(author)
  File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 26, in short_author_name_parts
    initials = get_initials(a)
  File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 22, in get_initials
    initials = initials.split('.')[0]
AttributeError: 'NoneType' object has no attribute 'split'
make: *** [Makefile:12: draft-political.html] Error 1

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

--------------662193517036D11BC9FF8A3C
Content-Type: text/markdown;
 name="draft-political.md"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-political.md"

---
title: Notes on networking standards and politics
abbrev: politix
docname: draft-irtf-hrpc-political-01
category: info

ipr: trust200902
area: IRTF
workgroup: Human Rights Protocol Considerations Research Group
keyword: Internet-Draft
stand_alone: yes
pi:
  rfcedstyle: yes
  toc: yes
  tocindent: yes
  sortrefs: yes
  symrefs: yes
  strict: yes
  comments: yes
  inline: yes
  text-list-symbols: -o*+

author:
-
       ins: N. ten Oever
       name: Niels ten Oever
       organization: University of Amsterdam
       email: mail@nielstenoever.net
-
       ins: A. Andersdotter
       name: Amelia Andersdotter
       organization: ARTICLE 19
       email: amelia@article19.org

normative:

informative:

   RFC0049:
   RFC0101:
   RFC0144:
   RFC0164:
   RFC0196:
   RFC0286:
   RFC0313:
   RFC0316:
   RFC0542:
   RFC0549:
   RFC0613:
   RFC1097:
   RFC1958:
   RFC2026:
   RFC2804:
   RFC3552:
   RFC3935:
   RFC5218:
   RFC6973:
   RFC7704:
   RFC7776:
   RFC8280:

   BramanI:
     title: "Internationalization of the Internet by design: The first de=
cade "
     date: 2012
     author:
        - ins: S. Braman
     target: http://dx.doi.org.proxy.uba.uva.nl:2048/10.1177%2F1742766511=
434731
     seriesinfo: "Global Media and Communication, Vol 8, Issue 1, pp. 27 =
- 45"

   BramanII:
     title: "The Framing Years: Policy Fundamentals in the Internet Desig=
n Process, 1969=E2=80=931979"
     date: 2010
     author:
        - ins: S. Braman
     target: http://dx.doi.org.proxy.uba.uva.nl:2048/10.1080/01972243.201=
1.607027
     seriesinfo: "The Information Society Vol. 27, Issue 5, 2011"

   Contreras:
     title:  "Technical Standards and Ex Ante Disclosure: Results and Ana=
lysis of an Empirical Study"
     date: 2013
     author:
        - ins: J.L. Contreras
     target:
     seriesinfo: "Jurimetrics: The Journal of Law, Science &amp; Technolo=
gy, vol. 53, p. 163-211"

   Feenberg:
     title: Critical Theory of Technology
     date: 1991
     author:
       - ins: A. Feenberg
     seriesinfo: p.5-6

   Carey:
     title: Communication As Culture
     date: 1992
     author:
       - ins: J. Carey
     seriesinfo: p. 139

   Postman:
     title: "Technopoly: the Surrender of Culture to Technology"
     date: 1992
     author:
       - ins: N. Postman
     seriesinfo: "Vintage: New York. pp. 3=E2=80=9320."

   DeNardis:
     title: The Internet Design Tension between Surveillance and Security=

     date: 2015
     author:
       - ins: L. Denardis
     target: http://is.gd/7GAnFy
     seriesinfo: IEEE Annals of the History of Computing (volume 37-2)

   Winner:
     title: Who will we be in cyberspace?
     date: 1995
     author:
         - ins: L. Winner
     target: iwcenglish1.typepad.com/iwc_media_ecology/Documents/Who_will=
_we_be_in_cyberspace.doc

   UNGP:
     title: United Nations Guiding Principles for Business and Human Righ=
ts
     date: 2011
     author:
        - ins: J. Ruggie
        - org: United Nations
     target: http://www.ohchr.org/Documents/Publications/GuidingPrinciple=
sBusinessHR_EN.pdf

   Abbate:
      title: Inventing the Internet
      date: 2000
      author:
        - ins: J. Abbate
      target: https://mitpress.mit.edu/books/inventing-internet
      seriesinfo: MIT Press

   Heidegger:
      title: "The Question Concerning Technology and Other Essays"
      date: 1977
      author:
        - ins: M. Heidegger
      target: "http://ssbothwell.com/documents/ebooksclub.org__The_Questi=
on_Concerning_Technology_and_Other_Essays.pdf"
      seriesinfo: "Garland: New York, 1977"

   Nadvi:
      title: Making sense of global standards
      date: 2004
      author:
        - ins: K. Nadvi
        - ins: F. W=C3=A4ltring
      seriesinfo: "In: H. Schmitz (Ed.), Local enterprises in the global =
economy (pp. 53=E2=80=9394). Cheltenham, UK: Edward Elgar."

   Russell:
      title: "Open standards and the digital age: History, ideology, and =
networks"
      date: 2014
      author:
        - ins: A.M. Russell
      seriesinfo: "Cambridge, UK: Cambridge University Press"

   RogersEden:
      title: "The Snowden Disclosures, Technical Standards, and the Makin=
g of Surveillance Infrastructures"
      date: 2017
      author:
        - ins: M. Rogers
        - ins: G. Eden
      seriesinfo: "International Journal of Communication 11(2017), 802-8=
23"
      target: "http://ijoc.org/index.php/ijoc/article/view/5525/1941"

   CJEU2004:
      title: "ECLI:EU:C:2004:257, C-418/01 IMS Health"
      date: 2004
      author:
        - ins: Court of Justice of the European Union
      target: "http://curia.europa.eu/juris/liste.jsf?num=3DC-418/01"
      seriesinfo: "Cambridge, UK: Cambridge University Press"

   CJEU2007:
      title: "ECLI:EU:T:2007:289, T-201/04 Microsoft Corp."
      date: 2007
      author:
        - ins: Court of Justice of the European Union
      target: "http://curia.europa.eu/juris/liste.jsf?num=3DT-201/04"
      seriesinfo: "Cambridge, UK: Cambridge University Press"

   draft-finance-thoughts:
      title: "Thoughts on IETF Finance Arrangements"
      date: 2017
      author:
        - ins: J. Arkko
      target: "https://datatracker.ietf.org/doc/html/draft-arkko-ietf-fin=
ance-thoughts"

   IAOC69:
      title: "IAOC Report Chicago"
      date: 2007
      author:
        - ins: IAOC
      target: "https://iaoc.ietf.org/documents/IAOC-Report-Chicago-69.pdf=
"

   IAOC77:
      title: "IAOC Report Anaheim"
      date: 2010
      author:
        - ins: IAOC
      target: "https://iaoc.ietf.org/documents/IAOC-Report-Anaheim-77.pdf=
"

   IAOC99:
      title: "IAOC Report Prague"
      date: 2017
      author:
        - ins: IAOC
      target: "https://iaoc.ietf.org/documents/IAOCReportinAdvanceofIETF9=
9.pdf"


   Ahlborn:
      title: "Implications of the Proposed Framework and Antitrust Rules =
for Dynamically Competitive Industries"
      date: 2006
      author:
        - ins: C. Ahlborn
        - ins: V. Denicol=C3=B3
        - ins: D. Geradin
        - ins: A.J. Padilla
      target: "http://curia.europa.eu/juris/liste.jsf?num=3DT-201/04"
      seriesinfo: "DG Comp=E2=80=99s Discussion Paper on Article 82, DG C=
OMP, European Commission"

   Hanseth:
      title: Insribing Behaviour in Information Infrastructure Standards
      date: 1997
      author:
        - ins: O. Hanseth
        - ins: E. Monteiro
      seriesinfo: Accounting, Management and Infomation Technology 7 (14)=
 p.183-211

   Woolgar:
      title: "Configuring the user: the case of usability trials"
      date: 1991
      author:
         - ins: S. Woolgar
      seriesinfo: "A sociology of monsters. Essays on power, technology a=
nd dominatior, ed: J. Law, Routeledge p. 57-102."

   Winner:
      title: "Upon openig the black box and finding it empty: Social cons=
tructivism and the philosophy of technology"
      date: 1993
      author:
        - ins: L. Winner
      seriesinfo: Science, Technology, and Human Values 18 (3) p. 362-378=


   Webster:
      title: Networks of Collaboration or Conflict? The Development of ED=
I
      date: 1995
      author:
        - ins: J. Webster
      seriesinfo: "The social shaping of inter-organizational IT systems =
and data interchange, eds: I. McLougling &amp; D. Mason, European Commiss=
ion PICT/COST A4"

   Sisson:
     title: Standards and Protocols
     date: 2000
     author:
       - ins: D. Sisson
     target: https://philosophe.com/design/standards/

   HagueHarrop:
     title: "Comparative Government and Politics: An Introduction"
     date: 2013
     author:
      - ins: R. Hague
      - ins: M. Harrop
     seriesinfo: "Macmillan International Higher Education. pp. 1=E2=80=93=
=2E ISBN 978-1-137-31786-5."

   BijkerLaw:
     title: "Shaping Technology/ Building Society: Studies in Sociotechni=
cal Change"
     date: 1992
     author:
      - ins: W. Bijker
      - ins: J. Law
     seriesinfo: "Cambridge, MA: MIT Press"

   Bloor:
     title: Knowledge and Social Imagery
     date: 1976
     author:
      - ins: D. Bloor
     seriesinfo: "London: Routeledge & Kegan Paul"

--- abstract

The IETF cannot ordain which standards or protocols are to be used on net=
work, but the standards developing process in the IETF has a normative ef=
fect. Among other things the standardisation work at the IETF has implica=
tions on what is perceived as technologically possible and useful where n=
etworking technologies are being deployed, and its standards output refle=
ct was is considered by the technical community as feasible and good prac=
tice. Because it mediates many aspects of modern life, and therefore cont=
ributes to the ordering of societies and communities, the consideration o=
f the politics and (potential) impact of protocols should be part of the =
standardization and development process.

--- middle

Introduction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    "Science and technology lie at the heart of social asymmetry.
       Thus technology both creates systems which close off other
       options and generate  novel, unpredictable and indeed
       previously unthinkable, option. The game of technology is
       never finished, and its ramifications are endless."

                                   - Michel Callon

    "The Internet isn't value-neutral, and neither is the IETF."

                                   -{{RFC3935}}

The design of the Internet through protocols and standards is a technical=
 issue with great political and economic impacts {{RFC0613}}. The early I=
nternet community already realized that it needed to make decisions on po=
litical issues such as Intellectual Property, Internationalization {{Bram=
anI}}, diversity, access {{RFC0101}} privacy and security {{RFC0049}}, an=
d the military {{RFC0164}} {{RFC0316}}, governmental {{RFC0144}} {{RFC028=
6}} {{RFC0313}} {{RFC0542}} {{RFC0549}} and non-governmental {{RFC0196}} =
uses, which has been clearly pointed out by Braman {{BramanII}}.

Recently there has been an increased discussion on the relation between I=
nternet protocols and human rights {{RFC8280}} which spurred the discussi=
on on the the value neutrality and political nature of standards. The net=
work infrastructure is on the one hand designed, described, developed, st=
andardized and implemented by the Internet community, but the Internet co=
mmunity and Internet users are also shaped by the affordances of the tech=
nology. Companies, citizens, governments, standards developing bodies, pu=
blic opinion and public interest groups all play a part in these discussi=
ons. In this document we aim to outline different views on the relation b=
etween standards and politics and seek to answer the question whether sta=
ndards are political, and if so, how.

Vocabulary Used
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Politics
: (from Greek: Politik=C3=A1: Politika, definition "affairs of the common=
s") is the process of making decisions applying to all members of a diver=
se group with conflicting interests. More narrowly, it refers to achievin=
g and exercising positions of governance or organized control over a comm=
unity. Furthermore, politics is the study or practice of the distribution=
 of power and resources within a given community as well as the interrela=
tionship(s) between communities. (adapted from {{HagueHarrop}})

Affordances
: The possibilities that are provided to an actors through the ordering o=
f an environment by a technology.

Protocols
: 'Protocols are rules governing communication between devices or applica=
tions, and the creation or manipulation of any logical or communicative a=
rtifacts concomitant with such communication.' {{Sisson}}

Standards
: 'An Internet Standard is a specification that is stable and well-unders=
tood, is technically competent, has multiple, independent, and interopera=
ble implementations with substantial operational experience, enjoys signi=
ficant public support, and is recognizably useful in some or all parts of=
 the Internet.' {{RFC2026}}


Research Question
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Are protocols political? If so, should the politics of protocols need to =
be taken into account in their development process?

Technology and Politics: a review of literature and community positions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In 1993 the Computer Professionals for Social Responsibility stated that =
'the Internet should meet public interest objectives', similarly {{RFC393=
5}} states that 'The Internet isn't value-neutral, and neither is the IET=
F.'. Ethics and the Internet was already a topic of an RFC by the IAB in =
1989 {{RFC1097}}. Nonetheless there has been a recent uptick in discussio=
ns around the impact of Internet protocols on human rights {{RFC8280}} in=
 the IETF and more general about the impact of technology on society in t=
he public debate.

This document aims to provide an overview of the spectrum of different po=
sitions that have been observed in the IETF and IRTF community, during pa=
rticipatory observation, through 39 interviews with members of the commun=
ity, the Human Rights Protocol Considerations Research Group mailinglist =
and during and after the Technical Plenary on Protocols and Human Rights =
during IETF98.
Without judging them on their internal or external consistency they are r=
epresented here, where possible we sought to engage with academic literat=
ure on this topic.

## Technology is value neutral
This position starts from the premise that the technical and political ar=
e differentiated fields and that technology is 'value free'. This is also=
 put more explicitly by Carey: "electronics is neither the arrival of apo=
calypse nor the dispensation of  grace.  Technology  is  technology;  it =
 is  a  means  for  communication  and  transportation  over  space, and =
nothing more." {{Carey}}. In this view protocols only become political wh=
en it is actually being used by humans. So the technology itself is not p=
olitical, the use of the technology is. This view sees technology as inst=
rument; "technologies  are  'tools' standing  ready  to  serve  the  purp=
oses  of  their  users.  Technology  is  deemed  'neutral,' without valua=
tive content of its own.'" {{Feenberg}}. Feenberg continues: "technology =
 is  not  inherently  good  or  bad,  and  can  be  used  to  whatever  p=
olitical  or  social  ends  desired  by  the  person  or  institution  in=
  control.  Technology  is  a  =E2=80=98rational entity=E2=80=99 and univ=
ersally applicable. One may make exceptions on moral grounds, but one mus=
t also understand that the "price for the achievement of environmental, e=
thical, or religious goals...is reduced efficiency." {{Feenberg}}.

## Some protocols are political some times
This stance is a pragmatic approach to the problem. It states that some p=
rotocols under certain conditions can themselves have a political dimensi=
on.  This is different from the claim that a protocol might sometimes be =
used in a political way; that view is consistent with the idea of the tec=
hnology being neutral (for the human action using the technology is where=
 the politics lies).  Instead, this position requires that each protocol =
and use be evaluated for its political dimension, in order to understand =
the extent to which it is political.

## All protocols are political sometimes
While not an absolutist standpoint it recognizes that all design decision=
s are subject to the law of unintended consequences. The system consistin=
g of the Internet and its users is vastly too complex to be predictable; =
it is chaotic in nature; its emergent properties cannot be predicted. Thi=
s concept strongly hinges on the general purpose aspect of information te=
chnology and its malleability. Whereas not all (potential) behaviours, af=
fordances and impacts of protocols can possible be predicted, one could a=
t least consider the impact of proposed implementations.

## The network has its own logic and values
While humans create technologies, this does not mean that they are foreve=
r under human control. A technology, once created, has its own logic that=
 is independent of the human actors that either create or use the technol=
ogy.

=46rom this perspective, technologies can shape the world. As Martin Heid=
egger says, "The hydroelectric plant is not built into the Rhine River as=
 was the old wooden bridge that joined bank with bank for hundreds of yea=
rs. Rather the river is dammed up into the power plant. What the river is=
 now, namely, a water power supplier, derives from out of the essence of =
the power station." {{Heidegger}} (p 16)  The dam in the river changes th=
e world in a way the bridge does not, because the dam alters the nature o=
f the river.

In the same way --in another and more recent example-- the very existence=
 automobiles impose physical forms on the world different from those that=
 come from the electric tram or the horse-cart. The logic of the automobi=
le means speed and the rapid covering of distance, which encourages subur=
ban development and a tendency toward conurbation. But even if that did n=
ot happen, widespread automobile use requires paved roads, and parking lo=
ts and structures. These are pressures that come from the automotive tech=
nology itself, and would not arise without that technology.

In much same way, then, networking technology, such as protocols, creates=
 its own demands. One of the most important conditions for protocol succe=
ss is its incremental deployability {{RFC5218}}.  This means that the net=
work already contains constraints on what can be deployed into it. In thi=
s sense the network creates its own paths, but also has its own objective=
=2E According to this view the goal of the network is interconnection and=
 connectivity; more connectivity is good for the network. Proponents of t=
his positions also often describe the Internet as an organism with its ow=
n unique ecosystem.

In this position it is not necessarily clear where the 'social' ends and =
the 'technical' begins, and it could be argued that the distinction itsel=
f is a social construction {{BijkerLaw}} or that a real-life distinction =
between the two is hard to be made {{Bloor}}.

## Protocols are inherently political
This position argues the opposite of 'technological neutrality'. This pos=
ition can be illustrated with Postman where he writes: 'the uses made of =
technology are largely determined by the structure of the technology itse=
lf' {{Postman}}. He states that the medium itself 'contains an ideologica=
l bias'. He continues to argue that technology is non-neutral:

(1) because of the symbolic forms in which information is encoded, differ=
ent media have different intellectual and emotional biases;
(2) because of the accessibility and speed of their information, differen=
t media have different political biases;
(3) because of their physical form, different media have different sensor=
y biases;
(4) because of the conditions in which we attend to them, different media=
 have different social biases;
(5) because of their technical and economic structure, different media ha=
ve different content biases.

Recent scholars of Internet infrastructure and governance have also point=
ed out that Internet processes and standards have become part and parcel =
of political processes and public policies. Several concrete examples are=
 found within this approach, for instance, the IANA transition or global =
innovation policy {{DeNardis}}. The Raven process in which the IETF refus=
ed to standardize wiretapping --which resulted in {{RFC2804}}-- was an in=
stance where an international governance body took a position that was la=
rgely political, although driven by a technical argument. The process tha=
t led to {{RFC6973}} is similar: the Snowden disclosures which occured in=
 the political space, engendered the IETF to act. This is summarized in {=
{Abbate}} who says: "protocols are politics by other means", emphasizing =
the interests that are at play in the process of designing standards.

This position further holds that protocols can never be understood withou=
t their contextual embeddedness: protocols do not exist solely by themsel=
ves but always are to be understood in a more complex context -- the stac=
k, hardware, or nation-state interests and their impact on civil rights. =
Finally, this view is that that protocols are political because they affe=
ct or sometimes effect the socio-technical ordering of reality. The latte=
r observation leads Winner to conclude that the reality of technological =
progress has too often been a scenario where the innovation has dictated =
change for society. Those who had the power to introduce a new technology=
 also had the power to create a consumer class  to  use  the  technology =
=E2=80=98with new practices, relationships, and identities supplanting th=
e old, ---and those who had the wherewithal to implement new technologies=
 often molded society to match the needs of emerging technologies and org=
anizations.=E2=80=99 {{Winner}}.

IETF: Protocols as Standards
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

In the previous section we gave an overview of the different existing pos=
itions of the impact of Internet protocols in the Internet community. In =
the following section we will consider the standards setting process and =
its consequences for the politics of protocols.

Standards enabling interoperating networks, what we think of today as the=
 Internet, were created as open, formal and voluntary standards. A platfo=
rm for internet standardisation, the Internet Engineering Task Force (IET=
F), was created in 1986 to enable the continuation of such standardisatio=
n work. The IETF has sought to make the standards process transparent (by=
 ensuring everyone can access standards, mailing-lists and meetings), pre=
dictable (by having clear procedures and reviews) and of high quality (by=
 having draft documents reviewed by members from its own epistemic commun=
ity). This is all aimed at increasing the accountability of the process a=
nd the quality of the standard.

The IETF implements what has been referred to as an "informal ex ante dis=
closure policy" for patents {{Contreras}}, which includes the possibility=
 for participants to disclose the existence of a patent relevant for the =
standard, royalty-terms which would apply to the implementors of that sta=
ndard should it enter into effect, as well as other licensing terms that =
may be interesting for implementors to know. The community ethos in the I=
ETF seems to lead to 100% royalty-free disclosures of prior patents which=
 is a record number, even among other comparable standard organisations {=
{Contreras}}.

## Competition and collaboration

Standards exist for nearly everything: processes, technologies, safety, h=
iring, elections, and training. Standards provide blue-prints for how to =
accomplish a particular task in a similar way for others that are trying =
to accomplish the same thing, while reducing overhead and inefficiencies.=
 Although there are different types and configurations of standards, they=
 all enhance competition by allowing different entities to work from a co=
mmonly accepted baseline.

On the first types of standards than can be found are "informal" ones --a=
greed upon normal ways of interacting within a specific community. For ex=
ample, the process through which greetings to a new acquaintance are expr=
essed through a bow, a handshake or a kiss. On the other hand "formal" st=
andards, are normally codified in writing. The next subsection will ----

Within economy studies, _de facto_ standards arise in market situations w=
here one entity is particularly dominant; downstream competitors are ther=
efore tied to the dominant entity's technological solutions {{Ahlborn}}. =
Under EU anti-trust law, de facto standards have been found to restrict c=
ompetition for downstream services in PC software products {{CJEU2007}}, =
as well as downstream services dependent on health information {{CJEU2004=
}}.

Even in international law, the World Trade Organisation (WTO) uses standa=
rds, although it recognises a difference between standards and technical =
regulations. The former are voluntary formal codes to which products or s=
ervices may conform, while technical regulations are mandatory requiremen=
ts to be fullfilled for a product to be accessible on one of the WTO coun=
try markets. These rules have implications for how nation states bounded =
by the WTO agreements can impose specific technical requirements on compa=
nies. Nonetheles, there are many standardisation groups that were origina=
lly launched by nation states or groups of nation states. ISO, BIS, CNIS,=
 NIST, ABNT and ETSI are examples of institutions that are, wholly or par=
tially, sponsored by public money in order to ensure smooth development o=
f formal standards. Even if under WTO rules these organisations cannot cr=
eate the equivalent of a technical regulation, they have important normat=
ive functions in their respective countries. No matter what form, all sta=
ndards enhance competition and collaboration because they define a common=
 approach to a problem. This potentially allows different instances to in=
teroperate or be evaluated according to the same indicators.

The development of formal standards faces a number of economic and organi=
sational challenges. Mainly, the cost and difficulty of organising many e=
ntities around a mutual goal, as well as the cost of research and develop=
ment leading up to a mutually beneficial technological platform. In addit=
ion, deciding what the mutual goal is can also be a problem. These challe=
nges may be described as inter-organisational costs. Even after a goal is=
 decided upon, coordination of multiple entities requires time and money.=
 One needs communication platforms, processes and a commitment to mutual =
investment in a higher good. They are not simple tasks, and the more diff=
erent communities are affected by a particular standardisation process, t=
he more difficult the organisational challenges become.

## IETF standards setting externalities

In spite of a strong community ethos and transparent procedures, the IETF=
 is not immune to externalities.

### Finance
Sponsorship to the IETF is varied, but is also of the nature that ongoing=
 projects that are in the specific interest of one or some group of corpo=
rations may be given more funding than other projects (see {{draft-financ=
e-thoughts}}). The IETF has faced three periods of decreased commitment f=
rom participants in funding its meetings in the past ten years, leading, =
naturally, to self-scrutiny, see for instance {{IAOC69}}, {{IAOC77}}, {{I=
AOC99}}.

### Interoperability and backward compatability
The need for interoperability, and backward compatability makes engineeri=
ng work harder. And once a standard is designed, it does not automaticall=
y mean it will be broadly adopted at a fast pace. Examples of this are IP=
v6, DNSSEC, DKIM, etc. The need for interoperability means that a new pro=
tocol needs to take into account a much more diverse environment than ear=
ly protocols, and also be amendable to different needs: protocols needs t=
o relate and negotiate in a busy agora, as do the protocol developers. Th=
is means that some might get priority, whereas others get dropped.

### Competition between layers
There is a competition between layers, and even contestation about what t=
he borders of different layers are. This leads to competition between lay=
ers and different solutions for similar problems on different layers, whi=
ch in its turn leads to further ossification, which leads to more contest=
ation.

## How voluntary are open standards?

Coordinating transnational stakeholders in a process of negotiation and a=
greement through the development of common rules is a form of global gove=
rnance {{Nadvi}}. Standards are among the mechanisms by which this govern=
ance is achieved. Conformance to certain standards is often a basic condi=
tion of participation in international trade and communication, so there =
are strong economic and political incentives to conform, even in the abse=
nce of legal requirements {{Russell}}. {{RogersEden}} argue:

   "As unequal participants compete to define standards, technological co=
mpromises emerge, which add complexity to standards. For instance, when w=
orking group participants propose competing solutions, it may be easier f=
or them to agree on a standard that combines all the proposals rather tha=
n choosing any single proposal. This shifts the responsibility for select=
ing a solution onto those who implement the standard, which can lead to c=
omplex implementations that may not be interoperable. On its face this ap=
pears to be a failure of the standardization process, but this outcome ma=
y benefit certain participants=E2=80=94 for example, by allowing an imple=
menter with large market share to establish a de facto standard within th=
e scope of the documented standard."


The need for a positioning
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

It is indisputable that the Internet plays an increasingly important role=
 in the lives of individuals.  The community that produces standards for =
the Internet therefore also has an impact on society, which it itself has=
 recognised in a number of previously adopted documents {{RFC1958}}.

The IETF cannot ordain which standards are to be used on the networks, an=
d it specifically does not determine the laws of regions or countries whe=
re networks are being used, but it does set open standards for interopera=
bility on the Internet, and has done so since the inception of the Intern=
et. Because a standard is the blue-print for how to accomplish a particul=
ar task in a similar way to others, the standards adopted have a normativ=
e effect. The standardisation work at the IETF will have implications on =
what is perceived as technologically possible and useful where networking=
 technologies are being deployed, and its standards output reflect was is=
 considered by the technical community as feasible and good practice.

This calls for providing a methodology in the IETF community to evaluate =
which routes forward should indeed be feasible, what constitutes the "goo=
d" in "good practice" and what trade-offs between different feasible feat=
ures of technologies are useful and should therefore be made possible. Su=
ch an analysis should take societal implication into account.

The risk of not doing this is threefold: (1) the IETF might make decision=
s which have a political impact that was not intended by the community, (=
2) other bodies or entities might make the decisions for the IETF because=
 the IETF does not have an explicit stance, (3) other bodies that do take=
 these issues into account might increase in importance to the detriment =
of the influence of the IETF.

This does not mean the IETF does not have a position on particular politi=
cal issues. The policies for open and diverse participation {{RFC7704}}, =
the anti-harassment policy {{RFC7776}}, as well as the Guidelines for Pri=
vacy Considerations {{RFC6973}} are proof of this. Nonetheless, these are=
 all examples of positions about the IETF's work processes or product. Wh=
at is absent is a way for IETF participants to evaluate their role with r=
espect to the wider implications of that IETF work.

Conclusion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Economics, competition, collaboration, openness, and political impact hav=
e been an inherent part of the work of the IETF since its early beginning=
s, by its nature as standards developing organization, through the contri=
butions of the members of the Internet community, and because the orderin=
g effect the Internet has on society. Whereas there might not be agreemen=
t in the Internet community on what the specific political nature is of t=
echnological development, it is undisputed that standards and protocols a=
re both product of a political process, and they can also be used for pol=
itical means. Therefore protocols and standards are not value neutral. Wh=
ereas there is no need for a unified philosophy of Internet protocols, it=
 is in the benefit of the IETF, the Internet and arguably society at larg=
e to take this into account in the standards development process.

The way forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There are instruments that can help the IETF develop an approach to addre=
ss the politics of standards. Part of this can be found in {{RFC8280}} as=
 well as the United National Guiding Principles for Business and Human Ri=
ghts {{UNGP}}. But there is not a one-size-fits-all solution. The IETF is=
 a particular organization, with a particular mandate, and even if a poli=
cy is in place, its success depends on the implementation of the policy b=
y the community.

Since 'de facto standardization is reliant on market forces' {{Hanseth}} =
we need to live with the fact standards bodies have a political nature {{=
Webster}} and are not value neutral. This does not need to be problematic=
 as long as there are sufficient accountability and transparency mechanis=
ms in place. The importance of these mechanisms increases with the import=
ance of the standards and their implementations. The complexity of the wo=
rk inscribes a requirement of competence in the work in the IETF, which f=
orms an inherent barrier for end-user involvement. Even though this might=
 not be intentional, it is a result of the interplay between the characte=
ristics of the epistemic community in the IETF and the nature of the stan=
dard setting process.

Instead of splitting hairs about whether 'standards are political' {{Winn=
er}} {{Woolgar}} we argue that we need to look at the politics of individ=
ual standards and invite document authors and reviewers to take these dyn=
amics into account.

Security Considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

As this draft concerns a research document, there are no security conside=
rations as described in {{RFC3552}}, which does not mean that not address=
ing the issues brought up in this draft will not impact the security of e=
nd-users or operators.


IANA Considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This document has no actions for IANA.


Acknowledgements
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks to Michael Rogers, Andrew Sullivan, Brian Carpenter, Mark Perkins =
and all contributors and reviewers on the hrpc mailinglist. Special thank=
s to Gisela Perez de Acha for some thorough editing rounds.

Research Group Information
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

The discussion list for the IRTF Human Rights Protocol Considerations wor=
king group is located at the e-mail address <hrpc@ietf.org>. Information =
on the group and information on how to subscribe to the list is at:
<https://www.irtf.org/mailman/listinfo/hrpc>

Archives of the list can be found at:
<https://www.irtf.org/mail-archive/web/hrpc/current/index.html>

--------------662193517036D11BC9FF8A3C--


From nobody Tue Sep 10 08:47:58 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF1A1201DC; Tue, 10 Sep 2019 08:47:43 -0700 (PDT)
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, SPF_HELO_NONE=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 CmVXlTZlPxjY; Tue, 10 Sep 2019 08:47:42 -0700 (PDT)
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 2DF80120043; Tue, 10 Sep 2019 08:47:42 -0700 (PDT)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1i7iMo-0000so-0z; Tue, 10 Sep 2019 08:47:42 -0700
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1i7iMo-0000so-0z@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Tue, 10 Sep 2019 08:47:42 -0700
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/Rc8QVJCJNn6eysUdUH3oTdvg3Zo>
Subject: [xml2rfc] New xml2rfc release: v2.27.1
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 15:47:44 -0000

Hi,

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

Release notes:

xml2rfc (2.27.1) ietf; urgency=medium

  * Refined the preptool code that inserts reference target URLs to use an
    more appropriate guess at the extension, depending on the base URL.

  * Corrected a mismatch between the default value for a switch in run.py
    and base.py.

  * Changed the code for the --id-is-work-in-progress to avoid duplicate 
    <refcontent> insertion.

 -- Henrik Levkowetz <henrik@levkowetz.com>  10 Sep 2019 15:43:47 +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.27.1'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Tue Sep 10 09:24:11 2019
Return-Path: <lists@digitaldissidents.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06747120227 for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 09:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level: 
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFUzbdS-GTlZ for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 09:24:03 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0ED61201CE for <xml2rfc@ietf.org>; Tue, 10 Sep 2019 09:24:02 -0700 (PDT)
Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <lists@digitaldissidents.org>) id 1i7ivP-0005Ta-Su for xml2rfc@ietf.org; Tue, 10 Sep 2019 18:24:00 +0200
From: Niels ten Oever <lists@digitaldissidents.org>
To: xml2rfc@ietf.org
References: <2cca546d-72cb-4776-f47d-b850376925c5@digitaldissidents.org>
Openpgp: preference=signencrypt
Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA==
Message-ID: <a24da7a3-b856-8c5b-9f95-cdd3646d27ae@digitaldissidents.org>
Date: Tue, 10 Sep 2019 18:23:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <2cca546d-72cb-4776-f47d-b850376925c5@digitaldissidents.org>
Content-Type: multipart/mixed; boundary="------------11A08B5843CB300813579936"
Content-Language: en-US
X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 19a47015fccc417f0c4d70d36519c40c
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/Qz9WM0EtcWRXpdH5s8gcwj_mwVs>
Subject: Re: [xml2rfc] new build errors
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 16:24:11 -0000

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

I thought the issues might have been due to python and other software version issues on my machine, but I got a similar output on https://xml2rfc.tools.ietf.org/ :

  Parsing file INPUT
  Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/templates/rfc2629.dtd
  Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/templates/rfc2629-xhtml.ent
  Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/templates/rfc2629-other.ent
  Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/templates/rfc2629.dtd
  Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/templates/rfc2629-xhtml.ent
  Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/templates/rfc2629-other.ent
Traceback (most recent call last):
  File "/usr/local/bin/xml2rfc", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/run.py", line 496, in main
    htmlwriter.write(filename)
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 1431, in write
    self._build_document()
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", line 1377, in _build_document
    self.write_reference_list(references[0])
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/legacy_html.py", line 570, in write_reference_list
    initials, surname = short_author_name_parts(author)
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/name.py", line 26, in short_author_name_parts
    initials = get_initials(a)
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/name.py", line 22, in get_initials
    initials = initials.split('.')[0]
AttributeError: 'NoneType' object has no attribute 'split'

Also attached XML FYI.

Any hints would ve very welcome!

Best,

Niels

On 9/9/19 10:07 PM, Niels ten Oever wrote:
> Hi all,
> 
> I caught another weird one that I did not know how to handle, especially since I did not change much in the draft. 
> 
> Any advice would be much appreciated! 
> 
> Attached the markdown file just in case.
> 
> Cheers,
> 
> Niels
> 
> $ make
> xml2rfc draft-political.xml --html
> Traceback (most recent call last):
>   File "/usr/bin/xml2rfc", line 11, in <module>
>     load_entry_point('xml2rfc==2.25.0', 'console_scripts', 'xml2rfc')()
>   File "/usr/lib/python3/dist-packages/xml2rfc/run.py", line 482, in main
>     htmlwriter.write(filename)
>   File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line 1430, in write
>     self._build_document()
>   File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line 1376, in _build_document
>     self.write_reference_list(references[0])
>   File "/usr/lib/python3/dist-packages/xml2rfc/writers/legacy_html.py", line 569, in write_reference_list
>     initials, surname = short_author_name_parts(author)
>   File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 26, in short_author_name_parts
>     initials = get_initials(a)
>   File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 22, in get_initials
>     initials = initials.split('.')[0]
> AttributeError: 'NoneType' object has no attribute 'split'
> make: *** [Makefile:12: draft-political.html] Error 1
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

--------------11A08B5843CB300813579936
Content-Type: text/xml;
 name="draft-political.xml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-political.xml"

<?xml version=3D"1.0" encoding=3D"UTF-8"?>
  <?xml-stylesheet type=3D"text/xsl" href=3D"rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->=


<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc rfcedstyle=3D"yes"?>
<?rfc toc=3D"yes"?>
<?rfc tocindent=3D"yes"?>
<?rfc sortrefs=3D"yes"?>
<?rfc symrefs=3D"yes"?>
<?rfc strict=3D"yes"?>
<?rfc comments=3D"yes"?>
<?rfc inline=3D"yes"?>
<?rfc text-list-symbols=3D"-o*+"?>

<rfc ipr=3D"trust200902" docName=3D"draft-irtf-hrpc-political-04" categor=
y=3D"info">

  <front>
    <title abbrev=3D"politix">Notes on networking standards and politics<=
/title>

    <author initials=3D"N." surname=3D"ten Oever (editor)" fullname=3D"Ni=
els ten Oever">
      <organization>University of Amsterdam</organization>
      <address>
        <email>mail@nielstenoever.net</email>
      </address>
    </author>

    <date year=3D"2019" month=3D"September" day=3D"10"/>

    <area>IRTF</area>
    <workgroup>Human Rights Protocol Considerations Research Group</workg=
roup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The IETF cannot ordain what standards or protocols are to be used on n=
etworks, but the standards development process in the IETF does have an i=
mpact on society through its normative standards setting process. This do=
cument aims to bring about a better understanding on the political nature=
 of standards and protocols. Among other things, the IETF=E2=80=99s work =
affects what is perceived as technologically possible and useful where ne=
tworking technologies are being deployed, and its standards reflect what =
is considered by the technical community to be feasible and good practice=
=2E Whereas there might not be agreement among the Internet protocol comm=
unity on the specific political nature of the technological development p=
rocess and its outputs, it is undisputed that standards and protocols are=
 both products of a political process, and they can also be used for poli=
tical means.</t>



    </abstract>


  </front>

  <middle>


<section anchor=3D"introduction" title=3D"Introduction">

<figure><artwork><![CDATA[
"Science and technology lie at the heart of social asymmetry.
   Thus technology both creates systems which close off other
   options and generate  novel, unpredictable and indeed
   previously unthinkable, option. The game of technology is
   never finished, and its ramifications are endless."

                               - Michel Callon

"The Internet isn't value-neutral, and neither is the IETF."

                               -{{RFC3935}}
]]></artwork></figure>

<t>The design of the Internet through protocols and standards is a techni=
cal issue with great political and economic impacts <xref target=3D"RFC06=
13"/> <xref target=3D"RFC3271"/>. The early Internet community already re=
alized that it needed to make decisions on political issues such as intel=
lectual property; internationalization <xref target=3D"BramanI"/>; divers=
ity; access <xref target=3D"RFC0101"/>; privacy; and security <xref targe=
t=3D"RFC0049"/>; and the military <xref target=3D"RFC0164"/> <xref target=
=3D"RFC0316"/>, governmental <xref target=3D"RFC0144"/> <xref target=3D"R=
FC0286"/> <xref target=3D"RFC0313"/> <xref target=3D"RFC0542"/> <xref tar=
get=3D"RFC0549"/> and non-governmental <xref target=3D"RFC0196"/> uses of=
 the network. This has been clearly pointed out by Braman <xref target=3D=
"BramanII"/>.</t>

<t>Recently there has been increased discussion in the IRTF and IETF on t=
he relation between Internet protocols and human rights <xref target=3D"R=
FC8280"/>, which spurred discussion of the value neutrality and political=
 nature of standards. The network infrastructure is on the one hand desig=
ned, described, developed, standardized and implemented by the Internet c=
ommunity, while on the other hand the Internet community and Internet use=
rs are also shaped by the affordances of the technology. Companies, citiz=
ens, governments, standards development bodies, public opinion and public=
 interest groups all play a part in these discussions. In this document w=
e aim to outline different views on the relation between standards and po=
litics, and seek to answer the question of whether standards are politica=
l, and if so, how.</t>

</section>
<section anchor=3D"vocabulary-used" title=3D"Vocabulary Used">

<t><list style=3D"hanging">
  <t hangText=3D'Politics'>
  (from Greek: Politik=C3=A1: Politika, definition =E2=80=9Caffairs of th=
e commons=E2=80=9D) is the process of making decisions applying to all me=
mbers of a diverse group with conflicting interests. More narrowly, it re=
fers to achieving and exercising positions of governance or organized con=
trol over a community. Furthermore, politics is the study or practice of =
the distribution of power and resources within a given community as well =
as the interrelationship(s) between communities. (adapted from <xref targ=
et=3D"HagueHarrop"/>)</t>
  <t hangText=3D'Affordances'>
  The possibilities that are provided to an actor through the ordering of=
 an environment by a technology. This means that a technology does not de=
termine what is possible, but that it that invites specific kinds of beha=
vior, and in that process shapes it.</t>
</list></t>

</section>
<section anchor=3D"research-question" title=3D"Research Question">

<t>Are protocols political?</t>

</section>
<section anchor=3D"technology-and-politics-a-review-of-literature-and-com=
munity-positions" title=3D"Technology and Politics: a review of literatur=
e and community positions">

<t>In 1993 the Computer Professionals for Social Responsibility stated th=
at =E2=80=98the Internet should meet public interest objectives=E2=80=99.=
 Similarly, <xref target=3D"RFC3935"/> states that =E2=80=98The Internet =
isn=E2=80=99t value-neutral, and neither is the IETF.=E2=80=99. Ethics an=
d the Internet was already a topic of an RFC by the IAB in 1989 <xref tar=
get=3D"RFC1087"/>. Nonetheless there has been a recent uptick in discussi=
ons within the IETF and IRTF about the impact of Internet protocols on hu=
man rights <xref target=3D"RFC8280"/>, and more generally in public debat=
e about the impact of technology on society.</t>

<t>This document aims to provide an overview of the spectrum of different=
 positions that have been observed in the IETF and IRTF community, and ha=
ve been observed during interviews, mailinglist exchanges, and during res=
earch group sessions. These positions were observed during participatory =
observation, through 39 interviews with members of the community, the Hum=
an Rights Protocol Considerations Research Group mailing list, and during=
 and after the Technical Plenary on Protocols and Human Rights during IET=
F98.</t>

<t>Without judging them on their internal or external consistency they ar=
e represented here. Where possible we also sought to engage with the acad=
emic literature on this topic.</t>

<section anchor=3D"technology-is-value-neutral" title=3D"Technology is va=
lue neutral">
<t>This position starts from the premise that the technical and political=
 are differentiated fields and that technology is =E2=80=98value free=E2=80=
=99. This is also put more explicitly by Carey: =E2=80=9Celectronics is n=
either the arrival of apocalypse nor the dispensation of  grace.  Technol=
ogy  is  technology;  it  is  a  means  for  communication  and  transpor=
tation  over  space, and nothing more.=E2=80=9D <xref target=3D"Carey"/>.=
 In this view protocols only become political when it is actually being u=
sed by humans. So the technology itself is not political, the use of the =
technology is. This view sees technology as instrument; =E2=80=9Ctechnolo=
gies  are  =E2=80=98tools=E2=80=99 standing  ready  to  serve  the  purpo=
ses  of  their  users.  Technology  is  deemed  =E2=80=98neutral,=E2=80=99=
 without valuative content of its own.=E2=80=99=E2=80=9D <xref target=3D"=
Feenberg"/>. Feenberg continues: =E2=80=9Ctechnology  is  not  inherently=
  good  or  bad,  and  can  be  used  to  whatever  political  or  social=
  ends  desired  by  the  person  or  institution  in  control.  Technolo=
gy  is  a  =E2=80=98rational entity=E2=80=99 and universally applicable. =
One may make exceptions on moral grounds, but one must also understand th=
at the =E2=80=9Cprice for the achievement of environmental, ethical, or r=
eligious goals=E2=80=A6is reduced efficiency.=E2=80=9D <xref target=3D"Fe=
enberg"/>.</t>

</section>
<section anchor=3D"some-protocols-are-political-sometimes" title=3D"Some =
protocols are political sometimes">
<t>This stance is a pragmatic approach to the problem. It states that som=
e protocols under certain conditions can themselves have a political dime=
nsion.  This is different from the claim that a protocol might sometimes =
be used in a political way; that view is consistent with the idea of the =
technology being neutral (for the human action using the technology is wh=
ere the politics lies).  Instead, this position requires that each protoc=
ol and use be evaluated for its political dimension, in order to understa=
nd the extent to which it is political.</t>

</section>
<section anchor=3D"all-protocols-are-political-sometimes" title=3D"All pr=
otocols are political sometimes">
<t>While not an absolutist standpoint it recognizes that all design decis=
ions are subject to the law of unintended consequences. The system consis=
ting of the Internet and its users is vastly too complex to be predictabl=
e; it is chaotic in nature; its emergent properties cannot be predicted. =
This concept strongly hinges on the general purpose aspect of information=
 technology and its malleability. Whereas not all (potential) behaviours,=
 affordances and impacts of protocols can possible be predicted, one coul=
d at least consider the impact of proposed implementations.</t>

</section>
<section anchor=3D"the-network-has-its-own-logic-and-values" title=3D"The=
 network has its own logic and values">
<t>While humans create technologies, this does not mean that they are for=
ever under human control. A technology, once created, has its own logic t=
hat is independent of the human actors that either create or use the tech=
nology.</t>

<t>From this perspective, technologies can shape the world. As Martin Hei=
degger says, =E2=80=9CThe hydroelectric plant is not built into the Rhine=
 River as was the old wooden bridge that joined bank with bank for hundre=
ds of years. Rather the river is dammed up into the power plant. What the=
 river is now, namely, a water power supplier, derives from out of the es=
sence of the power station.=E2=80=9D <xref target=3D"Heidegger"/> (p 16) =
 The dam in the river changes the world in a way the bridge does not, bec=
ause the dam alters the nature of the river.</t>

<t>In the same way =E2=80=93 in another and more recent example =E2=80=93=
 the very existence of automobiles imposes physical forms on the world di=
fferent from those that come from the electric tram or the horse-cart. Th=
e logic of the automobile means speed and the rapid covering of distance,=
 which encourages suburban development and a tendency toward conurbation.=
 But even if that did not happen, widespread automobile use requires pave=
d roads, and parking lots and structures. These are pressures that come f=
rom the automotive technology itself, and would not arise without that te=
chnology.</t>

<t>In much same way, then, networking technology, such as protocols, crea=
tes its own demands. One of the most important conditions for a protocol=E2=
=80=99s success is its incremental deployability <xref target=3D"RFC5218"=
/>.  This means that the network already contains constraints on what can=
 be deployed into it. In this sense the network creates its own paths, bu=
t also has its own objective. According to this view the goal of the netw=
ork is interconnection and connectivity; more connectivity is good for th=
e network. Proponents of this positions also often describe the Internet =
as an organism with its own unique ecosystem.</t>

<t>In this position it is not necessarily clear where the =E2=80=98social=
=E2=80=99 ends and the =E2=80=98technical=E2=80=99 begins, and it could b=
e argued that the distinction itself is a social construction <xref targe=
t=3D"BijkerLaw"/> or that a real-life distinction between the two is hard=
 to make <xref target=3D"Bloor"/>.</t>

</section>
<section anchor=3D"protocols-are-inherently-political" title=3D"Protocols=
 are inherently political">
<t>This position argues the opposite of =E2=80=98technological neutrality=
=E2=80=99. This position is illustrated by Postman when he writes: =E2=80=
=9Cthe uses made of technology are largely determined by the structure of=
 the technology itself=E2=80=9D <xref target=3D"Postman"/>. He states tha=
t the medium itself =E2=80=9Ccontains an ideological bias=E2=80=9D. He co=
ntinues to argue that technology is non-neutral:</t>

<t>(1) because of the symbolic forms in which information is encoded, dif=
ferent media have different intellectual and emotional biases;</t>

<t>(2) because of the accessibility and speed of their information, diffe=
rent media have different political biases;</t>

<t>(3) because of their physical form, different media have different sen=
sory biases;</t>

<t>(4) because of the conditions in which we attend to them, different me=
dia have different social biases;</t>

<t>(5) because of their technical and economic structure, different media=
 have different content biases.</t>

<t>Recent scholars of Internet infrastructure and governance have also po=
inted out that Internet processes and standards have become part and parc=
el of political processes and public policies. Several concrete examples =
are found within this approach, for instance, the IANA transition or glob=
al innovation policy <xref target=3D"DeNardis"/>. The Raven process in wh=
ich the IETF refused to standardize wiretapping =E2=80=93 which resulted =
in <xref target=3D"RFC2804"/> =E2=80=93 was an instance where an internat=
ional governance body took a position that was largely political, althoug=
h driven by a technical argument. The process that led to <xref target=3D=
"RFC7258"/> is similar: the Snowden disclosures, which occured in the pol=
itical space, engendered the IETF to act. This is summarized in <xref tar=
get=3D"Abbate"/> who says: =E2=80=9Cprotocols are politics by other means=
,=E2=80=9D emphasizing the interests that are at play in the process of d=
esigning standards.</t>

<t>This position further holds that protocols can never be understood wit=
hout their contextual embeddedness: protocols do not exist solely by them=
selves but always are to be understood in a more complex context =E2=80=93=
 the stack, hardware, or nation-state interests and their impact on civil=
 rights. Finally, this view is that protocols are political because they =
influence the socio-technical workings of reality and society. The latter=
 observation leads Winner to conclude that the reality of technological p=
rogress has too often been a scenario where innovation has dictated chang=
e for society. Those who had the power to introduce a new technology also=
 had the power to create a consumer class to use the technology =E2=80=9C=
with new practices, relationships, and identities supplanting the old, =E2=
=80=94 and those who had the wherewithal to implement new technologies of=
ten molded society to match the needs of emerging technologies and organi=
zations.=E2=80=9D <xref target=3D"Winner"/>.</t>

</section>
</section>
<section anchor=3D"ietf-protocols-as-standards" title=3D"IETF: Protocols =
as Standards">

<t>In the previous section we gave an overview of the different existing =
positions of the impact of Internet protocols in the Internet protocol co=
mmunity. In the following section we will review the standards setting pr=
ocess and its consequences for the politics of protocols, through the len=
s of existing literature on standards setting.</t>

<t>Standards enabling interoperating networks, what we think of today as =
the Internet, were created as open, formal and voluntary standards. A pla=
tform for Internet standardization, the Internet Engineering Task Force (=
IETF), was created in 1986 to enable the continuation of such standardiza=
tion work. The IETF has sought to make the standards process transparent =
(by ensuring everyone can access standards, mailing-lists and meetings), =
predictable (by having clear procedures and reviews) and of high quality =
(by having draft documents reviewed by experts from its own community). T=
his is all aimed at increasing the accountability of the process and the =
quality of the standard.</t>

<t>The IETF implements what has been referred to as an =E2=80=9Cinformal =
ex ante disclosure policy=E2=80=9D for patents <xref target=3D"Contreras"=
/>, which includes the possibility for participants to disclose the exist=
ence of a patent relevant for the standard, royalty-terms which would app=
ly to the implementers of that standard should it enter into effect, as w=
ell as other licensing terms that may be interesting for implementers to =
know. The community ethos in the IETF seems to lead to 100% royalty-free =
disclosures of prior patents which is a record number, even among other c=
omparable standard organizations <xref target=3D"Contreras"/>. In the fol=
lowing paragraph we will describe inherent tensions in the standards proc=
ess.</t>

<section anchor=3D"competition-and-collaboration" title=3D"Competition an=
d collaboration">

<t>Standards exist for nearly everything: processes, technologies, safety=
, hiring, elections, and training. Standards provide blue-prints for how =
to accomplish a particular task in a similar way for others that are tryi=
ng to accomplish the same thing, while reducing overhead and inefficienci=
es. Although there are different types and configurations of standards, t=
hey all enhance competition by allowing different entities to work from a=
 commonly accepted baseline.</t>

<t>On the first types of standards than can be found are =E2=80=9Cinforma=
l=E2=80=9D ones =E2=80=93 agreed-upon normal ways of interacting within a=
 specific community. For example, the process through which greetings to =
a new acquaintance are expressed through a bow, a handshake or a kiss. On=
 the other hand, =E2=80=9Cformal=E2=80=9D standards are normally codified=
 in writing.</t>

<t>Within economy studies, <spanx style=3D"emph">de facto</spanx> standar=
ds arise in market situations where one entity is particularly dominant; =
downstream competitors are therefore tied to the dominant entity=E2=80=99=
s technological solutions <xref target=3D"Ahlborn"/>. Under EU anti-trust=
 law, <spanx style=3D"emph">de facto</spanx> standards have been found to=
 restrict competition for downstream services in PC software products <xr=
ef target=3D"CJEU2007"/>, as well as downstream services dependent on hea=
lth information <xref target=3D"CJEU2004"/>.</t>

<t>Even in international law, the World Trade Organization (WTO) uses sta=
ndards, although it recognizes a difference between standards and technic=
al regulations. The former are voluntary formal codes to which products o=
r services may conform, while technical regulations are mandatory require=
ments to be fullfilled for a product to be accessible in a national marke=
t. These rules have implications for how nation states bound by WTO agree=
ments can impose specific technical requirements on companies. Nonetheles=
s, there are many standardization groups that were originally launched by=
 nation states or groups of nation states. ISO, BIS, CNIS, NIST, ABNT and=
 ETSI are examples of institutions that are, wholly or partially, sponsor=
ed by public money in order to ensure the smooth development of formal st=
andards. Even if under WTO rules these organizations cannot create the eq=
uivalent of a technical regulation, they have important normative functio=
ns in their respective countries. No matter what form, all standards enha=
nce competition and collaboration because they define a common approach t=
o a problem. This potentially allows different instances to interoperate =
or be evaluated according to the same indicators.</t>

<t>The development of formal standards faces a number of economic and org=
anizational challenges. Mainly, the cost and difficulty of organizing man=
y entities around a mutual goal, as well as the cost of research and deve=
lopment leading up to a mutually beneficial technological platform. In ad=
dition, deciding what the mutual goal is can also be a problem. These cha=
llenges may be described as inter-organizational costs. Even after a goal=
 is decided upon, coordination of multiple entities requires time and mon=
ey. One needs communication platforms, processes and a commitment to mutu=
al investment in a higher good. They are not simple tasks, and the more d=
ifferent communities are affected by a particular standardization process=
, the more difficult the organizational challenges become.</t>

</section>
<section anchor=3D"how-voluntary-are-open-standards" title=3D"How volunta=
ry are open standards?">

<t>Coordinating transnational stakeholders in a process of negotiation an=
d agreement through the development of common rules is a form of global g=
overnance <xref target=3D"Nadvi"/>. Standards are among the mechanisms by=
 which this governance is achieved. Conformance to certain standards is o=
ften a basic condition of participation in international trade and commun=
ication, so there are strong economic and political incentives to conform=
, even in the absence of legal requirements <xref target=3D"Russell"/>. <=
xref target=3D"RogersEden"/> argue:</t>

<t>=E2=80=9CAs unequal participants compete to define standards, technolo=
gical compromises emerge, which add complexity to standards. For instance=
, when working group participants propose competing solutions, it may be =
easier for them to agree on a standard that combines all the proposals ra=
ther than choosing any single proposal. This shifts the responsibility fo=
r selecting a solution onto those who implement the standard, which can l=
ead to complex implementations that may not be interoperable. On its face=
 this appears to be a failure of the standardization process, but this ou=
tcome may benefit certain participants =E2=80=93 for example, by allowing=
 an implementer with large market share to establish a <spanx style=3D"em=
ph">de facto</spanx> standard within the scope of the documented standard=
=2E=E2=80=9D</t>

</section>
</section>
<section anchor=3D"conclusion" title=3D"Conclusion">

<t>Economics, competition, collaboration, openness, and political impact =
have been an inherent part of the work of the IETF since its early beginn=
ings. The IETF cannot ordain which standards are to be used on the networ=
ks, and it specifically does not determine the laws of regions or countri=
es where networks are being used, but it does set open standards for inte=
roperability on the Internet, and has done so since the inception of the =
Internet. Because a standard is the blue-print for how to accomplish a pa=
rticular task, the adopted standards have a normative effect. The standar=
dization work at the IETF has direct implications on what is perceived as=
 technologically possible and useful where networking technologies are be=
ing deployed, and thus its standards reflect what is considered by the te=
chnical community as feasible and good practice.</t>

<t>Whereas there might not be agreement among the Internet protocol commu=
nity on the specific political nature of the technological development pr=
ocess and its outputs, it is undisputed that standards and protocols are =
both products of a political process, and they can also be used for polit=
ical means. Therefore protocols and standards are not =E2=80=98value-neut=
ral, and neither is the IETF=E2=80=99 <xref target=3D"RFC3935"/>. Thus we=
 can answer the research question =E2=80=98are protocols political=E2=80=99=
 in affirmative fashion.</t>

<t>Further research could explore how the political nature of protocols c=
an be taken into account in the standards development process in order to=
 (1) to minimize negative unintended social consequences, (2) ensure clea=
r understanding of the intended consequences, (3) maintain importance of =
the IETF as open standards body that facilitates global interoperability.=
</t>

</section>
<section anchor=3D"security-considerations" title=3D"Security Considerati=
ons">

<t>As this draft concerns a research document, there are no security cons=
iderations as described in <xref target=3D"RFC3552"/>, which does not mea=
n that not addressing the issues brought up in this draft will not impact=
 the security of end-users or operators.</t>

</section>
<section anchor=3D"iana-considerations" title=3D"IANA Considerations">

<t>This document has no actions for IANA.</t>

</section>
<section anchor=3D"acknowledgements" title=3D"Acknowledgements">

<t>Thanks to Michael Rogers, Joe Hall, Andrew Sullivan, Brian Carpenter, =
Mark Perkins, S Moonesamy and all contributors and reviewers on the hrpc =
mailinglist. Special thanks to Gisela Perez de Acha for some thorough edi=
ting rounds, and Amelia Andersdotter for text contributions.</t>

</section>
<section anchor=3D"research-group-information" title=3D"Research Group In=
formation">

<t>The discussion list for the IRTF Human Rights Protocol Considerations =
Research Group is located at the e-mail address <eref target=3D"mailto:hr=
pc@ietf.org">hrpc@ietf.org</eref>. Information on the group and informati=
on on how to subscribe to the list is at:
<eref target=3D"https://www.irtf.org/mailman/listinfo/hrpc">https://www.i=
rtf.org/mailman/listinfo/hrpc</eref></t>

<t>Archives of the list can be found at:
<eref target=3D"https://www.irtf.org/mail-archive/web/hrpc/current/index.=
html">https://www.irtf.org/mail-archive/web/hrpc/current/index.html</eref=
></t>

</section>


  </middle>

  <back>


    <references title=3D'Informative References'>





<reference  anchor=3D"RFC0049" target=3D'https://www.rfc-editor.org/info/=
rfc49'>
<front>
<title>Conversations with S. Crocker (UCLA)</title>
<author initials=3D'E.' surname=3D'Meyer' fullname=3D'E. Meyer'><organiza=
tion /></author>
<date year=3D'1970' month=3D'April' />
</front>
<seriesInfo name=3D'RFC' value=3D'49'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0049'/>
</reference>



<reference  anchor=3D"RFC0101" target=3D'https://www.rfc-editor.org/info/=
rfc101'>
<front>
<title>Notes on the Network Working Group meeting, Urbana, Illinois, Febr=
uary 17, 1971</title>
<author initials=3D'R.W.' surname=3D'Watson' fullname=3D'R.W. Watson'><or=
ganization /></author>
<date year=3D'1971' month=3D'February' />
</front>
<seriesInfo name=3D'RFC' value=3D'101'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0101'/>
</reference>



<reference  anchor=3D"RFC0144" target=3D'https://www.rfc-editor.org/info/=
rfc144'>
<front>
<title>Data sharing on computer networks</title>
<author initials=3D'A.' surname=3D'Shoshani' fullname=3D'A. Shoshani'><or=
ganization /></author>
<date year=3D'1971' month=3D'April' />
</front>
<seriesInfo name=3D'RFC' value=3D'144'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0144'/>
</reference>



<reference  anchor=3D"RFC0164" target=3D'https://www.rfc-editor.org/info/=
rfc164'>
<front>
<title>Minutes of Network Working Group meeting, 5/16 through 5/19/71</ti=
tle>
<author initials=3D'J.F.' surname=3D'Heafner' fullname=3D'J.F. Heafner'><=
organization /></author>
<date year=3D'1971' month=3D'May' />
</front>
<seriesInfo name=3D'RFC' value=3D'164'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0164'/>
</reference>



<reference  anchor=3D"RFC0196" target=3D'https://www.rfc-editor.org/info/=
rfc196'>
<front>
<title>Mail Box Protocol</title>
<author initials=3D'R.W.' surname=3D'Watson' fullname=3D'R.W. Watson'><or=
ganization /></author>
<date year=3D'1971' month=3D'July' />
</front>
<seriesInfo name=3D'RFC' value=3D'196'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0196'/>
</reference>



<reference  anchor=3D"RFC0286" target=3D'https://www.rfc-editor.org/info/=
rfc286'>
<front>
<title>Network Library Information System</title>
<author initials=3D'E.' surname=3D'Forman' fullname=3D'E. Forman'><organi=
zation /></author>
<date year=3D'1971' month=3D'December' />
</front>
<seriesInfo name=3D'RFC' value=3D'286'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0286'/>
</reference>



<reference  anchor=3D"RFC0313" target=3D'https://www.rfc-editor.org/info/=
rfc313'>
<front>
<title>Computer based instruction</title>
<author initials=3D'T.C.' surname=3D'O&apos;Sullivan' fullname=3D'T.C. O&=
apos;Sullivan'><organization /></author>
<date year=3D'1972' month=3D'March' />
</front>
<seriesInfo name=3D'RFC' value=3D'313'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0313'/>
</reference>



<reference  anchor=3D"RFC0316" target=3D'https://www.rfc-editor.org/info/=
rfc316'>
<front>
<title>ARPA Network Data Management Working Group</title>
<author initials=3D'D.B.' surname=3D'McKay' fullname=3D'D.B. McKay'><orga=
nization /></author>
<author initials=3D'A.P.' surname=3D'Mullery' fullname=3D'A.P. Mullery'><=
organization /></author>
<date year=3D'1972' month=3D'February' />
</front>
<seriesInfo name=3D'RFC' value=3D'316'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0316'/>
</reference>



<reference  anchor=3D"RFC0542" target=3D'https://www.rfc-editor.org/info/=
rfc542'>
<front>
<title>File Transfer Protocol</title>
<author initials=3D'N.' surname=3D'Neigus' fullname=3D'N. Neigus'><organi=
zation /></author>
<date year=3D'1973' month=3D'August' />
</front>
<seriesInfo name=3D'RFC' value=3D'542'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0542'/>
</reference>



<reference  anchor=3D"RFC0549" target=3D'https://www.rfc-editor.org/info/=
rfc549'>
<front>
<title>Minutes of Network Graphics Group meeting, 15-17 July 1973</title>=

<author initials=3D'J.C.' surname=3D'Michener' fullname=3D'J.C. Michener'=
><organization /></author>
<date year=3D'1973' month=3D'July' />
</front>
<seriesInfo name=3D'RFC' value=3D'549'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0549'/>
</reference>



<reference  anchor=3D"RFC0613" target=3D'https://www.rfc-editor.org/info/=
rfc613'>
<front>
<title>Network connectivity: A response to RFC 603</title>
<author initials=3D'A.M.' surname=3D'McKenzie' fullname=3D'A.M. McKenzie'=
><organization /></author>
<date year=3D'1974' month=3D'January' />
</front>
<seriesInfo name=3D'RFC' value=3D'613'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC0613'/>
</reference>



<reference  anchor=3D"RFC1087" target=3D'https://www.rfc-editor.org/info/=
rfc1087'>
<front>
<title>Ethics and the Internet</title>
<author><organization>Defense Advanced Research Projects Agency</organiza=
tion></author>
<author><organization>Internet Activities Board</organization></author>
<date year=3D'1989' month=3D'January' />
<abstract><t>This memo is a statement of policy by the Internet Activitie=
s Board (IAB) concerning the proper use of the resources of the Internet.=
</t></abstract>
</front>
<seriesInfo name=3D'RFC' value=3D'1087'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC1087'/>
</reference>



<reference  anchor=3D"RFC2804" target=3D'https://www.rfc-editor.org/info/=
rfc2804'>
<front>
<title>IETF Policy on Wiretapping</title>
<author><organization>IAB</organization></author>
<author><organization>IESG</organization></author>
<date year=3D'2000' month=3D'May' />
<abstract><t>This document describes the position that the Internet Engin=
eering Task Force (IETF) has taken regarding the inclusion into IETF stan=
dards-track documents of functionality designed to facilitate wiretapping=
=2E  This memo explains what the IETF thinks the question means, why its =
answer is &quot;no&quot;, and what that answer means.  This memo provides=
 information for the Internet community.</t></abstract>
</front>
<seriesInfo name=3D'RFC' value=3D'2804'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC2804'/>
</reference>



<reference  anchor=3D"RFC3271" target=3D'https://www.rfc-editor.org/info/=
rfc3271'>
<front>
<title>The Internet is for Everyone</title>
<author initials=3D'V.' surname=3D'Cerf' fullname=3D'V. Cerf'><organizati=
on /></author>
<date year=3D'2002' month=3D'April' />
<abstract><t>This document expresses the Internet Society's ideology that=
 the Internet really is for everyone.  However, it will only be such  if =
we make it so.  This memo provides information for the Internet community=
=2E</t></abstract>
</front>
<seriesInfo name=3D'RFC' value=3D'3271'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC3271'/>
</reference>



<reference  anchor=3D"RFC3552" target=3D'https://www.rfc-editor.org/info/=
rfc3552'>
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</title>=

<author initials=3D'E.' surname=3D'Rescorla' fullname=3D'E. Rescorla'><or=
ganization /></author>
<author initials=3D'B.' surname=3D'Korver' fullname=3D'B. Korver'><organi=
zation /></author>
<date year=3D'2003' month=3D'July' />
<abstract><t>All RFCs are required to have a Security Considerations sect=
ion. Historically, such sections have been relatively weak.  This documen=
t provides guidelines to RFC authors on how to write a good Security Cons=
iderations section.   This document specifies an Internet Best Current Pr=
actices for the Internet Community, and requests discussion and suggestio=
ns for improvements.</t></abstract>
</front>
<seriesInfo name=3D'BCP' value=3D'72'/>
<seriesInfo name=3D'RFC' value=3D'3552'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC3552'/>
</reference>



<reference  anchor=3D"RFC3935" target=3D'https://www.rfc-editor.org/info/=
rfc3935'>
<front>
<title>A Mission Statement for the IETF</title>
<author initials=3D'H.' surname=3D'Alvestrand' fullname=3D'H. Alvestrand'=
><organization /></author>
<date year=3D'2004' month=3D'October' />
<abstract><t>This memo gives a mission statement for the IETF, tries to d=
efine the terms used in the statement sufficiently to make the mission st=
atement understandable and useful, argues why the IETF needs a mission st=
atement, and tries to capture some of the debate that led to this point. =
 This document specifies an Internet Best Current Practices for the Inter=
net Community, and requests discussion and suggestions for improvements.<=
/t></abstract>
</front>
<seriesInfo name=3D'BCP' value=3D'95'/>
<seriesInfo name=3D'RFC' value=3D'3935'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC3935'/>
</reference>



<reference  anchor=3D"RFC5218" target=3D'https://www.rfc-editor.org/info/=
rfc5218'>
<front>
<title>What Makes for a Successful Protocol?</title>
<author initials=3D'D.' surname=3D'Thaler' fullname=3D'D. Thaler'><organi=
zation /></author>
<author initials=3D'B.' surname=3D'Aboba' fullname=3D'B. Aboba'><organiza=
tion /></author>
<date year=3D'2008' month=3D'July' />
<abstract><t>The Internet community has specified a large number of proto=
cols to date, and these protocols have achieved varying degrees of succes=
s. Based on case studies, this document attempts to ascertain factors tha=
t contribute to or hinder a protocol's success.  It is hoped that these o=
bservations can serve as guidance for future protocol work.  This memo  p=
rovides information for the Internet community.</t></abstract>
</front>
<seriesInfo name=3D'RFC' value=3D'5218'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC5218'/>
</reference>



<reference  anchor=3D"RFC7258" target=3D'https://www.rfc-editor.org/info/=
rfc7258'>
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials=3D'S.' surname=3D'Farrell' fullname=3D'S. Farrell'><orga=
nization /></author>
<author initials=3D'H.' surname=3D'Tschofenig' fullname=3D'H. Tschofenig'=
><organization /></author>
<date year=3D'2014' month=3D'May' />
<abstract><t>Pervasive monitoring is a technical attack that should be mi=
tigated in the design of IETF protocols, where possible.</t></abstract>
</front>
<seriesInfo name=3D'BCP' value=3D'188'/>
<seriesInfo name=3D'RFC' value=3D'7258'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC7258'/>
</reference>



<reference  anchor=3D"RFC8280" target=3D'https://www.rfc-editor.org/info/=
rfc8280'>
<front>
<title>Research into Human Rights Protocol Considerations</title>
<author initials=3D'N.' surname=3D'ten Oever' fullname=3D'N. ten Oever'><=
organization /></author>
<author initials=3D'C.' surname=3D'Cath' fullname=3D'C. Cath'><organizati=
on /></author>
<date year=3D'2017' month=3D'October' />
<abstract><t>This document aims to propose guidelines for human rights co=
nsiderations, similar to the work done on the guidelines for privacy cons=
iderations (RFC 6973).  The other parts of this document explain the back=
ground of the guidelines and how they were developed.</t><t>This document=
 is the first milestone in a longer-term research effort.  It has been re=
viewed by the Human Rights Protocol Considerations (HRPC) Research Group =
and also by individuals from outside the research group.</t></abstract>
</front>
<seriesInfo name=3D'RFC' value=3D'8280'/>
<seriesInfo name=3D'DOI' value=3D'10.17487/RFC8280'/>
</reference>


<reference anchor=3D"BramanI" target=3D"http://dx.doi.org.proxy.uba.uva.n=
l:2048/10.1177%2F1742766511434731">
  <front>
    <title>Internationalization of the Internet by design: The first deca=
de</title>
    <author initials=3D"S." surname=3D"Braman">
      <organization></organization>
    </author>
    <date year=3D"2012"/>
  </front>
  <seriesInfo name=3D"Global Media and Communication, Vol 8, Issue 1, pp.=
 27 - 45" value=3D""/>
</reference>
<reference anchor=3D"BramanII" target=3D"http://dx.doi.org.proxy.uba.uva.=
nl:2048/10.1080/01972243.2011.607027">
  <front>
    <title>The Framing Years: Policy Fundamentals in the Internet Design =
Process, 1969=E2=80=931979</title>
    <author initials=3D"S." surname=3D"Braman">
      <organization></organization>
    </author>
    <date year=3D"2010"/>
  </front>
  <seriesInfo name=3D"The Information Society Vol. 27, Issue 5, 2011" val=
ue=3D""/>
</reference>
<reference anchor=3D"Contreras" >
  <front>
    <title>Technical Standards and Ex Ante Disclosure: Results and Analys=
is of an Empirical Study</title>
    <author initials=3D"J.L." surname=3D"Contreras">
      <organization></organization>
    </author>
    <date year=3D"2013"/>
  </front>
  <seriesInfo name=3D"Jurimetrics: The Journal of Law, Science &amp; Tech=
nology, vol. 53, p. 163-211" value=3D""/>
</reference>
<reference anchor=3D"Feenberg" >
  <front>
    <title>Critical Theory of Technology</title>
    <author initials=3D"A." surname=3D"Feenberg">
      <organization></organization>
    </author>
    <date year=3D"1991"/>
  </front>
  <seriesInfo name=3D"p.5-6" value=3D""/>
</reference>
<reference anchor=3D"Carey" >
  <front>
    <title>Communication As Culture</title>
    <author initials=3D"J." surname=3D"Carey">
      <organization></organization>
    </author>
    <date year=3D"1992"/>
  </front>
  <seriesInfo name=3D"p. 139" value=3D""/>
</reference>
<reference anchor=3D"Postman" >
  <front>
    <title>Technopoly: the Surrender of Culture to Technology</title>
    <author initials=3D"N." surname=3D"Postman">
      <organization></organization>
    </author>
    <date year=3D"1992"/>
  </front>
  <seriesInfo name=3D"Vintage: New York. pp. 3=E2=80=9320." value=3D""/>
</reference>
<reference anchor=3D"DeNardis" target=3D"http://is.gd/7GAnFy">
  <front>
    <title>The Internet Design Tension between Surveillance and Security<=
/title>
    <author initials=3D"L." surname=3D"Denardis">
      <organization></organization>
    </author>
    <date year=3D"2015"/>
  </front>
  <seriesInfo name=3D"IEEE Annals of the History of Computing (volume 37-=
2)" value=3D""/>
</reference>
<reference anchor=3D"Winner" >
  <front>
    <title>Upon opening the black box and finding it empty: Social constr=
uctivism and the philosophy of technology</title>
    <author initials=3D"L." surname=3D"Winner">
      <organization></organization>
    </author>
    <date year=3D"1993"/>
  </front>
  <seriesInfo name=3D"Science, Technology, and Human Values 18 (3) p. 362=
-378" value=3D""/>
</reference>
<reference anchor=3D"Abbate" target=3D"https://mitpress.mit.edu/books/inv=
enting-internet">
  <front>
    <title>Inventing the Internet</title>
    <author initials=3D"J." surname=3D"Abbate">
      <organization></organization>
    </author>
    <date year=3D"2000"/>
  </front>
  <seriesInfo name=3D"MIT Press" value=3D""/>
</reference>
<reference anchor=3D"Heidegger" target=3D"http://ssbothwell.com/documents=
/ebooksclub.org__The_Question_Concerning_Technology_and_Other_Essays.pdf"=
>
  <front>
    <title>The Question Concerning Technology and Other Essays</title>
    <author initials=3D"M." surname=3D"Heidegger">
      <organization></organization>
    </author>
    <date year=3D"1977"/>
  </front>
  <seriesInfo name=3D"Garland: New York, 1977" value=3D""/>
</reference>
<reference anchor=3D"Nadvi" >
  <front>
    <title>Making sense of global standards</title>
    <author initials=3D"K." surname=3D"Nadvi">
      <organization></organization>
    </author>
    <author initials=3D"F." surname=3D"W=C3=A4ltring">
      <organization></organization>
    </author>
    <date year=3D"2004"/>
  </front>
  <seriesInfo name=3D"In: H. Schmitz (Ed.), Local enterprises in the glob=
al economy (pp. 53=E2=80=9394). Cheltenham, UK: Edward Elgar." value=3D""=
/>
</reference>
<reference anchor=3D"Russell" >
  <front>
    <title>Open standards and the digital age: History, ideology, and net=
works</title>
    <author initials=3D"A.M." surname=3D"Russell">
      <organization></organization>
    </author>
    <date year=3D"2014"/>
  </front>
  <seriesInfo name=3D"Cambridge, UK: Cambridge University Press" value=3D=
""/>
</reference>
<reference anchor=3D"RogersEden" target=3D"http://ijoc.org/index.php/ijoc=
/article/view/5525/1941">
  <front>
    <title>The Snowden Disclosures, Technical Standards, and the Making o=
f Surveillance Infrastructures</title>
    <author initials=3D"M." surname=3D"Rogers">
      <organization></organization>
    </author>
    <author initials=3D"G." surname=3D"Eden">
      <organization></organization>
    </author>
    <date year=3D"2017"/>
  </front>
  <seriesInfo name=3D"International Journal of Communication 11(2017), 80=
2-823" value=3D""/>
</reference>
<reference anchor=3D"CJEU2004" target=3D"http://curia.europa.eu/juris/lis=
te.jsf?num=3DC-418/01">
  <front>
    <title>ECLI:EU:C:2004:257, C-418/01 IMS Health</title>
    <author initials=3D"." surname=3D"Court of Justice of the European Un=
ion">
      <organization></organization>
    </author>
    <date year=3D"2004"/>
  </front>
  <seriesInfo name=3D"Cambridge, UK: Cambridge University Press" value=3D=
""/>
</reference>
<reference anchor=3D"CJEU2007" target=3D"http://curia.europa.eu/juris/lis=
te.jsf?num=3DT-201/04">
  <front>
    <title>ECLI:EU:T:2007:289, T-201/04 Microsoft Corp.</title>
    <author initials=3D"." surname=3D"Court of Justice of the European Un=
ion">
      <organization></organization>
    </author>
    <date year=3D"2007"/>
  </front>
  <seriesInfo name=3D"Cambridge, UK: Cambridge University Press" value=3D=
""/>
</reference>
<reference anchor=3D"Ahlborn" target=3D"http://curia.europa.eu/juris/list=
e.jsf?num=3DT-201/04">
  <front>
    <title>Implications of the Proposed Framework and Antitrust Rules for=
 Dynamically Competitive Industries</title>
    <author initials=3D"C." surname=3D"Ahlborn">
      <organization></organization>
    </author>
    <author initials=3D"V." surname=3D"Denicol=C3=B3">
      <organization></organization>
    </author>
    <author initials=3D"D." surname=3D"Geradin">
      <organization></organization>
    </author>
    <author initials=3D"A.J." surname=3D"Padilla">
      <organization></organization>
    </author>
    <date year=3D"2006"/>
  </front>
  <seriesInfo name=3D"DG Comp=E2=80=99s Discussion Paper on Article 82, D=
G COMP, European Commission" value=3D""/>
</reference>
<reference anchor=3D"HagueHarrop" >
  <front>
    <title>Comparative Government and Politics: An Introduction</title>
    <author initials=3D"R." surname=3D"Hague">
      <organization></organization>
    </author>
    <author initials=3D"M." surname=3D"Harrop">
      <organization></organization>
    </author>
    <date year=3D"2013"/>
  </front>
  <seriesInfo name=3D"Macmillan International Higher Education. pp. 1=E2=80=
=93. ISBN 978-1-137-31786-5." value=3D""/>
</reference>
<reference anchor=3D"BijkerLaw" >
  <front>
    <title>Shaping Technology/ Building Society: Studies in Sociotechnica=
l Change</title>
    <author initials=3D"W." surname=3D"Bijker">
      <organization></organization>
    </author>
    <author initials=3D"J." surname=3D"Law">
      <organization></organization>
    </author>
    <date year=3D"1992"/>
  </front>
  <seriesInfo name=3D"Cambridge, MA: MIT Press" value=3D""/>
</reference>
<reference anchor=3D"Bloor" >
  <front>
    <title>Knowledge and Social Imagery</title>
    <author initials=3D"D." surname=3D"Bloor">
      <organization></organization>
    </author>
    <date year=3D"1976"/>
  </front>
  <seriesInfo name=3D"London: Routeledge &amp; Kegan Paul" value=3D""/>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIAL+hd10AA+192ZIbR5ble36FW7Z1JzkDIFcyF3VXdZJKLipR4pCUZP1E
c0Q4AFcGwlHhEQlCNJr1P/TTPI7Z/MF8Qv1Jf8ncc6+7hwcSJFVlXfM0epCQ
QIQvdz13cdd4PN5rbVuZK/WDa41Xrla1adeuubX1XPlW16VuSq/ov2rlKtva
wu/p6bQxd1fhiw97pStqvaQxykbP2rFt2tl40ayKcXhDV+Ojs71Ct2bums2V
svXM7e3ZVXOl2qbz7cnR0eXRyZ5ujL5SL9+8e7aHBcwb162u1ItuqWv1xs4X
rVevG9e6wlXqqau9LU2jW0uf1BvjjW6KhXqOl/ZuzYZGKGmwujUNbWj8LVa2
x/t5rytX02I3xu+t7NWeUs2sMKVvN1X4VimaJPto69LUbfzCu6ZtzMynvzfL
wZ9tY4v0cOGWS3o3/Wrrytb9NOZDO66sb8c0yNRV9NjY/bf/vrenu3bhmqu9
MT3E/9iafvthQm/U6kdzZxr1wJS2dc3D+IRw4AdrKt8/FX90zVzX9jem1pX6
qbb0m7ftRrmZul56IlKpl/Fhs9S2ulL497/WGI+GcxhtQpTc26tds6SB7swV
8ZA42f9F77559vTo6OzyKn4+PjruP5+d9Z8fZ58vH6fPJxf959Pj0+xz//2j
s5Pscz/X4/7546OL8/j55OIozXV6cp7Wc/roURrn9PL0Ufz86OT4In4+P3mU
Pl/QQLLJJ40mmXx5JQQL+rMvssYk1lWgNejbLkySQzXdqNJ4OycuvKPvZ7bx
LX1T6NLsy3AlqcmVOjk6PpG/oygE5qixyMLbSVhGWIRu5oakbtG2q6vDw/LD
pHR2QmyfrBr3YTPppnrS3elJXV2dHJ1dHB4fTY6Pz8//8eTZ8fnZyfnjx4+O
j89Oz85Pj2U8bxpL6yT20s6eV26qK/WKJE6zJXhKUt3VpNjY40j9TAp5MVIv
ve+MOh6p1WqiTs5ppWeP9nOCbVMMFHhGP8HU/BvpL23rNVmMYqOedWR3oDia
pNnWQxp+ywSELSiM9yNF8nP5n//+H8eX55fbNDz6e9Pw6OLokAT4/OTk7HRC
Ex5PHh+dH52c76DiO95D0BcSjbdkWAypIFEP5Ir0ezTCwo+FcGTmyNY02g8p
R4OZYgEGVOrtwEbffFDXRCf1rfVF5XzX0NNkHLuqld+vSTY33noIJpnVm+XK
NmGYrtxsk+/0i+T7bvL9pF/hgIY7tv9d19ilgXH0IvvfuY7UpcJKvtfrkXpL
5KgLo/5JL1ffKN6gq9x8M1J3oNCjUxKsiTp+fDo+ieR5Zkw9Nc18SJ2njTgd
zEL+BhP0o+U7PL68PN65w7DB60ma4f6GVpNH48fCJHJcm60l5Aqirr16Shwg
ZmzNvlvFE3ll5F1Tq+PTS577tfMtCfC2YvF2yfuSs4XqvO2axpATa0CLsBRy
bBlZ9v+alZEfCvPu4PPPlrR2Dldk1urfyI9P2B6ckoaeHE2Eb9+aH0hi7ZZU
v9uh5O8M+Xki4ZRACbECO7kztqo0JAUC/dYUJFjtZktyH31p/SS235qaV7BT
862fzMvD8+fX9bMd1H95c3NDelTDNAXz/oJceJA04vyqa2HRHpDYdkujTs/H
Jw9527/YujbNcNO/LJxa04bU2tAmYeuKDQmcX+nC/HGLKbs3lW9LZhhuyq4L
U88JZSyOJ+1mZVa6nBAsOaTv3y9h0t+bgmXg8FtXdIxWDmlV77Gq92vzfmre
2/p9vyqyigVv53o6xcrCOsJ+XtZ3NAL2n9vs8Exkz1Gwy5+3LGHwOHbGH08M
Wtp21ZDtn9CHiSm7w6lzt/7QxrnHdjhvzr5XL9+R66CXeQ8vDKHI+TxxZeCb
/kdnPCswGbmCxsOuepVh8fuRdtmoG+/1xu8PdklO4fzLu3w16aff2uh+kETv
p65drE1VMcvKxCDDOy6qbgoH9f49Lfd9XO77frnv++W+B/Tl5b6X5U5W5Wx/
B4H2n+uG9KvsNXjEmxHV/UGXd3aLWK+0RAukqwY6MBe8kKKHbe6ffZkuf5rI
LNvfPyP5/sv/rsiF1PNd635JoOrFhPzIgsTiN/Xgppw8HKnvHVyBgUCsGutN
whNhlST8tVtu1ANYqUcwU5dnD8n0LkxFuHehlyP105+u1E25pq2om2qum2DF
3nTeE2e2JefHFdmpYeSE6Uo7twRnFNvGYDBGitgfnByeC6HXliSROfsKxa4n
JEthObso81Qvp40t50b2kv7MIwHWibAxRxLpbyjo2aUVb2u3pp8yiEEYbAce
GaWtB/kgyRiYbwJDhBsoAizgj+5v+uvqIwvd/uH5RGHtu0Ukw+g5Ahk67OPj
B5ifpOfi6GR8cXK6/xn9tL+6Agp4iBDxw2S1WPFXh7ohBFKZwztr1ocUZzw6
PL48i5juu5ufoATbtL15+v3Lq5ufrp5e8a8njwgSPh2fHV8QwFQvX70lY6Gr
drFNpq9p01PaZIstfkeRti1M9Fk3XeNWhjAgyYCrP7M/+FY9MXgU/zn8lf72
h4hYzeRXP/tj3S3/Ja5xpy35KyUv0Ob8c7R5d8W/nlxcksiNiUeHR2fqlS0a
592spb02q8k9An1Fjv7uBIoL/a8g0PWimrrmnl6+XK6qILwJlFB8tHLelBxi
GdiVEAHQS8i6kMGoyBpSQKK+3dQUhZH2VhsGMIYeodlJQ8sO+Yz7ynn0+CtE
ncSlbv/yM4MvS5DjL/9n+7dvJ+o5xRKlvffW9YQwwWv6hWzH34sV3z7nzf/n
v/9Pz8aN7CmMwWu9AnAmGC9KrS5ORgrP/vjq9aiXElgQy2/s3wd7iVE/rZAU
IA8REdK00sWtmroPzJwZ2RH8YltllquW4DuiRDJR5KTEUto765fJsq4Wlkyw
Wy0Ye7bbcL6HjqdfZtcWdBzSJQRmo0FMhhVIau5nXRHwUMcX6sHpQ8Qmp49P
xqfnF0KGF3remRe6ISptBSmgtW44d6SeO5L1GtCGB34dMo3E9xoYsnEltg7S
DqTwKwHqm4lMvwt48Yp2hC+vdLFkB6WGvuKFnTPSo4XwVxLVHBNcmKiXb5/8
oC7PL8bH42NC+6fH5xePx48CSnhif701DUW4W9t/u9CrIaA8VE86WzH/Q27g
isNyK5gF37k2+dmnC13Pze+L2+LGf5mE5ewA3LTCHeTIzNOr6ww8h71Vzm3F
M38idFAZGDCOzkR6Xy4J9TRbsff54y+ulWwBD79jUd+7ukQe843rWiOT/ZP6
k5lrKGtX0drG47HSU9IYXbR7exxY3rx7pgpd145sfVNqIuh6odsMqJEdXIX0
MqE2CZApIutgQvu0OMGaadey8vWvlubOVG7F8ruStFTKWmHe0hELF/oORFGW
xL5oMaQPGaB20bhuviCt9yplV7PhvWk5ogpDTyhStjRpCAaUtkvPiwUwpm0T
VZRGxEzyqzqE/TwUQzBZVMrLK5Jv5ALIeGzl+iMlyI4vHd7kQKdd0ChEgriz
A6/EscxmpqDVM0lpbWQxC0ObKJX2vVkKHoa8krfTSiSEyDvrKPql0U1eeuhf
MsKNqcHXpVlVbmNKMUAgWL/uxswqWkVaRBFqBLSK6YaX3GtPIXgPxGcuz4zu
1zR3DhQgLhEcIMuItWEfvMYlKhEKYkSv6XljjDCBqTTIU0YaZpMF+vuVKezM
FjsZkRYaSbZTvOL2idmrriWWWN4zsdt6+sLAPwzEe8BVoSjxFF/BtkpCMFvP
KmZXg6vZQHmUrnyvFEAO/QtLcoJ+Iqq3tGVZmb293HTv/Uv2D1uP5Flkjj6w
rix9JTq2MFrAmRdLov1miSziZhLtxbtF5/OXeVcFMQzlLL8h77+EXNqCviVf
CRLPRJrjCG4luIlZb2oUlYwiDhPRR0TQFQmQLVodpQNQ35TxZfr1zrrOk1x3
NdTjFg+OwqATTmrNCX8N/bOyKWqpuZpDjt/6RS7XyIvPEqYDv0xNRCX1F9v7
tX/GwMUUxBKkrCoiv1B8kGOzvj5o1R3897g2HVnLKsahltXd+qTpv3fWjx9D
OeXTJzG8Uu64VwiJNi8TSZq4F1eaWmf6ajk3vqZlqTl4mwke3pMgnhRKjKtX
vAxUhD59ks+o/Hz6JPwgmSJ2paX06qkrGrvckCVBBSfqEGlWTRzHn04t9S32
VFgvWLvOVsKLJKHrSNY0PAB5J1ikTvSJjGK7+UbZXXWijx9DjeTTp29UGZH/
N0oXrO2yneOjY/y8auydLvAjKBbyn+GRo7NLPBLxIUEZSzg5/nr8+CzSAxW1
T59GZOsi8qJFhqfO+qdOLh5nbyRqogaXfaY5RW5cPd414CUG6ZB7CWIQDH3w
ZAsi1hTZXULXzJqVA5FKGDeYbiFNTyMiEhmaN6agSapNsMtpEFtD+2Ggyh7E
R2/8hrwxVspuOVjjxlTChJhkvmfBRTgXDHcbqUTzzlASBBHFvJDdbZrhtGG7
rGIqqBgLWl9O3+2ERVADmVAwzzIl0I2wdFdj4zSYaBnsB30qGjuVj+w38DEO
zFLNJoYiRvZcvXe8rxC8s8qk2dgoLKJw7VIgkDZ+TQxvxHKx2/AEePvJCDEA
hpH19/ec3mbCgZiuLVJLBVHpN1P7XFb96DPoa+pKfmnVTSkgJitsEbwLveUr
Vj9D4S/3F9D6KlLOSm/g/eBrRFK8ydhI3HiJb3PQtTbAXbAIJKSo6dPzBIIa
/Iasj/+sdO1uqhgFbTa3GJNc6ZrhllF/jkloohKhJGZBNkSTobngPOAsR2rh
1qQkP7tCT7sKJuAnUomBE2Y/HEOtvSv1YNa4pXpOiOb2KoRgt3/5X+mjhkDB
T/Fq9omB2jaJeZABotT+w+g0IlCh35eS/+utpl6tqg2jPMf0X5olqguCQcT6
GeGPmHyy7jPiHYPgyD9iyisHzIhIbl1tGAERBMQ4GLZYWPLMAMTwDx8IkNLk
ANHO25QnEYnibCSBmdAlQUJaoKpJyA0/05KSgE/Us64BC5Y09SgxL+7Zo4gq
gYSAx0gdkqWWlLKLjFw5sBcro624roEWYKckfFrNiQB1rlT0GzkSJRBUCBCl
yi/s6oF/mIQrvkVKMFEPdKlXUHBm7MePWSz+6dPDvb3rXgf3pPwm0BxOA7Cb
vR9LWOPubHCAQIFF65rkwdkyNISzQ46XHjD1nW2cxPPTTXTkQbXZ5DNaDBPk
uIgjJYDr0tAul9CrFFOEsCEGYOKZ5b80H8O9iKtJ3kpm8NRQ2GVdE1Sjluej
bLJJIu617E5CC1Eso2zrCrTlWogRnEJSvD8qwjrDwlCfwtAKENGssRz6DvAS
RhwP9TxOUnl/1r/tH4BvTvwwf6QqSSL3unEzw0YN5Usg+BCi0/ZXiJeY+RtY
mBRDHAyMvV+4riqJgfCPWybVTX81SFEZfzBRby2hD7jzkcpAoYwcWH/wt8NR
muCG9KXoCyxpnLX2CcmRcJEPKIJc0iqSs7t+AnE4vry4lOWhZQgA8QfyqfQA
kPY2sgAngTlUR+C+gFvOnURU4BT1szNkwMEhOetuiP1nuzAGmYbPQwwMBqMT
IhTE0TRXYEBpUCzdOU+mW33GYQJoviuFEBQdtILpi2IbY1ZCIEv83bu63poy
QznHwbRyU/L+SADspEiGMBhZ3X+t7Jpk7dmfjrghzXIluyWDXnD+K/jN8HQT
dVh8hzfRfb9jj94vdg2+bs+14qqNXWmp5fOvocMp2rrTy2xF4psy3xX9YNgZ
dwb89d2LcZ8KGx1sDx/1rA3AoC+5va7QzcAMfj1ArIPZwyBgxOUFScAvtHrI
y69dOQ/Z6GUALbaJUUoFb2Y+hM+cUUE7YLGRnACcQ2NQixckCX0JCZM+zbOO
ABAkbCFmpp7reQjnGAyi/w3hW2YfXUBcrL+03H/4h7z2Tj8MQLXIc2QwjExD
W2a/J2CEhicJYCEdZoKGUBwbStJt2QbOrKlSHRevD1ZxIMuYEWo6CL4NoSv2
SxZXVNZ8QHXGIlYh6yPtQmrfIDQkLxnwQzRyTI8GIR4XJvUK9evNihZfuyaC
iRXh4dRgSNKOtgyV0wcjZiv9RsFX8pdaBefL1j/Kayh88i4VEbQmb9C04UtG
QYqbP4JBdpwI5N1N9slQ8Z5gPSNOZsuRmzbsnaL0ZZ58JDhbh7yV5iiZH8LA
nF8iWrE9JP1967YiBKRITDVjwrk2h8B4rvP3M2ngVmAQL46g9iBvxAE7YiwY
xG/U/iAByXJBjtDRZg5USqcqcTIQacW2RPGcxPkGpTd6D+wRhZJwaAeXSmQQ
ieoH0ecdsGJANSFbkgwGIIW9pfE467euJwcgfOxPA+3jZ37Y1gRjrrJthNlA
LdroggWc6C3JTmi5mmoKFEUCkOtDnk8YwfsDDONUVcZAfi1k5pCe4t14iyAY
3AvEoG2zFDXcxtzaVmAwPEME2jvIQnJ60MTqC5Sx3RxIxlgKoywtCCRoJWRl
JupHwopLiuM4Q0P+wYS0Hk1FckqDwCnUZUjgI3JeogrKqtpnyXsTsb9qgOBn
QeskoJBkL3Ehg7iQOgMsgg/0NGFzO0dOkGhLo08mE4vkdNkVRBczI3yKrOdm
ssU/NnFvWUMGadqe3J5+bO2S0DqLMdZbGMmUUcAxR92gAEkaR4sF00IcRuRZ
kmq2A+zlhzMxBVRhSOnRg+ZIwIV8EAW4BlK3u1TFyBZV0oK4Rw88DOavxwfJ
AhcVh8sC+FNmXJLpaV8ptcxxUGYoNFkwfpdVN+b2PatE8iLkUfUOtReLEpSL
gtzAT4FamnPTNGmsxw6tu5QlspKJR3LaP6S9viRRNtCYduB5GvPnjhQgENmA
EWm3od6BXRpR7ZBFh0rvoOgIdODQCswcyKhhp1yzN5Xskw1BUhhFxOm6qn6H
NP3CSR5YBlBk6l1FGupD8YBzcRJbF26O8DjGbVUVk7tZZE9T+I7DgCiAlWYM
SWoLE1ZKdO2JTEj9h0SX5OkjV0MgOQD1MS0uSSV2/56Tf87Bh60q8yGUcrJ8
/TeBKoQVXcuBSsi1fcNjkTI381BUQXIWlj6UCPtxTBm8RoGuuhWoQno/p6nh
Ak3K8wRcHm0/+RMAZjbYWdN3O4wSsYolEdJoibv6YhNzgyj8YOVahiLVwxjM
dg1Qb5Y/C/k8Hco4PcOhuwmG5Vsasf0rOJIjVtL8vk31sq0IYhX7SFLKUGBr
wGRZmhKBUvBOimtXvDIGSFHIxKGH+sygyDeKCbaQAABIScZYkCbtmD2Q2CpR
4ORArjPaYntkGWUW2uz9hbUhqYBizsrw+Z4ocskwuCZqsSCzsGjS186b7Yzl
3t4zMXVS/WTmk58aDQuZYAgnHfh1IlpF0nXt1SuEHnXfDqrQoDmScs1iUzZO
wCIqhpWu2wh7pp2tkP0ImvZmgXzJG8tJK89xMCdniMlr8vIEtkJvEe/qV1Js
oCxd34oN5U8wRwsiMEkKC9MG5zIm6o1O4LTh8cEqvQRwoYglrUDyWrxGiHLw
pOmN2q1HfFAJSQFNC0QsI+/4Dq7cNEgy4vkA3oGCAl8omONiYfgzvCbCyL40
Ue/TJ1Ibdfz4oWLxpHXGKFRWEkLHngfib8jLSEuOEClK4gjAVUeWYzBdtZxl
hOgPyrY8/IRTLxwyo+6HUcdjnqGWBHoK5UM2wXzQ0Cw8xcUCQ6Gc+SBxFg+t
u9YtHVkI5KqWgixXi41nMw7bkoyQ7Oae+3Ux9GEAnnxyEiryjEsV/SKJvRkX
JJBimkVfwgb7lYQgguQ8FBR4/3plYd7vUjIQiU/NzUPipWhLZL/0nMtk064h
mRvk7znEVewnOMh03HVLSo5HpaL6hETCIENqZ7Kp0nJEQlq+IlWmmUgM/ArQ
PF8vGJic80oj7iecFNtUKfbnHHXl2liJjH2pMXsgiVCSwi659yE5ZTKG6/cC
FZllzQaXTTtakRPO34orRYKWKCNGEeK4hva2q0OCfowlx2T6R6kEHu0eBdi0
BC84ObBz6cjsQ6II9dVtjvpgBnqcdsBFTWlrkRG5yBaKfNKTETyYZK1whg4h
yb1kb1b8Szk6mHACnT40udHHlgWaE7+wmFOT+j7E1Ni2jzSl6zwfd3vnK7Jd
AfUz2M+9QcpYkhkuCvKooSrRB7Hs250E4/ksVgq8DS26NoIiJaUrf95x+ZbV
PP8Kr3HEFWFoqoRyu2Zt6jakkjJQGfIJboZznbG+twWPPOfsuIDhl2LP4x4J
eRHYQo1cYFY0UDlstcmn0FKJzySfhHC4HpuB4AOJ9Q4k1otaf5CSKQfEqrmt
fexiCAgDjTLNvDNZcFUyzCvC3DGU1zGY7NsdpTYee+jIsjPdOIpAlX5c2dlw
tFgJYf+8dorry01fu6fR0FYWA67XA3ScBcYJKG+llngnwbGu+FtWp4Nhy05f
641ZoZ7UJDhVhb5aHYqv4TCV5ENgxRtUMxC8Sy4DGLHc7iDBciu0wFabvliS
yqt9sXhHHoTpDY8ZJoamvjCD6JCtA4HFbhnZs5/UFD1scmyBtzq12u/zACnv
wHUi0GlXxgxNAoE8V3t7D44fJv8aM818Fpqcjrg27tTjCCfD0TQOXEnJZe7k
7vg4k4So/ZeDNgwuBsJIc1oBSzf+G1rFyb1VSOdFrIewS2BfJz9zhjQt56tr
6KOufsrT7SlpzIFX/+qoMH1IVfdjnt3bRmbTEyGRkG3hY0OI9jtmErXsJ3q0
Y/HDnGpqyUmi+NVZYpJLpkktHsoXC0ei7gd1k62eCOnbS9VcSVNwFjbrJWFp
zCsvYLHZbj0K1QhJVqIlIACEwlRSu93qkQsDhFoMfi64/PoWwYoYM3JJrYlA
z4dgpgMiiDUj61PmZiQ5gToiJylX/XAteVkxIvRAOL9kKV6VMoVMDQ8cz1fG
hqc3Gngp60wVOUh1mcbMOO1C4pA1itDiaNm0KvhEAqfyUsOniSVHw74e5+vJ
LuMB8UJx5cFx8Dd5K3XGpqkrOYS/5XRP2BtzCWNF85Y3OFRATPOFKhuukvfV
5ZC+n3P+VrYdN8wDVrI/XjKO9dOSgR6kSBmOyYaTTWV+skl27Yqia/pqVpZF
kay4oYCill7TRFXuQmj7ooDvlkvyq79F2skRR1rHeuE44LtCznFHssZjmxI7
MJQa7eN0AMEY+1tMW6WuCJWK9qhzo68lLrnvx5CszeCCj1gRTEyYSZ8DhQMo
fsSqeZZXkL5FJOwkLwVQ0+NZ2ANW5w9sdlEjK8lY17SCq2yg0jHm4GiHjExl
pESS5RsFtRECHvRk91Ny5BZglmSBwrQxnKItFrcjxgAUSxjO0IoojtnhZaQL
gAa2PfVoFwTbqlCRnahntkbeeZThQ3uPOsM0WxY8ghezivNesjR09I976Q3I
nnnELYjR8YSqrcRjmvu6s/Ik0jfEIznAAQrB4FRdmZW74mg5hIgmbI6YhkEx
cmkCMkO52xcoLFoXNDkzNXics2ywBBJPs9XKloqgE5K90GUWsAO9h65g5JFr
IOwM1Ag+33ohJF40w0LS7wbZZM8o434mRu0z+K25/iRdOKTFeb9MhKclVxUs
h6IrzllEbSKZHyk+Q8ASsb0TpgZmIQJiPzEvNtyN5c42UHNJ45myb/cHEm2D
/UVnKTOck5H3O99pAfnlLZ4zHcJqhrCwNFc5ivX9Ccwv9pKkLEXsYEYrKfN2
jY7lu51NAL2vZpW910/11R6H7bs87vfIh8gO4lRVbi0Hi9PC+Kh86KcJ2r37
kERKr+bJ5hR1JcOap0v7Mj+nrY1sKW10WJu+NzHxor+Kg9RmWqX+BSSXdStV
iHiIhIPbNYTX1rdMOlfqTezxivQZSadCSGTiV8cpDkaegrNwy0DNPb5Z8+g1
TH+Lp3jLffNO8u6psSFjxk1NAmgkd/NO+1v1zBHoUQ8gYw9H7JLjSqR15rEU
87k1PoBNBACpMs1pia05VWz8DV4SlqTvDOAQbcjY5MW5Kq1Z+h6QkyD+SEcD
HNGG89mct5XOrv4Ucmin4HuWRCzQuwQ7S3vKm/sxKBLsNKQEvjxzyekeadXj
to+HopQztSCnoP7ciWXNXuZbsFJvjQ/vSWxmPqDQEJKbMUBPsv8w7yCo0JVj
OD8fWpqjeaI9OvA8xCYxIZoJPv6OK4tRVaDIJDsPlSxXOLmTOp24j7IJDX8M
6vZDuEO+HEcVW5OhpAA89+VEiG55wI8f09UwfYu0FccUOkRdH1/Jm6H/Bq/T
xGECE8pdeUI0zAKzbu6QuoqKHXdJFt9tCCxuxoiM4wEQyb9x92msTvV90LGH
Jzs1E5vdcBwTT0j2yfBhp1HelyngjIiAwh3bcEzKY6EkPe1RBn5leJ/PS4Pe
EvYUreibAg1cz6CByhsjjVpw+fjv8dHRP6atogklB69i3WzGlMAFL61sjnZY
d2hfGklGVWdHvQo5ngnFSOQYeKIhh3eYbbw+b/RqkQx3yl3FPAsyvT4GpzvV
XrI06VByyrJVlZ466Q8YGF5GkiBwLUcJ2Dhwt8pVH6+NtipPXs8MOrYWFgZl
JIlxLCscf0JOEiY+u2wpdspN0a1IRAZ1uXbi1gL8GY5avwh95bZAF7ZqYVYZ
s4bIg+sDeJGpnsH3tkkd0v1YqarAO4rt+dxbwAl32uyC897c7Jp6DTgcvY6h
UythWd7ppHAxjI8JzJmdd7E3LT+UMAqluAoNGQsO4IqMMVP+SXifAYUIslCp
RuKUTZ8ODePo4ShQVuVKFGF+WjWx/McgS3w9mqxtcESRqFTH1LAE0thOslH7
KG96RAB8QK8cdzh2XYv94liCy7Lw59JUnnqvUwdx3vLNLXAcuo8GljbCBdEq
zMRuhXnGWFAXZIRxHxIfcpNOMKBtjhLlXU0x8BrFMByr8Au4P06931rPuXrB
o208eDFS+3GLw0MAsjnkbB3R3oqLRiJRoMkvssF42YmXY8Uj9Z5EeIZa5/vB
eChO0OMUrt4CNdi2C+IggQCcrbTkcM9BEm+kIt2SYiR0UJXk2jyZB71MUuLC
eRCWQFRzVWtNzEKlV2O3z9bJUSV9CWJ5wuUCsDs/cTX45id4JTuWqw0qXCi2
c299q6nIDc0Ns4w7GwfCDJXMdoBgC5EEqPL6qcJtE+vQGS/HJ8kYhrsruFu3
dw27Bslqzkj4IqkxyG6mwc4Y499wtWs7jcJ7BN1+4aLfuwY54h8zC60e/PLu
x4eSQM50OKVQhj0dOuks8jI7z6r0kWpj5l0IqMRpYe0obRJJekAaAAPStL5v
VOlPnDY9ReAlYXk47SlWbedsPAMKWdKkGwp6AmHCSd6uqmbkbEJrjY7zhZ9j
WrcyYoYTOUXWY7Gv4bsxWFhsfrdGNPHyWkyZT1mUyP4RwfszwZInkYJtb1jy
bWWLd7V43JptddaEPsrsNW18cw9Ph3NMkjVj7WzsXPIUJCNdXSwEeg6XjASi
vEimcPAT7jP4caSevHw7Uk9/wL/pX+9G6vrJD+/kjsF3b18GaxbymWxNU2df
78TASod1RHQnyRM+aeDCueyQNiVfwPmRvt+J8X0IBpYOp3rzQjFNGcQrC3tu
QllYGkTADOFjyzwdopfQ6BM7UQAxiR13ugqj650CGFxgFIxQOO0P7c86KUNF
QGPRDhibQRTD9iZwGEkAYEpG3iL48Kw+CyLv+9h74GeYX+IDWiZ510EzoO5b
AUOqLzQWVcFv+0HRRHK4PiRsYhDL3mnQv6aHZdOAT3CPSQEd9ZN4DPiLvIOh
ZiMkeJQD71hA2M6BwKQs0DSFJo6JekUetgrt9gUK2twxb4F9ukrin/A2tyxD
hRIm0Y2AB7XsOE+JQu9o+8AVD8opudCmLwcu+/0AjHPX8kroLINxMzNhMMul
k620W4jOGTXrUio0I+6j45HWqQbXr4sb2bIz+AN+Qr57osSgI50FjceRm/E2
IR2fpGPFkaMFOk3Gq+EGH6ytcMzmFNsvibgWbSuJmH3rI8WtocuFlFo6DiTP
New2j1TAec1BKUXk17bL0OEYqID7/bx8ybZ7IXeyoJ7ONNgEJATEwh01QNvZ
PWScJs7LTemsnCTMOa4TqzQA7dsWN92NMBiUxU3g2ueENVSVJKZ5QW6k95VY
gBvcHPfHvb2nieZQL+Q/kruix24NkvPcDlmLNMQEf23mDqcXosXor6nIM1xb
KhlMhlhMDhE5f9Tf55fVbT5+5Bv6AL/eDmBofw3G0iAtbP2Sqxex4MTtD2kY
bvzntuqSb5Jlq8DZcZdakQdXAkg+VSNUYIweapsc6KbTO+G89xAttQyPskN3
8fJi7zIHK72dQ9OTne+vUY7k5jTJsovVNgGecWpmmprUKjPfdvIfP4ZL+kA4
+iPds4fz86iXy/3S+9foxzZ/5nsD8qSIeAImT7D0eWw2sDB4lAItvvBQ+lxj
DobMTayVhPtPMg/6bFB55IaE2G8kZ6oG6wmtodFDIVUbMTofxw1mCKkr3HEh
ORo+NM0SCdCj++xCbKmaWgRv8IUh2KI5cFqxiT2IiP0Wznk5E0WICKfC+ieD
f/MLO2t9KH8MDjdyoUJifIyQFk3rYR8W8/19Yn+YWgq3ieg6pWFi7WmrRbbP
AIWe4t6ThiMLnAOE70slYPRbRqxKv9gqa+L4rCGSE7GWr4PhurVQHt6nTZo0
YB3FxrM8rs2Dd0GtMT0lzURci00B4SLU4sgcI9HNWY4d4VZ+JNIXtO9URwjJ
UdPX3XHByFMuXPnh4VuKf4I6oqutx0KjIRAasfms0501mdpKQaKP/LgiHRJQ
q3C/TOievE2N55xus2yl0CrOwS13NyET5LME9valUjbLee+6SCrr+uobpWJ4
wLBhxyForkjodSgNziU10/SAcniBUn5jEqYVAbGtjOyJg0NXExoOkmyGvPKw
VhOPaiKkheVxgTxSfg7Hbbb79ifqScCnmaKHc7x96uz3Zs7E4+rSrXLJSYdS
ehguKdpwtmBH/SFeL5QqECXZ6KIdxnqxBfH/3X1WLe4y+q+41IpW+aUbrfb2
/v+dVu3vvtMKUhTSVZ+7rSjizoPfd3r9ID8RP5ErrNahftXf/JHijXQFyIHe
ff/AASNAgqApDNXk/VyNUwmhjyMNJi2ZOJKKDbHSDRpaeqYN+z3QcUqQs5Ya
SChB3U/bf+YqvBTVo98PiN7WdokeI4KqsuTsfFDWBBortyOFFr2QEpDq3NbN
drPUB3PvjNGIb6ZccibW1ilu788SyOF0v20VpTuJw3Nd8E1KyJykvquhuUT9
N97FNDzf/bky/N7etRevLRXDQq7tluJM4FZ0lHkWqHb9rU/FYCbON6aYLzZo
4X900pfgdhyw4Yb0skRmOvUTyVVW00Yqs3zGI18rl3PwXnCuLARxUXw8shzL
US2UNjh1ILkAbmT7On22LyhY8JGocFxP/BVGogH3rovbeOcko+x7w2EsXd8y
qsKdaNpU4ebokfrOGfWCrPhIXePMy1q97arK3mmCE08ai2tddbNiGDTCIZ1b
9drAntObb9UrhyqDXkqTDvAqH0bCNS+c6E4lYyaDKAr+t0j5RQYUP8FuIkBJ
a3xOoL3SmMn8RuxU17Tk0FzDlR8nIRz+/z986UE41Yr5rpemshp7oTlLx/kl
ht1oiEqrC6e3tq4dyP7fJF9oHAnZnP6KqyoW3FiRcLnD33LnAfG6coUklESa
zBhkinKp/hmU+1dr2hnu2/7DZPC/UolH8HgoqX0NfgzQwnfT2DsfjiZi7YDd
7dXeP8f/ucB6vZ7gf2HF93pjDbQbvkYYgx5iGX/ARTAUt971d1fxSMOC1BfH
HGsZ4HBtpjwmri8GIA03iS/aZfWHvf8LmPv3059rAAA=3D

-->

</rfc>


--------------11A08B5843CB300813579936
Content-Type: text/markdown;
 name="draft-political.md"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-political.md"

---
title: Notes on networking standards and politics
abbrev: politix
docname: draft-irtf-hrpc-political-04
category: info

ipr: trust200902
area: IRTF
workgroup: Human Rights Protocol Considerations Research Group
keyword: Internet-Draft
stand_alone: yes
pi:
  rfcedstyle: yes
  toc: yes
  tocindent: yes
  sortrefs: yes
  symrefs: yes
  strict: yes
  comments: yes
  inline: yes
  text-list-symbols: -o*+

author:
-
       ins: N. ten Oever (editor)
       name: Niels ten Oever
       organization: University of Amsterdam
       email: mail@nielstenoever.net

normative:

informative:

   RFC0049:
   RFC0101:
   RFC0144:
   RFC0164:
   RFC0196:
   RFC0286:
   RFC0313:
   RFC0316:
   RFC0542:
   RFC0549:
   RFC0613:
   RFC1087:
   RFC2804:
   RFC3271:
   RFC3552:
   RFC3935:
   RFC5218:
   RFC7258:
   RFC8280:

   BramanI:
     title: "Internationalization of the Internet by design: The first de=
cade"
     date: 2012
     author:
        - ins: S. Braman
     target: http://dx.doi.org.proxy.uba.uva.nl:2048/10.1177%2F1742766511=
434731
     seriesinfo: "Global Media and Communication, Vol 8, Issue 1, pp. 27 =
- 45"

   BramanII:
     title: "The Framing Years: Policy Fundamentals in the Internet Desig=
n Process, 1969=E2=80=931979"
     date: 2010
     author:
        - ins: S. Braman
     target: http://dx.doi.org.proxy.uba.uva.nl:2048/10.1080/01972243.201=
1.607027
     seriesinfo: "The Information Society Vol. 27, Issue 5, 2011"

   Contreras:
     title:  "Technical Standards and Ex Ante Disclosure: Results and Ana=
lysis of an Empirical Study"
     date: 2013
     author:
        - ins: J.L. Contreras
     target:
     seriesinfo: "Jurimetrics: The Journal of Law, Science &amp; Technolo=
gy, vol. 53, p. 163-211"

   Feenberg:
     title: Critical Theory of Technology
     date: 1991
     author:
       - ins: A. Feenberg
     seriesinfo: p.5-6

   Carey:
     title: Communication As Culture
     date: 1992
     author:
       - ins: J. Carey
     seriesinfo: p. 139

   Postman:
     title: "Technopoly: the Surrender of Culture to Technology"
     date: 1992
     author:
       - ins: N. Postman
     seriesinfo: "Vintage: New York. pp. 3=E2=80=9320."

   DeNardis:
     title: The Internet Design Tension between Surveillance and Security=

     date: 2015
     author:
       - ins: L. Denardis
     target: http://is.gd/7GAnFy
     seriesinfo: IEEE Annals of the History of Computing (volume 37-2)

   Winner:
     title: Who will we be in cyberspace?
     date: 1995
     author:
         - ins: L. Winner
     target: iwcenglish1.typepad.com/iwc_media_ecology/Documents/Who_will=
_we_be_in_cyberspace.doc

   Abbate:
      title: Inventing the Internet
      date: 2000
      author:
        - ins: J. Abbate
      target: https://mitpress.mit.edu/books/inventing-internet
      seriesinfo: MIT Press

   Heidegger:
      title: "The Question Concerning Technology and Other Essays"
      date: 1977
      author:
        - ins: M. Heidegger
      target: "http://ssbothwell.com/documents/ebooksclub.org__The_Questi=
on_Concerning_Technology_and_Other_Essays.pdf"
      seriesinfo: "Garland: New York, 1977"

   Nadvi:
      title: Making sense of global standards
      date: 2004
      author:
        - ins: K. Nadvi
        - ins: F. W=C3=A4ltring
      seriesinfo: "In: H. Schmitz (Ed.), Local enterprises in the global =
economy (pp. 53=E2=80=9394). Cheltenham, UK: Edward Elgar."

   Russell:
      title: "Open standards and the digital age: History, ideology, and =
networks"
      date: 2014
      author:
        - ins: A.M. Russell
      seriesinfo: "Cambridge, UK: Cambridge University Press"

   RogersEden:
      title: "The Snowden Disclosures, Technical Standards, and the Makin=
g of Surveillance Infrastructures"
      date: 2017
      author:
        - ins: M. Rogers
        - ins: G. Eden
      seriesinfo: "International Journal of Communication 11(2017), 802-8=
23"
      target: "http://ijoc.org/index.php/ijoc/article/view/5525/1941"

   CJEU2004:
      title: "ECLI:EU:C:2004:257, C-418/01 IMS Health"
      date: 2004
      author:
        - ins: Court of Justice of the European Union
      target: "http://curia.europa.eu/juris/liste.jsf?num=3DC-418/01"
      seriesinfo: "Cambridge, UK: Cambridge University Press"

   CJEU2007:
      title: "ECLI:EU:T:2007:289, T-201/04 Microsoft Corp."
      date: 2007
      author:
        - ins: Court of Justice of the European Union
      target: "http://curia.europa.eu/juris/liste.jsf?num=3DT-201/04"
      seriesinfo: "Cambridge, UK: Cambridge University Press"

   Ahlborn:
      title: "Implications of the Proposed Framework and Antitrust Rules =
for Dynamically Competitive Industries"
      date: 2006
      author:
        - ins: C. Ahlborn
        - ins: V. Denicol=C3=B3
        - ins: D. Geradin
        - ins: A.J. Padilla
      target: "http://curia.europa.eu/juris/liste.jsf?num=3DT-201/04"
      seriesinfo: "DG Comp=E2=80=99s Discussion Paper on Article 82, DG C=
OMP, European Commission"

   Winner:
      title: "Upon opening the black box and finding it empty: Social con=
structivism and the philosophy of technology"
      date: 1993
      author:
        - ins: L. Winner
      seriesinfo: "Science, Technology, and Human Values 18 (3) p. 362-37=
8"

   HagueHarrop:
     title: "Comparative Government and Politics: An Introduction"
     date: 2013
     author:
        - ins: R. Hague
        - ins: M. Harrop
     seriesinfo: "Macmillan International Higher Education. pp. 1=E2=80=93=
=2E ISBN 978-1-137-31786-5."

   BijkerLaw:
     title: "Shaping Technology/ Building Society: Studies in Sociotechni=
cal Change"
     date: 1992
     author:
        - ins: W. Bijker
        - ins: J. Law
     seriesinfo: "Cambridge, MA: MIT Press"

   Bloor:
     title: Knowledge and Social Imagery
     date: 1976
     author:
        - ins: D. Bloor
     seriesinfo: "London: Routeledge & Kegan Paul"

--- abstract

The IETF cannot ordain what standards or protocols are to be used on netw=
orks, but the standards development process in the IETF does have an impa=
ct on society through its normative standards setting process. This docum=
ent aims to bring about a better understanding on the political nature of=
 standards and protocols. Among other things, the IETF's work affects wha=
t is perceived as technologically possible and useful where networking te=
chnologies are being deployed, and its standards reflect what is consider=
ed by the technical community to be feasible and good practice. Whereas t=
here might not be agreement among the Internet protocol community on the =
specific political nature of the technological development process and it=
s outputs, it is undisputed that standards and protocols are both product=
s of a political process, and they can also be used for political means.

--- middle

Introduction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    "Science and technology lie at the heart of social asymmetry.
       Thus technology both creates systems which close off other
       options and generate  novel, unpredictable and indeed
       previously unthinkable, option. The game of technology is
       never finished, and its ramifications are endless."

                                   - Michel Callon

    "The Internet isn't value-neutral, and neither is the IETF."

                                   -{{RFC3935}}

The design of the Internet through protocols and standards is a technical=
 issue with great political and economic impacts {{RFC0613}} {{RFC3271}}.=
 The early Internet community already realized that it needed to make dec=
isions on political issues such as intellectual property; internationaliz=
ation {{BramanI}}; diversity; access {{RFC0101}}; privacy; and security {=
{RFC0049}}; and the military {{RFC0164}} {{RFC0316}}, governmental {{RFC0=
144}} {{RFC0286}} {{RFC0313}} {{RFC0542}} {{RFC0549}} and non-governmenta=
l {{RFC0196}} uses of the network. This has been clearly pointed out by B=
raman {{BramanII}}.

Recently there has been increased discussion in the IRTF and IETF on the =
relation between Internet protocols and human rights {{RFC8280}}, which s=
purred discussion of the value neutrality and political nature of standar=
ds. The network infrastructure is on the one hand designed, described, de=
veloped, standardized and implemented by the Internet community, while on=
 the other hand the Internet community and Internet users are also shaped=
 by the affordances of the technology. Companies, citizens, governments, =
standards development bodies, public opinion and public interest groups a=
ll play a part in these discussions. In this document we aim to outline d=
ifferent views on the relation between standards and politics, and seek t=
o answer the question of whether standards are political, and if so, how.=


Vocabulary Used
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Politics
: (from Greek: Politik=C3=A1: Politika, definition "affairs of the common=
s") is the process of making decisions applying to all members of a diver=
se group with conflicting interests. More narrowly, it refers to achievin=
g and exercising positions of governance or organized control over a comm=
unity. Furthermore, politics is the study or practice of the distribution=
 of power and resources within a given community as well as the interrela=
tionship(s) between communities. (adapted from {{HagueHarrop}})

Affordances
: The possibilities that are provided to an actor through the ordering of=
 an environment by a technology. This means that a technology does not de=
termine what is possible, but that it that invites specific kinds of beha=
vior, and in that process shapes it.

Research Question
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Are protocols political?=20

Technology and Politics: a review of literature and community positions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In 1993 the Computer Professionals for Social Responsibility stated that =
'the Internet should meet public interest objectives'. Similarly, {{RFC39=
35}} states that 'The Internet isn't value-neutral, and neither is the IE=
TF.'. Ethics and the Internet was already a topic of an RFC by the IAB in=
 1989 {{RFC1087}}. Nonetheless there has been a recent uptick in discussi=
ons within the IETF and IRTF about the impact of Internet protocols on hu=
man rights {{RFC8280}}, and more generally in public debate about the imp=
act of technology on society.

This document aims to provide an overview of the spectrum of different po=
sitions that have been observed in the IETF and IRTF community, and have =
been observed during interviews, mailinglist exchanges, and during resear=
ch group sessions. These positions were observed during participatory obs=
ervation, through 39 interviews with members of the community, the Human =
Rights Protocol Considerations Research Group mailing list, and during an=
d after the Technical Plenary on Protocols and Human Rights during IETF98=
=2E

Without judging them on their internal or external consistency they are r=
epresented here. Where possible we also sought to engage with the academi=
c literature on this topic.

## Technology is value neutral
This position starts from the premise that the technical and political ar=
e differentiated fields and that technology is 'value free'. This is also=
 put more explicitly by Carey: "electronics is neither the arrival of apo=
calypse nor the dispensation of  grace.  Technology  is  technology;  it =
 is  a  means  for  communication  and  transportation  over  space, and =
nothing more." {{Carey}}. In this view protocols only become political wh=
en it is actually being used by humans. So the technology itself is not p=
olitical, the use of the technology is. This view sees technology as inst=
rument; "technologies  are  'tools' standing  ready  to  serve  the  purp=
oses  of  their  users.  Technology  is  deemed  'neutral,' without valua=
tive content of its own.'" {{Feenberg}}. Feenberg continues: "technology =
 is  not  inherently  good  or  bad,  and  can  be  used  to  whatever  p=
olitical  or  social  ends  desired  by  the  person  or  institution  in=
  control.  Technology  is  a  'rational entity' and universally applicab=
le. One may make exceptions on moral grounds, but one must also understan=
d that the "price for the achievement of environmental, ethical, or relig=
ious goals...is reduced efficiency." {{Feenberg}}.

## Some protocols are political sometimes
This stance is a pragmatic approach to the problem. It states that some p=
rotocols under certain conditions can themselves have a political dimensi=
on.  This is different from the claim that a protocol might sometimes be =
used in a political way; that view is consistent with the idea of the tec=
hnology being neutral (for the human action using the technology is where=
 the politics lies).  Instead, this position requires that each protocol =
and use be evaluated for its political dimension, in order to understand =
the extent to which it is political.

## All protocols are political sometimes
While not an absolutist standpoint it recognizes that all design decision=
s are subject to the law of unintended consequences. The system consistin=
g of the Internet and its users is vastly too complex to be predictable; =
it is chaotic in nature; its emergent properties cannot be predicted. Thi=
s concept strongly hinges on the general purpose aspect of information te=
chnology and its malleability. Whereas not all (potential) behaviours, af=
fordances and impacts of protocols can possible be predicted, one could a=
t least consider the impact of proposed implementations.

## The network has its own logic and values
While humans create technologies, this does not mean that they are foreve=
r under human control. A technology, once created, has its own logic that=
 is independent of the human actors that either create or use the technol=
ogy.

=46rom this perspective, technologies can shape the world. As Martin Heid=
egger says, "The hydroelectric plant is not built into the Rhine River as=
 was the old wooden bridge that joined bank with bank for hundreds of yea=
rs. Rather the river is dammed up into the power plant. What the river is=
 now, namely, a water power supplier, derives from out of the essence of =
the power station." {{Heidegger}} (p 16)  The dam in the river changes th=
e world in a way the bridge does not, because the dam alters the nature o=
f the river.

In the same way -- in another and more recent example -- the very existen=
ce of automobiles imposes physical forms on the world different from thos=
e that come from the electric tram or the horse-cart. The logic of the au=
tomobile means speed and the rapid covering of distance, which encourages=
 suburban development and a tendency toward conurbation. But even if that=
 did not happen, widespread automobile use requires paved roads, and park=
ing lots and structures. These are pressures that come from the automotiv=
e technology itself, and would not arise without that technology.

In much same way, then, networking technology, such as protocols, creates=
 its own demands. One of the most important conditions for a protocol's s=
uccess is its incremental deployability {{RFC5218}}.  This means that the=
 network already contains constraints on what can be deployed into it. In=
 this sense the network creates its own paths, but also has its own objec=
tive. According to this view the goal of the network is interconnection a=
nd connectivity; more connectivity is good for the network. Proponents of=
 this positions also often describe the Internet as an organism with its =
own unique ecosystem.

In this position it is not necessarily clear where the 'social' ends and =
the 'technical' begins, and it could be argued that the distinction itsel=
f is a social construction {{BijkerLaw}} or that a real-life distinction =
between the two is hard to make {{Bloor}}.

## Protocols are inherently political
This position argues the opposite of 'technological neutrality'. This pos=
ition is illustrated by Postman when he writes: "the uses made of technol=
ogy are largely determined by the structure of the technology itself" {{P=
ostman}}. He states that the medium itself "contains an ideological bias"=
=2E He continues to argue that technology is non-neutral:

(1) because of the symbolic forms in which information is encoded, differ=
ent media have different intellectual and emotional biases;

(2) because of the accessibility and speed of their information, differen=
t media have different political biases;

(3) because of their physical form, different media have different sensor=
y biases;

(4) because of the conditions in which we attend to them, different media=
 have different social biases;

(5) because of their technical and economic structure, different media ha=
ve different content biases.

Recent scholars of Internet infrastructure and governance have also point=
ed out that Internet processes and standards have become part and parcel =
of political processes and public policies. Several concrete examples are=
 found within this approach, for instance, the IANA transition or global =
innovation policy {{DeNardis}}. The Raven process in which the IETF refus=
ed to standardize wiretapping -- which resulted in {{RFC2804}} -- was an =
instance where an international governance body took a position that was =
largely political, although driven by a technical argument. The process t=
hat led to {{RFC7258}} is similar: the Snowden disclosures, which occured=
 in the political space, engendered the IETF to act. This is summarized i=
n {{Abbate}} who says: "protocols are politics by other means," emphasizi=
ng the interests that are at play in the process of designing standards.

This position further holds that protocols can never be understood withou=
t their contextual embeddedness: protocols do not exist solely by themsel=
ves but always are to be understood in a more complex context -- the stac=
k, hardware, or nation-state interests and their impact on civil rights. =
Finally, this view is that protocols are political because they influence=
 the socio-technical workings of reality and society. The latter observat=
ion leads Winner to conclude that the reality of technological progress h=
as too often been a scenario where innovation has dictated change for soc=
iety. Those who had the power to introduce a new technology also had the =
power to create a consumer class to use the technology "with new practice=
s, relationships, and identities supplanting the old, --- and those who h=
ad the wherewithal to implement new technologies often molded society to =
match the needs of emerging technologies and organizations." {{Winner}}.

IETF: Protocols as Standards
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

In the previous section we gave an overview of the different existing pos=
itions of the impact of Internet protocols in the Internet protocol commu=
nity. In the following section we will review the standards setting proce=
ss and its consequences for the politics of protocols, through the lens o=
f existing literature on standards setting.

Standards enabling interoperating networks, what we think of today as the=
 Internet, were created as open, formal and voluntary standards. A platfo=
rm for Internet standardization, the Internet Engineering Task Force (IET=
F), was created in 1986 to enable the continuation of such standardizatio=
n work. The IETF has sought to make the standards process transparent (by=
 ensuring everyone can access standards, mailing-lists and meetings), pre=
dictable (by having clear procedures and reviews) and of high quality (by=
 having draft documents reviewed by experts from its own community). This=
 is all aimed at increasing the accountability of the process and the qua=
lity of the standard.

The IETF implements what has been referred to as an "informal ex ante dis=
closure policy" for patents {{Contreras}}, which includes the possibility=
 for participants to disclose the existence of a patent relevant for the =
standard, royalty-terms which would apply to the implementers of that sta=
ndard should it enter into effect, as well as other licensing terms that =
may be interesting for implementers to know. The community ethos in the I=
ETF seems to lead to 100% royalty-free disclosures of prior patents which=
 is a record number, even among other comparable standard organizations {=
{Contreras}}. In the following paragraph we will describe inherent tensio=
ns in the standards process.

## Competition and collaboration

Standards exist for nearly everything: processes, technologies, safety, h=
iring, elections, and training. Standards provide blue-prints for how to =
accomplish a particular task in a similar way for others that are trying =
to accomplish the same thing, while reducing overhead and inefficiencies.=
 Although there are different types and configurations of standards, they=
 all enhance competition by allowing different entities to work from a co=
mmonly accepted baseline.

On the first types of standards than can be found are "informal" ones -- =
agreed-upon normal ways of interacting within a specific community. For e=
xample, the process through which greetings to a new acquaintance are exp=
ressed through a bow, a handshake or a kiss. On the other hand, "formal" =
standards are normally codified in writing.

Within economy studies, _de facto_ standards arise in market situations w=
here one entity is particularly dominant; downstream competitors are ther=
efore tied to the dominant entity's technological solutions {{Ahlborn}}. =
Under EU anti-trust law, _de facto_ standards have been found to restrict=
 competition for downstream services in PC software products {{CJEU2007}}=
, as well as downstream services dependent on health information {{CJEU20=
04}}.

Even in international law, the World Trade Organization (WTO) uses standa=
rds, although it recognizes a difference between standards and technical =
regulations. The former are voluntary formal codes to which products or s=
ervices may conform, while technical regulations are mandatory requiremen=
ts to be fullfilled for a product to be accessible in a national market. =
These rules have implications for how nation states bound by WTO agreemen=
ts can impose specific technical requirements on companies. Nonetheless, =
there are many standardization groups that were originally launched by na=
tion states or groups of nation states. ISO, BIS, CNIS, NIST, ABNT and ET=
SI are examples of institutions that are, wholly or partially, sponsored =
by public money in order to ensure the smooth development of formal stand=
ards. Even if under WTO rules these organizations cannot create the equiv=
alent of a technical regulation, they have important normative functions =
in their respective countries. No matter what form, all standards enhance=
 competition and collaboration because they define a common approach to a=
 problem. This potentially allows different instances to interoperate or =
be evaluated according to the same indicators.

The development of formal standards faces a number of economic and organi=
zational challenges. Mainly, the cost and difficulty of organizing many e=
ntities around a mutual goal, as well as the cost of research and develop=
ment leading up to a mutually beneficial technological platform. In addit=
ion, deciding what the mutual goal is can also be a problem. These challe=
nges may be described as inter-organizational costs. Even after a goal is=
 decided upon, coordination of multiple entities requires time and money.=
 One needs communication platforms, processes and a commitment to mutual =
investment in a higher good. They are not simple tasks, and the more diff=
erent communities are affected by a particular standardization process, t=
he more difficult the organizational challenges become.

## How voluntary are open standards?

Coordinating transnational stakeholders in a process of negotiation and a=
greement through the development of common rules is a form of global gove=
rnance {{Nadvi}}. Standards are among the mechanisms by which this govern=
ance is achieved. Conformance to certain standards is often a basic condi=
tion of participation in international trade and communication, so there =
are strong economic and political incentives to conform, even in the abse=
nce of legal requirements {{Russell}}. {{RogersEden}} argue:

   "As unequal participants compete to define standards, technological co=
mpromises emerge, which add complexity to standards. For instance, when w=
orking group participants propose competing solutions, it may be easier f=
or them to agree on a standard that combines all the proposals rather tha=
n choosing any single proposal. This shifts the responsibility for select=
ing a solution onto those who implement the standard, which can lead to c=
omplex implementations that may not be interoperable. On its face this ap=
pears to be a failure of the standardization process, but this outcome ma=
y benefit certain participants -- for example, by allowing an implementer=
 with large market share to establish a _de facto_ standard within the sc=
ope of the documented standard."

Conclusion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Economics, competition, collaboration, openness, and political impact hav=
e been an inherent part of the work of the IETF since its early beginning=
s. The IETF cannot ordain which standards are to be used on the networks,=
 and it specifically does not determine the laws of regions or countries =
where networks are being used, but it does set open standards for interop=
erability on the Internet, and has done so since the inception of the Int=
ernet. Because a standard is the blue-print for how to accomplish a parti=
cular task, the adopted standards have a normative effect. The standardiz=
ation work at the IETF has direct implications on what is perceived as te=
chnologically possible and useful where networking technologies are being=
 deployed, and thus its standards reflect what is considered by the techn=
ical community as feasible and good practice.=20

Whereas there might not be agreement among the Internet protocol communit=
y on the specific political nature of the technological development proce=
ss and its outputs, it is undisputed that standards and protocols are bot=
h products of a political process, and they can also be used for politica=
l means. Therefore protocols and standards are not 'value-neutral, and ne=
ither is the IETF' {{RFC3935}}. Thus we can answer the research question =
'are protocols political' in affirmative fashion.

Further research could explore how the political nature of protocols can =
be taken into account in the standards development process in order to (1=
) to minimize negative unintended social consequences, (2) ensure clear u=
nderstanding of the intended consequences, (3) maintain importance of the=
 IETF as open standards body that facilitates global interoperability.

Security Considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

As this draft concerns a research document, there are no security conside=
rations as described in {{RFC3552}}, which does not mean that not address=
ing the issues brought up in this draft will not impact the security of e=
nd-users or operators.

IANA Considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This document has no actions for IANA.


Acknowledgements
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks to Michael Rogers, Joe Hall, Andrew Sullivan, Brian Carpenter, Mar=
k Perkins, S Moonesamy and all contributors and reviewers on the hrpc mai=
linglist. Special thanks to Gisela Perez de Acha for some thorough editin=
g rounds, and Amelia Andersdotter for text contributions.

Research Group Information
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

The discussion list for the IRTF Human Rights Protocol Considerations Res=
earch Group is located at the e-mail address <hrpc@ietf.org>. Information=
 on the group and information on how to subscribe to the list is at:
<https://www.irtf.org/mailman/listinfo/hrpc>

Archives of the list can be found at:
<https://www.irtf.org/mail-archive/web/hrpc/current/index.html>

--------------11A08B5843CB300813579936--


From nobody Tue Sep 10 09:56:09 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BC2120074 for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 09:56:06 -0700 (PDT)
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, SPF_HELO_NONE=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 kBuIU6lnAyS6 for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 09:56:04 -0700 (PDT)
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 AEE41120058 for <xml2rfc@ietf.org>; Tue, 10 Sep 2019 09:56:04 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:54477 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 1i7jQw-0003l1-Ni; Tue, 10 Sep 2019 09:56:03 -0700
To: Niels ten Oever <lists@digitaldissidents.org>, xml2rfc@ietf.org
References: <2cca546d-72cb-4776-f47d-b850376925c5@digitaldissidents.org> <a24da7a3-b856-8c5b-9f95-cdd3646d27ae@digitaldissidents.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <4dd516e2-5d2d-5643-11b5-e65227afacc7@levkowetz.com>
Date: Tue, 10 Sep 2019 18:55:54 +0200
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: <a24da7a3-b856-8c5b-9f95-cdd3646d27ae@digitaldissidents.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RppvPWNdptwapxgvAJk1PCJDMno9BUVdc"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, lists@digitaldissidents.org
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/XKlB6pvhwIn0qbUtlvl3beuWBfM>
Subject: Re: [xml2rfc] new build errors
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 16:56:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--RppvPWNdptwapxgvAJk1PCJDMno9BUVdc
Content-Type: multipart/mixed; boundary="3hEkkaw4IKFqc9D8Fbq7w9L8xNOHFeuCF";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Niels ten Oever <lists@digitaldissidents.org>, xml2rfc@ietf.org
Message-ID: <4dd516e2-5d2d-5643-11b5-e65227afacc7@levkowetz.com>
Subject: Re: [xml2rfc] new build errors
References: <2cca546d-72cb-4776-f47d-b850376925c5@digitaldissidents.org>
 <a24da7a3-b856-8c5b-9f95-cdd3646d27ae@digitaldissidents.org>
In-Reply-To: <a24da7a3-b856-8c5b-9f95-cdd3646d27ae@digitaldissidents.org>

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

Hi Niels,

This is a bug.  I'll debug and fix.

	Henrik

On 2019-09-10 18:23, Niels ten Oever wrote:
> I thought the issues might have been due to python and other software v=
ersion issues on my machine, but I got a similar output on https://xml2rf=
c.tools.ietf.org/ :
>=20
>   Parsing file INPUT
>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/te=
mplates/rfc2629.dtd
>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/te=
mplates/rfc2629-xhtml.ent
>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/te=
mplates/rfc2629-other.ent
>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/te=
mplates/rfc2629.dtd
>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/te=
mplates/rfc2629-xhtml.ent
>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/te=
mplates/rfc2629-other.ent
> Traceback (most recent call last):
>   File "/usr/local/bin/xml2rfc", line 11, in <module>
>     sys.exit(main())
>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/run.py", line 49=
6, in main
>     htmlwriter.write(filename)
>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py"=
, line 1431, in write
>     self._build_document()
>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py"=
, line 1377, in _build_document
>     self.write_reference_list(references[0])
>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/legacy_h=
tml.py", line 570, in write_reference_list
>     initials, surname =3D short_author_name_parts(author)
>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/name.py", l=
ine 26, in short_author_name_parts
>     initials =3D get_initials(a)
>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/name.py", l=
ine 22, in get_initials
>     initials =3D initials.split('.')[0]
> AttributeError: 'NoneType' object has no attribute 'split'
>=20
> Also attached XML FYI.
>=20
> Any hints would ve very welcome!
>=20
> Best,
>=20
> Niels
>=20
> On 9/9/19 10:07 PM, Niels ten Oever wrote:
>> Hi all,
>>=20
>> I caught another weird one that I did not know how to handle, especial=
ly since I did not change much in the draft.=20
>>=20
>> Any advice would be much appreciated!=20
>>=20
>> Attached the markdown file just in case.
>>=20
>> Cheers,
>>=20
>> Niels
>>=20
>> $ make
>> xml2rfc draft-political.xml --html
>> Traceback (most recent call last):
>>   File "/usr/bin/xml2rfc", line 11, in <module>
>>     load_entry_point('xml2rfc=3D=3D2.25.0', 'console_scripts', 'xml2rf=
c')()
>>   File "/usr/lib/python3/dist-packages/xml2rfc/run.py", line 482, in m=
ain
>>     htmlwriter.write(filename)
>>   File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line =
1430, in write
>>     self._build_document()
>>   File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line =
1376, in _build_document
>>     self.write_reference_list(references[0])
>>   File "/usr/lib/python3/dist-packages/xml2rfc/writers/legacy_html.py"=
, line 569, in write_reference_list
>>     initials, surname =3D short_author_name_parts(author)
>>   File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 26,=
 in short_author_name_parts
>>     initials =3D get_initials(a)
>>   File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 22,=
 in get_initials
>>     initials =3D initials.split('.')[0]
>> AttributeError: 'NoneType' object has no attribute 'split'
>> make: *** [Makefile:12: draft-political.html] Error 1
>>=20
>=20
>=20
>=20
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc
>=20


--3hEkkaw4IKFqc9D8Fbq7w9L8xNOHFeuCF--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl131ZsACgkQTptXS4+7
FxperxAAzrrdj4oLE3DhqoN/x0QulwEFk3UX9XCLi5n0UXczbelwVqhqSn1FYydy
yuxw0TYem1rQ5vw/Q50zqhhZjmteYYznp/P4C8jVD4Ce4o4zGuZHYeJ1t3qQ08Sf
wYx3y67cABugi/KHMIaWrZ6CLYdpO6CGij6GA0QhjbW6byHbT0yVNweAz7Dd7vSJ
+O9wccPvSzn7nQ8nNF1fJ+xeDzOTK8WFWfye2lPWUXSSYuDx1hFRkeQd91mzz5a1
9CctWtDT85ElgZEzkEcKapeFPvNBHGxzj/F6QZATJ7moNRp/+Me+Wpsxc8F7eqnL
G7aA/MPsAxB58sXxnoee2ewsIe74a6eaPm+4LiRV7R+FWJGqfV/Ti5UHKlD6a6gd
438JbJl/dhrMRxWAF7yYZhfCXHu2FeQdEc2eGa5MNOF8h6RikAxw5NmGMcJuZ6Sq
akwrCwuUUnP2zAu8DVhns5A2R3cjV+LjF1tj/rJZnazfVc2ulBcUE78r8jQMVAC8
Cf9La0FyeeYq2PaMB+SBAopONOWlz6lpxVytahJdlM5e6ZxkrDbb6bHRiUSqqOjQ
pruYQHk/3NaZ6FMijHgz+btRm/GLkf8uiiaP5HDmRXNqdkLSpd7LGXyvpcm5qUlA
gKVyKfD8l7as/51DUq+F+qFe8H4fQAnpVT9zOk+aWbj5hEt9G2A=
=ZdLt
-----END PGP SIGNATURE-----

--RppvPWNdptwapxgvAJk1PCJDMno9BUVdc--


From nobody Tue Sep 10 10:04:10 2019
Return-Path: <lists@digitaldissidents.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE21C120115 for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 10:04:08 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UG2z31JIU2Fa for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 10:04:06 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50791120058 for <xml2rfc@ietf.org>; Tue, 10 Sep 2019 10:04:05 -0700 (PDT)
Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <lists@digitaldissidents.org>) id 1i7jYC-0007qs-0v; Tue, 10 Sep 2019 19:04:03 +0200
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <2cca546d-72cb-4776-f47d-b850376925c5@digitaldissidents.org> <a24da7a3-b856-8c5b-9f95-cdd3646d27ae@digitaldissidents.org> <4dd516e2-5d2d-5643-11b5-e65227afacc7@levkowetz.com>
From: Niels ten Oever <lists@digitaldissidents.org>
Openpgp: preference=signencrypt
Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA==
Message-ID: <314947b2-6d10-90c8-8732-ea0d3392174d@digitaldissidents.org>
Date: Tue, 10 Sep 2019 19:03:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <4dd516e2-5d2d-5643-11b5-e65227afacc7@levkowetz.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YOUxhNrWjkE8oFFuaOmuRqbhYpU5DXehI"
X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: d9e86a85729c02611f348d7c163f195f
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/iTBTfYqy5OMtuB1PrPp0IlLMllI>
Subject: Re: [xml2rfc] new build errors
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 17:04:09 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--YOUxhNrWjkE8oFFuaOmuRqbhYpU5DXehI
Content-Type: multipart/mixed; boundary="dYren2tadCs7oAkmcZVI4P5z10DjR1kHl";
 protected-headers="v1"
From: Niels ten Oever <lists@digitaldissidents.org>
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
Message-ID: <314947b2-6d10-90c8-8732-ea0d3392174d@digitaldissidents.org>
Subject: Re: [xml2rfc] new build errors
References: <2cca546d-72cb-4776-f47d-b850376925c5@digitaldissidents.org>
 <a24da7a3-b856-8c5b-9f95-cdd3646d27ae@digitaldissidents.org>
 <4dd516e2-5d2d-5643-11b5-e65227afacc7@levkowetz.com>
In-Reply-To: <4dd516e2-5d2d-5643-11b5-e65227afacc7@levkowetz.com>

--dYren2tadCs7oAkmcZVI4P5z10DjR1kHl
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Thanks a lot! Am actually happily surprised it's not me :))

Let me know if I can be of any help!

Best,

Niels

On 9/10/19 6:55 PM, Henrik Levkowetz wrote:
> Hi Niels,
>=20
> This is a bug.  I'll debug and fix.
>=20
> 	Henrik
>=20
> On 2019-09-10 18:23, Niels ten Oever wrote:
>> I thought the issues might have been due to python and other software =
version issues on my machine, but I got a similar output on https://xml2r=
fc.tools.ietf.org/ :
>>
>>   Parsing file INPUT
>>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/t=
emplates/rfc2629.dtd
>>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/t=
emplates/rfc2629-xhtml.ent
>>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/t=
emplates/rfc2629-other.ent
>>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/t=
emplates/rfc2629.dtd
>>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/t=
emplates/rfc2629-xhtml.ent
>>   Resolving entity... /usr/local/lib/python2.7/dist-packages/xml2rfc/t=
emplates/rfc2629-other.ent
>> Traceback (most recent call last):
>>   File "/usr/local/bin/xml2rfc", line 11, in <module>
>>     sys.exit(main())
>>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/run.py", line 4=
96, in main
>>     htmlwriter.write(filename)
>>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py=
", line 1431, in write
>>     self._build_document()
>>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py=
", line 1377, in _build_document
>>     self.write_reference_list(references[0])
>>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/legacy_=
html.py", line 570, in write_reference_list
>>     initials, surname =3D short_author_name_parts(author)
>>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/name.py", =
line 26, in short_author_name_parts
>>     initials =3D get_initials(a)
>>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/name.py", =
line 22, in get_initials
>>     initials =3D initials.split('.')[0]
>> AttributeError: 'NoneType' object has no attribute 'split'
>>
>> Also attached XML FYI.
>>
>> Any hints would ve very welcome!
>>
>> Best,
>>
>> Niels
>>
>> On 9/9/19 10:07 PM, Niels ten Oever wrote:
>>> Hi all,
>>>
>>> I caught another weird one that I did not know how to handle, especia=
lly since I did not change much in the draft.=20
>>>
>>> Any advice would be much appreciated!=20
>>>
>>> Attached the markdown file just in case.
>>>
>>> Cheers,
>>>
>>> Niels
>>>
>>> $ make
>>> xml2rfc draft-political.xml --html
>>> Traceback (most recent call last):
>>>   File "/usr/bin/xml2rfc", line 11, in <module>
>>>     load_entry_point('xml2rfc=3D=3D2.25.0', 'console_scripts', 'xml2r=
fc')()
>>>   File "/usr/lib/python3/dist-packages/xml2rfc/run.py", line 482, in =
main
>>>     htmlwriter.write(filename)
>>>   File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line=
 1430, in write
>>>     self._build_document()
>>>   File "/usr/lib/python3/dist-packages/xml2rfc/writers/base.py", line=
 1376, in _build_document
>>>     self.write_reference_list(references[0])
>>>   File "/usr/lib/python3/dist-packages/xml2rfc/writers/legacy_html.py=
", line 569, in write_reference_list
>>>     initials, surname =3D short_author_name_parts(author)
>>>   File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 26=
, in short_author_name_parts
>>>     initials =3D get_initials(a)
>>>   File "/usr/lib/python3/dist-packages/xml2rfc/util/name.py", line 22=
, in get_initials
>>>     initials =3D initials.split('.')[0]
>>> AttributeError: 'NoneType' object has no attribute 'split'
>>> make: *** [Makefile:12: draft-political.html] Error 1
>>>
>>
>>
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/xml2rfc
>>
>=20

--=20
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488 =20
                   643A 0ED8 3F3A 468A C8B3


--dYren2tadCs7oAkmcZVI4P5z10DjR1kHl--

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

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

iQIzBAEBCgAdFiEEJFgLcFxK/YqUiGQ6Dtg/OkaKyLMFAl13118ACgkQDtg/OkaK
yLO49Q/+JV0W/7KAfr/wiWqAHkEQYvTFo1iM3EHni5GzK6GQ3IgY+o2qdXx2qd35
hCUbtYbvU5vn1W9rWzfxDHxps+10BVYT9IW1bFCj1j/PzOKB8tZcL8xQ/qj/9DUn
5nkJr07CKonZVTQL2J73zZhQRg0V6U87CdrkRTkGOO3Pg4/VZqrbdhpyrsjNdAI/
fuCnmXN0WuZnPrUqBUKXFLUU/vAHpo3zEjPXnj7aSsRVRFVTjDwob+Yh1Gw3AQwW
wPuCaGQbQlcilUIscgMrgLpupbh1J2dR9sDPYTeXgiq6+/U6u4TynJ0msMp/1B+n
x2mpWOdaANuKyBPndaJPl7K4CghkN+Q9X5Fcppm+Mla7fUlKuppavLfkNgBY2Pyf
u7TTcL3BLziaPmVAs17fGTNXpFvTKi898XywhlYLCnurrMIgolG06axr1rDFI+M6
TGJtJXi6zgO6/LWuwYfviI0oc+HCbd4oUGeVj4Zlzkuj3lhe6pZxIa1KrfSI2p2b
yFoRSQVROFno/ILuWHsQIG658t7j3ntN65s2xHsgZ+l4i75/1FfoKyN1ByA1qCXL
3b28gQD5QrNrBZJ+UfdOxnNn6KGqMobIi60tfDk5iVJzLlQTebQ5c0arICMy0Th5
7WCqfE9jWpBq0sqbF6BF+XudXFRJlhLsReCWVsrpT3Nmdk1E2s0=
=l9tN
-----END PGP SIGNATURE-----

--YOUxhNrWjkE8oFFuaOmuRqbhYpU5DXehI--


From nobody Tue Sep 10 10:53:59 2019
Return-Path: <trac@tools.ietf.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C475A12025D for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 10:53:57 -0700 (PDT)
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, SPF_HELO_NONE=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 np8J22wUMibU for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 10:53:55 -0700 (PDT)
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 C41891201B7 for <xml2rfc@ietf.org>; Tue, 10 Sep 2019 10:53:55 -0700 (PDT)
Received: from localhost ([::1]:53654 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1i7kKx-0002v2-D8; Tue, 10 Sep 2019 10:53:55 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "xml2rfc issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Cc: xml2rfc@ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: henrik@levkowetz.com
X-Trac-Project: xml2rfc
Date: Tue, 10 Sep 2019 17:53:55 -0000
X-URL: http://tools.ietf.org/tools/xml2rfc/
X-Trac-Ticket-URL: https://tools.ietf.org/tools/xml2rfc/trac/ticket/424
Message-ID: <068.fcca13afafcb2d1e79c2020929dec1cb@tools.ietf.org>
X-Trac-Ticket-ID: 424
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/LzIj6QBxpzE65u8jDuzEyaj-k4I>
Subject: [xml2rfc] #424 (Version 2 cli): Crash when author element only has organization info
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 17:53:58 -0000

#424: Crash when author element only has organization info

 I thought the issues might have been due to python and other software
 version issues on my machine, but I got a similar output on
 https://xml2rfc.tools.ietf.org/ :
 {{{
   Parsing file INPUT
   Resolving entity... /usr/local/lib/python2.7/dist-
 packages/xml2rfc/templates/rfc2629.dtd
   Resolving entity... /usr/local/lib/python2.7/dist-
 packages/xml2rfc/templates/rfc2629-xhtml.ent
   Resolving entity... /usr/local/lib/python2.7/dist-
 packages/xml2rfc/templates/rfc2629-other.ent
   Resolving entity... /usr/local/lib/python2.7/dist-
 packages/xml2rfc/templates/rfc2629.dtd
   Resolving entity... /usr/local/lib/python2.7/dist-
 packages/xml2rfc/templates/rfc2629-xhtml.ent
   Resolving entity... /usr/local/lib/python2.7/dist-
 packages/xml2rfc/templates/rfc2629-other.ent
 Traceback (most recent call last):
   File "/usr/local/bin/xml2rfc", line 11, in <module>
     sys.exit(main())
   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/run.py", line 496,
 in main
     htmlwriter.write(filename)
   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py",
 line 1431, in write
     self._build_document()
   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py",
 line 1377, in _build_document
     self.write_reference_list(references[0])
   File "/usr/local/lib/python2.7/dist-
 packages/xml2rfc/writers/legacy_html.py", line 570, in
 write_reference_list
     initials, surname = short_author_name_parts(author)
   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/name.py", line
 26, in short_author_name_parts
     initials = get_initials(a)
   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/name.py", line
 22, in get_initials
     initials = initials.split('.')[0]
 AttributeError: 'NoneType' object has no attribute 'split'
 }}}

-- 
----------------------------------+----------------------------------
 Reporter:  henrik@levkowetz.com  |      Owner:  henrik@levkowetz.com
     Type:  defect                |     Status:  new
 Priority:  medium                |  Milestone:
Component:  Version 2 cli         |    Version:  2.10.x
 Keywords:                        |
----------------------------------+----------------------------------

Ticket URL: <https://tools.ietf.org/tools/xml2rfc/trac/ticket/424>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>


From nobody Tue Sep 10 10:54:49 2019
Return-Path: <trac@tools.ietf.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB0912025D for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 10:54:48 -0700 (PDT)
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, SPF_HELO_NONE=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 IEbuk5OumKPt for <xml2rfc@ietfa.amsl.com>; Tue, 10 Sep 2019 10:54:46 -0700 (PDT)
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 615671201B7 for <xml2rfc@ietf.org>; Tue, 10 Sep 2019 10:54:46 -0700 (PDT)
Received: from localhost ([::1]:53664 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1i7kLm-000742-3C; Tue, 10 Sep 2019 10:54:46 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "xml2rfc issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Cc: xml2rfc@ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: henrik@levkowetz.com
X-Trac-Project: xml2rfc
Date: Tue, 10 Sep 2019 17:54:46 -0000
X-URL: http://tools.ietf.org/tools/xml2rfc/
X-Trac-Ticket-URL: https://tools.ietf.org/tools/xml2rfc/trac/ticket/424#comment:1
Message-ID: <083.90d79bad4a899d04c52ecc16cdb498a6@tools.ietf.org>
References: <068.fcca13afafcb2d1e79c2020929dec1cb@tools.ietf.org>
X-Trac-Ticket-ID: 424
In-Reply-To: <068.fcca13afafcb2d1e79c2020929dec1cb@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/3YYtzygXj4yW_M4hF3gaj0ieAf8>
Subject: Re: [xml2rfc] #424 (Version 2 cli): Crash when author element only has organization info
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 17:54:48 -0000

#424: Crash when author element only has organization info

Changes (by henrik@levkowetz.com):

 * cc: Niels, ten, Oever, <lists@digitaldissidents.org> (added)


-- 
-----------------------------------+----------------------------------
  Reporter:  henrik@levkowetz.com  |      Owner:  henrik@levkowetz.com
      Type:  defect                |     Status:  new
  Priority:  medium                |  Milestone:
 Component:  Version 2 cli         |    Version:  2.10.x
Resolution:                        |   Keywords:
-----------------------------------+----------------------------------

Ticket URL: <https://tools.ietf.org/tools/xml2rfc/trac/ticket/424#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>


From nobody Fri Sep 13 07:05:20 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92311200DF for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 07:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kH_M29a8iFo8 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 07:05:13 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 A4DD512002F for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 07:05:12 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id n10so2962665wmj.0 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 07:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=Vag7SsKo6MSBN44QaOo064IlToLj8sSyhM92S550s28=; b=ESoOjMuw1rWXBe5PU2XnHd7nEPy+M1s+nAK3e4mNVJhn8Ysn80jlWcY3N9K8OVtdpT v5uDTgEIrbxSmnKFy6W55YvxCwn2Kkbl8es2VaA279EpxPUj04wEUm8wybIpSc9I5rNs vETiyLArRjsDtRK8Bt74qSEC8qNsVPrlpzkz+N2w9OVWkQJUuC0tvSq2oyv3B9wmVzxU ogugaZpsSkPLpS36fON17xrJDrzAhBA9GqmrVp54UmFCU9hq8adMUemKFMqa3hea/8Hr 0FmiuaEW0E0m+9t0WdQSEtzmqLayagUCLqwDB2PdA+8T2HvX+FHpMLxZBRiW3uMVr5B5 yogw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=Vag7SsKo6MSBN44QaOo064IlToLj8sSyhM92S550s28=; b=lDbPa41X07afZVBHHyGj7sPLXWNGcJtVbKdtB5jymtavt4NTLlX8Sz+227avMRaLHV jSKkGiv4hJcDRO60gKQszOHuQ8Yvkq5sw7frmDrzkkxf5Oyu+12y2yaB83K3k28Jl5/F RmZ1i835AMXt730rAYOTTsDwfVz4ruBUL7LJFhFXhXmd+O3Q67jvkV8u8zkEmUSiyP85 AjHBdWzTBwPpetNcEqhDnO2BUmZvB0mW7QLdS0ChIOzFQQzzlc/aBENKlpbTJl2/pUKa ItUZ2g5IyFggg9szZR89ZcYMQAHA106/s2DpsA7Ih1929S+5ZWinQ2LIyCO1mTUbrfTk kl5A==
X-Gm-Message-State: APjAAAVDbbCRomJ/7fKRM3pog5XkShgR61dULCiU0tW/wYxtKYeEXd/E yiWuTFO2PFdiNIIOJDNlbCWEz3zY
X-Google-Smtp-Source: APXvYqweii7wPxz91cXcKRHJgfLZpXnAqdp9I1nvx43H3fuFEM0HcXXdP0XECCN9j8FPk34oyafjXA==
X-Received: by 2002:a1c:9805:: with SMTP id a5mr3497774wme.119.1568383510760;  Fri, 13 Sep 2019 07:05:10 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id g201sm4219153wmg.34.2019.09.13.07.05.09 for <xml2rfc@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 07:05:09 -0700 (PDT)
To: xml2rfc@ietf.org
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com>
Date: Fri, 13 Sep 2019 16:05:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
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/ksAJktwc0oOCj0MFB-PfFAyhgvo>
Subject: [xml2rfc] RFC date format?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 14:05:16 -0000

After submitting (in XML V3 format)
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-08
I see that you haven't fully made up your mind regarding date formats.

In the version created by the Web tool dates have changed to

nn month year

while the submitted generated version mixes the traditional and new date format.

I don't think there was a problem with the old format but what's more important is maintaining consistency.

thanx,
Anders


From nobody Fri Sep 13 07:18:11 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0D2120100 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 07:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0KTs99-HiFoi for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 07:18:08 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 34E641200EB for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 07:18:08 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id r17so1982909wme.0 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 07:18:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=wqd4FStKx95SO13JMPAzBauQLlsxib52ACB4Y2JjzCA=; b=nYy9LZLNsDP6DagGxMjdqB6SsYf72iVI3/gbRboP7WVc9wSH9euddSh8Py2IB3SLnJ rV464FlKMJCutVJqOYTahLsStbtI3SAsBo+lHZ0RPr1Hh1qGVKPLguL0FCX3C9kezjaJ wm9XVjonuMjviK0BJbuVD7wYKsNsnrAVhnHf9UYWGpZrR/vgV2ch8DJ6djPtzvC0VMlG 2I+8bk8ZKT2hW9ivP/R/w0I/YzYisU5uJb3SslwTpH2pV6FLe6DW76s4aYwJsfaxLKU0 gG5bxgKwO1FWU9jTkswJar4yG4cEQzIPe2RwpIEyfqfpsXN5Hlgt6HeJjjCKMbF1KCcU Avuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=wqd4FStKx95SO13JMPAzBauQLlsxib52ACB4Y2JjzCA=; b=VEg9/vapxo4kjyXhN1AHU50G46TZfayl0Us9kdaNIkH7fhZsUv32MFx60thhLcDdL/ gj1cXchu65Wku+in3dWtSsOTcJPe/HWJ6SDPaQVSWJywJKKdoynwlnxU0IU8g7uLdXgz +Ar3ga9Ci4zJhPsbKgf9cwLq7JIcJkjup7BGYrhOqOl5Ug69M9IgXO+jQje+/tDbGctR GoZjrB9AznSDs/Z4V+YhmsI3zh8svKRAPyrp/simmzptpBs3UDTrf7/E3Qju32MWrOtk FWwtl3JH1QltHKVO9LGFyWEwd+t0T9i7Qg2IUifSrVLncA5ZEztDkBMFGa8t7ttGTNkL RvNg==
X-Gm-Message-State: APjAAAUv973j7S9IDkNyj8FQLseYcrR9M1XQ7JhhDY1dHEAVKjknSnnk xkAYC/B61GNfIfJ+a+DqQ0wS9eJo
X-Google-Smtp-Source: APXvYqyxxBayR+RlbgZKq9UyI+L83QaDXjYUYtr8Y1iGZJIxKx6cp+xqJ6DsElpolMHJUPBS1rBYLw==
X-Received: by 2002:a1c:540c:: with SMTP id i12mr3914535wmb.90.1568384286290;  Fri, 13 Sep 2019 07:18:06 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id f186sm4348525wmg.21.2019.09.13.07.18.05 for <xml2rfc@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 07:18:05 -0700 (PDT)
To: xml2rfc@ietf.org
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com>
Date: Fri, 13 Sep 2019 16:18:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
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/YHNlHw4x5i8OfgFc1o3Fk9XGqa4>
Subject: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 14:18:10 -0000

Hi,

When switching to XML V3 the tables looked as bad as they always have so I reverted to my V2 <artwork> based design using the since long perfectly working table characters:
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-08#appendix-B

I would like RrfcMarkup <table> to use these characters instead of 7-bit ASCII.
The conversion to XML V3 also caused lines to fold although they fitted (with auto undenting) using XML V2.

thanx
Anders


From nobody Fri Sep 13 07:25:18 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27211120804 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 07:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 IUiuaO9gWYlh for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 07:25:16 -0700 (PDT)
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 A55211201DE for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 07:25:15 -0700 (PDT)
Received: by mail-wm1-x343.google.com with SMTP id g207so2997044wmg.5 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 07:25:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=/eMVPMjlQ9uII1kOFdCqzL2aGlgVVKo2/8InsQG6dV8=; b=vhq2JnCwI2MdoS1iz54SNNreUksRFVj7Id0GUVFpPjP50WcA5X38fAoUiJ1HtG1qI8 8OJgDG/wqzxZ9gnfyL5VNgC2HDafbceGODemCwvaKJ+xl5pJDkXbr96ADuZi7V9NprVO aZl5MI+gZy2fZcEFj76hF6P0SjyLw00ybEgxdMI7Bk3fo1U3/DR74hITMn29nRQX0bP/ Fb4koAdGfAdUrBvxxgZTEYHOHAdvpJlS5I54a97E5Fth4K6+ajcwSE/2917Uim8aeEm3 WBNEr6y29cpogRcXLFdzH+MhakvrBdW6UIU//8RwwDwDvz5h+WXNedo9PIevfChdPr1k 8G+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=/eMVPMjlQ9uII1kOFdCqzL2aGlgVVKo2/8InsQG6dV8=; b=gWW/yjDXkJt/1VBhMpCssRArbdfQZc8IuEiScm1b750Of+3a4PNfXepA1VN61y8cKX egaZXCDuYaGvhvBBCez5aKcdHdOHnOSiu/U8Wt93KSC24kiKnnOeckoZJpeYRNiTyq/+ gemeNP2Q0ivtUb46xHe6mkto7lmDYDu6IVJRaVCZD2/+E9g1WxcY0AWz8onj8/IXK6dV ar4Cg8FRn1Jsq5yJqjDHFvSoA7aAdfcwXNQKN3Ua30k8gawRUf83f74ETJjVbRwr+H2Z DgdMxmJQOlLry5of1aWgBo4K0+NQfFUco6/0aGDFcjomyMmlNdWxsq4AYQAVjlgkaKT9 HHnw==
X-Gm-Message-State: APjAAAWWVGh/Qg9zgYN4k9sFJIfjbNKyJUdnQCvaktjLnztdeby/ku0z DF8n6cHEnYXz9xbUd9ai5NCygMY/
X-Google-Smtp-Source: APXvYqxJ+fWolZEH9IKzL7wdlghSIwKDgYZPkvf3zAquwsbaEPDZH6AS5e1zA5VC3yefvyygOseJ2g==
X-Received: by 2002:a1c:a558:: with SMTP id o85mr3662803wme.30.1568384713814;  Fri, 13 Sep 2019 07:25:13 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id c3sm40634592wrh.55.2019.09.13.07.25.12 for <xml2rfc@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 07:25:13 -0700 (PDT)
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: xml2rfc@ietf.org
Message-ID: <7e3140aa-7c27-94ab-781b-e6ec3589872a@gmail.com>
Date: Fri, 13 Sep 2019 16:25:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
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/0hVK6CrAqCJmVICEcz63xOODECM>
Subject: [xml2rfc] Bullet lists in XML V3: o => *
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 14:25:17 -0000

Hi,

When switching to XML V3 bullet lists changed from using "o" to "*":
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-08#appendix-G

I tried to force using the bullet character <dt>&#x2022;</dt> but I only got "o".
Using RfcMarkup it would (AFAICT) be safe using the bullet character.

thanx
Anders


From nobody Fri Sep 13 07:57:12 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848CC12007C for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 07:57:10 -0700 (PDT)
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, SPF_HELO_NONE=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 l6bO8UyXlLVn for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 07:57:09 -0700 (PDT)
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 4034E120047 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 07:57:09 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53192 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 1i8n0T-0000c4-RG; Fri, 13 Sep 2019 07:57:08 -0700
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <a7344819-c320-9a03-6ca2-e129fc150ce5@levkowetz.com>
Date: Fri, 13 Sep 2019 16:56:58 +0200
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: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8oSUBqWrErVmtgugeSlr5S8A0tjSDs5fj"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, anders.rundgren.net@gmail.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/nkCU6Efp3SapiGmZU6OJDWsP4d4>
Subject: Re: [xml2rfc] RFC date format?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 14:57:11 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8oSUBqWrErVmtgugeSlr5S8A0tjSDs5fj
Content-Type: multipart/mixed; boundary="cL8HG1kOejUNXGfXfiRrbo3853A6DOGgX";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
Message-ID: <a7344819-c320-9a03-6ca2-e129fc150ce5@levkowetz.com>
Subject: Re: [xml2rfc] RFC date format?
References: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com>
In-Reply-To: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com>

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

You can choose format with the --legacy-date-format switch, except for th=
e
boilerplate which has a fixed format.

On 2019-09-13 16:05, Anders Rundgren wrote:
> After submitting (in XML V3 format)
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme=
-08
> I see that you haven't fully made up your mind regarding date formats.
>=20
> In the version created by the Web tool dates have changed to
>=20
> nn month year
>=20
> while the submitted generated version mixes the traditional and new dat=
e format.
>=20
> I don't think there was a problem with the old format but what's more i=
mportant is maintaining consistency.
>=20
> thanx,
> Anders
>=20
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc
>=20


--cL8HG1kOejUNXGfXfiRrbo3853A6DOGgX--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl17rjoACgkQTptXS4+7
FxoKSw//RSt+vNm6hfB67vhjS1KLT9fQ3vowY+b9jeSEzAKl5WGpDw/bo/1tYu2k
1xqWuFAyaZG1h1vgrNyEr80vZPWasEEXDciWymVlg4Y1M1JvlsuVdwPVufvnVKqQ
Z6ZB2wJ1k/DZZtOMp2hzjFAeaF7Z79XXU4LpLqoMIaVYUl1RbHKDTNqCjEikXaaL
VHleaftIKwlTPWtjz+lJNaJoiEWFShUsL1KWL5o+amyY9pBcNGzg1N2Yqf4bP6Ki
VurbX9M/5WW3emyj4+zYhaEnAQlBcSfJZHXyI6Hok0eAOic+SOnDCTNrPq7ACd6R
aXx87n71pou8vFsEpG4MDHeRTseWyptF8N038ag4BFb73OW/3/ViHkAQyQUxyvOU
xqPmH3bFTm0BOuORpacX/KruYtP/JnsVIKEYDbQ61oMUk0/h12h1bR2gaWzXVXsy
qYua9cmuRkmLc9Cw55xD7M7Mu7CXWElUEbdtQZRcifKfNAfhBTHoG9ka4qh6L3fW
gS8TJI7MNgQZGSi36XE0UYmd6krj8ESGG2IFdcU1+dbu3Dkl2YzFlC473+aS/J8x
pOq1v1kBYQzi27P4op3oAWaeOSuROe0Ts5gIn/QuE8l+3h+DE6A7/cv5kKJbwFnz
VeSAQqiTPr+8LSyuVJI44dDZ2sK7pfbpCAGRCQlepNWrsTiFuO8=
=GT95
-----END PGP SIGNATURE-----

--8oSUBqWrErVmtgugeSlr5S8A0tjSDs5fj--


From nobody Fri Sep 13 08:01:04 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E11C12086F for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:00:53 -0700 (PDT)
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, SPF_HELO_NONE=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 ewJGbOFkTy7s for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:00:51 -0700 (PDT)
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 6E336120843 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:00:51 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53276 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 1i8n46-0002kq-8a; Fri, 13 Sep 2019 08:00:51 -0700
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com>
Date: Fri, 13 Sep 2019 17:00:42 +0200
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: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="01O892gpadDq574nWhjMKemfMNivB2PJ8"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, anders.rundgren.net@gmail.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/Vdv2nRZbbRwRijFN4my60-Q48BI>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 15:00:54 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--01O892gpadDq574nWhjMKemfMNivB2PJ8
Content-Type: multipart/mixed; boundary="jGm3Hc405382onoAKttHCI2iuVoFmShIH";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
Message-ID: <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com>
In-Reply-To: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com>

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

Hi Anders,

On 2019-09-13 16:18, Anders Rundgren wrote:
> Hi,
>=20
> When switching to XML V3 the tables looked as bad as they always have
> so I reverted to my V2 <artwork> based design using the since long
> perfectly working table characters:=20
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme=
-08#appendix-B

Which won't result in HTML tables in the HTML output.

Yes, the v3 text output for tables need more work.

I would like RrfcMarkup <table> to use these characters instead of 7-bit =
ASCII.

That requires an update to RFC 7997, which can be done, of course, but
isn't part of the current v3 work.

> The conversion to XML V3 also caused lines to fold although they
> fitted (with auto undenting) using XML V2.

I'll need an XML source file to debug that.


Regards,

	Henrik


--jGm3Hc405382onoAKttHCI2iuVoFmShIH--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl17rxoACgkQTptXS4+7
FxqMzBAAy6gcZ9QzahnEla5ib/3xyxO54K+OE7XrmiV92zhzMTqdX1/826z3pvzW
4upUAr8NyGs1PcJe5PRqrD69n7TV4eN/CTjfJFLbcT5tbrBw4FAOR/lrxilZvuZS
8tMjDUX173dTZHxVtIONWBL7EBMgcly7DCIU34jwhD1ZJeHHMm8qLodFB1Cp4223
ROxzHLyM9SPjxq/vuaUj7ylR6m0ms7RK6nq/7t/r/ONslhXNDqHnwNMkuh1LS+j1
rfRyJzxkkbtmvspRdEMnn443qw1/Hnknmt35mFzycW6K7FFCn7b1qFZdFPW3AmsD
2INkGysWegkxfCeZOcYFXnJDINMyz8Nt8xBHEt4TDz4TWlG1OB+aGw32z4AOq2Ek
wpUSj6oQYK75ngqrOlFj+IybW/G1BvJINH0GOWjoFvXRWIR09VayPlmwK7swZ1Ir
1jdsbrnVnnHWmHGF/gPNwA5EP/i+mwppknGFEdJ5QfwS8oXiBK7BZLGjBxuhCOTl
vkKGztuf+DFXGmYtu0t025Qekb7OrCI7f+r1yj3rosTSQ6DsMzXzkKz59MyPCRpq
Z7CNdLOHlrq7XUW+YqGS84jBKXFhz4sY4lrkVquav5yiave9LgnuAgthvAACy4Ie
6RX3km0bfRGHpZxX1ZhSVk0E6ZzFKVgungsIwvYn9scBCmzCSEk=
=WLm7
-----END PGP SIGNATURE-----

--01O892gpadDq574nWhjMKemfMNivB2PJ8--


From nobody Fri Sep 13 08:02:26 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6C4120864 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sQob6Zqe9qm5 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:02:20 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 2CEB5120848 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:02:20 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id q17so27733248wrx.10 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:02:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=OKsUpoz260AnpO5i4qqozDavrFCs+8XocGAYZu6vlwE=; b=ZvO1ts4AZ2t+3I/3UlyaLIYqgI+5yHUJSm6lAmatgSfhWi0MwuFgBUFC29ebf0fGcw aSTxLrXQJrNXUe8ax3HVEKla94ef37GOvzzp6fpajoMi63v0mEDSAwFKW0+KysuDiuVC NMWe4i8YFeuMC/7k2HP3mQgyUA4veGSfPUm7/ZLdenC8YdsRik9ur0kMv563S5/es9pL t4mq6R5GqhmQbDvMdOtG6hL4xckJPH+9QZ/mgPZeR/lPvVR+WKeLeDGJJ4/sW0FdJEfl HDvBBgxG/MCPrHmoKKHNT4nY0YxsoOPmqixREoNXbrcUr09bztT/ciphX8glbxKEtZXX TAmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OKsUpoz260AnpO5i4qqozDavrFCs+8XocGAYZu6vlwE=; b=qPzFl0XmI9aZRFxKThZlCtK6dUyzIVqD9MqnZmpg8k0RyOIn6ggktblYF1fBQKsudN K/BhdzTMLZJqOARmfcg8Vkz9QO6KU1rmYCnJT8aoukym7VCHleNOjKPZF8X5WMJGxcG7 WdeIEpJrakO6Sfji+0Gr+1dhdsZwHUQnvh3ZZIUIdknzYgp7O9vy6K9uZQwRqFxurrHc e4WfT1XkO47lE3Tlyc7O7LtRCTv9lLGIeRnhsYutEtH7IxlgoOygdZw7muoF5IC8llBU dtEu7H2mLcMTMBLuFuwXymqh7Biu1BidYSLENJtIzlL4fCT9T83OyPeOKiHBUOy3uOw+ WcRQ==
X-Gm-Message-State: APjAAAWCLu0Ho7hks9D5jyEPouGXw8rE36AJtPY6PCibAYwJIyM0YhDi Wo41cbvkmIVGGqBneew2UYre9Y02
X-Google-Smtp-Source: APXvYqydiB8cEXQe5MBxQLLj/ZXEMTIWcrCLP/tqGCnYZosMRhbsCqI2z2hOQnP9R15PuvOeDkCrxw==
X-Received: by 2002:a5d:4904:: with SMTP id x4mr6900040wrq.219.1568386938004;  Fri, 13 Sep 2019 08:02:18 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id a18sm42728196wrh.25.2019.09.13.08.02.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 08:02:17 -0700 (PDT)
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com> <a7344819-c320-9a03-6ca2-e129fc150ce5@levkowetz.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <a566f342-aef1-2628-9eff-2b3c74387edb@gmail.com>
Date: Fri, 13 Sep 2019 17:02:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <a7344819-c320-9a03-6ca2-e129fc150ce5@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/whRmVV_qa0vlahNlEXWZMCae3Co>
Subject: Re: [xml2rfc] RFC date format?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 15:02:25 -0000

On 2019-09-13 16:56, Henrik Levkowetz wrote:
> You can choose format with the --legacy-date-format switch, except for the
> boilerplate which has a fixed format.

Hi Henrik,

This does not seem to address my concern about mixed date formats in submitted documents and that the Web tool does something else.

Anders

> 
> On 2019-09-13 16:05, Anders Rundgren wrote:
>> After submitting (in XML V3 format)
>> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-08
>> I see that you haven't fully made up your mind regarding date formats.
>>
>> In the version created by the Web tool dates have changed to
>>
>> nn month year
>>
>> while the submitted generated version mixes the traditional and new date format.
>>
>> I don't think there was a problem with the old format but what's more important is maintaining consistency.
>>
>> thanx,
>> Anders
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/xml2rfc
>>
> 


From nobody Fri Sep 13 08:02:39 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF85012088F for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:02:36 -0700 (PDT)
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, SPF_HELO_NONE=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 A6C-BgU-l3sO for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:02:35 -0700 (PDT)
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 167BF1208A5 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:02:35 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53287 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 1i8n5m-0000Vb-75; Fri, 13 Sep 2019 08:02:34 -0700
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <7e3140aa-7c27-94ab-781b-e6ec3589872a@gmail.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <2e674913-4018-3fe8-3efe-cb2a1c869605@levkowetz.com>
Date: Fri, 13 Sep 2019 17:02:26 +0200
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: <7e3140aa-7c27-94ab-781b-e6ec3589872a@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4PoMvi9eoVTSEN456UtoTHfRIaAseUl5H"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, anders.rundgren.net@gmail.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/BchBsgayYdv-f5c3mX6XMSR0kZI>
Subject: Re: [xml2rfc] Bullet lists in XML V3: o => *
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 15:02:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4PoMvi9eoVTSEN456UtoTHfRIaAseUl5H
Content-Type: multipart/mixed; boundary="fltucEmG4g6E7VD7hhAuvRWgkUn3Ssjkr";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
Message-ID: <2e674913-4018-3fe8-3efe-cb2a1c869605@levkowetz.com>
Subject: Re: [xml2rfc] Bullet lists in XML V3: o => *
References: <7e3140aa-7c27-94ab-781b-e6ec3589872a@gmail.com>
In-Reply-To: <7e3140aa-7c27-94ab-781b-e6ec3589872a@gmail.com>

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

Hi Anders,

On 2019-09-13 16:25, Anders Rundgren wrote:
> Hi,
>=20
> When switching to XML V3 bullet lists changed from using "o" to "*":
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme=
-08#appendix-G

Yes.  You can use --legacy-list-symbols to control this, or for more
control, use your own selection with --list-symbols=3D4*CHAR=20

> I tried to force using the bullet character <dt>&#x2022;</dt> but I onl=
y got "o".
> Using RfcMarkup it would (AFAICT) be safe using the bullet character.

That would also require an RFC 7997 update.


	Henrik


--fltucEmG4g6E7VD7hhAuvRWgkUn3Ssjkr--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl17r4IACgkQTptXS4+7
FxqMohAAyWln8NSJSg5FOFyrbNppbhewt36c24/nSsc/Yy+bOoBeKB8ZP1bpKjU7
5KHw+bXGkYV4NejVgyVrjG92em5+DWBJmNkvWfqBi/yeDrRn3unCLUG3F8xu2Ql0
LslMlWbEdZhbX/BheLViTb4yUAfeLvCbENBD1cgeO341X7x64B+PFXUQd1rPrvFi
CvyA4FwMf1hCsrRZ4QZIoDvU1N4BS0GNX0kVSJUME7WUp8fIYYct5nnyq6VPiLET
H/4XNUzDSqVSinp8gG6qjEZntOaxf7/Ct4Savfsjp9IF9qSW4PK2To4YqDhQBDd8
UiE25GaQKp924+XHsK1FP0+9WwN86mkeLTahEkSj471s62FSJ1g6+THMcTeyIK6M
u71mSt1InVrpIknSeyZL9AotaFcchtjjb+XS3A8hKpDq8wOPUpmJXoFPxKCQQNh3
xaokHLjzXPjCfLQKX6k/hsMpQm3iP60xgZwBv8GzI1hz+723Ha09K/ztqKPexoqR
PnhYkklSFbO4U3SrTNdYy6ZhB624P9bw5fZRlYVRhOcR6Buyz7P8vz22KF6CkBuH
G5Z8nhNFdcWiiOAnGOOfH+XzU3JFi02fAvlUAT/3O8HPXLHCWi40xhvsqTHldq8V
d9iwQRZo1vzjndH6yimW9KriDS7cY1f5SaVa5Q4Z6sMHmjpiAbk=
=VDoD
-----END PGP SIGNATURE-----

--4PoMvi9eoVTSEN456UtoTHfRIaAseUl5H--


From nobody Fri Sep 13 08:07:26 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEFC12085C for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:07:21 -0700 (PDT)
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, SPF_HELO_NONE=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 cuk5Ra6FTce8 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:07:20 -0700 (PDT)
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 3BD271200DF for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:07:20 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53321 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 1i8nAN-0000Xl-Jp; Fri, 13 Sep 2019 08:07:20 -0700
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com> <a7344819-c320-9a03-6ca2-e129fc150ce5@levkowetz.com> <a566f342-aef1-2628-9eff-2b3c74387edb@gmail.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <b293160b-a648-1f0e-8f90-a81347af7177@levkowetz.com>
Date: Fri, 13 Sep 2019 17:07:12 +0200
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: <a566f342-aef1-2628-9eff-2b3c74387edb@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3BMmbaF1XP0Jn8vQna5rhI7mEbrg4e8Vo"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, anders.rundgren.net@gmail.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/TqN5CB3_CqvTQzuPk-YrAKM9B_I>
Subject: Re: [xml2rfc] RFC date format?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 15:07:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--3BMmbaF1XP0Jn8vQna5rhI7mEbrg4e8Vo
Content-Type: multipart/mixed; boundary="6tEbSqRhg3JGLAVa05Pdmxd3KbFMCardP";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
Message-ID: <b293160b-a648-1f0e-8f90-a81347af7177@levkowetz.com>
Subject: Re: [xml2rfc] RFC date format?
References: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com>
 <a7344819-c320-9a03-6ca2-e129fc150ce5@levkowetz.com>
 <a566f342-aef1-2628-9eff-2b3c74387edb@gmail.com>
In-Reply-To: <a566f342-aef1-2628-9eff-2b3c74387edb@gmail.com>

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

Hi Anders,

On 2019-09-13 17:02, Anders Rundgren wrote:
> On 2019-09-13 16:56, Henrik Levkowetz wrote:
>> You can choose format with the --legacy-date-format switch, except for=
 the
>> boilerplate which has a fixed format.
>=20
> Hi Henrik,
>=20
> This does not seem to address my concern about mixed date formats in su=
bmitted documents and that the Web tool does something else.

In that case, you must give me more specific information and examples in
order to understand and possibly debug.


	Henrik


> Anders
>=20
>>=20
>> On 2019-09-13 16:05, Anders Rundgren wrote:
>>> After submitting (in XML V3 format)
>>> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-sche=
me-08
>>> I see that you haven't fully made up your mind regarding date formats=
=2E
>>>
>>> In the version created by the Web tool dates have changed to
>>>
>>> nn month year
>>>
>>> while the submitted generated version mixes the traditional and new d=
ate format.
>>>
>>> I don't think there was a problem with the old format but what's more=
 important is maintaining consistency.
>>>
>>> thanx,
>>> Anders
>>>
>>> _______________________________________________
>>> xml2rfc mailing list
>>> xml2rfc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/xml2rfc
>>>
>>=20
>=20
>=20


--6tEbSqRhg3JGLAVa05Pdmxd3KbFMCardP--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl17sKAACgkQTptXS4+7
FxqYfxAAg9HWnR0T7RUY9yTqQr3ugdZ3Fk1UTeMMhSFJX6CvbpKiyxhbGECFdu/R
8ZUZgyb6p/eHGzlWz0JL+uyvUxn8vEkU/VHF6a6DFq4Sor+Ir4DyngKsmBRmthjj
it80Dv5M5Z4GrWJloccPDAXj1v5fAjEkbJ4odaFN17DsQokOl5gs/TH/Xx7GCJ3R
4e7Q5iVhVAvSGnTu/GfYaojPF8Jn+6pN1qf48zMl8YVF5H8rwj2Pc4by9l5/23TQ
VYpirblGND4Igp1GgC8NK+U4AodAPOR+hXLWA9DCgoJJQKd1dCbNEEzG0wXxMvgo
kpeyvXOjH4xODJrSJsyKeMTTfwsaMYlFYEdhge9e7+Ip7OpRoKeydg+e4RbdWWXo
OL+XCsfLgF97DzahSdAU08Pg85jJJgWyoj32Lu+q+lIwZHLlhmSUn9AQE2IFt6Pu
MEghiNehXUjhftA3Fc8p2F+mCWeJN0zEJ6rdfMVYC2UEfz6veO1WUPTbLhw64/Ly
Ip2Yta1aUBuwsFstYZQSf6ilV2TxmoBxQtNm2QYNmlkw61S3h/Cjw5tz+fiDjWAH
F421dQ5dc0QWyPfVJ4FAIgu2GRAMVBW0vzdiqNgi27evYcSNXeS7hgg3dtn7GoCI
1QFxxMmxo/1/YOAw9p5dJTcDSCSiJPiE4RrvCoEAB1DUXgJNWlE=
=OeXD
-----END PGP SIGNATURE-----

--3BMmbaF1XP0Jn8vQna5rhI7mEbrg4e8Vo--


From nobody Fri Sep 13 08:18:52 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D70F120842 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 I4QKSADVUgFu for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:18:49 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 AE60B1200F9 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:18:48 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id a11so22725453wrx.1 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FwrCpC6+KjmW0P2NXnr3Gw7SZmjs5dC05hHhYHaudbw=; b=sH/REDerSPO8N6NjaXfcD+4BI6pkMDEMy28wCtC7SFumvV1oOSx2oWAX+uUEEn4h9w x9S6PuUT5IcBuiAkcHOZ0kV/Il4WM9M9b/FsfAGuZ53os4IP0XVfq9P20dcjwCSa9mxK x35sX6mCPewENuqSiR6YrxJHZKvzGNWEPrP+jexzInjRIXMLCRpPIC95Mk0wTZNS/nF+ j5b5+r5xx6PhHbDly9OVRPjmdVA5I3AxXczUdGwjYsZmaKV8dT77OHzEnvanGrud1vWd PHbmyUtSGr/8f9HE3A54jLDQvAsrLmb8YX5Y58bSl0QAtNtrRxg+mRZj0oLRIj6CIr8s dhOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FwrCpC6+KjmW0P2NXnr3Gw7SZmjs5dC05hHhYHaudbw=; b=k9pCeiwExpdHejIUc2XavYiqIwM+aBeYMv+V4ny3KsS4u8v8hd2fH+l/Mqmai+3h2d qPctVqz1Fm9YHJIdStvK8/jJgiMDZYWJSqfnFkEmGfMkaV79Ei2aYWD1/smSkePNNL6+ 5IHKnIEK1T3ncRsIb/73XCTeSlhI24ici6U4uuHZdSJJNpZf5r2xLyAgFj//2r0L7aQd u5Bq9t41Z8Vhf8bsUolY78OoCfDyNeShsq8mCgkXDlelRtMiFfoxK+ec86KRrDSsCum+ W1NSts1ukzhdFVA83Bkm3QYY4QwprA7JiSbuENAUXV7m4subJZnwc9Oxgw26ULsOpqUH oiYg==
X-Gm-Message-State: APjAAAUfqIdlbnS0w/HI0J4bMaQhyf5cPHLcyF6b8Zq0h9woPXp/Bilg cVpcu/O+qOt8e6Ai0S4cD2+0/lUn
X-Google-Smtp-Source: APXvYqxYXoxe1xEc73Ho+DgBhv3/9xv2NUzlzqLaPE7cN0lxsfgiNB8nonOh04mWctxs0vsqUM0m0g==
X-Received: by 2002:a05:6000:152:: with SMTP id r18mr3749922wrx.153.1568387926809;  Fri, 13 Sep 2019 08:18:46 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id x15sm2050359wmc.16.2019.09.13.08.18.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 08:18:46 -0700 (PDT)
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com> <a7344819-c320-9a03-6ca2-e129fc150ce5@levkowetz.com> <a566f342-aef1-2628-9eff-2b3c74387edb@gmail.com> <b293160b-a648-1f0e-8f90-a81347af7177@levkowetz.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <42746d08-1aef-fe42-f31e-204ed4d6620e@gmail.com>
Date: Fri, 13 Sep 2019 17:18:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <b293160b-a648-1f0e-8f90-a81347af7177@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/wcbU_-DP06oUNEUfGomtxywBX8U>
Subject: Re: [xml2rfc] RFC date format?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 15:18:51 -0000

Hi Henrik,

On 2019-09-13 17:07, Henrik Levkowetz wrote:
> Hi Anders,
> 
> On 2019-09-13 17:02, Anders Rundgren wrote:
>> On 2019-09-13 16:56, Henrik Levkowetz wrote:
>>> You can choose format with the --legacy-date-format switch, except for the
>>> boilerplate which has a fixed format.
>>
>> Hi Henrik,
>>
>> This does not seem to address my concern about mixed date formats in submitted documents and that the Web tool does something else.
> 
> In that case, you must give me more specific information and examples in
> order to understand and possibly debug.

If you run the V3 Web tool and ask for RfcMarkup for
https://raw.githubusercontent.com/cyberphone/ietf-json-canon/gh-pages/xmlv3/draft-rundgren-json-canonicalization-scheme.xml
you will (of today at least) see that all dates are in the new format.

The published version submitted as as XML
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-08
shows dates in old format except for
"This Internet-Draft will expire on 16 March 2020."

Cheers,
Anders


> 
> 
> 	Henrik
> 
> 
>> Anders
>>
>>>
>>> On 2019-09-13 16:05, Anders Rundgren wrote:
>>>> After submitting (in XML V3 format)
>>>> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-08
>>>> I see that you haven't fully made up your mind regarding date formats.
>>>>
>>>> In the version created by the Web tool dates have changed to
>>>>
>>>> nn month year
>>>>
>>>> while the submitted generated version mixes the traditional and new date format.
>>>>
>>>> I don't think there was a problem with the old format but what's more important is maintaining consistency.
>>>>
>>>> thanx,
>>>> Anders
>>>>
>>>> _______________________________________________
>>>> xml2rfc mailing list
>>>> xml2rfc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/xml2rfc
>>>>
>>>
>>
>>
> 


From nobody Fri Sep 13 08:26:00 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8221E120073 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BGFGx-I-vAR6 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:25:55 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 4F65B120047 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:25:55 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id o184so3221068wme.3 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:25:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ror41b8/99uJJWRc2xntOs3b4UqDA1CkZ8tcrf4WEs4=; b=YtB3JIBBdG62hWyG0dxcrJXwxsQEOxrYBL4qCZ6/dnO2SXqUNnw3WYqTrNNq7HVox9 JlUB5I38FPkZMhifJ8iDJ7Wq4qZSRcz8oMX7rMfm9bztQWmSvzSzsN9u5XpiwCgcwLzR MvMopb22YGvyynWsfa6kbHuwRxzE7ERiAv0763Fn3Tyhh9u8crSCZBQVHm5CH2VkHsyR +WFTzTKhbLH88LTpR2Dk61TwPXBlHD0H8oBABdyZT52tDjngzstYdGnIemAGZFedwGso RAixB5IG5jFx8v6eAchQ165JjjYDNKVqbpMLzOkRzUMcMPhlDhnyJPFI6jaL+P1RXKLH MnSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ror41b8/99uJJWRc2xntOs3b4UqDA1CkZ8tcrf4WEs4=; b=fCeG3+OALlm0phx2+I4ajGIcNIKdwGGUatu4/GMwkkcLKREWAOWBM413Rmvxm9Qp13 RYkQWMsvmVn4N2WmnW/IiM9RuguPffRTE39CebJp188DxWO6i8ZKQZiRZ7v7df1yOKjN n9Fl37JJJvd6Dcybj1194/Q4HJcXw+VgSjwnRYl5H1dB3DAp1IJ7KfGPjj7ett28thCk kUQ/iF8j8fCssdFa5pmekyssmXNAW09MNXL55WJNAG6idnYqLewG1pDFwNEnzCVIjAI2 Xfoia1Cwy8R/S9M2MCcxi2Uvq3SKiOa6cJ5lSNM+6+fntNN7JbkV+t52gkT+zIe42gYK cd5A==
X-Gm-Message-State: APjAAAVLSPKdZdm4hqTNK6i3bNEvNZ7JOsZbdiTjKjax4jZXLBdSzADV rmWwaZtm6pP8w5rNKiZa576pHjaI
X-Google-Smtp-Source: APXvYqwLC+WAISl/YKJ+dOe4hostPL3XFNkiLdORoLmpjJyGx0fFO/UBJOelfczzKWQnWPX4KULhxw==
X-Received: by 2002:a05:600c:21cf:: with SMTP id x15mr4096617wmj.145.1568388353483;  Fri, 13 Sep 2019 08:25:53 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id f66sm3201039wmg.2.2019.09.13.08.25.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 08:25:52 -0700 (PDT)
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com>
Date: Fri, 13 Sep 2019 17:25:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/FCVkXEOq4kBKY0e-06TNTXI2ow0>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 15:25:58 -0000

On 2019-09-13 17:00, Henrik Levkowetz wrote:
Hi Henrik,
> Hi Anders,
> 
> On 2019-09-13 16:18, Anders Rundgren wrote:
>> Hi,
>>
>> When switching to XML V3 the tables looked as bad as they always have
>> so I reverted to my V2 <artwork> based design using the since long
>> perfectly working table characters:
>> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-08#appendix-B
> 
> Which won't result in HTML tables in the HTML output.
> 
> Yes, the v3 text output for tables need more work.
> 
> I would like RrfcMarkup <table> to use these characters instead of 7-bit ASCII.
> 
> That requires an update to RFC 7997, which can be done, of course, but
> isn't part of the current v3 work.

Well, RFC 7997 only talks about Unicode in author-provided data which is not the case here.
The same goes for bullets lists.

It is not a big deal though, <artwork> saved my day anyway :-)

Cheers,
Anders

> 
>> The conversion to XML V3 also caused lines to fold although they
>> fitted (with auto undenting) using XML V2.
> 
> I'll need an XML source file to debug that.
> 
> 
> Regards,
> 
> 	Henrik
> 


From nobody Fri Sep 13 08:33:31 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6A120073 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:33:30 -0700 (PDT)
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, SPF_HELO_NONE=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 8VSr4TjhBWA7 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 08:33:28 -0700 (PDT)
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 48665120047 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 08:33:28 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53503 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 1i8nZe-0001LN-AM; Fri, 13 Sep 2019 08:33:27 -0700
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com> <a7344819-c320-9a03-6ca2-e129fc150ce5@levkowetz.com> <a566f342-aef1-2628-9eff-2b3c74387edb@gmail.com> <b293160b-a648-1f0e-8f90-a81347af7177@levkowetz.com> <42746d08-1aef-fe42-f31e-204ed4d6620e@gmail.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <a2820133-796a-bf11-6ff6-70dbc16e3dbb@levkowetz.com>
Date: Fri, 13 Sep 2019 17:33:13 +0200
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: <42746d08-1aef-fe42-f31e-204ed4d6620e@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tfGCU75vN66WnV7KGLIjWirhoWPCpmahN"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, anders.rundgren.net@gmail.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/o7t9EAhPY2P0DTlSmYKQS9OGtHM>
Subject: Re: [xml2rfc] RFC date format?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 15:33:31 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--tfGCU75vN66WnV7KGLIjWirhoWPCpmahN
Content-Type: multipart/mixed; boundary="1wdqN82WvBTMwBSAASCsmcn5iM5WlgCTG";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
Message-ID: <a2820133-796a-bf11-6ff6-70dbc16e3dbb@levkowetz.com>
Subject: Re: [xml2rfc] RFC date format?
References: <85e59f6d-f4d7-cc4c-93c2-5d3ee8dbd438@gmail.com>
 <a7344819-c320-9a03-6ca2-e129fc150ce5@levkowetz.com>
 <a566f342-aef1-2628-9eff-2b3c74387edb@gmail.com>
 <b293160b-a648-1f0e-8f90-a81347af7177@levkowetz.com>
 <42746d08-1aef-fe42-f31e-204ed4d6620e@gmail.com>
In-Reply-To: <42746d08-1aef-fe42-f31e-204ed4d6620e@gmail.com>

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

Hi Anders,

On 2019-09-13 17:18, Anders Rundgren wrote:
> Hi Henrik,
>=20
> On 2019-09-13 17:07, Henrik Levkowetz wrote:
>> Hi Anders,
>>=20
>> On 2019-09-13 17:02, Anders Rundgren wrote:
>>> On 2019-09-13 16:56, Henrik Levkowetz wrote:
>>>> You can choose format with the --legacy-date-format switch, except f=
or the
>>>> boilerplate which has a fixed format.
>>>
>>> Hi Henrik,
>>>
>>> This does not seem to address my concern about mixed date formats in =
submitted documents and that the Web tool does something else.
>>=20
>> In that case, you must give me more specific information and examples =
in
>> order to understand and possibly debug.
>=20
> If you run the V3 Web tool and ask for RfcMarkup for
> https://raw.githubusercontent.com/cyberphone/ietf-json-canon/gh-pages/x=
mlv3/draft-rundgren-json-canonicalization-scheme.xml
> you will (of today at least) see that all dates are in the new format.
>=20
> The published version submitted as as XML
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme=
-08
> shows dates in old format except for
> "This Internet-Draft will expire on 16 March 2020."

Right.  The --legacy-date-format doesn't affect the boilerplate, as I tri=
ed
to indicate.

Changing the default for xml2rfc output from submission-time conversion t=
o
use the new format should be trivial; will be so with the next release.


	Henrik


>=20
> Cheers,
> Anders
>=20
>=20
>>=20
>>=20
>> 	Henrik
>>=20
>>=20
>>> Anders
>>>
>>>>
>>>> On 2019-09-13 16:05, Anders Rundgren wrote:
>>>>> After submitting (in XML V3 format)
>>>>> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-sc=
heme-08
>>>>> I see that you haven't fully made up your mind regarding date forma=
ts.
>>>>>
>>>>> In the version created by the Web tool dates have changed to
>>>>>
>>>>> nn month year
>>>>>
>>>>> while the submitted generated version mixes the traditional and new=
 date format.
>>>>>
>>>>> I don't think there was a problem with the old format but what's mo=
re important is maintaining consistency.
>>>>>
>>>>> thanx,
>>>>> Anders
>>>>>
>>>>> _______________________________________________
>>>>> xml2rfc mailing list
>>>>> xml2rfc@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/xml2rfc
>>>>>
>>>>
>>>
>>>
>>=20
>=20
>=20


--1wdqN82WvBTMwBSAASCsmcn5iM5WlgCTG--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl17trkACgkQTptXS4+7
Fxp+XA/+Na74dGU8ZqBD5I2NGHwwVXN9lg83WaHzi7qlSZvrCOljfgIusSIG7OTA
N7UmHnHYheRscBenMxhOLYw+glgis48SDVzjQ5MdJ550Qu6xlS41kcVa5gJeMa9b
tLBHCZcgQ3UyQ6rA7HOZ8H8mC3UdYEHUNonIKRKldovadwJi2fPc7EuUMEH9paMu
3Z+jr5fZZHo59MvTIgOua6gjglxQodjSkptcnFVtj9ipDgTV1sf+OwRO1XnoyZKD
IJCXLImkjGaEiWMqH23RcHShTXnxaDVxo0TZdBacdf2vWzJdkBkJliKoSTS7ZiBl
MzcUcXNdJYRbe/RJjjq2Gg5AHa0ERND2XbEv4V7iaI41G+y61YIBoEZjTrYEinG3
tCV0QGbvIsv5gHXaojGlWRWzeNIx6iTxN/vZ3KY/8HRlQb3kqQ2pNsK5EBLZt2NL
YiQcfdLNBylk0zM7S60xNntnwnRwuONOR9FfjT0kAA7+Msm4ZVg6gWYmvByWYG/A
cmhOf0lxH4KJhLR2OA6Rv5jA2lRRjeBJiQYo6ttd5AUARc2BGpeggrvhnLKjW9ox
pmtqBTBXoN82W9tbhAbhj9gPD2AGcTVC52z59HgH5VaVqxDLeAfz0aykuWRYVsKz
poCcHAltgWzarR0OXOhxeMj0gW0xjz+bIQLaPoF7Xoo4b/5klI0=
=vvEa
-----END PGP SIGNATURE-----

--tfGCU75vN66WnV7KGLIjWirhoWPCpmahN--


From nobody Fri Sep 13 09:46:15 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CD712008F for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 09:46:13 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pqf4dM1p_cM8 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 09:46:09 -0700 (PDT)
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 B2B121200FF for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 09:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568393149; bh=qzlxRg0LmCo1+pbwlavUqPj7e03PQv0E2W+ElMU+tkQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=anXR91iwOOBMpi2GEUcHSeINcHSzINZUILhsLI4U7+raunIyyq0KaTrob0G5LsRFZ LNeUNSEgp1azDTYgMjfcmeJn1BPZUfD9KLunhCYNUiEUXSO5uCeYw535rD398txa2f J+D2uJ7wy9XhdE2E7W9xOj8C2zSu4cIdpqcXCygo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.151.56]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MJmKh-1hogLs2U7l-00KBE4; Fri, 13 Sep 2019 18:45:49 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de>
Date: Fri, 13 Sep 2019 18:45:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:JlS9lRb5+DCPOsh1tWUXCdBBIoBxW6BCS1R8bUBMn1oIrCJhqG4 llx8hmrq6Op2bj5JohyLg31hueqN8w316uFBEsNF35OCF4pQyxATHQeeXdvHjG5ih4PtIfx O6KJ7e2zGo6AHrRJxo7KSHP3nSOJZ/MIhJF8FNR86ZyxTmzzdQDrdXSD6s72D2jDX/EeRW5 Kg9S2OQrkOccsvEhar6ww==
X-UI-Out-Filterresults: notjunk:1;V03:K0:9qaIwKaKk7o=:2XkWP/gq21TkFSXAAhQLfo Ta1aEbciUz4ncjvS6hq8kmVcikLPNu1zkkbUgdo2OgDzLDiYuGCx3KHSh3+/sbUCl4wy4ZUhq pFic7tB5k496YSHJhz+h00w9Fk57nXk/9qcfLaLDAi1IWRINio/TMKQz4j0aIaSEm7fhxfdcM dkseHUfnexfDMMTtO2WpcJOcShgbhBOMlwq6fs5PuQJjDT5FeYA2hYPyPyglcI4weTxz2N+4i U8zR6TPTTMTfAAkNsWQfWuDLBxFdCVRHh60vRDOYgM79GFlX8cYWt6r7JqUrriaJcIfZkm2/c BWssa5S1yiPey+XWaKDfZEbdGmt+Ur+p+BnJb5uX05GLF37sE2FmDTiqdiom3jij0a5+lZwga NYJn1LGf/dtCYcoq8HrPHzvyxYgHWZVg0uX6rJM90k97Gp9UtxnbaVTND4REEd43tv1DwEKGL 5UTf0qijf85ctUWOmEpLKAMfS5JEBxQFqphiff7r/zK7suT4ZN6WCPWgCC9O4vPsE0vUdIQRE 0MoV/91sWlGRCrlBKpzCSJ/RMvO2o+E5dw07+CcCy9P+r1b1VIl5dNd7CJTVKyiwvv77ugl+z 8kKkr9FP/m4ihJ2s5DXQweHESQvRxp9LcbpsHdlF38Dt2SlGm+c0Y3Iw+EpOdZiURoEr7q/Qk FoLKl405wZ0yrBOHSD/e2F3eJwcem0t6IS1cTWxVI+XdfaCnGnH8ilhG5qxTwcxLEsWGExp0O tYu4pBbU9xZtop+KTCz4jBfFP1q0OTEMLDwzuSTlRhA/eNUMXjuZZan+j2/1dri+sY5/dOupx nSkfNgkgFeL8x7skYs1Xn4pD2g0SkGpneLcO985ANHr0mze0nzGHEYfuO1wjSLai5RFHle7q5 aVRjhfhp7S71nQf687nSC6Y56d079xeGYHcUkUV4ywCayDsoBVP3gLIqE4NwzRKwoAZjr6Jq9 iCDInxQd8jHtcQACkqA9cwXCmYFi4mBBLhJ6ozU+BbYBmlrHaj8pMHdS8boI02tpvcg9OB6HM 4eyPel0ngTG2AC/ormxpukZ+vy5CAY5JCsRYKq5QHYVVjPS4mW9D/mIWcl/LEQKAXNSeKwj+G /NcAIkjJqnz4TF1AqBKPb/8eprv/MID9z2wXmnp/aeNlgFGzXnxtEhwGX+IyETl6kbJijGe5x w4tDg30PqVdUq//KmpcvWITAC0+LFACa/FqPMJYzk0B92lCY9Sl4m++6QzhPY1j2/cBAV8j/j 6Y0OZe6j7wse8kfIw58XbmjlhbTruDzGxQhLDt0EBFN1B+zJDyIOWzTsYPbw=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/ouZXnUnjB1FuCdblwNtPjBfG_6k>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 16:46:14 -0000

On 13.09.2019 17:25, Anders Rundgren wrote:
> ...
> Well, RFC 7997 only talks about Unicode in author-provided data which is
> not the case here.
> The same goes for bullets lists.
> ...

I think we need to look at the role of the plain text output in the
future. The original plan was to make it as bare as possible, not even
paginated. Not sure why we deviated from that.

The format(s) to look for are IMHO HTML for on-screen, and HTML or PDF
for print. AFAIC, plain text is here because textual diffs work well,
and because it might have advantages when copy/pasted into plain text
email (or source code, or....). Making tables prettier doesn't seem to
be relevant for that (or might actually hurt).

> It is not a big deal though, <artwork> saved my day anyway :-)
> ...

IMHO the wrong decision. If it's a table, use a table. Otherwise you'll
end up with ugly output in the other output formats.

Best regards, Julian


From nobody Fri Sep 13 09:52:32 2019
Return-Path: <charles.perkins@earthlink.net>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4951200DB for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 09:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jal-vP55BzRD for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 09:52:28 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355761200D5 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 09:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1568393548; bh=S3c06PN/YjJ345ut5+d1+UF8Gbozpbt2HMDQ eBN/sFw=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=g63xFC6UgqW2oJAdWc/EFmDdziKXN6ZmY/R30qE20ccydO ftU+sd+DvGUgcFg7HxTBM4zeBHYKSSo4x0ovZ9rObWJYqe/BqNRVwhynxi8yeTviI4u DEDpAIYK1xv6Z4uaC6QfHcXU0rWClGTDOk86KBKLyKP5XPCc4aqcDAKTLV9/O8VkHZx sDt6I8heHC0Zb6o+ZJDV8D7VRMSd2Btm7PtnAoqfm+1OJmf2rGo2b+aPiPm4+sI4Jfc s+21rUMEVBLJrCTMokSC5ydRpi3OXa1wdIOt8dnhhSIzWnp0PGJM9mRm8XO4pzB2oyc NdTauBXVj8713rFLBAX+O1psDrbw==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=Yo5AOuSDaE7W6otTBHYAJYGUXRG4Iv2xToN1iHdk79XA/4nja9mZdvFDTYV1ECNLodE17l+7zw2ItyMdEc83J7rwqZvOXcTgv8gy33l+h475lMQ8QcmFx2Z4vDH5A3TySwDu3XAWWCLRHoOYRPaBWx3LY67UDc/ZVg3YhW75bvGxUwkOdfeeSk8VD5MO+Mfy1DVeEZo6YC/ulf9/044MZCcWBdXzvCRfQpN/f5Rhe9z0VCWA12Mgn9+i4QX72+WBsJUqIml+Bocq/dJricetlp55x4JLZAC3mIYPNwf53UtPzqLULWWrvavHjpDPtXBAW9lURybuksKMmGrGLqYV9w==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <charles.perkins@earthlink.net>) id 1i8oo6-0000VJ-NS; Fri, 13 Sep 2019 12:52:26 -0400
To: Julian Reschke <julian.reschke@gmx.de>, Anders Rundgren <anders.rundgren.net@gmail.com>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <8b9b63d3-0cb5-c943-7b92-2cf3ede8deba@earthlink.net>
Date: Fri, 13 Sep 2019 09:52:22 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c951ca00609b62c8e457c69a078ad5e0f25350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/fm-BO2tdk___22QmRrZu3-bTiB4>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 16:52:30 -0000

Hello folks,

On 9/13/2019 9:45 AM, Julian Reschke wrote:
>
> I think we need to look at the role of the plain text output in the
> future. The original plan was to make it as bare as possible, not even
> paginated. Not sure why we deviated from that.
>
That looks a lot like penalizing people who like plain text. Like me, 
for instance.

On the other hand it does seem to explain a lot of problems I've been 
having.

Regards,
Charlie P.



From nobody Fri Sep 13 22:04:50 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495761200FA for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 22:04:49 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJfgT8cfBhPW for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 22:04:46 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DD112003F for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 22:04:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568437482; bh=16VZp4uZkN93vDWGK1d+BO5RRdopvz10l0T3aPxY5R4=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=lB4Yr3bZkEIf6j9zehy22KsWWj3/COijlY/QFZUmUfM4/xIflLCnTlUyXKFM7CMcf STqYlptx6TMpDWzdMX0lfrbEEhOo5RlJQ8DDuD8NAkpcWU9wTbLvjT0vSJ0Q9z/IbR BSQc149Zy0vt4VaqKKg0Jxlhpw8EfcZlb81dKpx0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.159.64]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LyF3F-1iCb2S1TZF-015Yil; Sat, 14 Sep 2019 06:59:05 +0200
To: Charlie Perkins <charles.perkins@earthlink.net>, Anders Rundgren <anders.rundgren.net@gmail.com>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <8b9b63d3-0cb5-c943-7b92-2cf3ede8deba@earthlink.net>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <240ce695-ad69-7ab5-dfe5-ac7ec47e1cb8@gmx.de>
Date: Sat, 14 Sep 2019 06:59:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <8b9b63d3-0cb5-c943-7b92-2cf3ede8deba@earthlink.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Dwe6MNDI5T/Lxrl4+qEG5O89ybL8NOi5aUI6pM+1IwjKtD7Cn7g P1GNQAmTJPjfXzaF5hv9M38jicjn/9ih6YN/Op+0R2rTF3/quGQkQuiN7DPVaxGGEGz5skp nuUuzY68V8Fn1m286f0uD0smpBKy17bu0eU6oY3yqMYoTkrnqrEdxxVXwrCAUcbsvY0ufdO 3PGzDLjEi5dyK8k+uwIOA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:tg6yPr2AqjY=:wStJ67pcNuwgDOs4aiZ+Qt aldDSQNLNVGP9/eAL4scinYLsisJx7zBEMmRB4EjLA8MDhPqaKwm7YBH65bEtlK114qSZwSyL +ianpY0JPhy5QBD4vBulBiEB4zIbmRoASR1v882l6sPWX+SDAPy3Q0hURYimGE7UPJBg2fBVU gaGXANt3mQHfC+Z4BXhjnHM/ck51qKqBzSydGg4l0812v+4qxvZnGxHa8h+sdsv3fL45gSgHl jWQsFTJJ/WlQ3bTVxuX/EjpE7jZqn/6/YggGeOoNfJZ/W1hwNkpBadozV+X182PTIzfECWlhs Or3E6rFtwtKi98+wgq0nbmz2U77lJWFQZLV7E0sDyAEbvZnjd9JZpFZ04jG88qp6lDFNyDvq6 ypd9pP912kwwbvRyBlqBxmIk44Eq2qv9kKjGIZTHgfNjyZYzjFC6XQf1stwTFSeNVC5tXWRXB T37CWx1yrArUPizJgRYyKSI1KOVYgnfO7XhwMbDxSs59Zk/JbGM5NY/b+RfJLXRmCBM1MDL/X utke6sMfKvd1aa/DKOqaji+I/supQHWXgUsWRls50gPxwh9O5KDVhbPA83MIDc3gkK8MOKbyG nV/ER1IhnuSejgOM1PNPBrCUFKu4X14UpFtNU0zhLk2SSstGJatt5YDBAtWMo0nGohCDBMTku itnAONYQ0Cyuz5pWfXyyoalkbA3+8jtzdAXklTrLUSeyJbdjEd9J93DUs5ALuUHF8ITMD6kQY fAnSUCYeaGQy8wk74Sj7/O5obT5S2RbQqFifuBiJbQ/YRugKF+h5i3BcCnrYQaG26HSgru6CF AIKUxrZIw5iLV3wrbc5jX0W8TeA8nHEmbiNRVkw56LlPU2FizysuPm76/jgEd904ghKj2rjLi 9dW1w+VCxupOrLxTB5a3apA3Mn+5CuRFrFk0jEiYeYwrfi/lrycwMMQRaOQF9WzlDK+DqmL+d 32BooYirG3aFYewNXVJn0ieP2BfNvFGcdtxKgFnF/1HaecajnRSm1+6qgFNGR4ihRtCFSMOIT sTjrgSZiv/gKgD28nn1n9YTgU/38HI76cVcA5V7sMwcIptTG+0CyEEnRQSzHcAfNPsuuH3MD1 iWMaV/I1Kqbu2xHsXLz0S2sq+t9j5IOgLiqHdx+ao8aG/fwc6Ms6LjcQRWQAQiK6t0hSV2dP3 oF9ppjUMlBSLW+3yCEbTdigzyMc4t6SNSL5pdfQQPWz4sgIMKBxI+DYuR8R0wWvIs2Fy5cYV1 RkzkP+mIN903HuhTbSdmK/8N4KUJnsR2dxNQ4YYgthLWPRu2gmQiZun4YZ6M=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/yddOOJYccwNvVXf3kYM1iqW0siw>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 05:04:49 -0000

On 13.09.2019 18:52, Charlie Perkins wrote:
> Hello folks,
>
> On 9/13/2019 9:45 AM, Julian Reschke wrote:
>>
>> I think we need to look at the role of the plain text output in the
>> future. The original plan was to make it as bare as possible, not even
>> paginated. Not sure why we deviated from that.
>>
> That looks a lot like penalizing people who like plain text. Like me,
> for instance.

See <https://www.rfc-editor.org/rfc/rfc7990.html#section-7.3> and
earlier <https://www.rfc-editor.org/rfc/rfc6949.html#section-3.3>.

 > ...

Best regards, Julian


From nobody Fri Sep 13 22:08:23 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4011012003F for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 22:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YveAuDSk-NBk for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 22:08:19 -0700 (PDT)
Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 3C62912000F for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 22:08:19 -0700 (PDT)
Received: by mail-wr1-x442.google.com with SMTP id g7so33993798wrx.2 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 22:08:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+SjntUJngGE2C0TefJJT19Bq94HAFv9BAiSib/GmsIE=; b=m0yph05LSjGvz0ncGroMelt8N96KimTOVb2ktyIzzxi2LFM0i1Y9fPLt2MjxEAZpIN rMcKrx0h/i8BWTt9b0YrfpbaEW22fsE14m3fVJmp8yyUy99kWrhlW8YOovp/Y7X7Pa08 EDW5PmGog01smngFBodpdEJVarqjpuN4qj/2Wwhd8IpeJc+WalGUOAY5laMz7xeOu4DW Hi6wmW1LGbT4trbLkvWsfipBaHdCW87Yvl/BXPH3OcA6v/Hlm3JFtmQ8wF1F95jv/5tW dyo7WkD9MzVXAzN2gDCkUVuVzSDDEWWGvA8Wzb9YTHglaTIhyYF6gYe8H4/5pYc+meSq Stcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+SjntUJngGE2C0TefJJT19Bq94HAFv9BAiSib/GmsIE=; b=DK/xt0f+7yI+R3U0wWTB+bYW3vDIHc6G+Oq/yhbiaRUUrYZdyEqKKg7Q5Rx93SqCOg EeYLxHwpx7/gJGBwf7lbwGcw1FILVxdCXcQF3Frz+ghz+lFL4bBRxL7hMtTbd4o2MwEC sENzjTdtnz4S3f30WhKxoXzECDFkkCMYeWWmoxrsXwFPsKyOL3gg8TDQkVlK51fxEaCP D4W38gp0LoL8A4Ig9ph1DDOO0yDi+sCjQU4b6+W2Xnswpn4xMldZNdaz1BKMC9n4izLV 41VT2niPcBYRXHviPTzdJYK3TcecvHb+6rWOvdJIBxKHrSI4lkLhMM3JNvfn6ZMkMD8t MnFQ==
X-Gm-Message-State: APjAAAWb9MtNdVDWa+rv+BBazTk6YxmmdId/gvRAiL1yUqVPvb++4y9V 1msHI6FJZGCjjm3+AlcLSM/E5Sob
X-Google-Smtp-Source: APXvYqzq8nPOjbTh5MwO6kn6gI/Q052CWU6hGkR3cwNQ2V2BjPtcJJ9DANtnEaR4eGm+bLDjfZVAGw==
X-Received: by 2002:a5d:4444:: with SMTP id x4mr40626527wrr.11.1568437697362;  Fri, 13 Sep 2019 22:08:17 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id x17sm4576211wmj.19.2019.09.13.22.08.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 22:08:16 -0700 (PDT)
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de>
Message-ID: <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com>
Date: Sat, 14 Sep 2019 07:08:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/wCejV5d5em5iBie5E888XHlMET0>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 05:08:21 -0000

On 2019-09-13 18:45, Julian Reschke wrote:
> On 13.09.2019 17:25, Anders Rundgren wrote:
>> ...
>> Well, RFC 7997 only talks about Unicode in author-provided data which is
>> not the case here.
>> The same goes for bullets lists.
>> ...
> 
> I think we need to look at the role of the plain text output in the
> future. The original plan was to make it as bare as possible, not even
> paginated. Not sure why we deviated from that.

Paginated RfcMarkup is rather reducing readability and browsers can print fairly well these days.

RfcMarkup seems to be the current standard for communicating RFC.

Making HTML the standard probably requires more work and PIs.  XHTML is deprecated.

New problems:
------------
BTW, my recent XML V3 submission did not generate an HTML version at all!
My previous XML V2 submissions did this automatically.

The HTML output for Web tool doesn't produce any output. It says it doesn't find the file :-(
The URL input began to fail:
https://raw.githubusercontent.com/cyberphone/ietf-json-canon/gh-pages/xmlv3/draft-rundgren-json-canonicalization-scheme.xml

Cheers,
Anders

> 
> The format(s) to look for are IMHO HTML for on-screen, and HTML or PDF
> for print. AFAIC, plain text is here because textual diffs work well,
> and because it might have advantages when copy/pasted into plain text
> email (or source code, or....). Making tables prettier doesn't seem to
> be relevant for that (or might actually hurt).
> 
>> It is not a big deal though, <artwork> saved my day anyway :-)
>> ...
> 
> IMHO the wrong decision. If it's a table, use a table. Otherwise you'll
> end up with ugly output in the other output formats.
> 
> Best regards, Julian
> 


From nobody Fri Sep 13 22:26:25 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C3012003F for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 22:26:23 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFb5-pfPqmUM for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 22:26:20 -0700 (PDT)
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 DFDF012000F for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 22:26:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568438758; bh=Ctlo86tbcIoKxz6jrhoifgcoAtxkZ+pZYZDUAvfMAXc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=iCzwDV4rjkUNWtw499ybvaA6CEMZZMEvWDHkh8GkPqsIS11rYzHztEx4kl0aesD3H oRil9mHfViwrIAztzmtm7uSqiwLJP0bKjIo2EfVcaEXcNkFelSuCE1zj2Ech2Vzphq o62Tr+ViajZwl4KZ88/NUcG8WI7gTboe7C3fqFv0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.159.64]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MXp9i-1haml73TsC-00Y8qu; Sat, 14 Sep 2019 07:25:57 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de>
Date: Sat, 14 Sep 2019 07:25:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:uRYqCzFIktMf2qiYz4p0eLKw/LIUUXXY5jJmQfATbvfv1rVMYpo 3ows33U0yUgTWCNGqaDO6bLbZvyO8k5gpHGCb5RvVphcNNVX8vydfD8JdgMWaC9eKnVDPwY y1r/evqY596E2txvFQV2+hrx3HTMZqVZSKFhaWL19X3DOXP+GdFqlu9z+em+LlnwubRCmdE 9bjJ7pdZ5UIhM1eNB6XcQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:E59W+rx/Vis=:aSKO6b51RExoJQloCxaMNl oNLgNkCgTQefZBTTVBrYi4TB2sPlKrwbUl+5OePaj9DrYBdxVJk74xUTw0FN88A0SXubk8+xe IgY0Br+k+6S7X5NDjaY10ESLi8VWW7HUsLQ/3T6P2hV//IV965wQTwXvResZ+dB82WN4FlksA cGTd0JG/K68UUg6ttvbg5mj1tPX4bUH81NMb07MBj+W0eo3716tM9uC83bTdVv+7yiBVIlADs dQtEu0xh9E4Pdnp0zv9BToWdyyiHVztuY4HZykXxy+nycLNCIGCB/Dyp+bHrREaIh+6ik+w5X X2FqxOSq4XRNrn8QbSN7Q9kswQdiDhnxfBi2V0bZ3nJtOj5mc/dX/HFpf+p4b4VjqMkKis+uc l1bYQe2ApGlcH0FDAj0UkwPNR5V9zNUHW5B1BVuCGTENE8+kNO7E/3QvYmTzQ4dHBh7zVV3Tg ilnXBbQJ8jJufH/SNrrysAfFU1Equ0STBU0dY1NhIo9a3guE4HwejhAI0luWzodRXzYPAVS+x l7DE6UuNQSn2ZotxKyoDCxZ86ogJLOaaKyckOcolVM/c0ojSgipplbzKqME1Sdm+9VRXEPmep wojSTdORVjPPK+w+mlLqniyS+iflMOZUiA52C/y9mtSHXYgV7qrLqIxTtDNMsg/491+2yQmfo z4uYGj13R27BUFAKJW4Lf1jXlo53yYK/oxUDg92A6MB7cNLZaLOuOLM1h1WQ2av9vNTQXqkqx sCUEbcAGscLHuSqOSR3QKAkZEhpAHAhwznVYJejsjk+21qQ8XE1JWBBiPFwS54Rq82TY/fV7n GtVckPRaij6y/bhbwRHLZhMyLiy0lx40AhBu2yl5SdIgbkkT8DPtplj09eo5e0z5aaZvD58ev wwmMRL8JjTGKPp2xhwvPgcGVJjbfbnsLVcRcAXBK2prcI8bIud1nQ3FQsdcFttplGSQMvmXy6 BLogSHYFtJmMTXukpJ+uJr8tU+prvt3VIufkQjwKft2CJPzAoSFa1RJyLQyMSwCjxaiDIT5h6 FRncIKGyeOIqHK6fAfQurHxluozHw1wHeMBYbWq8uuG9MWGMauc8QdBqpnE01F38+/0w/4+2u vz9xkfzuY49FR8956pN3k2T3jScXewhAcRWylnxvJwDvgwWt9xDhvVhej/krtjDSA8AX8cr7y qqbb1zzWe6r8eFbXn6wLUaT7/GitEr2jjc9X80Dlz25V1b1aSf+1kxSo1fxMvGG/QEjnKuDch DzT8+zLLh7w1fgqQvxFEyVGLWZ8/NkiuIPMbep9Y/xJYsp+ZZIh5RdWcKnHU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/LL0oytuycsJgy1euBMi9LqeOgjI>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 05:26:24 -0000

On 14.09.2019 07:08, Anders Rundgren wrote:
> On 2019-09-13 18:45, Julian Reschke wrote:
>> On 13.09.2019 17:25, Anders Rundgren wrote:
>>> ...
>>> Well, RFC 7997 only talks about Unicode in author-provided data which =
is
>>> not the case here.
>>> The same goes for bullets lists.
>>> ...
>>
>> I think we need to look at the role of the plain text output in the
>> future. The original plan was to make it as bare as possible, not even
>> paginated. Not sure why we deviated from that.
>
> Paginated RfcMarkup is rather reducing readability and browsers can
> print fairly well these days.

Print plain text?

> RfcMarkup seems to be the current standard for communicating RFC.
>
> Making HTML the standard probably requires more work and PIs.=C2=A0 XHTM=
L is
> deprecated.

The "standard" is XML, in that the XML document is normative. HTML will
be generated from it.

I don't get your point about PIs, nor the one about XHTML.

> New problems:
> ------------
> BTW, my recent XML V3 submission did not generate an HTML version at all=
!
> My previous XML V2 submissions did this automatically.
>
> The HTML output for Web tool doesn't produce any output. It says it
> doesn't find the file :-(
> The URL input began to fail:
> https://raw.githubusercontent.com/cyberphone/ietf-json-canon/gh-pages/xm=
lv3/draft-rundgren-json-canonicalization-scheme.xml

My local install of xml2rfc dies with a stack trace, one issue is the
use of
<https://greenbytes.de/tech/webdav/rfc7991.html#element.dl.attribute.spaci=
ng>
which has been removed/changed but not yet documented in rfc7991bis.

Even after removing those, xml2rfc dies with:

> Traceback (most recent call last):
>   File "/bin/xml2rfc", line 10, in <module>
>     sys.exit(main())
>   File "/usr/lib/python2.7/site-packages/xml2rfc/run.py", line 595, in m=
ain
>     writer.write(filename)
>   File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line =
253, in write
>     html_tree =3D self.html_tree()
>   File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line =
231, in html_tree
>     html_tree =3D self.render(None, self.root)
>   File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line =
309, in render
>     res =3D func(h, x)
>   File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line =
625, in render_rfc
>     self.render(body, c)
>   File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line =
309, in render
>     res =3D func(h, x)
>   File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line =
1546, in render_front
>     entry(dl, 'Workgroup', wg.text)
>   File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line =
1511, in entry
>     dl.append( build.dd(*values, classes=3Dcls))
>   File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line =
93, in __call__
>     elem =3D super(ClassElementMaker, self).__call__(tag, *children, **a=
ttrib)
>   File "src/lxml/builder.py", line 226, in lxml.builder.ElementMaker.__c=
all__
> TypeError: bad argument type: NoneType(None)

You should submit a bug report.

Best regards, Julian





From nobody Fri Sep 13 22:37:48 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1C512003F for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 22:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uGQtBKTAl8kL for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 22:37:45 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 03EE512000F for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 22:37:44 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id l3so11211686wru.7 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 22:37:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=tddFzaTkAcWn+hWasu4NQCJeCN6t/01L00stJY7O3Cc=; b=OhAABWhXjfRa3A4phK6JoG+ExnPiiqwuTlzyTgj3lLH3fcgdCDGNGzysoOTvzlSTGD dB07Wq9pfJQD584rWO1/YJa9GeEyV5wFJ7jxyzM0l6maZv5qqXCzhSnOvMFB2qL4yQg3 16dBqjcRbQcEGt86B6CZPx4tBZhNUqujuRqYc22LE4BiuOkGcV6kWGKzTPqutmbuHpyK 7JvronlSyit3A6q7OS9IQHQNVWhRChJJqXEIDH5PdCqdpWjDN2MmrKwfmTP7WEXp/X7B SKoJd7MttPwqzlp/TC7o1OOi1Tq3MCkamL1YFGoLg1341xtKxQjq+UNcqlRJgt3Ub060 CVig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tddFzaTkAcWn+hWasu4NQCJeCN6t/01L00stJY7O3Cc=; b=DWZpUpyB/tH0QCe7AaYpED1NYcgsd1LQjHNcwo8Cu8fNIysNImXqa7bBoErGXLIBU/ BVVi7nxj70nAarnTPQp20k+u7iUlcVxE0ab/aTiOydSguC9T9iYjanO1Z3WDlcLn3cSW hHRFLZWkpdotQ6TZpxD01hmRYdQJ+dQ/5/qgER8A6DszAZ/idltLsYm8a8QaM7kDNQuY T7zj1+bQO+XYdOGIrWqShYSeJO4vsPJw6grIsngNFnxkY8lxzJv+8jxrFaijoyg2b7CP H7iIxsqnxlZgry/DTdtrfODO0RK/aiIE7X9D+2Wb68emCbwRM2vIvOFqdBj/jBGrXIn+ nLXw==
X-Gm-Message-State: APjAAAWxCHGjMM6FiE842+sESSXIQ1eqbmF0TJyuZetXU2qf96wFWjq8 zxXTiUR9S+v6prDaisCnGA0N1Fuy
X-Google-Smtp-Source: APXvYqxDmwoxEARIggUREohXC2mIR4bKRzhImNlXksoi6bSQYm8xOm8n4Yjqret+G//6hgOi6yN4iQ==
X-Received: by 2002:adf:f110:: with SMTP id r16mr15730724wro.152.1568439463117;  Fri, 13 Sep 2019 22:37:43 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id v11sm45602990wrv.54.2019.09.13.22.37.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 22:37:42 -0700 (PDT)
To: Julian Reschke <julian.reschke@gmx.de>, Charlie Perkins <charles.perkins@earthlink.net>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <8b9b63d3-0cb5-c943-7b92-2cf3ede8deba@earthlink.net> <240ce695-ad69-7ab5-dfe5-ac7ec47e1cb8@gmx.de>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <64a455fd-e128-d9fa-ba47-08f744f4fc94@gmail.com>
Date: Sat, 14 Sep 2019 07:37:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <240ce695-ad69-7ab5-dfe5-ac7ec47e1cb8@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/_M7N-uo_k0rI-F2R-M0M02wHj9M>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 05:37:47 -0000

On 2019-09-14 06:59, Julian Reschke wrote:
> On 13.09.2019 18:52, Charlie Perkins wrote:
>> Hello folks,
>>
>> On 9/13/2019 9:45 AM, Julian Reschke wrote:
>>>
>>> I think we need to look at the role of the plain text output in the
>>> future. The original plan was to make it as bare as possible, not even
>>> paginated. Not sure why we deviated from that.
>>>
>> That looks a lot like penalizing people who like plain text. Like me,
>> for instance.
> 
> See <https://www.rfc-editor.org/rfc/rfc7990.html#section-7.3> and

"A Byte Order Mark (BOM) will be added at the start of each file"

I accidentally got a BOM in a file which cause GitHub/Jenkins to fail.
Not even Windows' ultra-primitive Notepad needs BOM these days.

Thanx,
Anders

> earlier <https://www.rfc-editor.org/rfc/rfc6949.html#section-3.3>.


> 
>   > ...
> 
> Best regards, Julian
> 


From nobody Fri Sep 13 23:03:40 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F001200A1 for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 23:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DYqylug5I8Ed for <xml2rfc@ietfa.amsl.com>; Fri, 13 Sep 2019 23:03:35 -0700 (PDT)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 F143512000F for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 23:03:34 -0700 (PDT)
Received: by mail-wr1-x443.google.com with SMTP id i1so33385692wro.4 for <xml2rfc@ietf.org>; Fri, 13 Sep 2019 23:03:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+HRy4gwrrsAVMvl5YTLGvs/Fss2Sj1/yI1fZltz1u7Y=; b=bpfmkH8MW4CroFDi6wM0XSwqeB24ma7MiBSdz1PD39whibHE7I4Lc/KV0IzpsozeeV ZglfFeMfvi3LitWVAngB/8LsMs2qHH4u6MvllLxU/gwpFw862l6o8ACkyBRMtDUDS/oj b3TeA7FQmgC3tvHRoMuT8wir/klRwzmiaXo0l6f08APwDq3RCrJjUsdJFl+8huFOLczp odFstcC2iLGstCa5Af+YrYjnJbB0xquA8z+ThBI8il8roBg5tJL7N2gQ6uiz0HVG/+WP dKSA6tabq3WB0g4+ac02MrSBys/wnElLC/wRECFkar21r3mJmAXNdJJmVhl8Vbf3iRXT gDag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+HRy4gwrrsAVMvl5YTLGvs/Fss2Sj1/yI1fZltz1u7Y=; b=QdoHP+evkb+P0+CJqGYHlwyTe7rWSOeZ1ZLJ+J8uM6i+QpKiuJp38SlJ8GRkDQ+X9c iTXcxSzD1yalZ0mAF48OfaVTK9TUY7T5Mf8p4+tPc/DJsACqPV7bQRlW4Hx8KZvYguah Z/pRwQ8j1IAeKW5CQptGOoU/xU0lmr4T5+1a+za7TVJ0yLApKYYV2zhgZhsV6R7+MPe9 C7qxb/d2W8VzBYFVgykWLt9SeM+vusVE6fZ0rt6aWTss6W6tTw3GeL4jX0CrIWDlJYU+ uMrTEVcMnI7izqG8O+TcJgCb8Ed766aBkn9nTxV19w7fvLiSBGJJFsLuCzBGDoQG29ZE nHsA==
X-Gm-Message-State: APjAAAXytRP1rKKt0RoCgr9SjR6b+3GPPaNRq59zUwyHFVGwGM74EYMf ZthAH5Po+C83/MJEsHtRCHjnQNu1
X-Google-Smtp-Source: APXvYqzd9QvTaM7viF9tkJZ6dJChKPfqjf/NpxPtugjV1LG9pgOcuOaApgS7gATvMYatOdqXo3qJ3A==
X-Received: by 2002:adf:dc91:: with SMTP id r17mr853898wrj.22.1568441013080; Fri, 13 Sep 2019 23:03:33 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id d4sm3727440wrq.22.2019.09.13.23.03.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 23:03:32 -0700 (PDT)
To: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com>
Date: Sat, 14 Sep 2019 08:03:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/57LHahQKtCtbwY76J0sWSTvIzm4>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 06:03:38 -0000

Hi Julian,

On 2019-09-14 07:25, Julian Reschke wrote:
> On 14.09.2019 07:08, Anders Rundgren wrote:
>> On 2019-09-13 18:45, Julian Reschke wrote:
>>> On 13.09.2019 17:25, Anders Rundgren wrote:
>>>> ...
>>>> Well, RFC 7997 only talks about Unicode in author-provided data which is
>>>> not the case here.
>>>> The same goes for bullets lists.
>>>> ...
>>>
>>> I think we need to look at the role of the plain text output in the
>>> future. The original plan was to make it as bare as possible, not even
>>> paginated. Not sure why we deviated from that.
>>
>> Paginated RfcMarkup is rather reducing readability and browsers can
>> print fairly well these days.
> 
> Print plain text?

I just thought that pagination was intended for that purpose.
If not pagination has no purpose.

> 
>> RfcMarkup seems to be the current standard for communicating RFC.
>>
>> Making HTML the standard probably requires more work and PIs.  XHTML is
>> deprecated.
> 
> The "standard" is XML, in that the XML document is normative. HTML will
> be generated from it.

Sure, XML is the standard for creating RFC, I was rather referring
to links to published RFCs used everywhere.

HTML is currently NOT generated for V3 submissions.

> I don't get your point about PIs, nor the one about XHTML.


Since you as an author would like your precious text to be rendered
as good as possible, I guess that SVG would not be a part of RfcMarkup
making "line-art" variants a necessity.

PIs could be used to keep the XML intact.

XHTML is a deprecated W3C standard currently used by RFCs.  It is not
a problem but switching to HTML5 is preferable.

> 
>> New problems:
>> ------------
>> BTW, my recent XML V3 submission did not generate an HTML version at all!
>> My previous XML V2 submissions did this automatically.
>>
>> The HTML output for Web tool doesn't produce any output. It says it
>> doesn't find the file :-(
>> The URL input began to fail:
>> https://raw.githubusercontent.com/cyberphone/ietf-json-canon/gh-pages/xmlv3/draft-rundgren-json-canonicalization-scheme.xml
> 
> My local install of xml2rfc dies with a stack trace, one issue is the
> use of
> <https://greenbytes.de/tech/webdav/rfc7991.html#element.dl.attribute.spacing>
> which has been removed/changed but not yet documented in rfc7991bis.
> 
> Even after removing those, xml2rfc dies with:
> 
>> Traceback (most recent call last):
>>    File "/bin/xml2rfc", line 10, in <module>
>>      sys.exit(main())
>>    File "/usr/lib/python2.7/site-packages/xml2rfc/run.py", line 595, in main
>>      writer.write(filename)
>>    File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line 253, in write
>>      html_tree = self.html_tree()
>>    File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line 231, in html_tree
>>      html_tree = self.render(None, self.root)
>>    File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line 309, in render
>>      res = func(h, x)
>>    File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line 625, in render_rfc
>>      self.render(body, c)
>>    File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line 309, in render
>>      res = func(h, x)
>>    File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line 1546, in render_front
>>      entry(dl, 'Workgroup', wg.text)
>>    File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line 1511, in entry
>>      dl.append( build.dd(*values, classes=cls))
>>    File "/usr/lib/python2.7/site-packages/xml2rfc/writers/html.py", line 93, in __call__
>>      elem = super(ClassElementMaker, self).__call__(tag, *children, **attrib)
>>    File "src/lxml/builder.py", line 226, in lxml.builder.ElementMaker.__call__
>> TypeError: bad argument type: NoneType(None)
> 
> You should submit a bug report.
> 
> Best regards, Julian
> 
> 
> 
> 


From nobody Sat Sep 14 01:18:18 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DF9120025 for <xml2rfc@ietfa.amsl.com>; Sat, 14 Sep 2019 01:18:16 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExQZv4YehU4H for <xml2rfc@ietfa.amsl.com>; Sat, 14 Sep 2019 01:18:13 -0700 (PDT)
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 4A90B120024 for <xml2rfc@ietf.org>; Sat, 14 Sep 2019 01:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568449078; bh=72YG3kvKOWpbIuh0nFUWxLDqXZShuaR1cXCmeurzVMg=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=PNISwSPn3wk27vIIuGDrqyolTjqtLwy+klcFMYRLX1ffA4e55YloT8BcOfjd2hiAs I3lNsfcQMtQyNfej7aIP94Qn1MlhGo8B4N7imgJsdJwJvmlOvQ5c9ePy5i48SR2YAo brM9fSRvXS50SehHEdFFOXabZNaG60LX9XXX3yGw=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.159.64]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MJSx9-1i7gTe460J-0037Rv; Sat, 14 Sep 2019 10:17:58 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de>
Date: Sat, 14 Sep 2019 10:17:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Ho/eBU1zHzrMvUlBmm3QMA80tSZF2cEOd0xXc8+PUR5kASHLmLr GTU4A5zvfIsNr34Jrd+oJ/Qe7cJ41SVS80Oiz6VKJdnuy+Pp2BdM9rLDmnG/cf8OUlz8HaT sqcJuFpX5mimONk9OgwtMwEYdiUoAeVnDHPS6WLXmtaIxyATjNZdTVHeEOdJJWM83PN62yZ Ib+CzVBHnq0qOTS/aPTzg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Ejs3WLNx03I=:zbATlTe41QaR9Z1RmtGFv2 Arh+tduPkGlfdXpMrDj35JOHtQQdJSLMwyc9R9HYb2FN8y0DwMxu9dN3vU5JC/JH23PUEMMQM mpcESQh6SVtCp3DA/qT/7EKeDwVP5bFJBVsWK8pijif+0zCsDQiE4eDuZzScC97v93IzAX3Mb sJd9XjPYw0whK1frVjgU/lwITix7IrQLXKQE9rVCjjsMI4Em7orwKfvHBoPRvvvVchM5x0eyU qzhj+9A0rS/wsvbcBP29VgQiHLjmtA/56OdVDZHAIt7ipW+5+QhgXXEmWx5CCjvVbfxLSkBT+ Wka1Au6vGGO3MfKeq5qI5QXRl0aW+eqU9BwEHYRnReHG4xLycQbg15ZtyBiCFLOiqFSk2ISj8 Rh2O+iSJ4HU1aSAlnp1P8G0E0IRNttu+7Gr6XDI3g/R3uHnyuZ/gA0TBRbj2BD09CL0t1wp3f 0X5d5zrvkAAaF9N4sGjg0k7rEt8ZzD6G5vdssCtEnjwUGJLYIqnFWVHggikxzTCE3rOdvzeXp R8I2sxc29AC/ftKFfcFCooiBH0704uYrhZYzck7Gu9q7ar+DempydkQ9nrlYM2ErTpJIUEL0v LpKlRkRnwG//kRswod4gVPoxpY2NE9iyLx259b9qtGuYvZMgnDcDPsrLWLYFyX4++hAaB3ybE gLJjtM6oAq2CoG3Z61mDcQu7mj+r+H2qM2R1AX2eoo7lfjEYgiy0nz5pp86P5LQeY1ybj59GX 1I682nVOlWgcQe8bK5jjGFFqiYLHQY1ozmx8rV+Qe9Y8TOwfeF942Ym2lV8g1pjWR4M69J27v 6Cd6nGxKsRN7GIBYu90K2XrWjf1eGu53Ad4ENLtewbNJCJtsWTtjyK3btBavcPv5ActAZrlpr iKPahDRQfiy/MAn4qr03ku0IfBoBkr1exZavgerTto8BZUrfoC07efDe76Odv9vV9Fxa9JMVu 4+gmqha7t0d7iAqn5uTcmVBtGJCwJFFRjVWctF5sAMofZ4DAWnzQ/719Lopyx2EQAwQyHKS7O AaQeNsv1qhR7D0PqS8RHjfJRUPe34Vm7AC9JzpS3m1ngNYREVQXtcQPhhp7Y8MFY/B8ojX6Xv nElBLJUXFPFmcIdj5XlDducSA0xR7SpRD9ssJ9fCLxUFYCrFyCyX8WGMXK3LtQ1z4boClcpky 6DXiBEXSVYrsU/Txla9gqbq7vafDwo/FnHLUG3uiwhEKw6rWoLJC2aGlSYujLsELczR95a8nr /GP61x6ansT1veMfQMIIDd4CsC7ECUVYh96Z82Z3h0VTILNUr7o/wQ+ljDcw=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/dIGAov3TIw1r85KoSFUo9Zcy_tE>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 08:18:17 -0000

On 14.09.2019 08:03, Anders Rundgren wrote:
> Hi Julian,
>
> On 2019-09-14 07:25, Julian Reschke wrote:
>> On 14.09.2019 07:08, Anders Rundgren wrote:
>>> On 2019-09-13 18:45, Julian Reschke wrote:
>>>> On 13.09.2019 17:25, Anders Rundgren wrote:
>>>>> ...
>>>>> Well, RFC 7997 only talks about Unicode in author-provided data
>>>>> which is
>>>>> not the case here.
>>>>> The same goes for bullets lists.
>>>>> ...
>>>>
>>>> I think we need to look at the role of the plain text output in the
>>>> future. The original plan was to make it as bare as possible, not eve=
n
>>>> paginated. Not sure why we deviated from that.
>>>
>>> Paginated RfcMarkup is rather reducing readability and browsers can
>>> print fairly well these days.
>>
>> Print plain text?
>
> I just thought that pagination was intended for that purpose.
> If not pagination has no purpose.

With all due respect, it's pretty easy to make absolute statements like
these.

The current plan was agreed upon after long mailing list discussions,
many years ago. It's a compromise, yes.

People in fact do like pagination, even when not printing (I don't
belong to that group). It was very hard to get to where we are right
now, where pagination is just a service for certain output formats
(originally planned for PDF only), not something inherent in the
canonical RFC format.

That said, I still don't understand what you're referring to when you
say "Paginated RfcMarkup is rather reducing readability and browsers can
print fairly well these days."

>>> RfcMarkup seems to be the current standard for communicating RFC.
>>>
>>> Making HTML the standard probably requires more work and PIs.=C2=A0 XH=
TML is
>>> deprecated.
>>
>> The "standard" is XML, in that the XML document is normative. HTML will
>> be generated from it.
>
> Sure, XML is the standard for creating RFC, I was rather referring
> to links to published RFCs used everywhere.
>
> HTML is currently NOT generated for V3 submissions.

I'm sure it's planned. And yes, I agree that it should happen ASAP.

>> I don't get your point about PIs, nor the one about XHTML.
>
>
> Since you as an author would like your precious text to be rendered
> as good as possible, I guess that SVG would not be a part of RfcMarkup
> making "line-art" variants a necessity.

I do not necessarily agree that I would always supply line art as well.

> PIs could be used to keep the XML intact.

I still don't get that.

> XHTML is a deprecated W3C standard currently used by RFCs.=C2=A0 It is n=
ot
> a problem but switching to HTML5 is preferable.

"currently used by RFCs" where?

> ...

Best regards, Julian


From nobody Sat Sep 14 02:19:43 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C60912007A for <xml2rfc@ietfa.amsl.com>; Sat, 14 Sep 2019 02:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XAjZY6zRrcJT for <xml2rfc@ietfa.amsl.com>; Sat, 14 Sep 2019 02:19:39 -0700 (PDT)
Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 7DD29120059 for <xml2rfc@ietf.org>; Sat, 14 Sep 2019 02:19:39 -0700 (PDT)
Received: by mail-wr1-x444.google.com with SMTP id g7so34325484wrx.2 for <xml2rfc@ietf.org>; Sat, 14 Sep 2019 02:19:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jn7As5FzPJoeU4Km7Ql9xiNki4txg4i2R2YAQTFwYVc=; b=BT+OtZZ+3Hvj6MWz/H52CUst41kFeOAhhRZbggreB3kAf8gtdVo5UdFjQgnD04oRY+ qqi4sQd9m4IJazEdi2Jvt6AIYv2Ps84B/8gLcegJ0m921KSKi5Thkgnp3JT0Z887p2nt KakZlINwm1Ue4t9uBz+pKRoeLT+pLXBHicboLvt0xrkZNTJz4oZRoLBrmx1tjVUWxcPs x3/Ea5Zwo9FSyQM5WK3LTPj5Qrs8nF36lW4/35yzfehqfCLgEoetDVjaBtKcZIYxuNRB 9oN3gJ5UbbgAkaDzh1yCbat6/n/uSDAkfRsF1A351uzekzFekSTofPZ9o28vmH9dbue2 LI8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jn7As5FzPJoeU4Km7Ql9xiNki4txg4i2R2YAQTFwYVc=; b=PRPTJp9RBTTBIaPZdRw8m/NNXd2hA59w+bahOP0iS7ctnM5Bsm9KiW5+cx4OLxlO7c PQawYHnGQZMRzTyVj6kEqpkp5HmHvcU6lnFDdYNj4FL8BvkQhd9iLVvcXZyA9KJYWuUv zIbe3Ax6PeJ7se/U6jrRoAlM3YuP9nw9RX9WGxhbkElchKaO8BSLDn7aWy4dTfxRVkWV bevlUrsK9OOWm4QFG16dRd+tHKL45mJINbrnr8qnR12j+ohWGbLGmcfX75lxDC5SRFJo yJ4dwkC0EJkSh9m9sPBUZfCOHpbAmpGa2kzmqAxjGT5fwmx326THl2Yl03PO24brT+Zy VYOA==
X-Gm-Message-State: APjAAAWIHcYNz0eTcenCazAJMvQiOjbtQ6usJFkNSz5kfFrgD1yGdEue tjzllxjL3f66Qwp6IbUWjgjyzJRU
X-Google-Smtp-Source: APXvYqza4jPUA41gQ2G6b+wQOgTkHNqAJ1/7Op5nDzfnVsZrTCkBE/PL5/6fcCQpo7QVvOSPTfCxBg==
X-Received: by 2002:a5d:46c4:: with SMTP id g4mr5424970wrs.189.1568452777615;  Sat, 14 Sep 2019 02:19:37 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id w12sm47045266wrg.47.2019.09.14.02.19.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Sep 2019 02:19:36 -0700 (PDT)
To: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com>
Date: Sat, 14 Sep 2019 11:19:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/KZ1XGc-YmYnwenjPOrElkxVTPtk>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 09:19:41 -0000

On 2019-09-14 10:17, Julian Reschke wrote:
> On 14.09.2019 08:03, Anders Rundgren wrote:
>> Hi Julian,
>>
>> On 2019-09-14 07:25, Julian Reschke wrote:
>>> On 14.09.2019 07:08, Anders Rundgren wrote:
>>>> On 2019-09-13 18:45, Julian Reschke wrote:
>>>>> On 13.09.2019 17:25, Anders Rundgren wrote:
>>>>>> ...
>>>>>> Well, RFC 7997 only talks about Unicode in author-provided data
>>>>>> which is
>>>>>> not the case here.
>>>>>> The same goes for bullets lists.
>>>>>> ...
>>>>>
>>>>> I think we need to look at the role of the plain text output in the
>>>>> future. The original plan was to make it as bare as possible, not even
>>>>> paginated. Not sure why we deviated from that.
>>>>
>>>> Paginated RfcMarkup is rather reducing readability and browsers can
>>>> print fairly well these days.
>>>
>>> Print plain text?
>>
>> I just thought that pagination was intended for that purpose.
>> If not pagination has no purpose.
> 
> With all due respect, it's pretty easy to make absolute statements like
> these.

Pardon me.

> 
> The current plan was agreed upon after long mailing list discussions,
> many years ago. It's a compromise, yes.

I'm sure about it.

> 
> People in fact do like pagination, even when not printing (I don't
> belong to that group).

OK.

> It was very hard to get to where we are right
> now, where pagination is just a service for certain output formats
> (originally planned for PDF only), not something inherent in the
> canonical RFC format.
> 
> That said, I still don't understand what you're referring to when you
> say "Paginated RfcMarkup is rather reducing readability and browsers can
> print fairly well these days."

Well, having code examples and tables interspersed with pagination
information is not everybody's cup of tea :-)

Unpaginated Web pages print fairly well these days.  I believe there
even is a way to paginate specifically for printing.


> 
>>>> RfcMarkup seems to be the current standard for communicating RFC.
>>>>
>>>> Making HTML the standard probably requires more work and PIs.  XHTML is
>>>> deprecated.
>>>
>>> The "standard" is XML, in that the XML document is normative. HTML will
>>> be generated from it.
>>
>> Sure, XML is the standard for creating RFC, I was rather referring
>> to links to published RFCs used everywhere.
>>
>> HTML is currently NOT generated for V3 submissions.
> 
> I'm sure it's planned. And yes, I agree that it should happen ASAP.
> 
>>> I don't get your point about PIs, nor the one about XHTML.
>>
>>
>> Since you as an author would like your precious text to be rendered
>> as good as possible, I guess that SVG would not be a part of RfcMarkup
>> making "line-art" variants a necessity.
> 
> I do not necessarily agree that I would always supply line art as well.
> 
>> PIs could be used to keep the XML intact.
> 
> I still don't get that.

Maybe there is something I have misunderstood.

The idea is simply that there would be a single master document (in XML) that would conditionally produce different output depending on directives given by the author.

Since the transition to new formats always take long time, PIs could ease that.
> 
>> XHTML is a deprecated W3C standard currently used by RFCs.  It is not
>> a problem but switching to HTML5 is preferable.
> 
> "currently used by RFCs" where?

In RfcMarkup and HTML RFCs.

Cheers,
Anders

> 
>> ...
> 
> Best regards, Julian
> 


From nobody Sat Sep 14 02:42:02 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B82120026 for <xml2rfc@ietfa.amsl.com>; Sat, 14 Sep 2019 02:42:01 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7TBtMirrDsd for <xml2rfc@ietfa.amsl.com>; Sat, 14 Sep 2019 02:41:58 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F7F120059 for <xml2rfc@ietf.org>; Sat, 14 Sep 2019 02:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568454103; bh=mEsSCcXqD4mG7DdrtraFCc+hWCz6FNViTVWdUCoyFDo=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=C6gKcF8JZKjX1w5OxVsggdHj8UWJFDO/JCaxlvEAskMqV+D4IvyR1/6w+AfKQvUdo zx7x+YGWC4kwEuTtGXE9KPJgRtz6223mL7geBZuVw54UVWecoiA5+67Bn4ItM7SEpX NgfWTAKbj/18i7W5ZkqGfqXM0qcY9L6JyBvh1xE8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.159.64]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MfHAH-1icLld41Rj-00gpbK; Sat, 14 Sep 2019 11:41:43 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de>
Date: Sat, 14 Sep 2019 11:41:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:kCKirIeZkEcDANJE74JBSnVk2FIg7j3Wz6i4k13/IPYqCvMTuLB WWAyg9tU+YYpnup6c2RHROLWpjXgknFzssjHmtGVfzl3Nxl+ZryLKrZbFf+I3wGQimwySiA ffq6JDFlDfNgsWBYXUz2eRewbSKoyRwjgY8+j/SCacank70759ZqnU70SwDc6bRhyedjk2M XwEMqby12EuQVSarasx2A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:yy9BTkmHReA=:PrBJ70n+3jMhB7I3WiUR9i 1Ev8v9iNlRk4SgmNGp649e5ggQpbbQkDpP4TxIhuzVf//BeQ+juEWj9rD0CdAzMWk8v4tl9p2 M4ampKd4Vno8ew4RhaqQW1RRryg8/8yuyhyKQEs4YhbT0cS06AJfFsDuvpEDIc7+ulFjeVzFB HsPpT+8COLKdOPqAUwN5iiBfMsA+NNDWIgBFYtk4X52YIr9u6axi2ya0dbzIZSndke1Jq98vt f//PyNABYGMcHUDaRuo2mIeKViqdAWojD0/+JNsIbPpVtGb4YvxCP2sp71aC7ZxG6pEXDhEpX /7k9VL5ijF8ThRZifA5TPORYDlZVvEsnrHSi00kmc/OFBVCNXkLcnY0zbAg11E959LtK8Co/D Ve7UnMKz4Ba/iOJCkBOAeF0clwaxHPmTOCGcXBQsBn5cY+EEwHA6VmH1csrdGfd+tgVLlzNRz B1a1mZi8bkWuUQDJfMrDGp/jvSebey+pIBXNuQx+mDwDGTNqYCBkSgPra4mF00FupS9fMO1ru idMaI9y10qyGdJkQvYmEi6LLuIjbVkUbKB2/UPYbcIfBiOGFRuburP4wrOS3onkf7jYN5AINy qbtgXJ4pLWdNV5HudA9EMWY7lHIWI+MhinwiAbm+IYEtM92mMloXAi+1wELz5ghUwEENcRbel 2cuf5Zw4b5UCyoaK8Y9+6Wee9aJ0/ftMEW1QgScdsF8BnKk/SysTfYXJP8UFfl6/fAeik5E0S 72YnAUuzdwfoW3vG4H6hjRMxkSyFa2c+BhCXX+fIt8KhGLucfMkdTO42uZjy1gzUnHo2cSdSf uZYd+xo+ZoI1tmf2wTheBuJNXanm1oYTHccBcMtT27ifk+FuLvWBJdXpGvf5p2J35tE+l3i1P 8ihmQz1rmGMAhxyuFCYCMbLeYsKPz9n8UDfQQ1jZzlzGE9/RJsDLnKInJxC1D+82zuPRS3Ba+ IIpWHDwaB0CpVvM0RQalgBHbQV6WSa1FHJqSKQXQaO96ftRVk9RTInT0PjSE7lQ55dtggimFA oxq59oOuUFZsSeZDL2PYGZURULdIwmbLZFw3F06QXGdV1i6WGhAd5WczecbixbBF+dSx32KWj C0AtBP+hQiQJpHPPQIGA+9Sj1uyCnD5lMxNnjOK+RSEfju3QixRQXw74TkvMIBM0Onr31WTUN 2TYY8amrAIzsPARUJDDczK9GXYwVfoA6nTBM3uDblLRzO1ucrKasDPxvmMTDJ39X+HPAXyGHP 4iwJ/cDpGN1eqOl6z25zCqfm2pBV87a3oEbaXpYWBnRc6k7PtmRAQU+kviJ4=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/OejyMPMS_UxzMDobP4QjWaxvGd8>
Subject: Re: [xml2rfc] Tables in XML V3 - A downgrade
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 09:42:01 -0000

On 14.09.2019 11:19, Anders Rundgren wrote:
> ...
>> That said, I still don't understand what you're referring to when you
>> say "Paginated RfcMarkup is rather reducing readability and browsers ca=
n
>> print fairly well these days."
>
> Well, having code examples and tables interspersed with pagination
> information is not everybody's cup of tea :-)
>
> Unpaginated Web pages print fairly well these days.=C2=A0 I believe ther=
e
> even is a way to paginate specifically for printing.

Yes, but that requires the document to be HTML, not plain text. That's
what confused me.

rtfc2629.xslt generates the required CSS print information
(headers/footers etc). Unfortunately, browsers do not really care yet.
(PrinceXML does when generating PDF from HTML).

xml2rfc doesn't seem to generate it yet, but I'm sure it will at some poin=
t.

> ... >>> PIs could be used to keep the XML intact.
>>
>> I still don't get that.
>
> Maybe there is something I have misunderstood.
>
> The idea is simply that there would be a single master document (in XML)
> that would conditionally produce different output depending on
> directives given by the author.
>
> Since the transition to new formats always take long time, PIs could
> ease that.

The vocabulary has supported plain text fallbacks for ages, see
<https://greenbytes.de/tech/webdav/rfc7749.html#rfc.section.2.5.p.5>.
xml2rfc-as-implemented introduces something new for that, see
<https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-not=
es-09#section-3.1.1>.

>>> XHTML is a deprecated W3C standard currently used by RFCs.=C2=A0 It is=
 not
>>> a problem but switching to HTML5 is preferable.
>>
>> "currently used by RFCs" where?
>
> In RfcMarkup and HTML RFCs.

RfcMarkup has no official standing (and yes, I like it as well, and it
has served us well for a very long time). It apparently generates XHTML,
but the content is served as text/html on tools.ietf.org. It might be
good to change it to produce valid HTML5.

And when you say: "HTML RFCs", what are you referring to?

Best regards, Julian


From nobody Sun Sep 15 13:23:14 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F12120043; Sun, 15 Sep 2019 13:23:06 -0700 (PDT)
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, SPF_HELO_NONE=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 ZiPcPsqO65e9; Sun, 15 Sep 2019 13:23:05 -0700 (PDT)
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 4B53012002F; Sun, 15 Sep 2019 13:23:05 -0700 (PDT)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1i9b33-0000iJ-5e; Sun, 15 Sep 2019 13:23:05 -0700
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1i9b33-0000iJ-5e@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Sun, 15 Sep 2019 13:23:05 -0700
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/GI2eX9u6-UXEAm4UVz99RVdQdKs>
Subject: [xml2rfc] New xml2rfc release: v2.28.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Sep 2019 20:23:07 -0000

Hi,

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

Release notes:

xml2rfc (2.28.0) ietf; urgency=medium

  * Fixed the handling of empty <workgroup> entries when writing HTML, and 
    added handling for multiple <workgroup> entries for text output.  Fixes 
    issue #425.

  * Fixed an inconsistency in the handling of non-ASCII author initials.

  * Added some XML cleanup before writing prepped output.

  * Fixed a case where for instance 'Section b.2' would be emitted instead 
    of the correct 'Appendix B.2'

  * Changed the restricted right margin for <dt> terms.

  * Added a check for conflicting schema information for v3 input files, 
    and fixed a failure to heed the presence of preptool errors when genreating 
    v3 format outputs.

  * Adjusted the library call default value for --legacy-date-format to
    match the command line setting.

  * Added a script to minify javascript (through an external service), and 
    added a javascript minification step to the Makefile.

  * Added a html <div> for external metadata, and updated metadata.js to 
    look for online metadata also for documents served from disk.

  * Fixed a problem with authors without any name, with only organization 
    information present.

 -- Henrik Levkowetz <henrik@levkowetz.com>  15 Sep 2019 20:16:05 +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.28.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Sun Sep 15 21:24:07 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9284F1201E5; Sun, 15 Sep 2019 21:23:56 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpHKLTHCK5Td; Sun, 15 Sep 2019 21:23:54 -0700 (PDT)
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 C755912008D; Sun, 15 Sep 2019 21:23:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568607813; bh=p7HSoP6GPgnkCMZLwnlFDgum6AbXFixRVczW3BSutVk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=HSV0FuGAU/IF1DppSpdBhOeDjjPQ5AuSJoDaWD3OZ2kB8hVID1ooA2AL79JNhfpsv IK5382+nlJGFKq9OoMvXHgP+b5oN6QywWmqS+65tTDtUGaytTm4ee+wHS6+6bhZqeV 6oLgtJYnuDJHkt8UNB5PsSLZmpqsHuoev5oIiwHo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.141.216]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MUHbK-1his0V2pNK-00Qx7B; Mon, 16 Sep 2019 06:23:33 +0200
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
References: <E1i9b33-0000iJ-5e@durif.tools.ietf.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <44fe97cd-6e97-1649-5ead-72521124e921@gmx.de>
Date: Mon, 16 Sep 2019 06:23:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <E1i9b33-0000iJ-5e@durif.tools.ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:4BRjC8hDI2gQ3aNblX7bgBQTCptOu0Py8Oe50pB3IwSXhDE8RTU UKb3fwyT5nrJ26IlEyrvP66/sHI1XJdEe4NYvXz9gXsO7fiN8pUodIOZKUfv7QwOZ6UAc5U eiIv/T1Lmsq7GThJ8uL6SJvMO5jbkfB3BtqvZb0ljyj3HTCQ27/XbP97RiJU8Ik+iSXkChe gZwL4TP1Iy5xqCoNHDbdQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:/IuSlEhTPss=:nH8UddTgB7JQ3FXL3SAKh7 T4GOzx7njwPKGnQN8NgTJSezayTn0EtRy6CWF5+g8uAluSeIU3f8rUbYcuehA5wrrPNYOnB7/ c32+yKYhyXzUztz1DDt0lqyB+ZoSFwAVNRqyH8JcBp1CWGLgMw4CV7nLGnoVvJ9NPdFcvg/5u SYhe1KQV4eg2TXVjbqKooQSVxu9Wfbjp2K40ewJNy3iUc8cogEKRooPPgnO9i+V2p3lYbAcrF 09o/zjwfbQbG6dBITYwqx7Srzm1k+Ttq9N73SHt0rV/PI/t69UJsJoE6aE7kXtjONJ4qXuRvP jHZTDDtnp4oojC67Lm/SyMwW4oAYzneD26rQcioXcf9uF/V41Ff1PaZS+89E3gccSXH9ixDn/ 2IC83V5rUzPEVdDMltpOoYRIqdy8ckjK6+ohT3jH5u1i/3/JbaqJ0O/+GJZPP6nzajd1R0zfm /x6Jt4CdGk59ml2yiHjcGoguyLpBCWIHLMyTbQpMlFA5uyyYOgf+IX3xaVb6V+cnkBjURj7QP nQGhmFQz7q8fQwTVbdrumI35KD5TSAcB21i3xcCIR43fUmVwIbobRNHriqAaD5RJ07Y/xBUO9 k5nKAeZA62T7rQzVBbxuIlxkql63YKMeMRe5JD6D1UYjcnm4Ra8FQRtYAfmQrAWGzBYrtXW1o kVeH9kJEoWaXbweRTAkWopA4wpA+qDiRNYbll2KKFvtM+XBr60MWdFOGteLL5Agcm2Xc8Ln+i BQfRy1OonizPOEw/miXMpTEIXl32Bsjg3LAQmHM3NCWn5D3q1S7Ef9lJ8oR6+w+o6CfD+AZpc 0pvU1nyoB44AoB9coZMiCJOX+YnESvroVuCcYFvgfHP2KiSG1OXShesX1LpL1ocVcDIeyb67U sYXPAp7166/znTstmMAvhHNXYj8WPrjJZga64aCOKznrCYA2LbX7dAyMsqS21s8dQgLO1YuJf rNUwmqpz7Z4U9fQ+8WmbjRPxIJX3THWiV8fXBelDeKufwIaVW7d6OJBBrZ4o6MS/3hD74TopS TZjG9vUWFkQzjGHxrfgw7xPr6/eTBC8OtytyPMynUyk5hJeD6K8MalAoDR9/fU/OSTl8kAUTa pDkXjLCDgTHxrguB291/OsLAIHQjYcFX05tiK6kqA+E7MbsHRc7Zy6T/ZpLIMRDqLiXIZYMFG wP+7Xv0mbvi93W+CQE/H+9hl/ZY3GzJ9Pil93utOHoh783/HKOC4E5RPtLSmnRNq2Qt9nQjB7 VhHe3qzhUzNCZT/7dFlXQGxVzHpGsXAO8H4McZhzNb/NoguUpfJfzlFmvAkQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/fW3ODVDe-5jdh7G1QJYKMGetRDU>
Subject: [xml2rfc] multiple <workgroup> elements, was: New xml2rfc release: v2.28.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 04:23:57 -0000

On 15.09.2019 22:23, Henrik Levkowetz wrote:
> ...
>    * Fixed the handling of empty <workgroup> entries when writing HTML, =
and
>      added handling for multiple <workgroup> entries for text output.  F=
ixes
>      issue #425.
> ...

Interesting. Have you ever seen multiple <workgroup> elements in the wild?

I opened
<https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/99>,
proposing to tighten the grammar instead.

Best regards, Julian


From nobody Sun Sep 15 22:22:42 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1075D1200FB for <xml2rfc@ietfa.amsl.com>; Sun, 15 Sep 2019 22:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1CrAvi8wULK3 for <xml2rfc@ietfa.amsl.com>; Sun, 15 Sep 2019 22:22:39 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 6772712008C for <xml2rfc@ietf.org>; Sun, 15 Sep 2019 22:22:39 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id r17so6416185wme.0 for <xml2rfc@ietf.org>; Sun, 15 Sep 2019 22:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=xsnzezGJv0uG8RLxW3wWKkp6R7WGLyxGD1qsCc5IeBc=; b=K3gcnLGupimI7/p9icS3ln6cUmVSXCP3RVbal1O/YX6c6QHVkQuy6F/sPRLy56LkEr er4xMriqkxMuvg0GlTU5jR+gokKqm3rTPwjKNKUazQkuRESMPm/fUDco0W/MaBnkjH8E /GD7k1YexP6/aIqQvrxfuNqGvE4Ne0AiRjbRk/mTZNl+3JDNi8Fnk14opZ9VAL29shAb df06DVYex4NNJiCKOIxl5RdcaL93F/Br5zG9AwK3dzZyImHRn7ovSwovBAJFskQ0RUU1 VCq4SGhG5dMf1wi7BMPd6xh2sxuOTidl8KKM2230SeUZlbo6e/S5JdmwORxYjwQeXyRz ZOgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xsnzezGJv0uG8RLxW3wWKkp6R7WGLyxGD1qsCc5IeBc=; b=OIKHPq1B/pTlSTYD4/wHGTDAnn+Z0i8jxQut7pjeuMjIi0ufccaiUwSgSfzid5kXCa zPuSel+dwPOFoR4Q3gl3O+uMG6V2JkFGKPSHzghnTGS2pn+gNLcMGjjVsNF8Tgovg5mc Ki+XQJNzDErfwySG2s78D75DU1rcnQ3HiFnkNHb73WIzmlxCfCok1z6eZw2y+5BNsio9 d8grEtM7pC6aKJxi6WwDk57wNaCf8m4DgCph09deS+bGbnXdQcTauzjdOO9H96YEuNGJ /9O+eyFd/A8gd5VsL91dXG3HEg+deSinRs+DuZUd/E4KkgL/wAvFhblIXChi9JwhZshk F55A==
X-Gm-Message-State: APjAAAXO3/CFibqN6QUzfjgJQgoWDWZX4U2/3n7wvTZYkm90KA5j6ML1 3lDLr30DBvir2MGee0AdXkIMMP8V
X-Google-Smtp-Source: APXvYqwG+d5zwoOELFfwY+SrTAsjnqCzg33fICUlRlePQ21f1uNFFv9sPWtGi3GJz9ekjScneJ0/rA==
X-Received: by 2002:a1c:8147:: with SMTP id c68mr995549wmd.0.1568611357143; Sun, 15 Sep 2019 22:22:37 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id x5sm54310625wrg.69.2019.09.15.22.22.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Sep 2019 22:22:36 -0700 (PDT)
To: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com>
Date: Mon, 16 Sep 2019 07:22:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/ZWU0Q05hzaF85y9QYcYgovNOgSY>
Subject: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 05:22:41 -0000

On 2019-09-14 11:41, Julian Reschke wrote:
<snip>
> 
> RfcMarkup has no official standing (and yes, I like it as well, and it
> has served us well for a very long time). It apparently generates XHTML,
> but the content is served as text/html on tools.ietf.org. It might be
> good to change it to produce valid HTML5.

This in interesting and but also rather confusing since this is the by far most used method for communicating RFCs by developers.
> 
> And when you say: "HTML RFCs", what are you referring to?

The format that is called "html" which for unknown reasons was removed from XML V3 submissions:
V2: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06
V3: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-08

Regards,
Anders


From nobody Sun Sep 15 23:19:13 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A177D1200B8 for <xml2rfc@ietfa.amsl.com>; Sun, 15 Sep 2019 23:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XA6RQTGGmX-z for <xml2rfc@ietfa.amsl.com>; Sun, 15 Sep 2019 23:19:09 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 97760120048 for <xml2rfc@ietf.org>; Sun, 15 Sep 2019 23:19:09 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id 7so8624952wme.1 for <xml2rfc@ietf.org>; Sun, 15 Sep 2019 23:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=dPjQQtpUdp/3QNuuEL+QChl5Yn+JwdcbBRcI2TXW85s=; b=S8CPtJ5ouU+F0mRfR6MaeB4wIPoWO7btPYqi0UrD+dfEtssmXLOndGq7XMAgWDKya9 foIEJk/XWY/0YkC4OL//+vnSn2AfbpOE86++nfL65U0nQuYrv2hrolE2bLpb6ilNNeaM FqTbokv7b72YL9jhUu+5QAzmUDI9kS379VfiXGryqkT3LK0R0vH3LQwlZzUT/8L/oY4p UpZKFeGQM4whYZhPn8gcsnX5yS9xrdFsluGxu27hPSqKjHtEK6rXIWHOQZK2TUmIDMW9 UBOS1St6Xw/tLy5IAG3plzYhhrPlbQooU1Qfm7plOQlRsqU9k4b6oH6K7f9Ra8fpZ4us HtSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=dPjQQtpUdp/3QNuuEL+QChl5Yn+JwdcbBRcI2TXW85s=; b=Gf2XWuAdmgxbVx1tO4IYhzXo09r/b0ywAac56+M3a3DEHvM3tLv28U5FWn9jRDAEtl j2DkVFrwTl1+vITDeDm3lB6UsnG+ZjQbSfmjgMsVsxtFI7svtrAhFptlZ7vjc8RMtUSv bzTtz2r5rigYQiADTqCJi3zZFq9dsYjE1u1D7MrSs7vXWc1IpnRHlc//ONy5gfesMVak GdYptDzjuVfttdewHTG9u8sfiyyLFVD56poeML1ZKHHQ95Y8sgi2MWZEaYIrcxMpqmwz o9axT5xIFFHHS4r8letAqYF4KDWwboYM3var1k9XvgUK5FfKTwWFHzWTTg/CTsJ9aWl9 NZFw==
X-Gm-Message-State: APjAAAWh0sodb/WW/M7mr8NzsSZkpOcJd5StUIeuqaNi8z6Upqlre1WS HwrgUI9baaZMRjVVM0vAIfMuGhCz
X-Google-Smtp-Source: APXvYqzpmqnCF7u9Peuu5TMKKgYAxvFtArdGUkLY0myN3dQvyEMI10gufX1sucyi9kFmFKFZSx6TeA==
X-Received: by 2002:a05:600c:230d:: with SMTP id 13mr5303174wmo.114.1568614747693;  Sun, 15 Sep 2019 23:19:07 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id d193sm17586676wmd.0.2019.09.15.23.19.06 for <xml2rfc@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Sep 2019 23:19:07 -0700 (PDT)
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: xml2rfc@ietf.org
Message-ID: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com>
Date: Mon, 16 Sep 2019 08:19:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/F0iYgOwQLzddEqJs5tG04ogv1qo>
Subject: [xml2rfc] ID Nits incompatible with submission version of ID Nits
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 06:19:12 -0000

When clicking on [Nits] in https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-09
I get:
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-rundgren-json-canonicalization-scheme-09.txt
This version of idnits (2.16.02) produces incorrect/different information which did not show up when I submitted the I-D in XML V3 using the Web tool:

"== Missing Reference: 'RFC7638' is mentioned on line 495, but not defined"

There are no missing references.  Apparently, a SHOULD is missing in:
https://tools.ietf.org/html/rfc7991#section-2.42

"  ** There are 55 instances of too long lines in the document, the longest one being 141 characters in excess of 72"

There is no line with 141 characters in excess of 72.  Unicode issue?
However, there is though a bunch of lines that are exactly 73 characters long due to a change in "auto undent" which apparently has been removed in the XML V3 RfcMarkup renderer.

thanx
Anders


From nobody Mon Sep 16 00:07:14 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86412080E for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 00:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KyNy3HFObuFL for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 00:07:09 -0700 (PDT)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 8D85512080C for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 00:07:09 -0700 (PDT)
Received: by mail-wm1-x344.google.com with SMTP id y135so6592065wmc.1 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 00:07:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=7oug9MPBDn9WBcdiA2vrEYo2C5LceE0WOWUobCDgEQ0=; b=GLA4Yco5FWx3sez3cLRoylGjtLZhCWpu6MDmsTSXOJ0894gn/+bDjoAFzJj7/nV0/D cG9voP9H9hecEaU7TD2DsykqdMFJkm1ZpVOmVy6jqif2xmtdEVWdyApmoJM3w5fphO58 gTbuNxW+O0YwmYJmsd8b4FkWHlHbv3Qdew5MZOyhDXrDhDMsPc8VJVCaFvOUexiS/wNe ooavrF+LFkHRvSs7dqdYbFIgEFJ0hITf7BmLPTK5QdZohR/LiJTwRGrGjkFeSkigvUhP XcTDa/JH1IvyYfWYBBQp2KLyeaPBEI4YKFBxivQFZw4TCGUq3tY4gqM9t7kN7xhwZUK+ Sflg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=7oug9MPBDn9WBcdiA2vrEYo2C5LceE0WOWUobCDgEQ0=; b=IEYQfNMWKDZMAB6UQVFUnQoBrsJnRv/xmPpyeo8S+sS53tkuvNxefCMKEw+mwYQs9s g9hF0T3+UCVxEKqHS7PUlbxdjyD36Rqh6rFTmJ6Yw8+opNU6L12o7Squ9bTJ6dRD2vt/ 36Tzk0OdMq3TFUkMCRxiT4SLLHf6oGYeqMP9DbSNL4yWKpqcyyPODdYwIwijorWOwZAW YMhl3OmH1TIO634czJPsUGLng/7j+iVrI1Vpyia9AKGbLJFpC6zTjCQqBRVz2883UTCd xPbJw1dXACnn+gUVE9ygO3WVecW/RPLroyYx86YhowAbpFLuQFLTza9H+00rjxiP2gD7 0VSA==
X-Gm-Message-State: APjAAAUFgmGjpz8VyGM+XqCsaGf72vNZr5hdeYN/dq0rhePBgu29a17E Cxlo5pdGw6sTSsyXsb1EjDO2xzeV
X-Google-Smtp-Source: APXvYqwFa7Po2W7EknHRI6SX3Iem0PcGAwCFSV8X/bByxTlFspOYcTrIoKzUqitsGMHL3J/NA6Ve8A==
X-Received: by 2002:a05:600c:295d:: with SMTP id n29mr12020647wmd.36.1568617627642;  Mon, 16 Sep 2019 00:07:07 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id q10sm75818485wrd.39.2019.09.16.00.07.06 for <xml2rfc@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 00:07:06 -0700 (PDT)
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: xml2rfc@ietf.org
Message-ID: <0dcd3a1b-f16d-97ee-5ef4-de7e5b9058c8@gmail.com>
Date: Mon, 16 Sep 2019 09:07:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
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/fO3LypO0KNI4DSiFihSO_7_2rxU>
Subject: [xml2rfc] [xml] should render?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 07:07:12 -0000

When i click [xml]
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-09
I get (when using Chrome but not strangely not when using Firefox):
ERROR: /rfc/front/date/@month missing (and XSLT processor cannot compute the system date)

IMO, [xml] should provide the XML "as is" for people with interests in checking or "borrowing" and not try to render.
The "tool tip" also says: 'XML source for this document'

thanx
Anders


From nobody Mon Sep 16 01:06:01 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E22912083E for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:05:55 -0700 (PDT)
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, SPF_HELO_NONE=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 ajb02PEyjQ-f for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:05:53 -0700 (PDT)
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 DBCCB120830 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:05:53 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:49161 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 1i9m1A-0007FE-PR; Mon, 16 Sep 2019 01:05:53 -0700
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <0dcd3a1b-f16d-97ee-5ef4-de7e5b9058c8@gmail.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <ac14cf4c-0dcb-068b-2109-c64b321b7e89@levkowetz.com>
Date: Mon, 16 Sep 2019 10:05:24 +0200
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: <0dcd3a1b-f16d-97ee-5ef4-de7e5b9058c8@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4EfpWqVqsRfJB66sGKRFoT02Q0FgeIs7I"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, anders.rundgren.net@gmail.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/lC2iENQB3AsQgWYejbJzapmMf7c>
Subject: Re: [xml2rfc] [xml] should render?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:06:00 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4EfpWqVqsRfJB66sGKRFoT02Q0FgeIs7I
Content-Type: multipart/mixed; boundary="g333wcFd9laB3TEmObBiXX2XRqDnbM9VA";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
Message-ID: <ac14cf4c-0dcb-068b-2109-c64b321b7e89@levkowetz.com>
Subject: Re: [xml2rfc] [xml] should render?
References: <0dcd3a1b-f16d-97ee-5ef4-de7e5b9058c8@gmail.com>
In-Reply-To: <0dcd3a1b-f16d-97ee-5ef4-de7e5b9058c8@gmail.com>

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


On 2019-09-16 09:07, Anders Rundgren wrote:
> When i click [xml]
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme=
-09
> I get (when using Chrome but not strangely not when using Firefox):
> ERROR: /rfc/front/date/@month missing (and XSLT processor cannot comput=
e the system date)
>=20
> IMO, [xml] should provide the XML "as is" for people with interests in =
checking or "borrowing" and not try to render.
> The "tool tip" also says: 'XML source for this document'

You're very swift with very definitive statements.

Here, what's happening is that the server is serving you XML "as is".  Yo=
ur
browser is then applying the XSLT stylesheet you have specified in your
submitted XML.  Don't blame the server for that.


	Henrik


--g333wcFd9laB3TEmObBiXX2XRqDnbM9VA--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl1/QkQACgkQTptXS4+7
FxoI6Q//YUlUJ9cwu7hnKtFw3fakQnCNbvJkFR3kqesMgBR/fOjSlXbSG91iO1YR
NfBOMRhdrqhuDvcADd7WmsTr1ISD7Cv33oCx8hZ/b9l9mp8pTzScgHSv/xP87LIi
DuL6xF+gntzrwhFFBTO1Ptg9oX2gpDBpgFtZciY/2Fq0TR23fwkDF0C83wObChg6
YLPWcA51xWcXpX2pmVfgd2LBlBsKUF1IAvBy7m5YXiagNPAmy2OAwWFChQFEJFgG
/ddfsGrBWVPkdQSyO4Jn/33PQPCxjQxPN+BzWzxuvrHJq1LhE1shG38WJorDeJv6
A98eCFvzBXct+y4+uLtelJjcSyZbMxzarTX520JzP7V1Og/3BZ6gll4wLwsoSVFa
qps0AKS3bJckOPWh+zJCSEUM1OCLMuJnYazAiKCWi2bF2ZA9ncThGfQy352zdWLT
G7UODJUpurU/1VFKAGYiVl7eTuUX6ytYVt9eGQ1qj+CF1+0dlH0CMUCvloKR1g/b
gmw1mmt5+TGI6wEuNUsWI7cNvE5UF1g3FYeT9OpCOPyNQcHiN5vWuH9gcl46K+1J
EFCorYMRLoZIDWHnUlePg6IThDqCx+Fi5ONOrFXPGOUMAlZeVO408JhkycGs3qIO
6hEuzgGWTsTSfolkiiXY4td+Prs63Q7unWbtlbD4Eu6B8jWQHcM=
=lq0c
-----END PGP SIGNATURE-----

--4EfpWqVqsRfJB66sGKRFoT02Q0FgeIs7I--


From nobody Mon Sep 16 01:15:09 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7812081C for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:15:08 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUry7kwYiTtB for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:15:06 -0700 (PDT)
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 D4D77120812 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:15:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568621703; bh=pc/i3vQQq5IuDgVoBYODoesRyiDvYY/bYorgNd2xk2E=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=bDhpEHUhGFiUuHRPQyfYEM070jFYkkLySQs5JrX40Rge6JywFCN104vDp4izbzGth otPfqOs/iSzy/H4UQ6olihMBATDS5dKJl2ZMBWIsm84GAm+nAfgdGmG0gSpuDTH963 RdxG94G4We6sYo5IUb/nQS9PwRuvWwMDI9/SUPaM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.141.216]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2FhY-1iQLYc1Ukm-00s36s; Mon, 16 Sep 2019 10:09:38 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <b65d00b8-5788-69a1-d996-52f3391fc966@gmx.de>
Date: Mon, 16 Sep 2019 10:09:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:NSXB4IQ0938AfWa2op9NgCDGR4yVYzp/y45/hPw+xfEhxdRHIXO yl1UNnJPeDugLuXC2olWuxL67FFnWuTkLr0esCiO18B+YjUoLJrbahq5+Pp+GOMRR1+bSvN ffU8PBPXdvEqQiYovza0hw+PYIulLc50sQ8I3wJC7zfHax3Dt7TKNstr2Zw1SEUdb1x1Exc VcdTN889SHM2xbSDviyig==
X-UI-Out-Filterresults: notjunk:1;V03:K0:KTmGzSfcu1U=:NHaAFQGN4mlkmvTmz51TGI GmSN1EqauE5DNBzcLWBmlPsoLenwyvlrLsYAG40122+viDgO8nthCde/OhdKex3FcKfaMUb19 IqWS3cI617fH2O6ZprBye9rsuKLr0V7IVuIDPsDKwiJphNEhVLODtCjY2RSS38RZToHMdKu+k M2ghucapnmkJnS5/TI6ZDydLHVhXscsYSTQrmepN5cjj4E2eCROObLNnMpLVBk+Yujade99FV cb77V+INbSHidZ4h3JlSSePokA8pOudMMmiSY8TXWHxxm8OQ1T6jheITZnM+iUYuirfGCoMov slhnNvJx+VHP1/T5cXJupZ0J5m/ZTSpS8FH4disUA2zIqB1dy7nR6V+WR3F2pFbixGHQ+tGP1 qBg7jQaGzTvdiM9FTlUl+Wo6ilUWpXGqfk/ph53GrVGGwlELfj4hDpud+clfSEuPi+CJ5wP5j LyTissMDA5UvXsW0M54oqscowmOFetIpM+WVq5YIlaI/yu7jRgGaM2Sk08L29FvYvQRHCn0yg tYoMl0sTbTQuPNTFMTEsdoH2yc1Mp+YQ/2JlaV0ialO3A446BD5peFtSFJo/bVu9YQ5iSwcnQ NE3VYzF9Azj2/corxfViS4HH/dKlKBg2nOB0ggJomUU1z9gfAUBP9b3l4Qb8tkiG0bjyNaiVb xtyvg4epkoeQlhvWiMneH8nvKeomwfdprx5Eyx+Y+1IU0BHQoW+5OpgyMYS2EEdYdpHCqtnqL 0Ym7yeN/bDemiGZMTmQfAFjpMphtW2DKeOhU/2OLaXpBuwuWrwnxeF/civWG0t1m999pRSbhX thnJ4njSKg0GR0sC3D5TYoD8mpco53rAY64QBk5XK+LB7XtOZZIJQFqS9KZ5Sjnlv988ycJlT 14df4ywOcX4TvJenTPAIRB5gCK/9CHYZ58Ec5rL8pe4FtYfWWWx+P2BMP5GoDSUslM/xeWs7N 0T1qmh5ZJPzZKYRLQOeedRkPRuAaw40NGS3RQWCj1HKKkrhEEK/3kueyWNCWWDWnX0Y1q9M6x NWCcVGYErQzfhqIiqDKFS6bH11BFkzDutUllVKZp5mzYS71kYApZgweThKyi4HJRh24b5lyYM 37oXPBLB99c5RZrhg5iLG2HYuVvCh5EaOfdK/H9mKmDm4RSIeY+EAlL0F+FGro6ZrIfBbv2f5 lJelvLd9WF1x6jl8EZ9/MaFTKG1U6cM/R9FuMf5LOS4sp67xNyEMq0KJelhnghxtoVTsl8F+5 Up0zjexUcIA2AWcswQFP2Fz0IH2FWNlvGhHWSTwz5CS/reES+AhmylYgbglY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/eBvFsEU5oTUVcuX_wWfsV_Ewt7Y>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:15:08 -0000

On 16.09.2019 07:22, Anders Rundgren wrote:
> On 2019-09-14 11:41, Julian Reschke wrote:
> <snip>
>>
>> RfcMarkup has no official standing (and yes, I like it as well, and it
>> has served us well for a very long time). It apparently generates XHTML=
,
>> but the content is served as text/html on tools.ietf.org. It might be
>> good to change it to produce valid HTML5.
>
> This in interesting and but also rather confusing since this is the by
> far most used method for communicating RFCs by developers.

Right now, but the whole point is that in the future we'll be able to
generate the HTML directly from XML.

>> And when you say: "HTML RFCs", what are you referring to?
>
> The format that is called "html" which for unknown reasons was removed
> from XML V3 submissions:
> V2:
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-=
06
> V3:
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-=
08

OK. You'll need to ask the tools team about that.

Best regards, Julian


From nobody Mon Sep 16 01:18:14 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF47212003F for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:18:07 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCIIXADgqjmu for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:18:05 -0700 (PDT)
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 6C2F512081C for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:18:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568621871; bh=a9DguinaapFBbjfcDGW6+rS2iCAm941FAA3EKsHMTtI=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=P+5ff0rwrkwUYqBgRBONTPl1akrvUeX2fydG0wm8J8juc689sRVLiKXXkzKmh6fJA CM9bp6GaaEqswAXyg229THSlTntvPBK9WhMZuaY34NR09pqh6Ix/dP9qo/YK/9T72s ickwPkl5eDHgn1L+yn+HU6OJn7Wzob2NBsvdcb2k=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.141.216]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N2E1G-1iEpur2LF8-013fB6; Mon, 16 Sep 2019 10:17:51 +0200
To: Henrik Levkowetz <henrik@levkowetz.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <0dcd3a1b-f16d-97ee-5ef4-de7e5b9058c8@gmail.com> <ac14cf4c-0dcb-068b-2109-c64b321b7e89@levkowetz.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <3d869d0d-32b4-f147-b0f7-9965a155baf8@gmx.de>
Date: Mon, 16 Sep 2019 10:17:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <ac14cf4c-0dcb-068b-2109-c64b321b7e89@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:ZUzTC2kz+Byp7PStEFicWku7aDS7KzBsa0gESCBEDCVO+qdQJOX Yk216iDptZXCONVq/8bSDbbul2KP4OJpg7PUoCIxg7u0GpmRSz5wOHBeYClZ7UgtCTv+/qf HE3lXptw+fUb52YEXRIIKpVrhGf4X7UZtJYaJ+NuLL1gPpXRdGzYoLef1szaPSlZLi08VD2 fv5twL0qo5l9o7ObTsGyA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:5uobha6WFek=:POHWn5QScKxkYhWtjSBIbv aZPEb9ONcZPr454GxRIEInGRCaH+ZJQ/72DoriX43EKPwS/uwqmtjkAVpq5m3P2r92aNd6fHA MRFa0lWGsh+hmavhm3HZv+WMxVtgSWXehVHyc7fNEcgSSf9jr2uqyiL7TaWTpp/FXAvfAIJS2 MNVBeVkDE0xvRAt+4TTQauHo/O9R04xGMVoC5Ya8wbCDq4ctY1lwv6QFa7acGNBVwfWdCYamH Kb1cGrbw2XDjKIAfMDstXsZ/3Trw4d1cDgzjSaHYM+XNRApcZOijqgQip4CndOzm9x99zs8aF ta29Qp6gxHwzVt/P7hgtpu9C0RxCY2ZVQKB0V35NJKGHwWMN0PMfx6cWhCwxDHAgRLNX6GApW 7tuay2P7XVUgHPIbkAkfS1xu0ma+ipEBlLZXn6wER95y6obWlCd262Txu5/CmE9C7Ag+53HTS rJ1OACpYkC/O+1kI3mNWPGrTDOj8PEAQmDxa+W4Fc/vV5hsQJDQFxVH1B6rSIxU7EXhCtr2in +qZ/dL4X0Ci0wdTX0kxm2gbv77hRmkOFppnSNohLrHn4F6mYcnEhjpYO1CgVG/pkLroAOYOKh clv1bzPnjRaN4V0230nrDwj0oxavnxZO7+ymIYfMKVJD6eGuyFvv42sb4gHT7aGyZ9/mrzAQe NGjkAVxAjZPXOMFkynjAr79iKk19eyz8GCPLypjg8risNoEaaqeKx/38ThiT57kiR9iqSHfz2 LqRh/3VYQ22KHCzwV4jiLEtjT6n11u/cVLSVc5kDl/GqhlreleqA5llmJGguhz3gIXrrCTNko gOph7N9x4mmWwPnMPnejlc0UkHNgP3NL8gMe60rwCN10QEyjTovEN76xOWNa5OcZlR4GMsrqV QXGPMfBw8UZDYXQwnROy5R6jbR3WmoyWKPSLPTdEAEUgxdPMdcAnhCd+Yc/t55HJWxdYPiWKt cfT42WXjDb8bM7Wj7cPsF43OoOkhIjZmIlN0w8Dd8QxDG3N+UTxt6/7jRQm+5owxp6wK4UX7E Ss/nv1d9ss29ah7Qx1GkoWrlYG2rmFMJ04uK48IqGFF9jHoYt5d6EBytLvX/XVd2FQUgklKa7 ULuv9oF+kjTSgftMBmoIukTzXfwVfDNTIw5fifRAoLguSsV6dWTFIuMPqlZhKchr0GDfOSFBw vIsmfr1vApPo/jyoEQdRj+uSSbrP3JPOhUCWN3lnd1e2fmrsLixVpMPIkHxRV83p3ume6YxN2 h+0MpVsfTjPqbpXR4F2URbQDep03hLobm4XOMhFN8OXBXMrq2nRSefAcpYM0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/YJdhwgPhr_Oh-Z6SfW9GvJXkZZY>
Subject: Re: [xml2rfc] [xml] should render?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:18:08 -0000

On 16.09.2019 10:05, Henrik Levkowetz wrote:
>
> On 2019-09-16 09:07, Anders Rundgren wrote:
>> When i click [xml]
>> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme=
-09
>> I get (when using Chrome but not strangely not when using Firefox):
>> ERROR: /rfc/front/date/@month missing (and XSLT processor cannot comput=
e the system date)
>>
>> IMO, [xml] should provide the XML "as is" for people with interests in =
checking or "borrowing" and not try to render.
>> The "tool tip" also says: 'XML source for this document'
>
> You're very swift with very definitive statements.
>
> Here, what's happening is that the server is serving you XML "as is".  Y=
our
> browser is then applying the XSLT stylesheet you have specified in your
> submitted XML.  Don't blame the server for that.

Right.

This is a shortcoming of Chrome; see
<https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#xslt.engin=
es.browser>
and <https://bugs.webkit.org/show_bug.cgi?id=3D4079> (reported 2005, still
marked as "new").

Best regards, Julian


From nobody Mon Sep 16 01:34:17 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7D9120828 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:34:15 -0700 (PDT)
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, SPF_HELO_NONE=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 AHz52gRi4a5F for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:34:14 -0700 (PDT)
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 149FE120826 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:34:14 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:49549 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 1i9mSa-0001vE-Li; Mon, 16 Sep 2019 01:34:13 -0700
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <fe3a8952-3117-8367-ac5f-efb81cb356ba@levkowetz.com>
Date: Mon, 16 Sep 2019 10:34:04 +0200
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: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UNuCn8rutftMK3tsB3fURoA9GVsJPATGR"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, anders.rundgren.net@gmail.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/POHa-f0IUcwe6sgeiGtZgNzzSIU>
Subject: Re: [xml2rfc] ID Nits incompatible with submission version of ID Nits
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:34:15 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UNuCn8rutftMK3tsB3fURoA9GVsJPATGR
Content-Type: multipart/mixed; boundary="HUI69Uu5qs7ghWMQdvNOajaamh4AuBTiH";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
Message-ID: <fe3a8952-3117-8367-ac5f-efb81cb356ba@levkowetz.com>
Subject: Re: [xml2rfc] ID Nits incompatible with submission version of ID Nits
References: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com>
In-Reply-To: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com>

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


On 2019-09-16 08:19, Anders Rundgren wrote:
> When clicking on [Nits] in https://tools.ietf.org/html/draft-rundgren-j=
son-canonicalization-scheme-09
> I get:
> https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-run=
dgren-json-canonicalization-scheme-09.txt
> This version of idnits (2.16.02) produces incorrect/different informati=
on which did not show up when I submitted the I-D in XML V3 using the Web=
 tool:
>=20
> "=3D=3D Missing Reference: 'RFC7638' is mentioned on line 495, but not =
defined"
>=20
> There are no missing references.  Apparently, a SHOULD is missing in:
> https://tools.ietf.org/html/rfc7991#section-2.42

Heh.  Right, you used "Informal References" instead of "Informative Refer=
ences".
Good one.

> "  ** There are 55 instances of too long lines in the document, the lon=
gest one being 141 characters in excess of 72"
>=20
> There is no line with 141 characters in excess of 72.  Unicode issue?

Quite possibly, yes.

> However, there is though a bunch of lines that are exactly 73
> characters long due to a change in "auto undent" which apparently has
> been removed in the XML V3 RfcMarkup renderer.

Yes, the v3 renderer does not shift too long artwork left, which the v2
did.


	Henrik


--HUI69Uu5qs7ghWMQdvNOajaamh4AuBTiH--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl1/SP0ACgkQTptXS4+7
Fxo+Sw/8Cpb2+hf+ioKU6R14DTWWTPHB8OeRkvtBEB7PTtHAEq3KRin9wTYstRTY
/E8c6hMcHOkDcpCnN4oX+bm0IFM2Xa5gEqtGOYlLlTDubT/02vZV9nyRUypfd/ob
6AGcOmEwHeRaI/i5/xzLIYvk//O85qlOmMghX6KowwBsdcCKo14Oa3gPXIEs2owc
FyPWCcdQgQMiJAwlCx/PqYiJ9Dy6GsyVWKpanJNX0ix1SmTvuvkS/HoiAYPx/uIu
G6uVqCOJ/P5nk5rIdFQaqQzqUMwpcm4QruSBt60q1yycMs3TH21rV50Zgsz/DVSo
mUROJiBvYbpeBZ7WhUPzJAdUySigd+Tf+sMeUouVlKMIIlHpjnaA0iOsth/2UqOO
80TnR1/xGE+VuIOiWHnl7Jb8R//ggFQEaggb/JWJPmXV4hdI+el6XBEB0BYxVCgg
Gb1FESVOQu7rodG+Bp3qaXCGasifgRCCVEYiq/kfmnejZTs7Ibkwqo4y7Zdy1VjA
g46aHLRIqRTUnrDyQpbmpyogmiWek6cdQpLV1vQ09zhBDP56ECHqToSd/jw0/Cco
8U0pvUTkiyX7upnHKXXSlpwZFWsRJ3aGoiF1rSF3mXQL4MMm/ZnUWn2JwY3zVkAH
r6Ez8ETI+iCTX5f3IskWc1rja6jV78t9y2uF6hdNxLC28N99f/4=
=JXG3
-----END PGP SIGNATURE-----

--UNuCn8rutftMK3tsB3fURoA9GVsJPATGR--


From nobody Mon Sep 16 01:36:37 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93FA120825 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:36:35 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPvBHUWW76-w for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:36:33 -0700 (PDT)
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 DC896120827 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:36:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568622987; bh=230xlXDQ+xb0t62bqiOA7QUYOZbNhyEhncd9i9Qsi7Y=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=e0AopvQnlofriXVtMLWfgLWieGjr1XXCEtagH78o4vzrdiFTcph84fVrqkEkh2yln yYnAtpH0oDFaXgyup7dndEOIC2zO6W8RSjUInFJzpZwblVLVz23Qn9uxhK/6ayywIW G6DIiVJd199nGdDtZ/z2w70Rkhpivu3Y/d27eL8Q=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.141.216]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LjquD-1igdCk3IM5-00bvJN; Mon, 16 Sep 2019 10:36:27 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <0f2a8198-7596-fb51-c582-dfb0bbb62441@gmx.de>
Date: Mon, 16 Sep 2019 10:36:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Jog3OY3ZChvGfWe+2UEvlNuAK5tqOdz82u27OZpTQruaaDmjGbz 5WCISCrHtkrcB4QqjTRjoyA2aQVdIdrXzbOyVMe8LcFRZivHLwpRBeqx+pFIbhw5GMjRjBO AhAAcSpd7e+An2j40KY+OO0pvBmFmCiVvy7Hjo6bMWLUOENs0/Ft4/ps4buPSjIb4ygPVZP La3j+OCdiwg7l7rNWS7Ow==
X-UI-Out-Filterresults: notjunk:1;V03:K0:z3VtEuAJe4I=:JUbyuiA2heU84pnzNs5ZNZ 42C8vjfAji3ipdbgwb+0BOQwe2ZVWeWQ2kRcUsF+DdqsResJ31HMieCq/BSYv3UXnnlOr35nb O7j0ZTsjDL+xDO3oisHAJfh+j5iBSllvEJw9YESpqXJIQ6h8Ibkij+hWoquNP3Qovvgz9EoM2 mJWWeCI0afacC6Q1y3gKOueTu33TqYgE+6UD7LKcOd/IAh5Y6hdwdkoAOtQ7BSCLsF31pYyFt Pi/uZDlOmVQDAuQP5ZjPTMBH1AsiWNmiPOTXTS4g2wVqAKVaEAaeiGT852bizh79zWFL9ntWO CwCYo4E1MBBt8gc9csswEv1R2eDnd9FXEe3gQpaicXqZ+AdBp3k0g670rXyj9DND9PB/2+dH3 Gdo6r67HqMOKTjOvRrFSGjJJZKS1vJArnF5F9HFCgC0t7tthX+1KhVML+AVTILkXB3w86IUMA evoznirovnbHDgd3p1lcfDhntaicjDg/lxdwBCYj23DbIS135c0tS0XAuk3OTR7o2M3o1hPTK jIS0+ECBLI911FGynyd5qdJ8Z6APcGY/z87Kb60IH+GyzeEwk0bx4Bz62D9y4ZIV9pi8eAmbH H6c6CDYfJseThQEqGt+2+kuKaQKMWXwH+uxI6h0ZwRjfeVUPhYd8ZVCU3ztTgLaqMlJY6PLqv lZDGeekgebr46FeJ7sbcIdHeS1O5ox5WL+6Mi80jG+QCJw5ALKA6tX2oDUi/m06Dg6xvrqG5J TGhYFWb/Wa+UOVSGpmQt0nfuWIP2xmO2A/yt1UpOS0+j89zqIHDw2qPtAUMw1foj33zFSe/Mh ApHSwo1w9d9pF8jOJRqRabpqjh5t6sjPMGKolxMVRtTpjDMWOjoTC+/WtDvSq5a4wKFKsHX7W x8VJS2MUd4OlFeMTlYoWCgT/ZjSP1rDha+cK7oxdraX2CvbZoyI10+kfBUJl5yVwBLbpd1POy f4dwU+AFHqPNZM05edTv+FNIwhny2QkXXR0QdkT9osbAdHz0hyTfUs9W2abkEp+nwxRdeQqQJ h9+1qZnT1XeKTESn/z6W5GAbUBQyQr864Q7CJ7SIksRseFlb5pnAn5LagxNKUSZ/jcGHNgCvZ RbmDEGBPYRJ3WcwunGWQcdKZgdmmPQzm8W7SPwydbSkfuMM3KxYny4737V8v4XKbCcZ56KEoj dhwQeJk0k8sdApZ/Fzknoe3gGaHugASCTvcP33ZA7hVwWk5XQG84fhOEcPM2AMqbrT1IGCqY3 Nuvp3KiixH1cHQOqTKOPgHrsHiM2ZNdBtApcb8k+cp6H6dGj3CAgV7YTkl74=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/KJuLAYurDG0BjLEf8zk9Zbpx5kI>
Subject: Re: [xml2rfc] ID Nits incompatible with submission version of ID Nits
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:36:36 -0000

On 16.09.2019 08:19, Anders Rundgren wrote:
> ...
> There are no missing references.=C2=A0 Apparently, a SHOULD is missing i=
n:
> https://tools.ietf.org/html/rfc7991#section-2.42
> ...

Could you please elaborate...?

Best regards, Julian


From nobody Mon Sep 16 01:42:17 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D301A12002E for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RtpSHZBrevPn for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:42:14 -0700 (PDT)
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 05BAB12003F for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:42:14 -0700 (PDT)
Received: by mail-wm1-x343.google.com with SMTP id o184so9194371wme.3 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:42:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jZ3pYoY7BFGpZxxvwvaYX+E0M0u+wIVMVwcPEaqfK7A=; b=WYlBdrRWFORaZ7E8zBW1eRm7Kkz2x1Ish2LAqK8MBdlOk4L5c93r05m+uSP2mWKOjr b2Sj5rS47KNHXGDfaapVxUvyCwxhrPYaduFbe1Zz93xDVILcxe0CjGj4q6yGnQm4sa48 7sc6AmLcVdaOBPODeRH7qjWZqGaABmOnQN/zgCY8s8Ki8OZ7knFQEeYipK7jVgPOH+y1 s8tdCaAYboAMgDFsCIHAeeLY9QbyxJpQKr6FRBQkT+uqpPLmHc4Vg/DJNjetwsRiHqSZ 3bupDJBolXLp2OWjI8ihpDnZ7PaVkyd+Zs9LaPxtrGEyIiXfWTW8qROkMxt9YU5cVlr3 23kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jZ3pYoY7BFGpZxxvwvaYX+E0M0u+wIVMVwcPEaqfK7A=; b=WvbZ5E/ia+eGOtP0bVHJLflPZOTRqVQqFM6uKs5eOJh8rhGFXq2cu6pLEDazuw6T89 glkQOD/0uWcX+Qkl7j5bxJhP32DTX2wITgVyhuoaoFRSuDTc5l68OEehh26bV+ek0tF+ KrqE38kPN0YMknJvAtnMYBvZO6DzY7wUxY9LKEqIlb1YlG8q1bqXls0LD7fsqIHGP7wu D6Z2VjM/wqOkCYS7399tBooO7d/dz4kJoTty24TSypcU28XyxJCUMqtySgVG8W+9KZxP qZMvE+1HObukgGE6USFMQKnkVngnHWrlkdSXWC0SK4SkbmA/jbWFt1qdw5ReJuxgq13H Q9uA==
X-Gm-Message-State: APjAAAW7vQBPortJqOpVmiFtBeDxXiYpAkOCAqUddBGb9HghoTuHTiYs eBJMk2hEdsR1pNDAnXQfUJlG4JpS
X-Google-Smtp-Source: APXvYqwdaoN9Vri0gDefvZGN1oi1YWB+yLaBKV1vBl0SnYsWQypw8WQzVGIVy0ysZOt28H92xchkTg==
X-Received: by 2002:a7b:c353:: with SMTP id l19mr1731306wmj.173.1568623332146;  Mon, 16 Sep 2019 01:42:12 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id e6sm10780755wrp.91.2019.09.16.01.42.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 01:42:11 -0700 (PDT)
To: Julian Reschke <julian.reschke@gmx.de>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <0dcd3a1b-f16d-97ee-5ef4-de7e5b9058c8@gmail.com> <ac14cf4c-0dcb-068b-2109-c64b321b7e89@levkowetz.com> <3d869d0d-32b4-f147-b0f7-9965a155baf8@gmx.de>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <3f5a2907-5412-888c-c950-04463f0e5ec2@gmail.com>
Date: Mon, 16 Sep 2019 10:42:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <3d869d0d-32b4-f147-b0f7-9965a155baf8@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/3q1IaNVxOY2UgyoyXjYf3pE1y78>
Subject: Re: [xml2rfc] [xml] should render?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:42:16 -0000

On 2019-09-16 10:17, Julian Reschke wrote:
> On 16.09.2019 10:05, Henrik Levkowetz wrote:
>>
>> On 2019-09-16 09:07, Anders Rundgren wrote:
>>> When i click [xml]
>>> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-09
>>> I get (when using Chrome but not strangely not when using Firefox):
>>> ERROR: /rfc/front/date/@month missing (and XSLT processor cannot compute the system date)
>>>
>>> IMO, [xml] should provide the XML "as is" for people with interests in checking or "borrowing" and not try to render.
>>> The "tool tip" also says: 'XML source for this document'
>>
>> You're very swift with very definitive statements.
>>
>> Here, what's happening is that the server is serving you XML "as is".  Your
>> browser is then applying the XSLT stylesheet you have specified in your
>> submitted XML.  Don't blame the server for that.
> 
> Right.
> 
> This is a shortcoming of Chrome; see
> <https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#xslt.engines.browser>
> and <https://bugs.webkit.org/show_bug.cgi?id=4079> (reported 2005, still
> marked as "new").

Well, I couldn't really know that.

Don't take it wrong, but I believe that indicates what Google thinks of XSLT.
It is not a problem though, I just pushed every button to see where it took me :-)

Thanx,
Anders

> 
> Best regards, Julian
> 


From nobody Mon Sep 16 01:50:47 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C36C120827 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2Q7l4C6kk7on for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:50:43 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 8F86512002E for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:50:43 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id 5so3281275wmg.0 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:50:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=V8McI/wbokSQ5FcDcAJC2QyADfmEZcV90bV71q+5KoA=; b=nT/mEX3MR026BX9DPG4jwf+UK5BBJaZnxB5fjowMT6nkRmXe+///EEg+uVIMNyfAY3 VnAuU7Tfq8sXEmizpDk7tB2yqyFGzI6awtunsvzF4FzCtU4xBojocx4pYCTdXPX5Zkdr v2bU05vykMQhCeui8DTT7jnFOCiZzIQ8e/9UYh/orpGoDH27W9Xm2frrvZfT10vwc3B6 cWgE42TcNM1/+N26uayHVqW3V8VCIYh3MJ2ApAkpKVYUnFrC1qXgizH+lnr5HPzjGbyG OHQ4zpzBVOuep0bm60ivwNHEsCF6KLGMPSOukjUg2B9E+6WIXRBzKSx1PjQsZgn40u5I 0O3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V8McI/wbokSQ5FcDcAJC2QyADfmEZcV90bV71q+5KoA=; b=QdLTvMQ2G1Ohr5D9Qotm0AcskrJO5LpHkkAWIOhipoZiIu4k/kjb/ZG9MqvbzJXlb2 ofLZr5DYB0q42AZ1DEZ40oJVOCfI2eWXd9whm+7DasC6dH7G5tYmqvCQ9W8l3vdJYbsp bPVRgwWCy2Su44hISwcdMXN3zl06lLd6zmmZfA1/hY03NG6yMWcxIzj1eSn21kPXQGLp zW/T2OMO4130V78qXXyYL1HSSxt57wk7ZS4uYR3+D3aD86VKrbDRkM6vWHgztBDapx0H ZFdg0aa7sp8W1NVshgKJai5TzZx4xij2ry1qrZJU1LFlKYxTONBbpJZnGsMK/qP7Hm3z ZTuA==
X-Gm-Message-State: APjAAAURP4qUenqbBFuefSGU4XvMezJQAm9cGePIn21tvsuUltzDMohs 677Dw/NbHmxflQ+nKpJRJdFXlOxI
X-Google-Smtp-Source: APXvYqzMzs77Qx4/JG3t0GhaRVWKwbI5AWKQn+9mnoaldbILADD9xuPjIvEmPg8SGHnsC0zli/HU6g==
X-Received: by 2002:a7b:c182:: with SMTP id y2mr4201323wmi.156.1568623841698;  Mon, 16 Sep 2019 01:50:41 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id h63sm3374867wmf.15.2019.09.16.01.50.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 01:50:41 -0700 (PDT)
To: Julian Reschke <julian.reschke@gmx.de>, xml2rfc@ietf.org
References: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com> <0f2a8198-7596-fb51-c582-dfb0bbb62441@gmx.de>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <e1404283-720a-4739-ce12-77881f47fb5c@gmail.com>
Date: Mon, 16 Sep 2019 10:50:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <0f2a8198-7596-fb51-c582-dfb0bbb62441@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/yiVzRYWWUtWJuE41YizmktCgrds>
Subject: Re: [xml2rfc] ID Nits incompatible with submission version of ID Nits
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:50:45 -0000

On 2019-09-16 10:36, Julian Reschke wrote:
> On 16.09.2019 08:19, Anders Rundgren wrote:
>> ...
>> There are no missing references.  Apparently, a SHOULD is missing in:
>> https://tools.ietf.org/html/rfc7991#section-2.42
>> ...
> 
> Could you please elaborate...?

Henrik provided that in a previous mail.

It is nit-picking but it was non-obvious for me as non-experienced RFC author.
Or is it rather idnits that is nit-picking? :-)

Regards
Anders

> 
> Best regards, Julian
> 


From nobody Mon Sep 16 01:53:16 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1511D120826 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:53:15 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iu3SX-pokP4 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 01:53:12 -0700 (PDT)
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 D34D712002E for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 01:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568623974; bh=jB3I8yfeiJk8LBltTgxScTMCeb50o5zhajyHbWLbhzI=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=dOShfvr3mkCZvd4J/U5HXbjgrqvsHTCe5PznDfiE8NkC2ZAuPCaVgO8kNfdFHzq8g w/tvB+VhPrb6JfyPATk8+WhNqdMVGW+vos2Uv3M6aorn99TIu/o8n8uXINahz+1YNO jLdKMpb2ZHPhTjRNcD85BLtRhLtMccHpHd2x/tts=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.141.216]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M5HZD-1iIvyz2Z5j-00zYTc; Mon, 16 Sep 2019 10:52:54 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc@ietf.org
References: <0dcd3a1b-f16d-97ee-5ef4-de7e5b9058c8@gmail.com> <ac14cf4c-0dcb-068b-2109-c64b321b7e89@levkowetz.com> <3d869d0d-32b4-f147-b0f7-9965a155baf8@gmx.de> <3f5a2907-5412-888c-c950-04463f0e5ec2@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <6caa3884-3646-af6b-d383-bea45ff226f7@gmx.de>
Date: Mon, 16 Sep 2019 10:52:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <3f5a2907-5412-888c-c950-04463f0e5ec2@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:jI0q6TbB5N68Yyh+8oU/Jru6yLBwTGNUc1/BkiECoSPktQRLXZX Lh7kYssfLaSLzeJrirPG95Rw2ZNMsufBhSTYzy/L1nVl1F6NWxV3p8/8FJFCnqA1j4fvKRE K7v3R11BxKB9rIP1Lsyi2DUf0sRBwMSeDVOduVzeVs+yR61KrtZnrbtlxXnZnd1qHMJ5gVA vQqn8UAJGklImGWfy/TFQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:CgV8iY0eQsY=:H872BSi5KpGU9GIfiK2aak IjqydI5LVu6RtAp6blRv4HPRg+d7hqMCImo6Oi8BIZuzsSzdMTUzfUoEAlo00yGQK/7m8/tB1 W2h8YecxN3QXJW/Z5WJT7zP86HmbIU/WkhwebKR+pNzT/KbJ9TSMNTMza789VKyz67j8Xmmbq 5T2d/Vcc/r4tRpZwImKI1o/TWBm5qXnBdzOXw55T14GHFEwNevbdRIPNwaSzNXqmvNGrF6MWG eb1UOkyPi6bgZpT5XfzEVdN9xHG2lr3s37cmoIWZEHysdHXBPQilg7pEgAWkRCJIp2eCTPNCi e/x9HmZufxU040cNV7Drh4x7E10tTsi5/CTSlifNRtfCOeVGDR2xdVnOZAy5oDH60LGlrCzj9 sWvLbOxw1Cw3jc3fwOgmnXMBc7qaO8oaklgBI3dxcgaIMNN5XCcRJsD02NxSnbIrMIyuDj5Fi WXyU5JOPaxDCa7+EiBR3cUL3au1M5gZFm7SpC+mx20AZJtVP5aw2FmXbZhuE25PFrKkjTbM3j /JLH0YbsmCRsEDYU0w8sxPnjx/E4+dseaPnUrxaUZ+GPW1Fjq5EXaV/MCJIjleV3LYq6bLGF8 lWSr4p1r8082Ad0vkO8r50ZTxlXCkSYzsNQY/1RfRqO9fWdKr5QSiUcBaVRMgdby04m5QStFN WlKwCPk8U8TjzE98Qx4eObGON9QwQoJ9kSjkilEYMb1rhzgpWVn/TYo7PZk3sfl5PmoOmMB4V l1C7KR2ggVLaxSn5VzQZZzfuflRsyEoh010sj7FWw4v0mEpU9yaFTeXBcjL5FFG3HLvhuh2XW k7pnxtgslO9pGRPPiH9O2V9fnQYCjA5fzA6I+pKHS2NMPjFPPPSs9B5ei/a/+aHm9s0QMROE1 vpfzUzzLrccj1SKjtEp1AH5yrEq+MVA6QG2kewSSlS8tVmUn5E9pjTLFbHM3znOXorZGsDHJb 4sU7ELhLVDNX61mEGQc9MLuxJzclDrRQ6IsPlZYanzo/UESW8Bzo4Ro/Jy/YPII05K3orbdqv IAHReUs4+urtspJ7TVkghkjnKMWS6U6pxpWLEIuFzE/dZN5gGUAEtSB2h5toPw9XMIgsaK+zV xSTcwJsVAq2NwTl3SKDkuCxL7xyfHHqnwywF4yniBqfVVtxC6K1a7494xwl9Laf45kSeVT59q f0fecuCasd6+wk3Qx30FVkFu6KB60SCv8bkh10U+7iFi6AYeyFMcslPjQ/KQx0loXydnKtuY6 QaEH0KyhAfHV2TXfj0WVzjN120XUbwoQQha/RG+xTkm3mx4CXHDepcVTXYpo=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/0Vh6OLw5Qnl3PKOuJ7D_PY2Auak>
Subject: Re: [xml2rfc] [xml] should render?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:53:15 -0000

On 16.09.2019 10:42, Anders Rundgren wrote:
> ...
>> Right.
>>
>> This is a shortcoming of Chrome; see
>> <https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#xslt.en=
gines.browser>
>>
>> and <https://bugs.webkit.org/show_bug.cgi?id=3D4079> (reported 2005, st=
ill
>> marked as "new").
>
> Well, I couldn't really know that.
>
> Don't take it wrong, but I believe that indicates what Google thinks of
> XSLT.

Actually, XML (in the browser) in general...

> ...

Best regards, Julian


From nobody Mon Sep 16 02:47:02 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB06120810 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 02:47:00 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fog-lM78Noq for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 02:46:57 -0700 (PDT)
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 C17DF120019 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 02:46:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568627209; bh=P4+EGcV5HJumwGTeK6NoqxyNNaljGBJPDrvRAZhGOho=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=fg6n1pHHhbwbVkzRtjbXg7E+7MByqjkJM1LWiMh2pqsOxmxgsIVVASHfMlv+hzpDX Q5f8TgxyEDlB4wyaxUt6/G4mAjmNPhj+76Q2QOfMakjF+xZ8eZiF1RssmJxm2hJ7C6 KN7eyjtkZdvP6v49AFLGrU5L/4jD7Fq/SvUDB0rU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.34] ([5.10.171.186]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LqQTl-1ieRaK3LYP-00e8Pr; Mon, 16 Sep 2019 11:46:49 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com> <0f2a8198-7596-fb51-c582-dfb0bbb62441@gmx.de> <e1404283-720a-4739-ce12-77881f47fb5c@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <e37e0a8b-9258-1706-6085-d42434be16c7@gmx.de>
Date: Mon, 16 Sep 2019 11:46:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <e1404283-720a-4739-ce12-77881f47fb5c@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:T8xw4h0kYxw53QIpS6uKmD9WbkFwVCaNLoIjMKwITcLWscB8BjH vvQV/IBF9YevGFO9veA2nxSAUwgr74RK+xwt0k/JBf+k6XmfxNu5DkY1WR70HtXYKQ911tr phg0ZdwE8m2ljaIW+YTzm2BhxLu+Didg7IlpU6KB2i5m6rcIrzPFHAKHyUzRVwCYU3Xs4qc 7dqq559W/C/NeSfUS7mMg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:97QZXtbvwPE=:anUulhbWK0fyNVWJ9117jf /0gjboQs7LdBsk7u3MgCaYvrDB0+6aEwzmCMv9uW0ozd0PrQp0CE5rRBsuRyg6OAGSdKQp80u goQVcugRU8qliojbNXVpFjD3nR9F3nfLbkTNCiv25ICCIM9vHUoz7s+5qB9NyEpBshEj/SNbv UaaU2iHdLgNgH89LC0G8xKw0nzY/VqOj5EbMZdiAns3iZqrSxVFx8X/agXdGBeZ+pFAWW9/qt yE6dyyfzNTQ4sfD02Ssy88DeAhv5+v9H3k7saFKIuCa9EczYYZNR4YwKdJEaQTF4rbDHiJdJB rMY2vBCOJRLsWcffw4tbpykoJIULDXI7qTWN7RYUG4TmF4W9RCjRcfS+wPjSNsOd8uBhRuzq7 A6AN1b+fdxjzD+LzZTXdeXmzsT7wMlpgc9pgHJIT/ovOZ1woC0eVkfNpHrkrDVlGlF/q1/O79 LJCXBAgTWpyr8LZpQobAg74i5+Hz5TQkj8U3r1LEfFkx7rrDxCArrkYpYaQ0rw3ko2XQfYMOD qEz8O6Q+14FbyNorE80Aa4fsfV1sSlYAmvG5BwAWjRSD64HXnoFGl3UWlkYh0aKkSJzc2eJTJ tP1DC/ZRyC3UfUpGoWoQCoq7lIPwoF5qee71TpcILzF1bqqk2XhJH+aE36TnDMFcm0u78AuhB 2vnOzJ644C9IP3xQ70KgKRK/PHBxg73Xc2mP0Oc1wjPDj9t98gISsN1qbiw3VTTtqowtIrchj rtGgAp/lk4VJZtqqXgzctMeUDz8LH3Wy0sKHe5NhaJs8i/kReThpiGu0eRb5gIKvHoxF8a9jw R58593gcw0p7NySFFD4Kd0g+TxzdPrN503RzbgyeUYGrKBouzwgJU/PaowHqwMWJpq3CeRbUz G5jXYJGQNayCTclrp7bJUK4XrhALLyOAHyDNgxV9JW+Se4W3OEE8cG2WpRq6MUcVbOIaChQDi hg2dyVzup9YO2Yz/t2Uf4p553hPw7mEBKH4Qd1GMHOqaH0e155vJWlQB6uVjxYmoS/8x0PNdR 8LMAxMNGBgO7+4wQ6oM100YwpbdS2AxElSlnOXRrOtsMppg54v4nW+dKntcqCJiM31UWFkKa+ 4mSLa9vRhXex0uaLUnb0BENpAlV1Ra/2f/QqiEpsUB9oz1YxuhFhuf+59Pbo5aWu3iYfIsDLD 6vF3ucJ0DEqMdt/cfcS/BFXJTCQKFuVAzo8MC+dK19kdd9qH2UpB1ySY9dYiuhGl73hI+OnmZ 5EoKgyszLoBt1smgybNRFeZzSZU30jGXVJpeBWDlHDTmIr0B7wZj2e8rdLDI=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/1kHomZNCFZpZXmKI3knXPTrZeW4>
Subject: Re: [xml2rfc] ID Nits incompatible with submission version of ID Nits
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 09:47:01 -0000

On 16.09.2019 10:50, Anders Rundgren wrote:
> On 2019-09-16 10:36, Julian Reschke wrote:
>> On 16.09.2019 08:19, Anders Rundgren wrote:
>>> ...
>>> There are no missing references.=C2=A0 Apparently, a SHOULD is missing=
 in:
>>> https://tools.ietf.org/html/rfc7991#section-2.42
>>> ...
>>
>> Could you please elaborate...?
>
> Henrik provided that in a previous mail.
>
> It is nit-picking but it was non-obvious for me as non-experienced RFC
> author.
> Or is it rather idnits that is nit-picking? :-)

RFC 7991 defines the vocabulary. RFC and ID requirements on the
*contents* (like boilerplate or references) do not belong there.

Best regards, Julian


From nobody Mon Sep 16 03:26:35 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8736120019 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 03:26:26 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1863RZMfVJFR for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 03:26:24 -0700 (PDT)
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 CE87912082E for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 03:26:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568629543; bh=QUiKqTjlLHJKBzMenHSYdtf8Jmk0QQc4TQP8SJW7H6k=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=awUetC/DReMLG6VUq3e0nn/L6Rr5TK0x9hjk5FNdpOybX5VY4ALFcupChzEpKl+oi 7ZlHh5WiMXlwYqMt0QoDGmIfSPjf6yIGlGyGsYKF6nfOjsvEYf9KggCLm/WLbWJLym sUDbBj/PpAkbZGjXC0afxsLXZnJqmTE3/fnOXqRQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.34] ([5.10.171.186]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhCDT-1iU0K82WkZ-00oavh; Mon, 16 Sep 2019 12:25:43 +0200
To: Henrik Levkowetz <henrik@levkowetz.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <c4ebf511-f2bb-36b5-9616-d00d20ffa395@gmail.com> <fe3a8952-3117-8367-ac5f-efb81cb356ba@levkowetz.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <8bc0d5b0-57a1-b71f-5934-18c534a5804d@gmx.de>
Date: Mon, 16 Sep 2019 12:25:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <fe3a8952-3117-8367-ac5f-efb81cb356ba@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:XlUvGi6q3yD81+xZbz7iyVWzbMO/bYawA7QtiD51Mruwmk2Gl8p /ldQO5POO6bVYZuf9LiLj0EFpup4Zsqbc6wKr9RO/d4TxODutpdOwtZSWZC5MYzO4uBnp+e mtKvLXT9qiDhQvtaHnAvo9/FXdlK+HL0VD9KjMF1EXUbfg76Q+qAWiGPRCkzd3V4oUOI92r NgtW1cCCUsk7QWR5o6Zog==
X-UI-Out-Filterresults: notjunk:1;V03:K0:oqp6oUoaHZI=:z/S+gzMLSBDRbdwDsT9Nju hOX552sDS9VXWADAGfujLGb5h7AvmiVtqjdp7653mcFHd7tT5X9K/CcvSglSxTaHOtOPsW0FB Z+opzBmgJ9KmVEz36WdXPslgfOBFlTJbV4BGux76I1qj6MeVuuZxGfpCkAIS33MazQYgH1jYD l3COOQfVxw5Pf1EvkzjOqi97fF8V37lknSVPuWSbV+reo+2czVmLFzgkS7fJHDE5ea4uyKyIV POFuUSDIZ2jdbCFZiR6vVEL3Hw501+ji0zpo97WS1rNfavgipRJiuF/JaN3OCEVO9sLZMzkEi McKFxqkRtTkWxRUUWsKAEPelOO0Av3/QWP8nL1KeKlACAhnAfpbgKLwqAcsy5ar9K9skHYj1Y Mh3uT35duyGgMbpPsC6SDO/gUaFC5D5cU6AknjiMfMbSKRV7sXFzQCAFBKZZNS+jv2Y5WPnwz miM8UZVKBIqcz2wir5T4G0Fg8nRJunDnByFAsoUH7QiaWgZ76h7tjpRYG4NHLMJaGWkO2hrQq xPBhyNiDRowN2kHPF/Kt5fUYFjiuWEYlWrMYQ8+P1Jlr9JywUFIbZPl8fDEyQAcuffKVHC4H4 HtCyrIzmlRwuHuhgAnFxSyIMwm2VIjkmXON56GnC5w6jTSBl8MTHHOJhqmA/fSx0Y0dvYlWrL 3y5uRbyc2R7r+SIGBIC075FzABZsBBPWZ7BmpAnHniqPNLEFShxEKGIDUeFI51d9hV5rpNmOF OHBbPxAnnL713KO1IXXFzhTTMQkW2c66ZBBvg531GZOKFJuTdM5W9o4x97YuKLmaBKZta7tMP 98qMaIc3sg6rHhCAM/E1W0BrqR/Ermu/A72hAhhAEyE/bBICTciJridYyOu7uWsjAriJ6IbLA NAGtdXpBe5D7ndOPqpvYNxiaa+PKnjlVwP8Kd+l0vwCT7/THUAvT9A5xAVzbEJRINYZVfg1ND GBpGatykDxnQZmyMlSbhi3YSYE+uhvM5X4i8ZkfLCXSId9jlHX7QaUunWSK8+h+/KwHa7W3Ap KeiYY/m9uCvjZwFm7fr/Ufk4Eo7cEd+y9Mjn1Qc6SUKf5N+yLjlHPe12MOU6bM1lsZP/8Oe/R qlx4esM3OBaO8sJZMmh6nNUgMRCeBpiuDVXLyD2knP3z9iXX87cAYyCqLeSDnquRkKrfgtJZ4 ZCb1J9zXB2vzKEvmAAUKBiVbKCKRXz2lXMOnGQj8prpkdoxWsIJ/iHZwf2Kj8icx9U5AMVxQB pF8LcxNIAe1ID7gbVr0qrtAs5WCkvFbCr3/PPztlh8TZ5wv3xen1D5Xd2OTg=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/6nb-XzH7XuaArZjAbd-2tS3nbXI>
Subject: Re: [xml2rfc] ID Nits incompatible with submission version of ID Nits
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 10:26:27 -0000

On 16.09.2019 10:34, Henrik Levkowetz wrote:
>
> On 2019-09-16 08:19, Anders Rundgren wrote:
>> When clicking on [Nits] in https://tools.ietf.org/html/draft-rundgren-j=
son-canonicalization-scheme-09
>> I get:
>> https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-run=
dgren-json-canonicalization-scheme-09.txt
>> This version of idnits (2.16.02) produces incorrect/different informati=
on which did not show up when I submitted the I-D in XML V3 using the Web =
tool:
>>
>> "=3D=3D Missing Reference: 'RFC7638' is mentioned on line 495, but not =
defined"
>>
>> There are no missing references.  Apparently, a SHOULD is missing in:
>> https://tools.ietf.org/html/rfc7991#section-2.42
>
> Heh.  Right, you used "Informal References" instead of "Informative Refe=
rences".
> Good one.
> ...

I'd say it's a very misleading warning then.

Best regards, Julian


From nobody Mon Sep 16 07:27:36 2019
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBEE120072 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 07:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 XWTlhUHrbcFf for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 07:27:33 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C0E120090 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 07:27:33 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x8GERVrJ029737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 10:27:32 -0400
To: xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu>
Date: Mon, 16 Sep 2019 10:27:31 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/yFsr22SuZ7Jc2gvFS9fZL3HuIjI>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 14:27:35 -0000

On 9/16/19 1:22 AM, Anders Rundgren wrote:
> On 2019-09-14 11:41, Julian Reschke wrote:
> <snip>
>>
>> RfcMarkup has no official standing (and yes, I like it as well, and it
>> has served us well for a very long time). It apparently generates XHTML,
>> but the content is served as text/html on tools.ietf.org. It might be
>> good to change it to produce valid HTML5.
> 
> This in interesting and but also rather confusing since this is the by 
> far most used method for communicating RFCs by developers.

Do you have any data to backup this claim?

	Thanks,
	Paul


From nobody Mon Sep 16 07:46:08 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F30120118 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 07:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AjfAP-Y8ry1O for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 07:46:04 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 7476C120113 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 07:46:04 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id r195so101284wme.2 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 07:46:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ASQOG2DEhPrqKBQcW1nKrjkSvesCGfLwrUpX6j2rt6Q=; b=qFw+ZmascjII+isUB9WxCVofAR7jUqjZ2KLW2E4Pk/gKcozIG4a/m7MXwG0DDB0VT8 aa7mGCzzwPPAgtwkHSQU0PDDL9WE0vQG+8L0rbwvl3vqc93sgIHf36wqu6OsuA8TnTK2 S9cjOvAEcHTVgFKgdrx0AOEZkuUnryAgcIXlcQbFtX48rXwib7mBeptE4lhL5Z7HFMYo 42K/2LOU8W8/SFTWkPNYXD80zqW8fuYt0aM9pcdQ0ekcwFnCIdFTUpV7R1maZTTxC/V5 Ak6fUugS11G2IZ+9oPNAqNT2wPYMOwyncP8U7ej28ajsIPCW9kBNjLLz/sn8h0X4IAyf Grcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ASQOG2DEhPrqKBQcW1nKrjkSvesCGfLwrUpX6j2rt6Q=; b=hxyMfdP9T4ZbDG+etkKT5VsPr34lQvBBnipJHaSP0L8ZKYuyuJpCnCLBJQcV288bVU h/8lGkckxgXtJGdzR3E35q5OzD5Ml1ppz1fM53BiXGEA6Nf1EqlHwOauFqpl5qDJPAmG m4AkIcLC8MSAsqDXLdlR6Xjr/gQQOKlKpKWspYLl6epFYibzYq1uw7RiTmE3L4R8DmFw IyAuISZWSF9SgfF478LEnPPBsoCO0AdRHRRod8JmA8bDGiyj7JQo7TwOuxYwF7gctII7 4duemfnLEp3M9JfXFu/t60GMJG9V04FSm6wc9ZPBLdgLEg3z3yzFLKsL3LzjcXz2xIbY kc1g==
X-Gm-Message-State: APjAAAXhiWeHHBDroZKgpNOi7B8TXkzQcVHu63HTs6CVHrNpME2TOS04 +AAjdgyk5sEpj3+NPmiAMY3ZIFSn
X-Google-Smtp-Source: APXvYqxurwFPyCctpS7rh1ha/UTbOnb3iXaJVfG8rFDAgYewCLr3IhoOIYHCxEd6ZNI4RrUitfHEww==
X-Received: by 2002:a1c:23d7:: with SMTP id j206mr41925wmj.57.1568645162640; Mon, 16 Sep 2019 07:46:02 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id y12sm27901611wrn.74.2019.09.16.07.46.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 07:46:01 -0700 (PDT)
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com>
Date: Mon, 16 Sep 2019 16:46:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/vpmVtMPdBpWoDEJ-8kRsbNLfUos>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 14:46:07 -0000

On 2019-09-16 16:27, Paul Kyzivat wrote:
> On 9/16/19 1:22 AM, Anders Rundgren wrote:
>> On 2019-09-14 11:41, Julian Reschke wrote:
>> <snip>
>>>
>>> RfcMarkup has no official standing (and yes, I like it as well, and it
>>> has served us well for a very long time). It apparently generates XHTML,
>>> but the content is served as text/html on tools.ietf.org. It might be
>>> good to change it to produce valid HTML5.
>>
>> This in interesting and but also rather confusing since this is the by
>> far most used method for communicating RFCs by developers.
> 
> Do you have any data to backup this claim?

No, OTOH, since I mostly work with JSON-based stuff, the documents are fairly recent.

What I'm sure that I have newer seen in wild are references to PDF RFCs (which apparently are in plain text).

Thanx,
Anders

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


From nobody Mon Sep 16 07:54:12 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B031312084D for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 07:54:09 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjsEOiwMyYE5 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 07:54:07 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C7B12083D for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 07:54:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568645641; bh=IOGeNAaHe7QMY1ia2GWJSJLK250Ig8XyBpQNacEVKD0=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=bUpw4Hnrsl+Cs6d/NNtLjc03oPLDnJ3S4f0JC8ULyjI0AycGxvOx1r5y7KpHpwW1/ p9srOCS5JFJ1QtNM3QvlKJE42ZT+7pVA24cDzTp/ETz2P890ZhazsbIl9wktHqM2yL vmbff0HySKdesNdrlKuhXB5itBFVgKm97VOu4crU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.34] ([5.10.171.186]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MRoyH-1hh30S1heL-00SvRo; Mon, 16 Sep 2019 16:54:01 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu> <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <dcf93ec6-bb2c-3323-a98d-41c9bcdc4e8d@gmx.de>
Date: Mon, 16 Sep 2019 16:54:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:OVTfRz1WsML+vORrhj3HCOzW+gzbS1zs3Rk0fU2JVazZffkMrqF 0jGr5zganUldSTms2ktjecsBh3njEC8LHAfWLTofu17SDIa6GJbZPaH8MgdE8RnCedvpe60 wvXn6oPEaZkDYDni0PA35bL22iuZvVPkiYdxqKJ7UtOw/gC4jELlGljR2xTNSK5b7mSFPIZ qdKHCu2WV6Abh54jCSyqg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:fflbATCggsM=:3nm8u3gRRTEc9+MS3Li4jK RpoycEaSnmb6ZVi2eDRsOg2ztVhTC1ICBOZEtzX7t+IIgljGxcTsKJddcXMkSCdlO0jGRjKzh 1n6CG6lWRO0pSOotRcXiDZWlIIccedo5hKBRk8JtOVz5gsDELrzzn3g+ZOc6qK582l36rdmW/ /Sf4dyvl+DYyNSo+e8ORW68nHQjJ4hXB+TK/HsSX6BMMK1pbGpdAVknShd7ia63yc/krgks9h d0ROSo+o7Jeokb9ac2kDGCo0e5RV/+/6CFCfjg61V4BnMz7nA8gqWEuEmPEXYKj5K1+dCU0cF u6xOatcJT1F7289tcGquFwOtRs5il0ZjBMTdDmQSDkKPuWu2UihoAkBR7rYXIjKcLMD+JCshw JFaD4jl2O/Wcta5TIC7R0qK69+FB7ByXVxUdoT8IAVRXqxLECe5KGkK0rRtVKi5nZN7Wp1BVc 56dbYhoePVA0O+Xu7X7m0rHBs742Eb+t2Ztm4PtuEFb5ZxZllfXmMhVFu9Phef6mA6+Qnl/Uk iXGyFq7Ehydq+a8UoFghxnTemVQqBVVdU7/+2cInUiWle1oFH0cvjRfV8MDMPVZO59ORabjJr j/OfOO3sHJhCr+87ifBDZQaNXyZ2dkvQyiKdgwJVnx9OWftEJu8jT0xFnlTCl2Q8wZCr3sIGl /VIIwXHWfwshYVU4hrte9EiPsa/U7gVd2QgNmSd1Z0rKC0BHy3s5sqHTgz9BRcCVnnlEWBVL4 Uzekza4KlHK0Zbq4Hn8sCJprvyFIbjvMRDh/8NF6ApIk2JM92f3O4C1gPkP7jaKoxDFlGiJx5 dajhPX0M4g2NZ6kribZHp+zzmWmcW8CXcIb4sMkyAmBtfJQ7KNpqB3MzbvYlfaVudkCdXIC1G AhMGh1YaSSZBKxghpxiTrxlkozXZa/FA26tXpCbyTV8q+hWSnAd9uZ9vSFODSGfduCyBhaD4F dLOljWu7xVbXv2UacBCBfjgq8QKy037OhCs/CbfLMPW/FWbpILHLAwzj63nW200i0QmT8QtCx o3lHsGcW8YBC4dpvoGzjNiHqbS+6xfY6meEs6c3b4dX3WfOuSp9Mx3MHO98R9E4KRoJkKFew/ 6mT4oIJqeazoS6sfwyEkxvxL6fV6D8BbiC7ShR9rKO2MvP6rqGLKqmhIQbW174XLdLHUGZhNO w/88H31/xUNONvNEZtp7grmCR++sQ/NUiDm7QLRr/Kd2qL1xG+Q8ORieT7GoaJyD8wW/NawgJ jnRMzoltWEthZISETajuWEzoda/ByWZiBlA8wLoCqEX9QddNx6T1KqmW73eM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/OIfW7PQyzf96-P1XUYLDvDtyNxU>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 14:54:10 -0000

On 16.09.2019 16:46, Anders Rundgren wrote:
> On 2019-09-16 16:27, Paul Kyzivat wrote:
>> On 9/16/19 1:22 AM, Anders Rundgren wrote:
>>> On 2019-09-14 11:41, Julian Reschke wrote:
>>> <snip>
>>>>
>>>> RfcMarkup has no official standing (and yes, I like it as well, and i=
t
>>>> has served us well for a very long time). It apparently generates
>>>> XHTML,
>>>> but the content is served as text/html on tools.ietf.org. It might be
>>>> good to change it to produce valid HTML5.
>>>
>>> This in interesting and but also rather confusing since this is the by
>>> far most used method for communicating RFCs by developers.
>>
>> Do you have any data to backup this claim?
>
> No, OTOH, since I mostly work with JSON-based stuff, the documents are
> fairly recent.
>
> What I'm sure that I have newer seen in wild are references to PDF RFCs
> (which apparently are in plain text).
> ...

I agree with that, but I don't see how that supports the statement about
RfcMarkup... (it may well be true, but RfcMarkup is something that was
created because we did not have "official" HTML renderings of the
documents, and this is going to change soon anyway).

Best regards, Julian


From nobody Mon Sep 16 08:32:54 2019
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F8612012A for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 08:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 CvV4S0czS8-B for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 08:32:50 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978DF120122 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 08:32:50 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x8GFWljC001876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Sep 2019 11:32:48 -0400
To: Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu> <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu>
Date: Mon, 16 Sep 2019 11:32:47 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/XBl9u-7f_Rx0zQfSybu9oecNVP8>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 15:32:53 -0000

On 9/16/19 10:46 AM, Anders Rundgren wrote:
> On 2019-09-16 16:27, Paul Kyzivat wrote:
>> On 9/16/19 1:22 AM, Anders Rundgren wrote:
>>> On 2019-09-14 11:41, Julian Reschke wrote:
>>> <snip>
>>>>
>>>> RfcMarkup has no official standing (and yes, I like it as well, and it
>>>> has served us well for a very long time). It apparently generates 
>>>> XHTML,
>>>> but the content is served as text/html on tools.ietf.org. It might be
>>>> good to change it to produce valid HTML5.
>>>
>>> This in interesting and but also rather confusing since this is the by
>>> far most used method for communicating RFCs by developers.
>>
>> Do you have any data to backup this claim?
> 
> No, OTOH, since I mostly work with JSON-based stuff, the documents are 
> fairly recent.

I don't recall every having seen a reference to an RfcMarkup.

> What I'm sure that I have newer seen in wild are references to PDF RFCs 

Nor have I.

The most common references I see are to either the "HTMLized" form, the 
plain text, or the datatracker page.

Personally I much prefer to work with the HTMLized form. It gives easy 
ability to jump around in the document, the extra info in the header 
including links to related tools, etc. and yet the text is almost 
identical to the plain text form which makes it easy to jump back and 
forth between a diff and the full document. It is also convenient to cut 
and paste bits of the document into email. I much prefer this format to 
the HTML format generated directly from xml.

When a new version of a document is published, I first pull up the 
HTMLized format. Then from there I follow the link to open a diff in 
another tab. That way I can skim the changes and easily refer back to 
the full document when I need more context.

I hope that the HTMLized format will continue to be available. It could 
however be directly generated from the XML rather than from the 
plaintext. Generating it from the plaintext sometimes results in defects 
regarding references.

	Thanks,
	Paul


From nobody Mon Sep 16 08:34:05 2019
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCDE12012A for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 08:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fNeCmZZlnXYV for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 08:34:00 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 01E64120122 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 08:34:00 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id r5so5415905wrm.12 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 08:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=YktYnW4eVhSs8sBOGgDI6HmwuHYOkmRAmhgwzrye7Ng=; b=e+GLQwxaa5N8Xr5srGvGd+iLOyM45RgEGDusSVghdRI2gUbFB1umagSEkVWzUTCJxE 8YA2BncOdM9abC0b2gc6elSmLxeyJx/fqYpCilz1yo4gyeb6ZwyIuxoYe49ulYjP4YgQ /6kKLUN5T4ItvLE0IfADow+9C1GMwCjZCtuxrgHh2x9p9nLXRE8KYIZHa7lHAAHtg3Sg vr2jwAosIKH5fa2r66+QyCI08lv244YLbyvuo2/cK+c9RxKc9Yc6W8ehu6DKLHjYlR9P CiT7OxLr/kSYRulb8fnANcJzz9ObRCTwOHrqwbaVxig0vzSxF2rQ2dc6KWcQELj1Knwk tMHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YktYnW4eVhSs8sBOGgDI6HmwuHYOkmRAmhgwzrye7Ng=; b=I3xAwT/mmXLmBCYuluBSbJtkvmKvrV4GRTagX2vO4CxbZzSDwy4dh78tVPAEuo0eOA 3mvarWDHk0dmpFguN41+sli+OtEPI5DTsvsAmyz0DBlsrMpEFwcWhZq2Mn3OZrBQE+MW ewYdA/sGxqQmjNr7S91wNl6TdlGMNBMYH4aDESeYvzLn7PgjXXDe+Z8Ht70sgj2+RIJI txcQdOdFvsFi5o0lnoxo7sLT9QiXMoFyXhLspNoJQcXPrOOXWyxI+Ch9aQfefOxMJjBH GjV6NqQReymFeh1jPzKBuyYYUb36RML14/q8WdtBfiMsM9VQP5ZWgDa1+TD/oP4SgdIs UEWg==
X-Gm-Message-State: APjAAAWDg4K7UCBHOUGP9Cb8hyDGIF7s9FUh0PZPOibqUmj+TC+yZsXW ywBiizhCF886xRRB7OrLpc0shdLR
X-Google-Smtp-Source: APXvYqzuPrDNczxN5FuWWcXl0DXbJ+gcaiQp3tld/l/qHzxnncX9Kl7gjIdoXJLeVQ5TGi3zjr6F8Q==
X-Received: by 2002:adf:dd41:: with SMTP id u1mr315065wrm.49.1568648038111; Mon, 16 Sep 2019 08:33:58 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id f24sm197178wmb.16.2019.09.16.08.33.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 08:33:57 -0700 (PDT)
To: Julian Reschke <julian.reschke@gmx.de>, Paul Kyzivat <pkyzivat@alum.mit.edu>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu> <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com> <dcf93ec6-bb2c-3323-a98d-41c9bcdc4e8d@gmx.de>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <f9fad0ca-bfdb-33a3-411e-c411608ae96f@gmail.com>
Date: Mon, 16 Sep 2019 17:33:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <dcf93ec6-bb2c-3323-a98d-41c9bcdc4e8d@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/qcuVZ8y7aVbZez32k5rl5vSYG4Q>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 15:34:03 -0000

On 2019-09-16 16:54, Julian Reschke wrote:
> On 16.09.2019 16:46, Anders Rundgren wrote:
>> On 2019-09-16 16:27, Paul Kyzivat wrote:
>>> On 9/16/19 1:22 AM, Anders Rundgren wrote:
>>>> On 2019-09-14 11:41, Julian Reschke wrote:
>>>> <snip>
>>>>>
>>>>> RfcMarkup has no official standing (and yes, I like it as well, and it
>>>>> has served us well for a very long time). It apparently generates
>>>>> XHTML,
>>>>> but the content is served as text/html on tools.ietf.org. It might be
>>>>> good to change it to produce valid HTML5.
>>>>
>>>> This in interesting and but also rather confusing since this is the by
>>>> far most used method for communicating RFCs by developers.
>>>
>>> Do you have any data to backup this claim?
>>
>> No, OTOH, since I mostly work with JSON-based stuff, the documents are
>> fairly recent.
>>
>> What I'm sure that I have newer seen in wild are references to PDF RFCs
>> (which apparently are in plain text).
>> ...
> 
> I agree with that, but I don't see how that supports the statement about
> RfcMarkup... (it may well be true, but RfcMarkup is something that was
> created because we did not have "official" HTML renderings of the
> documents, and this is going to change soon anyway).

I don't think the motives for using HTML has been very strong.
Is there actually a single RFC out there using SVG and Unicode?

Anyway, I surely look forward to HTML!

Lists currently look a bit "crammed" in my opinion:
https://tools.ietf.org/id/draft-rundgren-signed-http-requests-00.html

Anders

> 
> Best regards, Julian
> 


From nobody Mon Sep 16 08:43:40 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3369712081D for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 08:43:39 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG2K-v-qJo2i for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 08:43:36 -0700 (PDT)
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 EDDC512012A for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 08:43:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568648608; bh=Hrk8WK240/ZwiQZ6iAYkegp4FHBW1SmMbN5bgEv7g+E=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=JA9F9SY94GJ6Jl4DZ8+CZ237l00yhVtYwqlKgUpiaK3XLUTQjQBPiJyLucE4cgG2e RDSCwh4QYW4NeV2YoxfQIgNimafiIAG//MwzbBcx/fO5IVE7aac1bOx33mW/neKQUy IgJULkIWjE50Btj7cJoArKdciA++sBt2i2F3jB98=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([93.203.231.165]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lf0M7-1iRaz12b55-00qmgU; Mon, 16 Sep 2019 17:43:28 +0200
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu> <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com> <dcf93ec6-bb2c-3323-a98d-41c9bcdc4e8d@gmx.de> <f9fad0ca-bfdb-33a3-411e-c411608ae96f@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <dde6f0eb-36b7-c1a8-2062-9309ebaa68a3@gmx.de>
Date: Mon, 16 Sep 2019 17:43:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <f9fad0ca-bfdb-33a3-411e-c411608ae96f@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:yILDXPtso1sRbuJ+QdfA5QbhYnn+jM29FvwQPvdYHUhEsHmmALw cJdquXNRD0kVpQ3Uu2blpbQ2aZpOEda44z/ne5XehvxH9bBnAQUuDKGqdsxss4ACL52Rlbd Jf+QVg5SuScceGQEigLD4skBjejL9MSIRLuQm8qS4erZn/DO9ZY69TYMAWY06tw8BHFezJC sYcaBPn6ViokzvhvOtO5A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:dCDg4Ovo4tE=:excK6aGFVHbtCUfnK3TUD5 XRz93XpV8UMw+XeTnIKJgc90d0KgjYdLDaT0Zxy/aqCEYlm4TcoZBskdWZYc+OE70Y+q9haLG yHT/lw5S/UgA50bYJrUpQg6k4eK3JCAYVZfoP9EXEYBg38pP3f/cA0vuIR9ARjAmsMHtJIlb2 scxG84pwgUH5wnVSholzfpMEZP9DRVufRuzOLCBvdZ9k+5AObHavZiGQW0baubli5XlBSubXn aeFwxhE7joFTBx9AsRHoETvaibxZfFrkn0UN/iZYvOJ28KYOxxZsBgQROiUE2bJ5H9iT8yXUo dNk6RTo7/VFjSsOU0Y3D4T8zcd5Bj1TJQogu8sue0aNimyq0Cj06M7AOz6JEJcgyJa3xqPvaK arncTMVeV0MKJoUa1Qhl04EFV03JHvrQW4mBlPxqp40Lufgh6/oucDln/Y8XXlQ9U13la26Vv WOogOu1Fgw9srZ1TLBTWfLhCUoPm7qQMzb0Uulc2CI8bdy1AGJCepXWZMS1CQtBe6rJfYXtY5 dEufYO/6HeA9uQnlouJDZ+XGGszD3vkWCGpc6rIRUIQMcjspC9tpwqyb8EKc4rWwxG/cMp0gs 5c2v1fAkmJHd5d5AZG4sQ1rHwcdEtHfBYNcAEJ6KyNhs5gKyUlTDTpFzDYk4NsUpTD36DJrVF 8ncqtZpMfPTTaYShM68Jwc16X8AytIYrFJgnq7ZcgUMyy907aJPyCE0Wm0lDvLVR5CWjnCCbL XYyaqRwsUAWzz1GQr+gpd/Y2t90t31aw5nuSvdAQzZ+a8EYNabVYX+bqOYTgonCMfqhq6vFb0 dgilbvjdLK8jjl1p3duyyl78iJQ1q1U6bGmzBli83gjVkZL2qYwh7/GId19qKMnCv5Aoak1dK aAJnydyy9xTNn8o3+lZnuKwemWO/oMEK0Ao0HHhrZIHkU2PVP+1yMhgAUwHPt5kYULoj6jqBP K8LCUZwOYmPD5RPg/e38nBx7tor5cQNvudmcqHha7zxcMb2YaGPIbH92ZvASWJhkObk86i2cq 9suAuUZCVLwE27yhKy9ohsQ8RqkAiOrD0B9ork7X78L4cQJ6XkIzBqZXOyGSlOHtJrFTQL+Mt 9aKnqfDuta5S1tmRvSHyfYS5++ZypBoGpqlMFOrUq0p4FWvSFCiOWSOibCISAed4Q3X529Ck6 vhxAPOFeFmEIQBrd3FVSgIfCsCRIuRF5ComD8Fn9a0g1/ldf4SAOf1Ltlc6FykbqMIsVYXZR1 mOIrijsc0S3Qw/ZXfs43wjalgzQdLA9931phSDyI8H1y9soatk6NVSpqvpWs=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/QINLqj18MV8-hImilP7o7P9XDVM>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 15:43:40 -0000

On 16.09.2019 17:33, Anders Rundgren wrote:
> ...
> I don't think the motives for using HTML has been very strong.
> ...

And you did re-read the epic discussion that lead to this decision?

> ...
> Is there actually a single RFC out there using SVG and Unicode?
> ...

Yes, there is one for non-ASCII, if that's what you're asking. That
said, how is this relevant when in fact it wasn't possible to do so up
until now?

> Anyway, I surely look forward to HTML!
>
> Lists currently look a bit "crammed" in my opinion:
> https://tools.ietf.org/id/draft-rundgren-signed-http-requests-00.html

Looking at the source:

> <meta name=3D"generator" content=3D"xml2rfc version 2.21.0 - https://too=
ls.ietf.org/tools/xml2rfc" />

The lists indeed look crammed, but what you're looking at is the HTML
output in the "v2" mode, which we'll hopefully won't be using anymore
soonish.

Best regards, Julian


From nobody Mon Sep 16 08:53:49 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B3112008A for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 08:53:47 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lx0LDnqsNhw for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 08:53:44 -0700 (PDT)
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 02BF5120052 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 08:53:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568649217; bh=wf1ok139/F8Ro5qqcV1U0zGTk4uRi5w7oc12LbM1NPY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=OOKU3/ZAO3HfpjGiFFw7MkPsgxQW0OHQ2lwG//I+1QdxDy1crfF1mcJrc8su0jYft f67cef2qkmFzac1sHHZFz+LGVcIVlRgc9KH9dU8S4qVX8s1KE5V80TqEi18Gp6a2yT P1hPXVu6IyadHJXlyL0qfI1VLeBLmk1XfJm5mcY8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([93.203.231.165]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MQu9K-1hfh1y3bWo-00UI9N; Mon, 16 Sep 2019 17:53:37 +0200
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu> <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com> <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <37d53cf7-3e99-e4dc-d66a-7bd452e0f3ea@gmx.de>
Date: Mon, 16 Sep 2019 17:53:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:CkjP7+vzPTMhc3nE1BizL7aG+J0QITQK5aJM/vfxE9F4p0uhEXo D0grCGkbcv29fUUwUlFxLEJMJ6NMbwLZr+Xn/aS3hbW35NrZiJBPHmqN5QwiLKEKPnk5BvI 9zT2l2A7XuNL0lEm0Gc230exaRhgPoDkRNw6ckNpc/VgbOAU7gU4Q1yxhwanlw4Gs6FkK3q 0bzcK9/nUclqKKyvHBxBA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:qn4WkEbzp0Q=:ORHVFEDxNHABVIQfarKNFy ULP1ATnBQ79PYe97QfBxwOmc8f71MVPpTVZ8FYYmgBCJY5SmccFdH2+0GPh8RXfMkUSYu6JEb bt42kJYUwdoW7LRA1mZUTIaHsZlIvxnIgbwMeQhstc136/II7IVxKW0pp4tYmvlcEUS+GkWSh C0PpBzGjifwxZX5sFLV6XU5clEDFWQ7/xFoHKnvuaujSzPEa6wqP9Gn5flEw8OBeH9ktg+GLj b5yW8ZsNyuZgaB7iODytZREc9hItTOK/TTsLPqxObFfMb3Vqdajwp0+dx0EXH2pXs87RkAu07 nFc+mthT4PJgKZg4AzEFJteZLX29K0OCgvTbeIjmSQKB08gG1syn/xxhlZl2WnbchVEAXBUNT v5/3Yl7RLmsfxjnFZvzPGMgbab/oTA9dNiDKq8lFg9tb3BJTXxc1M63M7W1P7SMPDHspuZeMi 0/DMJdWq0EnGIt3q6FnyIzDZ+68YJjmr4c/CynyCCsZ4QCp3MAvBbsXYg0w+ZnbbsVlvMfQOJ D4lGa4M+XbCAEM5/B+pxITUqanLjQNSie/19YJBeHogfstFCp3Qrkq+f0w1xdVv96/cq1nHqO GIpc0zZtcBOw3uNgLKjnkaR94E/Ae7+pspEsmQ95b3Zy/+TnfhZGOWYnA10wSvE74Uw6AN1FY YbAlFBZgC0gWZM4OeoDJqm6ldwp8Cu5W5w9LHeHcUhDReDBU21+hKG3Jlokb77LPyvU4NYfyy F8aqL111SMI79BtvmCa0RRib/lPOUQmo2HkRznP+sKa29peNtlpy/dBpmnADPX8GuNhrredJP VH01iInuB+3x1rnVHNovv07emJ2iS/+MWUIsLcVr1O/oOhWaNELj/Z3ycjZjI1sYRmHU6/qge 78cJE7LK3YPovud8kWLNSnBlBBOamDSXCHSJJKTiRP/C2z2IxeXTECrt2e+wsntfUwEa+ncQ6 jutcRXqLBmgvp/6SrU6ehDtUhR9ywwxGfJYMoSx82EemYqkkjn+81PLy7cSHKn8CB4njwo8jm 9tSn06HkDmpGlG4MZICvGmXYXC4glA2BUM08HYwR8KwDpyuxnGAYxlD0IVbRv5SjiUAtHXa/9 vNU5P8RksMyhmpaOKro+RUXhNaqIB3gnijAaNUetgjf/9fzxS79BqaTgU7TmKdMvC3zeDTIYc idVsuVP5nGdzj5+tIgaxTRnw8ezbUOm3i9+RSvgA5256ebTwI6tGH/Hso0Nu97EXB9mlCw3T6 BVphtleUrL0wcLUBCk6RO9NUoD587aKZLv8jjjKCsn9BptI0LbXUJ7G17UR0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/U0tO3TilC94YeMBr5XktPhBwCY0>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 15:53:48 -0000

On 16.09.2019 17:32, Paul Kyzivat wrote:
> On 9/16/19 10:46 AM, Anders Rundgren wrote:
>> On 2019-09-16 16:27, Paul Kyzivat wrote:
>>> On 9/16/19 1:22 AM, Anders Rundgren wrote:
>>>> On 2019-09-14 11:41, Julian Reschke wrote:
>>>> <snip>
>>>>>
>>>>> RfcMarkup has no official standing (and yes, I like it as well, and =
it
>>>>> has served us well for a very long time). It apparently generates
>>>>> XHTML,
>>>>> but the content is served as text/html on tools.ietf.org. It might b=
e
>>>>> good to change it to produce valid HTML5.
>>>>
>>>> This in interesting and but also rather confusing since this is the b=
y
>>>> far most used method for communicating RFCs by developers.
>>>
>>> Do you have any data to backup this claim?
>>
>> No, OTOH, since I mostly work with JSON-based stuff, the documents are
>> fairly recent.
>
> I don't recall every having seen a reference to an RfcMarkup.

Funny enough, that is the tool that is creating the HTNLized versions.

>> What I'm sure that I have newer seen in wild are references to PDF RFCs
>
> Nor have I.

PDF RFCs have been possible in the past, but certainly not encouraged.

> The most common references I see are to either the "HTMLized" form, the
> plain text, or the datatracker page.
>
> Personally I much prefer to work with the HTMLized form. It gives easy
> ability to jump around in the document, the extra info in the header
> including links to related tools, etc. and yet the text is almost
> identical to the plain text form which makes it easy to jump back and
> forth between a diff and the full document. It is also convenient to cut
> and paste bits of the document into email. I much prefer this format to
> the HTML format generated directly from xml.

There are multiple tools that do this, so it would be good to be more
specific here (xml2rfc in v2 mode? in v3 mode? rfc2629.xslt?)

> ...

Best regards, Julian


From nobody Mon Sep 16 09:37:00 2019
Return-Path: <agmalis@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F8812004F for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 09:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dCKXipWj4m4b for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 09:36:55 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 26FE3120026 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 09:36:55 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id x4so552856qtq.8 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 09:36:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9JdY3qkhao+6cWCU9mOcrQmNnuXBvGj5JadYXDOw/LU=; b=dGIOHM3C9dwTScGDLhuV5g7FbgS5CC4sqy69E0k11TFwKgPzlEcmsZmua+gD8tkxye ZXQV6ujSuWbnYSPAk0SJZhFMv7HDuPywjqdxak+tbFxL1PV+qikiyHBrnnq7i6UCH3oV +e0wKicIzk0EbznLo8R5j2oCCh5q3fLIudWca5aPXXn+BgC76LDf09n4Pp8e1pLfyH5s DDwy8Xpbeai61CUwT71RYxIBYGw8a/oYzwyZUVLK77aBGPrtSqpQKeq9s6RRuivJeLSx RORZwN9A0U2Bf3VEOJQF2HcBGDcnmG0CoNssbBeuYfbbl90MuH49La5Td8HcaVhub58u oqSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9JdY3qkhao+6cWCU9mOcrQmNnuXBvGj5JadYXDOw/LU=; b=N6IZcPEBRGcGw91hmkiyhjtN/Mb7oKZV95Vex5oQ7qxrvvmP+Yt+YVCXDQHW1BjLf0 KmWwzwS052Dq4uUXQQ0u1qnwnMqORVZfTtQHeo2ByODkCSZgNL9phD3L8/tpSEYqnfFB SorbeStILVkCUKYpdmper3rdEzKz5x/eTjQFblFkVxSR4CRrdxj98w38vRf/SVxTLFnN giZu0MJSqhoPFE+GeowkdeffRTM/GZ+mKDBv1gbNsaiNvJ4Qxbay2WS6QkKDksDEGhL1 7Cd/p6csupN4uZVS6+tCMkbiwFr5VtqXgsCKi3RnSTaoy5iHEXUkaxSysW8fHDIrBDuD au4w==
X-Gm-Message-State: APjAAAUaflHkr+y6jd8Osox9TPLEb5AA6a8MHz1MjqWSERgtMum/Tdag NVhNhO4TaiOs3pBOzDZhKtG2sUVKQOYCOUk5m1w=
X-Google-Smtp-Source: APXvYqxu1Eveno8/ZctfgCVYXXIE6OE/PFJu9DcQxEfq/wHFmzIwzKAa4J3xjo1bLkpPLgZllnv0nXzJY78UScoP3rs=
X-Received: by 2002:aed:3091:: with SMTP id 17mr482673qtf.219.1568651814074; Mon, 16 Sep 2019 09:36:54 -0700 (PDT)
MIME-Version: 1.0
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu> <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com> <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu> <37d53cf7-3e99-e4dc-d66a-7bd452e0f3ea@gmx.de>
In-Reply-To: <37d53cf7-3e99-e4dc-d66a-7bd452e0f3ea@gmx.de>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Mon, 16 Sep 2019 12:36:43 -0400
Message-ID: <CAA=duU0OD8c93v3efFPtHB-wuJAa0RZTF_ShV+G1T1Tow9XqMw@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000277b260592ae3642"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/q-Oepvmwg_GEW1VYl0rYF-0TyMw>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 16:36:58 -0000

--000000000000277b260592ae3642
Content-Type: text/plain; charset="UTF-8"

> PDF RFCs have been possible in the past, but certainly not encouraged.

In the PALS WG, we did an RFC where the PDF is the "canonical" output (
https://tools.ietf.org/pdf/rfc7893.pdf ). Check out the figures and you'll
see why. In the upcoming V3 world, we would be able to do this with the
HTML version as well. except that SVG figures will be black and white only
(a definite drawback in this case, esp. for figures 5-8).

Cheers,
Andy

--000000000000277b260592ae3642
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>&gt; PDF RFCs have been possible in =
the past, but certainly not encouraged.</div><div><br></div>In the PALS WG,=
 we did an RFC where the PDF is the &quot;canonical&quot; output ( <a href=
=3D"https://tools.ietf.org/pdf/rfc7893.pdf">https://tools.ietf.org/pdf/rfc7=
893.pdf</a> ). Check out the figures and you&#39;ll see why. In the upcomin=
g V3 world, we would be able to do this with the HTML version as well. exce=
pt that SVG figures will be black and white only (a definite drawback in th=
is case, esp. for figures 5-8).</div><div dir=3D"ltr"><br></div><div>Cheers=
,</div><div>Andy</div><div><br></div></div>

--000000000000277b260592ae3642--


From nobody Mon Sep 16 11:18:29 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF68120818 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 11:18:27 -0700 (PDT)
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, SPF_HELO_NONE=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 yfXoW5NaLjoj for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 11:18:20 -0700 (PDT)
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 9C956120047 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 11:18:20 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56494 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 1i9vZq-0002xD-3r; Mon, 16 Sep 2019 11:18:19 -0700
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu> <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com> <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <503b3bc4-daf0-cc9b-6fe3-948706db3a76@levkowetz.com>
Date: Mon, 16 Sep 2019 20:18:10 +0200
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: <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="upMkNwQ0AdputAXPSOftXknqsrKTkN6o7"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, anders.rundgren.net@gmail.com, pkyzivat@alum.mit.edu
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/08OC1xNuHc-I4M2qFyFn7JfPktA>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 18:18:27 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--upMkNwQ0AdputAXPSOftXknqsrKTkN6o7
Content-Type: multipart/mixed; boundary="6LKoInh83wG3OpBXaS0FsW2MGioV5LBbs";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>,
 Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
Message-ID: <503b3bc4-daf0-cc9b-6fe3-948706db3a76@levkowetz.com>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com>
 <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com>
 <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com>
 <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de>
 <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com>
 <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de>
 <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com>
 <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de>
 <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com>
 <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de>
 <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com>
 <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu>
 <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com>
 <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu>
In-Reply-To: <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu>

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

Hi Paul,

On 2019-09-16 17:32, Paul Kyzivat wrote:
> On 9/16/19 10:46 AM, Anders Rundgren wrote:
>> On 2019-09-16 16:27, Paul Kyzivat wrote:
>>> On 9/16/19 1:22 AM, Anders Rundgren wrote:
>>>> On 2019-09-14 11:41, Julian Reschke wrote:
>>>> <snip>
>>>>>
>>>>> RfcMarkup has no official standing (and yes, I like it as well, and=
 it
>>>>> has served us well for a very long time). It apparently generates=20
>>>>> XHTML,
>>>>> but the content is served as text/html on tools.ietf.org. It might =
be
>>>>> good to change it to produce valid HTML5.
>>>>
>>>> This in interesting and but also rather confusing since this is the =
by
>>>> far most used method for communicating RFCs by developers.
>>>
>>> Do you have any data to backup this claim?
>>=20
>> No, OTOH, since I mostly work with JSON-based stuff, the documents are=
=20
>> fairly recent.
>=20
> I don't recall every having seen a reference to an RfcMarkup.

rfcmarkup is the script that does the htmlization of text drafts and
rfcs.  I've pulled the interesting bits out as a python lib,
https://pypi.org/project/rfc2html/ .

>> What I'm sure that I have newer seen in wild are references to PDF RFC=
s=20
>=20
> Nor have I.
>=20
> The most common references I see are to either the "HTMLized" form, the=
=20
> plain text, or the datatracker page.
>=20
> Personally I much prefer to work with the HTMLized form. It gives easy =

> ability to jump around in the document, the extra info in the header=20
> including links to related tools, etc. and yet the text is almost=20
> identical to the plain text form which makes it easy to jump back and=20
> forth between a diff and the full document. It is also convenient to cu=
t=20
> and paste bits of the document into email. I much prefer this format to=
=20
> the HTML format generated directly from xml.
>=20
> When a new version of a document is published, I first pull up the=20
> HTMLized format. Then from there I follow the link to open a diff in=20
> another tab. That way I can skim the changes and easily refer back to=20
> the full document when I need more context.
>=20
> I hope that the HTMLized format will continue to be available.

That is my plan, yes.  I see no reason to stop the scripts that does that=

job.

> It could=20
> however be directly generated from the XML rather than from the=20
> plaintext. Generating it from the plaintext sometimes results in defect=
s=20
> regarding references.

Yes.  When I can find the time, I thought I'd at least try to do a CSS
stylesheet that applies a style to the v3 html that makes it come out
very close to the htmlized version.

Generating html which has *exactly* the same line breaks as the text outp=
ut
will require writing a almost completely new formatter that does the text=

format line breaking, but inserts the proper links everywhere the regular=

HTML v3 renderer does so.  I don't know when, if ever, I'd have that much=

time to spare.


Best regards,

	Henrik


--6LKoInh83wG3OpBXaS0FsW2MGioV5LBbs--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl1/0eIACgkQTptXS4+7
Fxp7lg/+NLQrWEOlL3wSZbDRcGdSBWB7O/Hjwo11UcFeramwZeyu1jn0yya7grmx
CsC6OayTxXQoiFTR2H84yz1HLf70yJ4L6p3qwQZM+FqOIs1bt8iTO0CgHxoDOW6c
dUCaWqM5o94LivnSZSxJbVgKZLja+LLhizzIbqfFO51OEppnWizCbc+/+7UbP7OP
DNeDouyzLsnEeJGVJFt83MhgugqwZ7LfmVsncp9XW2FTYCjanPaGwrQT1fV3rszE
UAX5qis52slHrlUAxMPnA4O6uttLVDG/GAt9Bz+NfHPB1fRqt0o0yptQC7/RawXY
YSTxhCAbcDoBfky5pMBTgyRu2E14kF8NJZLI1p3fmJtAs5K737tkpak/Fd6QbjZK
Gox93Fj6dhAOXzF0yjkFreC4vF9A8Di4+ZepD9tjcRnvgZZ3rlSEmbduSeUmr/9+
chNhCTS8J+cQo6qALzyovPCGOG1RYjymq+v8tQLf83OTZI4vWvScWG6lpivTqDlJ
RdOznzF/EcsW+pmoIYxzv7qwi0pYfb8SZfnml+KUQD6JfkbQ/16QHBTvEhFH9JJL
KYFUdNOXSkLlG56wH10omj7+ddwfTxia4j5uieVT8SZiA7EgEHcZAV4J3IGhxtK1
wh+js/XIOGV9HkYIOc58cHTWLboY4mA84PKUuTtsyEtTmWYdp10=
=c57A
-----END PGP SIGNATURE-----

--upMkNwQ0AdputAXPSOftXknqsrKTkN6o7--


From nobody Mon Sep 16 11:35:35 2019
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B33120086 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 11:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 G5D-EPZFvI7a for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 11:35:27 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07E112004A for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 11:35:26 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x8GIZMe8014106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Sep 2019 14:35:22 -0400
To: Julian Reschke <julian.reschke@gmx.de>, Anders Rundgren <anders.rundgren.net@gmail.com>, xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu> <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com> <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu> <37d53cf7-3e99-e4dc-d66a-7bd452e0f3ea@gmx.de>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <75e85e74-944f-85b0-b3b1-1c5af6ec513b@alum.mit.edu>
Date: Mon, 16 Sep 2019 14:35:22 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <37d53cf7-3e99-e4dc-d66a-7bd452e0f3ea@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/DsG1c6F-hbSGzAbStQxJJQcZYS0>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 18:35:34 -0000

On 9/16/19 11:53 AM, Julian Reschke wrote:
> On 16.09.2019 17:32, Paul Kyzivat wrote:
>> On 9/16/19 10:46 AM, Anders Rundgren wrote:
>>> On 2019-09-16 16:27, Paul Kyzivat wrote:
>>>> On 9/16/19 1:22 AM, Anders Rundgren wrote:
>>>>> On 2019-09-14 11:41, Julian Reschke wrote:
>>>>> <snip>
>>>>>>
>>>>>> RfcMarkup has no official standing (and yes, I like it as well, 
>>>>>> and it
>>>>>> has served us well for a very long time). It apparently generates
>>>>>> XHTML,
>>>>>> but the content is served as text/html on tools.ietf.org. It might be
>>>>>> good to change it to produce valid HTML5.
>>>>>
>>>>> This in interesting and but also rather confusing since this is the by
>>>>> far most used method for communicating RFCs by developers.
>>>>
>>>> Do you have any data to backup this claim?
>>>
>>> No, OTOH, since I mostly work with JSON-based stuff, the documents are
>>> fairly recent.
>>
>> I don't recall every having seen a reference to an RfcMarkup.
> 
> Funny enough, that is the tool that is creating the HTNLized versions.

Interesting. But what ends up being referenced is the resulting HTML.

>>> What I'm sure that I have newer seen in wild are references to PDF RFCs
>>
>> Nor have I.
> 
> PDF RFCs have been possible in the past, but certainly not encouraged.
> 
>> The most common references I see are to either the "HTMLized" form, the
>> plain text, or the datatracker page.
>>
>> Personally I much prefer to work with the HTMLized form. It gives easy
>> ability to jump around in the document, the extra info in the header
>> including links to related tools, etc. and yet the text is almost
>> identical to the plain text form which makes it easy to jump back and
>> forth between a diff and the full document. It is also convenient to cut
>> and paste bits of the document into email. I much prefer this format to
>> the HTML format generated directly from xml.
> 
> There are multiple tools that do this, so it would be good to be more
> specific here (xml2rfc in v2 mode? in v3 mode? rfc2629.xslt?)

I'm speaking here mostly as a consumer of rfcs and drafts, though I also 
author them. As a consumer I just see the results, not how they were 
produced. But I presume most have been produced from v2 xml using 
xml2rfc in v2 mode.

I look forward to seeing what might be available as v3 comes into use. 
If there is a good side by side diff tool for the html format or 
directly for the xml, that will be a start. Even then it will be 
interesting to see how easy it is to move back and forth between the 
diff and the full text.

(Sometimes I would prefer the side by side diff to include the full text 
so that there is complete context. But other times that would make it 
very convenient to see what has changed.)

Note that I'm only relating this to the way *I* have learned to work 
using the available tools. Perhaps new and better ways to work will be 
possible with the new format and related tools.

	Thanks,
	Paul


From nobody Mon Sep 16 12:24:55 2019
Return-Path: <stewart.bryant@gmail.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CB11200CC for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 12:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2n6cse8PZIrz for <xml2rfc@ietfa.amsl.com>; Mon, 16 Sep 2019 12:24:46 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 5A6261201C6 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 12:24:46 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id t3so519947wmj.1 for <xml2rfc@ietf.org>; Mon, 16 Sep 2019 12:24:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9j/w7cZO0qLyI7f2BOJAc3eLPxN4ngMBuLUH9o4SlO8=; b=T0IYqY8lE7l/KK8D7UtRlB3YfMPvWXouSa8kUpDeUCVksgF02xii7m28/3eemistXb LvAO7D6MyQsv/C3Adj+JltU6Pe40paHOiWUbX1qb9lBoRbFChgEVXs1TsYlEdfmmxgqR e0FgBUPE66mokmeBAMAk/d2vZmDOT+yZBLgjF5hzurWHI/2xO09KWCr7/JkamSxA6Vd/ HTCxw2pAQWQHemUlXspCeJkaBNqSKowNafIQEcEVtdhD8LGjpxhrQy3kQVWF1yZVPMqJ PO9aVNzeNVQ9bDaHcqBuiPg5PuGbdoeuHp8eqjjjGU7RaDpllbMYOAasemupCxQy8K47 aqag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9j/w7cZO0qLyI7f2BOJAc3eLPxN4ngMBuLUH9o4SlO8=; b=DwtkoGBVQGsDmlaIta5NB4GDixYBMX6E+NryUTdx0VOMDCnfmaylNKtVuZRQWo7ZSv 6FtHHV0pZCpbzhCSfiqRur1xODSg9NpOIGYRYxTIEPafRck/SAqlF4cZNHiJqrReSegq KwSIy5ey2C3PtSJMH/rqF4Ng+QbBpSOohFFPNBnLHCSyT+N+xEk1503tzN1hALWNYahb rL6pzKb6i2NE0dz/mCKnYsj8QSkeBf81DhEX1PWkz1Hz2X661kB1EXhMR+3VSN25rwtb QO9GLUVhqUZCoC4MU4kUCxImxR1QWzKJNw2fqNdlD/M4O4hodXmbWw6RzQ3Ut3nB8xoE rmGQ==
X-Gm-Message-State: APjAAAUzoksHP3hFhrUgv00Fj7fIk3hqsoMJrHP4gqL8UOwf0qgX9+Jz 0o+yMT9yiP/GPt8B2CSFf1zB/e8w
X-Google-Smtp-Source: APXvYqzC0Dj+rlNR/vIr5EzqeCXH3+7VnpavE57hLm6cCX8XZdAyP8ToEHUOOigkAjgI0QcwpZvg9A==
X-Received: by 2002:a1c:1d4:: with SMTP id 203mr493117wmb.104.1568661884398; Mon, 16 Sep 2019 12:24:44 -0700 (PDT)
Received: from [192.168.178.22] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id h63sm59084wmf.15.2019.09.16.12.24.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 12:24:43 -0700 (PDT)
To: "Andrew G. Malis" <agmalis@gmail.com>, Julian Reschke <julian.reschke@gmx.de>
Cc: xml2rfc@ietf.org
References: <94358f7d-3465-4161-1597-f1dbfba73b3f@gmail.com> <d44ac5f1-e4c2-1239-4bea-714a721115b8@levkowetz.com> <9ceb0697-c3ae-4f14-606c-4e089f04e2f2@gmail.com> <a4874a50-ffc3-80f5-cb42-09f82072644c@gmx.de> <04713f10-5c19-2ad5-2fa6-2db5f1ed5599@gmail.com> <f5554cd0-9c74-3a8c-5af9-25b947d499d8@gmx.de> <7bb2a5fb-262d-39b5-3bb0-72e068923ea7@gmail.com> <c3c8db0e-e719-32e6-ca3c-736e25ce8936@gmx.de> <f2f49552-091d-50e4-e2e2-2fdd30cbb7ae@gmail.com> <bd07ad5a-a0a7-f821-54ec-c09ee5614e2a@gmx.de> <d9883584-1d5e-4d34-9bde-00d32dc49435@gmail.com> <599cb714-89e8-271c-4d5e-ba294fa7d3cf@alum.mit.edu> <ee1a1699-a5e3-3c2b-ad53-ff80a120f7eb@gmail.com> <19509146-279f-4fb7-4b44-3feea81e87f9@alum.mit.edu> <37d53cf7-3e99-e4dc-d66a-7bd452e0f3ea@gmx.de> <CAA=duU0OD8c93v3efFPtHB-wuJAa0RZTF_ShV+G1T1Tow9XqMw@mail.gmail.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <22f2fb6e-de1f-d1fd-a167-39e7622953e3@gmail.com>
Date: Mon, 16 Sep 2019 20:24:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAA=duU0OD8c93v3efFPtHB-wuJAa0RZTF_ShV+G1T1Tow9XqMw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/dVGdet0h50IOXKSUVkShnjfjwyM>
Subject: Re: [xml2rfc] RfcMarkup not authoritative, HTML is gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 19:24:53 -0000

On 16/09/2019 17:36, Andrew G. Malis wrote:
>  > PDF RFCs have been possible in the past, but certainly not encouraged.
> 
> In the PALS WG, we did an RFC where the PDF is the "canonical" output ( 
> https://tools.ietf.org/pdf/rfc7893.pdf ). Check out the figures and 
> you'll see why. In the upcoming V3 world, we would be able to do this 
> with the HTML version as well. except that SVG figures will be black and 
> white only (a definite drawback in this case, esp. for figures 5-8).
> 
> Cheers,
> Andy
> 

.. and RFC5317 the text version being a pointer to the pdf which carried 
a set of slides jointly agreed with the ITU.

However the most famous was RFC1305 which defines NTPv3 (NTPv2 was 
published in PS format)

My experience has always been that if you had a good reason for 
publishing in pdf was always possible and perhaps authors should have 
pushed a bit harder.

- Stewart


From nobody Tue Sep 17 14:15:34 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8A12007A; Tue, 17 Sep 2019 14:15:26 -0700 (PDT)
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, SPF_HELO_NONE=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 go3C1zf7Jizw; Tue, 17 Sep 2019 14:15:23 -0700 (PDT)
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 580C1120043; Tue, 17 Sep 2019 14:15:23 -0700 (PDT)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1iAKol-0003df-02; Tue, 17 Sep 2019 14:15:23 -0700
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1iAKol-0003df-02@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Tue, 17 Sep 2019 14:15:22 -0700
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/NMI639F5KZdY0tVUtXFZ2a-Vr3Y>
Subject: [xml2rfc] New xml2rfc release: v2.29.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2019 21:15:26 -0000

Hi,

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

Release notes:

xml2rfc (2.29.0) ietf; urgency=medium

  * Adjusted the handling of ASCII, Latin, and non-Latin names and
    abbreviation in the v3 text formatter to act the same way as the v3
    HTML formatter.

  * Added RFC #### to the HTML rendered document title (for RFCs).

  * Added <artset> in the schema in two places that were missed when 
    first introducing it.

  * Changed the metadata json URL to avoid CORS issues due to redirects.
    Added a missing JS 'var' keyword and fixed a typo.

  * Handled a file open mode deprecation issue.  Fixes issue #427.

  * Added 'table' to the internal list of block-level elements.

  * Added the traditional default 'Network Working Group' to the top of 
    HTML output for drafts.

 -- Henrik Levkowetz <henrik@levkowetz.com>  17 Sep 2019 21:06:37 +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.29.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Wed Sep 18 08:24:28 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F0D120890; Wed, 18 Sep 2019 08:24:20 -0700 (PDT)
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, SPF_HELO_NONE=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 cpnEyZ-P4Azx; Wed, 18 Sep 2019 08:24:19 -0700 (PDT)
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 7B192120881; Wed, 18 Sep 2019 08:24:19 -0700 (PDT)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1iAboZ-0004HO-6y; Wed, 18 Sep 2019 08:24:19 -0700
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1iAboZ-0004HO-6y@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Wed, 18 Sep 2019 08:24:19 -0700
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/MZGffhoSH2xuVQeZArINn7rRB6w>
Subject: [xml2rfc] New xml2rfc release: v2.29.1
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2019 15:24:21 -0000

Hi,

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

Release notes:

xml2rfc (2.29.1) ietf; urgency=medium

  * Fixed an issue with pagination that could occur if a table (or other 
    block) longer than a page ended on the last page.

 -- Henrik Levkowetz <henrik@levkowetz.com>  18 Sep 2019 15:22:19 +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.29.1'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Thu Sep 19 04:51:00 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FDF1200E9; Thu, 19 Sep 2019 04:50:51 -0700 (PDT)
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, SPF_HELO_NONE=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 RuecEf6ENSh9; Thu, 19 Sep 2019 04:50:49 -0700 (PDT)
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 CE96B12003F; Thu, 19 Sep 2019 04:50:49 -0700 (PDT)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1iAuxV-0002lQ-J2; Thu, 19 Sep 2019 04:50:49 -0700
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1iAuxV-0002lQ-J2@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Thu, 19 Sep 2019 04:50:49 -0700
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/sckR0QteX2C_E3miD6ws5lGBasY>
Subject: [xml2rfc] New xml2rfc release: v2.30.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 11:50:52 -0000

Hi,

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

Release notes:

xml2rfc (2.30.0) ietf; urgency=medium

  * Added logging configuration for weasyprint.  This controls the logging
    level based on the --quiet and --verbose flags, and should make
    weasyprint logging ouput more consistent across systems.

  * Weasyprint reports ERROR if a CSS <link> URL isn't available, so we
    won't insert a <link> for "rfc-local.css" when generating PDF if the
    file doesn't exist.

  * Tweaked the Makefile to use --add-include in some cases, for regression 
    testing.

  * Corrected the <xi:include> links produced during v2v3 conversion with
    the --add-xinclude switch, 

  * Changed the code to not retain <!ENTITY> declarations after v2v3
    conversion.

  * Changed BaseV3Writer.die() to raise an exception, rather than exit on 
    the spot, in order to do the right thing when called as a library.

  * Tweaked the command-line messages when a fatal error is raised in a 
    writer.

 -- Henrik Levkowetz <henrik@levkowetz.com>  19 Sep 2019 04:48:21 -0700

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.30.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Mon Sep 23 23:54:03 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DA912010C for <xml2rfc@ietfa.amsl.com>; Mon, 23 Sep 2019 23:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.026
X-Spam-Level: 
X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA-6QQkRMaTP for <xml2rfc@ietfa.amsl.com>; Mon, 23 Sep 2019 23:53:59 -0700 (PDT)
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 0308912001E for <xml2rfc@ietf.org>; Mon, 23 Sep 2019 23:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1569308033; bh=Yr/ClIrfxHFIRvfWI0BmRY3F1x6MFX5/70AqF/Acg6w=; h=X-UI-Sender-Class:To:From:Subject:Date; b=CyY4Q2F73G0MZFUN5ms+YlBUntrKeAerMNgxa1vUjzbO9qZ5iwps5r4yN/3FhJoYM 9alxrTPGrwId6ixD6jfMzxij5hlBv5ZYYtD91Zy0HdxQbSatfzmbaeUkYTudh0dZlh /xl/ExdkVNkG171cLv8VRc+t4b4uXL3Nscbj6pnM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.138.111]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MO9zH-1iWDnd4AUD-00OVR2 for <xml2rfc@ietf.org>; Tue, 24 Sep 2019 08:53:53 +0200
To: xml2rfc@ietf.org
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <866c58ff-c977-a0d3-ded5-fbf3ef449182@gmx.de>
Date: Tue, 24 Sep 2019 08:53:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:ttPIjHoK9EvKzTziw+Xpn/ylkfIhm8rXQTCuQ6H/v5hlu426Bds 9fhI6deugKDGi+cUxL+88i9WSP3ASvWQMzJBuRd0gQXqk2w+C8Bc2i49sQq+sLIsQTPW2Jp XxYBDreUqLzRICoKBH4v7c+ptXN1ZQirbRP/w+XaQYXxQt5fEquJubzIj/o+5RclCYbo5xJ tzep2n/ZRUqK6wYeQCkVQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:95lLHB6Ixp4=:IGHJjg0k3SL9Msr7zs69XJ ejW4uP+efMrxMnKzx/dbuyoPHtdCs6r93WlBlSY/35F8m9oCfLUvBxf7Xiv+9nGRDtPTMzNH8 WNL9bn1JQxjmkfq9ONChF1vO012F0bu49NE2q8nJ530nIwZu37+J4rjtcZemaZ2AkILnxIeHV /N4HZ5N4gj7KuujicTS3OeOgqo2eEEpJno3MXKNYqIBB5aiobcjIJwVcIY3M+t45vIjv+8zVc p/WkCwzQ3uBbF2ZqRT/arn4OovC11cvS7IUsSkFs55/RcuZzQbLJHsAuhrJyQypPaL04xzVFr iUV3fbrcbhEaLvomHmeSL4S2tJ8jU7L+JsjvKQATe8m1IQZtjq917bt6ssETgHgAbIbXHPgX+ FKPYsFz4I7DxufFTAyTHYpBwsyBdmddyhKQZxv/S7XYwEybYiwi15a+/8eMXuNdEDmrj0O9jm zAiBqzPg4WW065QFTdV5kiRUw7zwAT/B97agsKxvK+QI2ozAEOdbRtbhAv0XOIulJiWau8mXz rBknGA8V2mo0oleBryCjoFKpvs1TIff/Z9m9ST1k6j4OioUGpEytdvGdEKAuHyPli4dZqOggS LLZL+ok1WbD1+yh3j9QhZgyIso7y52PyjSA0rwA7olSAcWXOV1VqlEDLceykaaaMmyE0Yyvgt dpJ9gL1BE7hOkvsv6SFefyTs49Qtao5UiY8n9yAPEqgmUQ7/fVU3jFbLqOdLnAdEO/zHwqnzc S5sQAlcHWpeatCzVWbc/vv2T7PD9K2Zh3YoQF4lbZrHSAf3w0WE+hR6gIm5nasgbOZAgIT+jQ QfaIuXgLlphRcKI1mvlwAFeYKZW9YuwzJHULuKhb6QYXZPT733/y55LtN6p0rPjviDnEXRaK4 OTjsoTtSYwxzsZAVsOODzfr75bCn7Yv9wY5F5ldHVXgz73aokOp15EfEs1Y7AfqEg3E/XiwUT 452vomRYmdvgvCCIQoQyTZn+yz5/1rIqNOCOVFkoQt4Hg0N8CXUUZvlyxPct1Lie4AxNkNQDE BrvDtcc/gVrszFwDaMf6CWtj59A4nA0ySAJVB+kpto2VXUqNleXL7msii84EGxWfmbjXLBpL7 6JTDKQpE9EboLVCWc35VdhQnqB/9t8ptt4OX2/jv0Yidv5FF8f1Gx422XPBDvBCeSxRhbqzmO JkVpik26leHOmEJhoReHsxbsgUCguD/VFnLF6GNKLyfLNSoZbNRH2dU3v0+6GlxN2xMJF7teQ l8c3pDp7nH8DxPyNjG7OeRWjHjfZ31fY/zBI8MIZ3DbFCiXf3XD9MgPqjVgY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/5p2YS9EnzrikcfsYQsFvtYQLJ8k>
Subject: [xml2rfc] ticket notifications gone?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 06:54:02 -0000

Hi there,

I just noted that notifications about new/changed tickets apparently
aren't sent anymore here. Is that intentional?

Best regards, Julian


From nobody Wed Sep 25 06:01:01 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0700312022C for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 06:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 PP77tjWTY1Qo for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 06:00:57 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAC512008A for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 06:00:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 51C5661FDB for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 09:00:55 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dRkqrfqGJNe5 for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 09:00:51 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id DCAF0615EB for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 09:00:50 -0400 (EDT)
To: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com>
Date: Wed, 25 Sep 2019 09:00:45 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/b79vM8w89AqEUx_ept-2Pu48V28>
Subject: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 13:01:00 -0000

I want to include the following as a reference:

https://eprint.iacr.org/eprint-bin/cite.pl?entry=2017/498

The actual paper is:

https://eprint.iacr.org/2017/498.pdf

How can this be done?  Is there a DOI method for it?

thanks


From nobody Wed Sep 25 07:41:51 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A0012003E for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 07:41:48 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 liYVv45EdzvX for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 07:41:46 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF531200B5 for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 07:41:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8E563615EB for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 10:41:45 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VP1zEYxHBRVE for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 10:41:41 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id EBFA560029 for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 10:41:38 -0400 (EDT)
From: Robert Moskowitz <rgm@htt-consult.com>
To: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com>
Message-ID: <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com>
Date: Wed, 25 Sep 2019 10:41:33 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/76yRYo29MRgJG9vxd7I71SCo6Fo>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 14:41:49 -0000

oops.  Hit the wrong key back there...

On 9/25/19 9:00 AM, Robert Moskowitz wrote:
> I want to include the following as a reference:
>
> https://eprint.iacr.org/eprint-bin/cite.pl?entry=2017/498
>
> The actual paper is:
>
> https://eprint.iacr.org/2017/498.pdf
>
> How can this be done?  Is there a DOI method for it?

Joan just sent me the following DOI information on his paper:

Yes, I found it at:

https://link.springer.com/chapter/10.1007%2F978-3-319-70697-9_21

this is what it says:

https://doi.org/10.1007/978-3-319-70697-9_21


Now to get that working as I have the NIST stuff working...



From nobody Wed Sep 25 09:56:49 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE30512012E for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 09:56:47 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 reCPaGwTy-kj for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 09:56:45 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141FF1200CE for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 09:56:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DAB1E615EB for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 12:56:43 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UbTVwMGaLN5J for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 12:56:39 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3866660029 for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 12:56:39 -0400 (EDT)
From: Robert Moskowitz <rgm@htt-consult.com>
To: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com>
Message-ID: <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com>
Date: Wed, 25 Sep 2019 12:56:33 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/Sm1eBEnMnH3RZoYMg145oxajaaM>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 16:56:48 -0000

On 9/25/19 10:41 AM, Robert Moskowitz wrote:
> oops. Hit the wrong key back there...
>
> On 9/25/19 9:00 AM, Robert Moskowitz wrote:
>> I want to include the following as a reference:
>>
>> https://eprint.iacr.org/eprint-bin/cite.pl?entry=2017/498
>>
>> The actual paper is:
>>
>> https://eprint.iacr.org/2017/498.pdf
>>
>> How can this be done?  Is there a DOI method for it?
>
> Joan just sent me the following DOI information on his paper:
>
> Yes, I found it at:
>
> https://link.springer.com/chapter/10.1007%2F978-3-319-70697-9_21
>
> this is what it says:
>
> https://doi.org/10.1007/978-3-319-70697-9_21
>
>
> Now to get that working as I have the NIST stuff working...

When I try:

https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.10.1007/978-3-319-70697-9_21

I get

invalid DOI or type

What is the proper invocation?

Thanks


From nobody Wed Sep 25 10:11:37 2019
Return-Path: <arusso@amsl.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE48120811 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 10:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 gclW-QNQL7Zs for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 10:11:33 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4E412013C for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 10:11:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 9391720336E; Wed, 25 Sep 2019 10:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZLoDKET7AhH; Wed, 25 Sep 2019 10:10:08 -0700 (PDT)
Received: from [IPv6:2601:602:8500:9790:1031:4450:e85b:e3ee] (unknown [IPv6:2601:602:8500:9790:1031:4450:e85b:e3ee]) by c8a.amsl.com (Postfix) with ESMTPSA id 49A03202EAE; Wed, 25 Sep 2019 10:10:08 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Alice Russo <arusso@amsl.com>
In-Reply-To: <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com>
Date: Wed, 25 Sep 2019 10:11:32 -0700
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <47575705-D614-4404-868C-9E14225EE3D8@amsl.com>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com>
To: Robert Moskowitz <rgm@htt-consult.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/yfIBspNsG8nFtN_lJ-ayqoEZjUg>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 17:11:37 -0000

Hi,
=
https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.1007/97=
8-3-319-70697-9_21.xml
seems to work.

template:
=
https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.<number>.x=
ml

Alice

> On Sep 25, 2019, at 9:56 AM, Robert Moskowitz <rgm@htt-consult.com> =
wrote:
>=20
>=20
>=20
> On 9/25/19 10:41 AM, Robert Moskowitz wrote:
>> oops. Hit the wrong key back there...
>>=20
>> On 9/25/19 9:00 AM, Robert Moskowitz wrote:
>>> I want to include the following as a reference:
>>>=20
>>> https://eprint.iacr.org/eprint-bin/cite.pl?entry=3D2017/498
>>>=20
>>> The actual paper is:
>>>=20
>>> https://eprint.iacr.org/2017/498.pdf
>>>=20
>>> How can this be done?  Is there a DOI method for it?
>>=20
>> Joan just sent me the following DOI information on his paper:
>>=20
>> Yes, I found it at:
>>=20
>> https://link.springer.com/chapter/10.1007%2F978-3-319-70697-9_21
>>=20
>> this is what it says:
>>=20
>> https://doi.org/10.1007/978-3-319-70697-9_21
>>=20
>>=20
>> Now to get that working as I have the NIST stuff working...
>=20
> When I try:
>=20
> =
https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.10.1007/978-3-=
319-70697-9_21
>=20
> I get
>=20
> invalid DOI or type
>=20
> What is the proper invocation?
>=20
> Thanks
>=20
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc


From nobody Wed Sep 25 10:31:20 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26291201E0 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 10:31:18 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 D45FW5NvD7QP for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 10:31:17 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B05812001A for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 10:31:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 37F2C615EB; Wed, 25 Sep 2019 13:31:15 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DcCLsk-u31bx; Wed, 25 Sep 2019 13:31:09 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id D22EE60029; Wed, 25 Sep 2019 13:31:06 -0400 (EDT)
To: Alice Russo <arusso@amsl.com>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com>
Date: Wed, 25 Sep 2019 13:31:00 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <47575705-D614-4404-868C-9E14225EE3D8@amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/FTDu9gNfqg1g5ACFolE06rPl_-8>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 17:31:19 -0000

On 9/25/19 1:11 PM, Alice Russo wrote:
> Hi,
> https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.1007/978-3-319-70697-9_21.xml
> seems to work.

when I use

     <?rfc 
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.1007/978-3-319-70697-9_21.xml?anchor=ASIACRYPT-2017"?>

xml2rfc gives me the warnings:

Warning: Illegal character replaced in string: &#128;
Warning: Illegal character replaced in string: &#147;

And the reference text becomes:

    [ASIACRYPT-2017]
               Daemen, J., Mennink, B., and G. Van Assche, "Full-State
               Keyed Duplex with Built-In Multi-user Support", Advances
               in Cryptology a&#128;&#147; ASIACRYPT 2017 pp. 606-637,
               DOI 10.1007/978-3-319-70697-9_21, 2017.

I am running the most recent version of xml2rfc.  When I add --v3, I get 
the substitutions without any warnings.



>
> template:
> https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.<number>.xml
>
> Alice
>
>> On Sep 25, 2019, at 9:56 AM, Robert Moskowitz <rgm@htt-consult.com> wrote:
>>
>>
>>
>> On 9/25/19 10:41 AM, Robert Moskowitz wrote:
>>> oops. Hit the wrong key back there...
>>>
>>> On 9/25/19 9:00 AM, Robert Moskowitz wrote:
>>>> I want to include the following as a reference:
>>>>
>>>> https://eprint.iacr.org/eprint-bin/cite.pl?entry=2017/498
>>>>
>>>> The actual paper is:
>>>>
>>>> https://eprint.iacr.org/2017/498.pdf
>>>>
>>>> How can this be done?  Is there a DOI method for it?
>>> Joan just sent me the following DOI information on his paper:
>>>
>>> Yes, I found it at:
>>>
>>> https://link.springer.com/chapter/10.1007%2F978-3-319-70697-9_21
>>>
>>> this is what it says:
>>>
>>> https://doi.org/10.1007/978-3-319-70697-9_21
>>>
>>>
>>> Now to get that working as I have the NIST stuff working...
>> When I try:
>>
>> https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.10.1007/978-3-319-70697-9_21
>>
>> I get
>>
>> invalid DOI or type
>>
>> What is the proper invocation?
>>
>> Thanks
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/xml2rfc


From nobody Wed Sep 25 11:10:25 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5564120839 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 hQ1O5tUDrXZe for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:10:21 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F895120236 for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 11:10:21 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46dmLg6GSbzyXp; Wed, 25 Sep 2019 20:10:19 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com>
Date: Wed, 25 Sep 2019 20:10:19 +0200
Cc: Alice Russo <arusso@amsl.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
X-Mao-Original-Outgoing-Id: 591127817.7323641-a5ae34b7cd8d6bfa2a222b3847279ab5
Content-Transfer-Encoding: quoted-printable
Message-Id: <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com> <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com>
To: Robert Moskowitz <rgm@htt-consult.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/rfzujuUDK3POwTe99LM8II5e6u8>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 18:10:24 -0000

>=20
>     <?rfc =
include=3D"https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI=
.10.1007/978-3-319-70697-9_21.xml?anchor=3DASIACRYPT-2017"?>
>=20
> xml2rfc gives me the warnings:
>=20
> Warning: Illegal character replaced in string: &#128;
> Warning: Illegal character replaced in string: &#147;
>=20
> And the reference text becomes:
>=20
>    [ASIACRYPT-2017]
>               Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>               Keyed Duplex with Built-In Multi-user Support", Advances
>               in Cryptology a&#128;&#147; ASIACRYPT 2017 pp. 606-637,
>               DOI 10.1007/978-3-319-70697-9_21, 2017.

Something is very broken with the XML2RFC you are using (or with a =
firewall you are going through).

The XML at the URL is:

<reference anchor=3D'ASIACRYPT-2017' >
  <front>
    <title>Full-State Keyed Duplex with Built-In Multi-user =
Support</title>
    <author initials=3D"J." surname=3D"Daemen" fullname=3D"Joan Daemen">
      <organization></organization>
    </author>
    <author initials=3D"B." surname=3D"Mennink" fullname=3D"Bart =
Mennink">
      <organization></organization>
    </author>
    <author initials=3D"G." surname=3D"Van Assche" fullname=3D"Gilles =
Van Assche">
      <organization></organization>
    </author>
    <date year=3D"2017"/>
  </front>
  <seriesInfo name=3D"Advances in Cryptology =E2=80=93 ASIACRYPT 2017" =
value=3D"pp. 606-637"/>
  <seriesInfo name=3D"DOI" value=3D"10.1007/978-3-319-70697-9_21"/>
</reference>

Note the en-dash (U+2013) before =E2=80=9CASIACRYPT=E2=80=9D, which =
turns into mojibake on your system (looks like UTF-8 misinterpreted as =
Latin-1).

Gr=C3=BC=C3=9Fe, Carsten


From nobody Wed Sep 25 11:18:54 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37776120236 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 3cjxQFDljaad for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:18:50 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E6712003F for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 11:18:50 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46dmXT19R6zyY2; Wed, 25 Sep 2019 20:18:49 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org>
Date: Wed, 25 Sep 2019 20:18:48 +0200
Cc: Alice Russo <arusso@amsl.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
X-Mao-Original-Outgoing-Id: 591128327.179391-ad4c6ab236d869b3c0d3e748f8fb8e73
Content-Transfer-Encoding: quoted-printable
Message-Id: <F43BC3B4-D1AE-47D1-A2E5-7EBCCDBFF4C7@tzi.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com> <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com> <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org>
To: Robert Moskowitz <rgm@htt-consult.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/QRXPAR79ji6q66s7GeRuY4HRhqg>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 18:18:52 -0000

On Sep 25, 2019, at 20:10, Carsten Bormann <cabo@tzi.org> wrote:
>=20
> Something is very broken with the XML2RFC you are using (or with a =
firewall you are going through).

I get

   [DUPLEX]   Daemen, J., Mennink, B., and G. Van Assche, "Full-State
              Keyed Duplex with Built-In Multi-user Support", Advances
              in Cryptology - ASIACRYPT 2017 pp. 606-637,
              DOI 10.1007/978-3-319-70697-9_21, 2017.

(Oops, should have used your label instead of DUPLEX.)

Oh, xml2rfc 2.26.0

Retrying with xml2rfc 2.30.0:

   [DUPLEX]   Daemen, J., Mennink, B., and G. Van Assche, "Full-State
              Keyed Duplex with Built-In Multi-user Support", Advances
              in Cryptology - ASIACRYPT 2017 pp. 606-637,
              DOI 10.1007/978-3-319-70697-9_21, 2017.

Hmm, works for me.  (This is with Python V3 on a High Sierra Mac.)

Gr=C3=BC=C3=9Fe, Carsten


From nobody Wed Sep 25 11:33:33 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D671202A0 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:33:31 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 9T8VYiKW2C46 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:33:27 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729851201E0 for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 11:33:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 54A6360029; Wed, 25 Sep 2019 14:33:25 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3AGGeAdL3rqH; Wed, 25 Sep 2019 14:33:11 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2455A615EB; Wed, 25 Sep 2019 14:33:11 -0400 (EDT)
To: Carsten Bormann <cabo@tzi.org>
Cc: Alice Russo <arusso@amsl.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com> <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com> <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org> <F43BC3B4-D1AE-47D1-A2E5-7EBCCDBFF4C7@tzi.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <d1f43ef6-ba8b-cc30-c1fd-1b27edde24f4@htt-consult.com>
Date: Wed, 25 Sep 2019 14:33:05 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <F43BC3B4-D1AE-47D1-A2E5-7EBCCDBFF4C7@tzi.org>
Content-Type: multipart/mixed; boundary="------------99ECA65A64726744F5116F1D"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/eUvvOdA-3-55R21_kqCBi6aFyl8>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 18:33:31 -0000

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



On 9/25/19 2:18 PM, Carsten Bormann wrote:
> On Sep 25, 2019, at 20:10, Carsten Bormann <cabo@tzi.org> wrote:
>> Something is very broken with the XML2RFC you are using (or with a firewall you are going through).
> I get
>
>     [DUPLEX]   Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>                Keyed Duplex with Built-In Multi-user Support", Advances
>                in Cryptology - ASIACRYPT 2017 pp. 606-637,
>                DOI 10.1007/978-3-319-70697-9_21, 2017.
>
> (Oops, should have used your label instead of DUPLEX.)
>
> Oh, xml2rfc 2.26.0
>
> Retrying with xml2rfc 2.30.0:
>
>     [DUPLEX]   Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>                Keyed Duplex with Built-In Multi-user Support", Advances
>                in Cryptology - ASIACRYPT 2017 pp. 606-637,
>                DOI 10.1007/978-3-319-70697-9_21, 2017.
>
> Hmm, works for me.  (This is with Python V3 on a High Sierra Mac.)

I am using xml2rfc v2.30.0, Python V2 on my Fedora 30 system.

And when I try:  https://xml2rfc.tools.ietf.org/

I get the same problem:

    [ASIACRYPT-2017]
               Daemen, J., Mennink, B., and G. Van Assche, "Full-State
               Keyed Duplex with Built-In Multi-user Support", Advances
               in Cryptology a&#128;&#147; ASIACRYPT 2017 pp. 606-637,
               DOI 10.1007/978-3-319-70697-9_21, 2017.


xml attached


--------------99ECA65A64726744F5116F1D
Content-Type: text/xml; charset=UTF-8;
 name="draft-moskowitz-hip-new-crypto-01.xml"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="draft-moskowitz-hip-new-crypto-01.xml"

﻿<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="std" docName="draft-moskowitz-hip-new-crypto-01" ipr="trust200902">

<front>
<title abbrev="HIP New Crypto">New Cryptographic Algorithms for HIP</title>
	<author fullname="Robert Moskowitz" initials="R" surname="Moskowitz">
    <organization>HTT Consulting</organization>
    <address>
      <postal> 
	    <street></street>
        <city>Oak Park</city>
        <region>MI</region>
        <code>48237</code>
        <country>USA</country>
      </postal>
      <email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Stuart W. Card" initials="S." surname="Card">
	<organization>AX Enterprize</organization>
	<address>
	  <postal>
	    <street>4947 Commercial Drive</street>
	    <city>Yorkville</city>
	    <region>NY</region>
	    <code>13495</code>
	    <country>USA</country>
	  </postal>
	  <email>stu.card@axenterprize.com</email>
	</address>
	</author>
	<author fullname="Adam Wiethuechter" initials="A." surname="Wiethuechter">
	<organization>AX Enterprize</organization>
	<address>
	  <postal>
	    <street>4947 Commercial Drive</street>
	    <city>Yorkville</city>
	    <region>NY</region>
	    <code>13495</code>
	    <country>USA</country>
	  </postal>
	  <email>adam.wiethuechter@axenterprize.com</email>
	</address>
	</author>
<date year="2019" />
   <area>Internet</area>
   <workgroup>HIP</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>HIP</keyword>
<abstract>
<t>
	This document provides new cryptographic algorithms to be used with 
	HIP.  The Edwards Elliptic Curve and the Keccak sponge functions 
	are the main focus. The HIP parameters and processing instructions 
	impacted by these algorithms are defined.
</t>
</abstract>
</front>
<middle>   
<section title="Introduction">
<t> 
	This document adds new cryptographic algorithms for <xref 
	target="RFC7401">HIPv2</xref>. This includes:
	<list style="symbols">
    <t>
		New elliptic curves for ECDH.
    </t>
    <t>
		The Edwards Elliptic Curve Digital Signature Algorithm (EdDSA) 
		used in Host Identities (HI) and for Base Exchange (BEX) 
		signatures.
    </t>
	<t>
		Hashes used in Host Identity Tag (HIT) generation, and 
		wherever else hashes are needed.
	</t>
	<t>
		Keyed hashes used for KEYMAT generation and packet MACing 
		operations.
	</t>
	<t>
		AEAD and stream ciphers to use in HIP and HIP enabled secure 
		communication protocols.
	</t>
	</list>
</t> 
<t>
	The hashes and encryption are all built on the <xref 
	target="Keccak">Keccak</xref> sponge function.
</t>
<t>
	These additions reflect selection of advances in the field of 
	cryptography that would best benefit HIP, particularly in 
	constrained devices and communications.
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
	<section title="Requirements Terminology">
	<t>
		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 
		"MAY", and "OPTIONAL" in this document are to be interpreted as 
		described in BCP 14 <xref target="RFC2119" /> <xref 
		target="RFC8174" /> when, and only when, they appear in all 
		capitals, as shown here.
	`</t>
	</section>
	<section title="Definitions">
	<t>
		<list style="hanging">
		<t hangText="Keccak (KECCAK Message Authentication Code):">
			The family of all sponge functions with a KECCAK-f 
			permutation as the underlying function and multi-rate 
			padding as the padding rule.
		</t>
		<t hangText="KMAC (KECCAK Message Authentication Code):">
			A PRF and keyed hash function based on KECCAK.
		</t>
		<t hangText="cSHAKE (The customizable SHAKE function):">
			Extends the SHAKE scheme to allow users to customize their 
			use of the function.
		</t>
		<t hangText="SHAKE (Secure Hash Algorithm KECCAK):">
			A secure hash that allows for an arbitrary output length.
		</t>
		<t hangText="PRF (Pseudorandom Function):">
			A function that can be used to generate output from a 
			random seed such that the output is computationally 
			indistinguishable from truly random output.
		</t>
		<t hangText="capacity:">
			In the sponge construction, the width of the underlying 
			function minus the rate.
		</t>
		<t hangText="rate:">
			In the sponge construction, the number of input bits 
			processed per invocation of the underlying function.
		</t>
		<t hangText="XOF (eXtendable-Output Function):">
			A function on bit strings (also called messages) in which 
			the output can be extended to any desired length.
		</t>
		</list>
	</t>
	</section>
</section>
<section anchor="HIP_param" title="HIP Parameter values for new Crytpo">
<t>
	HIP parameters carry information that is necessary for establishing 
	and maintaining a HIP association.  For example, the device's 
	public keys as well as the signaling for negotiating ciphers and 
	payload handling are encapsulated in HIP parameters.  Additional 
	information, meaningful for end hosts or middleboxes, may also be 
	included in HIP parameters.  The specification of the HIP 
	parameters and their mapping to HIP packets and packet types is 
	flexible to allow HIP extensions to define new parameters and new 
	protocol behavior.
</t>
<section anchor="ecdh" title="Elliptic Curves for Diffie-Hellman">
<t>
	Elliptic curves Curve25519 and Curve448 <xref target="RFC7748">RFC 
	7748</xref>) are specified here for use in the HIP Diffie-Hellman 
	exchange.
</t>
<t>
	Curve25519 and Curve448 are already defined in Section 5.2.1 of 
	<xref target="I-D.ietf-hip-dex"> </xref>, using the HIP-DEX CKDF.  
	Here they are defined for using the new KMAC <xref 
	target="NIST.SP.800-185">NIST SP 800-185</xref> derived KDF in 
	<xref target="hip_keymat" />.
</t>
<section anchor="Diffie_Hellman" title="DIFFIE_HELLMAN">
<t>
	The DIFFIE_HELLMAN parameter may be included in selected HIP 
	packets based on the DH Group ID selected.  The DIFFIE_HELLMAN 
	parameter is defined in Section 5.2.7 of <xref target="RFC7401" />.
</t>
<t>
	The following Elliptic Curves are defined here:
</t>
    <figure>
      <artwork>
Group                              KDF              Value

Curve25519 [RFC7748]               KKDF             13
Curve448   [RFC7748]               KKDF             14
      </artwork>
    </figure>

<t>
	A new KDF for KEYMAT, Section 6.5 of <xref target="RFC7401"/> and 
	Section 6.3 of <xref target="I-D.ietf-hip-dex"> </xref> using 
	Keccak is defined in <xref target="hip_keymat" />.
</t>
</section>
</section>
<section anchor="EdDSA" title="Edward Digital Signature Algorithm">
<t>
	Edwards-Curve Digital Signature Algorithm (EdDSA) (<xref 
	target="RFC8032">RFC 8032</xref>) are specified here for use as 
	Host Identities (HIs).
</t>
<section anchor="host_id" title="HOST_ID">
<t>
	The HOST_ID parameter specifies the public key algorithm, and for 
	elliptic curves, a name.  The HOST_ID parameter is defined in 
	Section 5.2.19 of <xref target="RFC7401" />.
</t>
<figure>
    <artwork>
     Algorithm
     profiles         Values

     EdDSA            13 [RFC8032]       (RECOMMENDED)
    </artwork>
</figure>

	<t>
	For hosts that implement EdDSA as the algorithm, the following ECC 
	curves are available:
</t>
<figure>
    <artwork>
     Algorithm    Curve            Values

     EdDSA        RESERVED         0
     EdDSA        EdDSA25519       1 [RFC8032]
     EdDSA        EdDSA25519ph     2 [RFC8032]
     EdDSA        EdDSA448         3 [RFC8032]
     EdDSA        EdDSA448ph       4 [RFC8032]
    </artwork>
</figure>
</section>
<section anchor="hit_suite_list" title="HIT_SUITE_LIST">
	<t>
		The HIT_SUITE_LIST parameter contains a list of the supported 
		HIT suite IDs of the Responder. Based on the HIT_SUITE_LIST, 
		the Initiator can determine which source HIT Suite IDs are 
		supported by the Responder. The HIT_SUITE_LIST parameter is 
		defined in Section 5.2.10 of <xref target="RFC7401" />.
	</t>
	<t>
		The following HIT Suite ID is defined, and the relationship 
		between the four-bit ID value used in the OGA ID field and the 
		eight-bit encoding within the HIT_SUITE_LIST ID field is 
		clarified:
	</t>
<figure>
    <artwork>
     HIT Suite       Four-bit ID    Eight-bit encoding
     RESERVED            0             0x00
     EdDSA/SHAKE128      5             0x50           (RECOMMENDED)
    </artwork>
</figure>
<t>
	The following table provides more detail on the above HIT Suite 
	combinations.  The input for each generation algorithm is the 
	encoding of the HI as defined in <xref target="gener_hit" />. The 
	output is 96 bits long and is directly used in the ORCHID.
</t>
	<texttable title="HIT Suites" anchor="table_hit_suites">
	<ttcol align="right">Index</ttcol>
	<ttcol align="left">Hash function</ttcol>
	<ttcol align="left">HMAC</ttcol>
	<ttcol align="left">Signature algorithm family</ttcol>
	<ttcol align="left">Description</ttcol>
	<c>5</c> <c>SHAKE128</c> <c>KMAC128</c> <c>EdDSA</c> <c>EdDSA HI hashed with cSHAKE128, output is 96 bits</c>

	</texttable>
</section>
</section>
<section anchor="hash" title="Hashing with the Keccak Function">
<t>
	The <xref target="Keccak">Keccak</xref> sponge function is the 
	basis for the new SHA-3, standard <xref target="NIST.FIPS.202">NIST 
	FIPS 202</xref>, and the customized XOF functions in <xref 
	target="NIST.SP.800-185">NIST SP 800-185</xref>.  These are used 
	here as an alternative to all the hashing functions in HIP.
</t>
<t>
	Hardware implementation of Keccak in VHDL is available from <xref 
	target="Keccak">Keccak</xref>.
</t>
<section anchor="Keccak_P" title="The Keccak Permutation">
<t>
	Keccak is described as a sponge function.  The analogy to a 
	sponge is that an arbitrary number of input bits are "absorbed" 
	into the state of the function, after which an arbitrary number of 
	output bits are "squeezed" out of its state.
	<list >
<t>
		The Keccak function is defined to have a width of b bits.  
		Where b is the capacity (c) + rate (r).
</t>
<t>
	The rate is the number of bits "fed" into the sponge at a time.
</t>
<t>
	The capacity is twice the desired hash "strength" and part of the 
	sponge width.
</t>
	</list>
</t>
<t>
	b is one of the set {25, 50, 100, 200, 400, 800, 1600}.  In FIPS 
	202, b=1600.  Thus a hash strength of 128 bits can be delivered 
	with c=256 and r=1344, or 168 byte segment input to the sponge.
</t>
<t>
	Keccak can also provide a hash strength of 128 bit with b=800 
	(r=544 or 68 bytes) and b=400 (r=144 or 18 bytes).  256 bit 
	strength can only be provided with b=1600 or 800.
</t>
<t>
	FIPS 202 does not specify use of these smaller values for b which 
	may be preferred in memory constrained devices, processing 
	relatively short input strings.  Future work will determine if the 
	smaller values for b result in a significant performance/memory 
	improvement to warrant their use.
</t>
</section>
<section anchor="rhash" title="RHASH">
<t>
	The RHASH is the general term used throughout <xref 
	target="RFC7401" /> to refer to the hash used for a specific HIT 
	suite.  For this addendum SHAKE128 is used, even for HIs of 
	EdDSA448.
</t>
<t>
	Unless otherwise specified, L of SHAKE128 is 256, resulting in a 
	similar output to SHA256.  Any truncation used for, older, fixed 
	output hashes is still used.  This is to simplify code 
	integration.  One exception to this is in <xref target="gener_hit" 
	/>.
</t>
</section>
<section anchor="hip_macs" title="HIP_MAC and HIP_MAC2">
<t>
	The HIP_MAC and HIP_MAC2 parameters in <xref target="RFC7401" /> 
	use HMAC <xref target="RFC2104" />.  This performs two hashes on a 
	string with a key for a keyed hash the length of the underlying hash.
</t>
<t>
	Here, KMAC from <xref target="NIST.SP.800-185">NIST SP 
	800-185</xref> is used.  This is a single pass using the underlying 
	cSHAKE function.  The function call is:
</t>
<figure>
    <artwork>
     KMAC128(Key, Input String, 256, "")
    </artwork>
</figure>
</section>
</section>
<section anchor="keyak" title="HIP Cipher">
<t>
	HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of <xref 
	target="RFC7401" />.  The Keccak Keyak cipher, ref, is recommended. 
	Keyak is a candidate in the NIST Lightweight Cryptography 
	competition and is consistent with the overall approach in this 
	addendum to use Keccak functions for simplicity in design and 
	implementation.
</t>
<section anchor="hip_cipher" title="HIP_CIPHER">
<t>
	The HIP_CIPHER parameter values for Keyak are:
</t>
<figure>
      <artwork>hip_cipher
     Suite ID           Value

     RIVER KEYAK        6     (Keyak)
     LAKE KEYAK         7     (Keyak)
      </artwork>
</figure>

<t>
	For use as the HIP Cipher, the TAG generated in Keyak is discarded. 
	The Keyak SUV is the key plus IV specified for the encrypted 
	parameter.  River Keyak MAY be used for <xref 
	target="I-D.ietf-hip-dex"> </xref>, in place of AES-CTR.
</t>
<t>
	Lake Keyak can provide 256 bits of security by following the 
	recommendations for the Keyak cipher.
</t>
</section>
</section>
</section>
<section anchor="gener_hit" title="Generating a HIT from an HI">
<t>
	The EdDSA/cSHAKE based HITs vary slightly the ORCHID generation 
	method described in section 3.2 of <xref target="RFC7401" />.  The 
	XOF functionality of cSHAKE produces an output of L bits.  This 
	replaces the Encode_96 function in the ORCHID generation.
</t>
<t>
	For identities that are EdDSA public keys, the ORCHID input 
	consists of the public key encoding as specified for the Host 
	Identity field of the HOST_ID parameter (see <xref 
	target="host_id"/>).  Since L is less than 128, cSHAKE128 is used 
	for all EdDSA curve sizes:
</t>
<figure>
    <artwork>
     cSHAKE128(EdDSA public key, 96, "", Context ID)
    </artwork>
</figure>
</section>
<section anchor="hip_keymat" title="HIP KEYMAT Generation">
<t>
	The KMAC function provides a new, more efficient, key derivation 
	function over HKDF <xref target="RFC5869" />.  This will be 
	referred to as KKDF.
</t>
<t>
	The choice of KMAC128 or KMAC256 is based on the strength of the 
	output key material.  For 256 bits of strength equivalent to 
	HMAC-SHA256, use KMAC256.  Per <xref 
	target="NIST.SP.800-56Cr1">NIST SP 800-56Cr1</xref>, Section 4.1, 
	Option 3:
</t>
<figure>
    <artwork>
     OKM = KMAC[128|256](salt | info, IKM, L, S)
    </artwork>
</figure>
<t>
	L is the derived key bit length.  Since 4 HIP keys are "drawn" from 
	this output, the length is 4 * HIP_key_size.  Per <xref 
	target="ASIACRYPT-2017">ASIACRYPT 2017, pp. 606-637</xref> each of 
	these derived keys will have the same strength as the 
	Diffie-Hellman shared secret.
</t>
<t>
	S is the byte string 01001011 || 01000100 || 01000110, which 
	represents the sequence of characters “K”, “D”, and “F” in 8-bit 
	ASCII.
</t>
<t>
	Salt and info are derived as defined in <xref target="RFC7401" /> 
	or <xref target="I-D.ietf-hip-dex"> </xref>.  There are special 
	security considerations for IKM per <xref target="RFC7748" />.  The 
	two HIs MUST be used in constructing IKM as follows:
</t>
<figure>
    <artwork>
     IKM = Diffie-Hellman secret | HI-R |  HI-I
    </artwork>
</figure>
<t>
	These are separately DER encoded.
</t>
</section>
<section anchor="PRF" title="Using Keccak for a Pseudorandom Function">
<t>
	Appendix B of <xref target="NIST.SP.800-185">NIST SP 800-185</xref> 
	defines how to use SHAKE, cSHAKE, or KMAC as a PRF.
</t>
</section>

<section anchor="IANA" title="IANA Considerations">
    <t>
	  IANA will need to make the following changes to the "Host 
	  Identity Protocol (HIP) Parameters" registries:
    </t>
    <t>
      <list style="hanging">
        <t hangText="Diffie Hellman:">
		  This document defines the new Curve25519 and Curve448 for the 
		  Diffie-Hellman exchange (see <xref target="Diffie_Hellman" 
		  />).
        </t>
        <t hangText="Host ID:">
		  This document defines the new EdDSA Host ID (see <xref 
		  target="host_id" />).
        </t>
        <t hangText="HIT Suite ID:">
		  This document defines the new HIT Suite of EdDSA/cSHAKE (see 
		  <xref target="hit_suite_list" />).
        </t>
        <t hangText="HIP Cipher:">
		  This document defines the new Keyak ciphers for HIP encrypted 
		  parameters (see <xref target="hip_cipher" />).
        </t>
      </list>
    </t>
</section>
<section title="Security Considerations">
<section anchor="keymat_security" title="Keymat vulnerabilities">
<t>
	<xref target="RFC7748" /> warns about using Curve25519 and Curve448 
	in Diffie-Hellman for key derivation:
</t>
<t>
	Designers using these curves should be aware that for each public 
	key, there are several publicly computable public keys that are 
	equivalent to it, i.e., they produce the same shared secrets.  Thus 
	using a public key as an identifier and knowledge of a shared 
	secret as proof of ownership (without including the public keys in 
	the key derivation) might lead to subtle vulnerabilities.
</t>
<t>
	This applies to <xref target="I-D.ietf-hip-dex"> </xref>, but may 
	have broader consequences.  Thus the two Host IDs are included with 
	the Diffie-Hellman secret.
</t>
</section>
</section>
<section title="Acknowledgments">
<t>
	Quynh Dang of NIST gave considerable guidance on using Keccak and 
	the NIST supporting documents.  Joan Deamen of the Keccak team was 
	especially helpful in many aspects of using Keccak, particularly 
	with the KEYMAT section and the strength of the derived keys.
</t>
</section>
</middle>
<back>
<references title="Normative References">
	<?rfc include="reference.RFC.2119.xml"?>
	<?rfc include="reference.RFC.8174.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/NIST.FIPS.202.xml?anchor=NIST.FIPS.202"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/NIST.SP.800-185.xml?anchor=NIST.SP.800-185"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/NIST.SP.800-56Cr1.xml?anchor=NIST.SP.800-56Cr1"?>
</references>
<references title="Informative References">
	<?rfc include="reference.RFC.2104.xml"?>
	<?rfc include="reference.RFC.5869.xml"?>
	<?rfc include="reference.RFC.7401.xml"?>
	<?rfc include="reference.RFC.7748.xml"?>
	<?rfc include="reference.RFC.8032.xml"?>
	<?rfc include="reference.I-D.ietf-hip-dex.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.1007/978-3-319-70697-9_21.xml?anchor=ASIACRYPT-2017"?>
<reference anchor="Keccak" target="https://keccak.team/index.html">
  <front>
    <title>The Keccak</title>
<author fullname="Guido Bertoni" initials="G." surname="Bertoni"> 
	<address/> 
</author> 
<author fullname="Joan Daemen" initials="J." surname="Daemen"> 
	<organization>Radboud University</organization>
	<address/> 
</author> 
<author fullname="Michaël Peeters" initials="M." surname="Peeters"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<author fullname="Gilles Van Assche" initials="G." surname="Van Assche"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<author fullname="Ronny Van Keer" initials="R." surname="Van Keer"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<date/>
</front>
</reference>
</references>
</back>
</rfc>

--------------99ECA65A64726744F5116F1D--


From nobody Wed Sep 25 11:42:44 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39562120859 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 Q0_9ValfBBp6 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:42:41 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361A3120842 for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 11:42:41 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46dn3z4PxyzyY2; Wed, 25 Sep 2019 20:42:39 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <d1f43ef6-ba8b-cc30-c1fd-1b27edde24f4@htt-consult.com>
Date: Wed, 25 Sep 2019 20:42:39 +0200
Cc: Alice Russo <arusso@amsl.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
X-Mao-Original-Outgoing-Id: 591129757.729972-71a2f595d75ffa94f2134946217975c4
Content-Transfer-Encoding: quoted-printable
Message-Id: <B37A8438-2EC8-4492-9E6C-8A175C6105D5@tzi.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com> <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com> <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org> <F43BC3B4-D1AE-47D1-A2E5-7EBCCDBFF4C7@tzi.org> <d1f43ef6-ba8b-cc30-c1fd-1b27edde24f4@htt-consult.com>
To: Robert Moskowitz <rgm@htt-consult.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/vUsou64ktMe9mEoq8ori2fEWPqE>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 18:42:43 -0000

On Sep 25, 2019, at 20:33, Robert Moskowitz <rgm@htt-consult.com> wrote:
>=20
> And when I try:  https://xml2rfc.tools.ietf.org/
>=20
> I get the same problem:

Yep, verified with kdrfc -r (which is a front end to calling =
kramdown-rfc and using the remote xml2rfc service).

   [ASIACRYPT-2017]
              Daemen, J., Mennink, B., and G. Van Assche, "Full-State
              Keyed Duplex with Built-In Multi-user Support", Advances
              in Cryptology a&#128;&#147; ASIACRYPT 2017 pp. 606-637,
              DOI 10.1007/978-3-319-70697-9_21, 2017.

I can=E2=80=99t reproduce this with a local xml2rfc even when switching =
to Python v2 (I think).
The next thing I=E2=80=99d try would be different locale settings, but =
I=E2=80=99m too exhausted to do this now.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Wed Sep 25 11:49:44 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835BA120810 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 tKuNPU4qw9cW for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 11:49:41 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3131207FF for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 11:49:41 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46dnD302GjzyY2; Wed, 25 Sep 2019 20:49:38 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <B37A8438-2EC8-4492-9E6C-8A175C6105D5@tzi.org>
Date: Wed, 25 Sep 2019 20:49:38 +0200
Cc: Alice Russo <arusso@amsl.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
X-Mao-Original-Outgoing-Id: 591130176.837323-486a66a14bb292d090ab9af2341ffe9f
Content-Transfer-Encoding: quoted-printable
Message-Id: <C694FEAF-D432-464C-AC5E-2F6C92A53B96@tzi.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com> <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com> <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org> <F43BC3B4-D1AE-47D1-A2E5-7EBCCDBFF4C7@tzi.org> <d1f43ef6-ba8b-cc30-c1fd-1b27edde24f4@htt-consult.com> <B37A8438-2EC8-4492-9E6C-8A175C6105D5@tzi.org>
To: Robert Moskowitz <rgm@htt-consult.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/5hoNLDodk3MCnsDew4aAmd879EY>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 18:49:43 -0000

Hmm, it does not happen if I expand the reference to the XML myself.
A problem with <?rfc include?> ?

Gr=C3=BC=C3=9Fe, Carsten


> On Sep 25, 2019, at 20:42, Carsten Bormann <cabo@tzi.org> wrote:
>=20
> On Sep 25, 2019, at 20:33, Robert Moskowitz <rgm@htt-consult.com> =
wrote:
>>=20
>> And when I try:  https://xml2rfc.tools.ietf.org/
>>=20
>> I get the same problem:
>=20
> Yep, verified with kdrfc -r (which is a front end to calling =
kramdown-rfc and using the remote xml2rfc service).
>=20
>   [ASIACRYPT-2017]
>              Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>              Keyed Duplex with Built-In Multi-user Support", Advances
>              in Cryptology a&#128;&#147; ASIACRYPT 2017 pp. 606-637,
>              DOI 10.1007/978-3-319-70697-9_21, 2017.
>=20
> I can=E2=80=99t reproduce this with a local xml2rfc even when =
switching to Python v2 (I think).
> The next thing I=E2=80=99d try would be different locale settings, but =
I=E2=80=99m too exhausted to do this now.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
>=20
>=20


From nobody Wed Sep 25 12:17:43 2019
Return-Path: <ietf@augustcellars.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DAA120288 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 12:17:40 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 pAsAYr_utxw2 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 12:17:39 -0700 (PDT)
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 A661F12022C for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 12:17:38 -0700 (PDT)
Received: from Jude (192.168.1.159) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 25 Sep 2019 12:17:28 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Robert Moskowitz' <rgm@htt-consult.com>, 'Carsten Bormann' <cabo@tzi.org>
CC: <xml2rfc@ietf.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com> <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com> <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org> <F43BC3B4-D1AE-47D1-A2E5-7EBCCDBFF4C7@tzi.org> <d1f43ef6-ba8b-cc30-c1fd-1b27edde24f4@htt-consult.com>
In-Reply-To: <d1f43ef6-ba8b-cc30-c1fd-1b27edde24f4@htt-consult.com>
Date: Wed, 25 Sep 2019 12:17:26 -0700
Message-ID: <01bf01d573d5$e0012f60$a0038e20$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKjoTqU20UtCvZA9v9QClm5+gwDGAFFplExAPFGSlMBzip0owFHfk8BAkUOpTsB+/NTVwJEZF5ypUHZOPA=
Content-Language: en-us
X-Originating-IP: [192.168.1.159]
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/IpmdKY9kfzvj4J9bQaXWbJ2Uf1o>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 19:17:41 -0000

Run away from Python v2 as soon as you want something other than ASCII - =
it does not like Unicode by default and it is easy to get the =
programming wrong.

-----Original Message-----
From: xml2rfc <xml2rfc-bounces@ietf.org> On Behalf Of Robert Moskowitz
Sent: Wednesday, September 25, 2019 11:33 AM
To: Carsten Bormann <cabo@tzi.org>
Cc: xml2rfc@ietf.org
Subject: Re: [xml2rfc] BibTeX Citation in xml



On 9/25/19 2:18 PM, Carsten Bormann wrote:
> On Sep 25, 2019, at 20:10, Carsten Bormann <cabo@tzi.org> wrote:
>> Something is very broken with the XML2RFC you are using (or with a =
firewall you are going through).
> I get
>
>     [DUPLEX]   Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>                Keyed Duplex with Built-In Multi-user Support", =
Advances
>                in Cryptology - ASIACRYPT 2017 pp. 606-637,
>                DOI 10.1007/978-3-319-70697-9_21, 2017.
>
> (Oops, should have used your label instead of DUPLEX.)
>
> Oh, xml2rfc 2.26.0
>
> Retrying with xml2rfc 2.30.0:
>
>     [DUPLEX]   Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>                Keyed Duplex with Built-In Multi-user Support", =
Advances
>                in Cryptology - ASIACRYPT 2017 pp. 606-637,
>                DOI 10.1007/978-3-319-70697-9_21, 2017.
>
> Hmm, works for me.  (This is with Python V3 on a High Sierra Mac.)

I am using xml2rfc v2.30.0, Python V2 on my Fedora 30 system.

And when I try:  https://xml2rfc.tools.ietf.org/

I get the same problem:

    [ASIACRYPT-2017]
               Daemen, J., Mennink, B., and G. Van Assche, "Full-State
               Keyed Duplex with Built-In Multi-user Support", Advances
               in Cryptology a&#128;&#147; ASIACRYPT 2017 pp. 606-637,
               DOI 10.1007/978-3-319-70697-9_21, 2017.


xml attached



From nobody Wed Sep 25 12:38:54 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B40B1202DD for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 12:38:52 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 1xhIEs714c_D for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 12:38:50 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3A41200CD for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 12:38:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4897E615EB; Wed, 25 Sep 2019 15:38:48 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GCv8KoQxwbxI; Wed, 25 Sep 2019 15:38:42 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 6826D60029; Wed, 25 Sep 2019 15:38:42 -0400 (EDT)
To: Jim Schaad <ietf@augustcellars.com>, 'Carsten Bormann' <cabo@tzi.org>
Cc: xml2rfc@ietf.org
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com> <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com> <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org> <F43BC3B4-D1AE-47D1-A2E5-7EBCCDBFF4C7@tzi.org> <d1f43ef6-ba8b-cc30-c1fd-1b27edde24f4@htt-consult.com> <01bf01d573d5$e0012f60$a0038e20$@augustcellars.com>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <f7186618-524f-3092-0e4e-52649a467fb6@htt-consult.com>
Date: Wed, 25 Sep 2019 15:38:34 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <01bf01d573d5$e0012f60$a0038e20$@augustcellars.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/6opBe5fQK39GRBaqoYbKN_ydLXU>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 19:38:52 -0000

I lost my notes on how to run xml2rfc under python3.  Plus I probably 
have to run pip under P3 first?

On 9/25/19 3:17 PM, Jim Schaad wrote:
> Run away from Python v2 as soon as you want something other than ASCII - it does not like Unicode by default and it is easy to get the programming wrong.
>
> -----Original Message-----
> From: xml2rfc <xml2rfc-bounces@ietf.org> On Behalf Of Robert Moskowitz
> Sent: Wednesday, September 25, 2019 11:33 AM
> To: Carsten Bormann <cabo@tzi.org>
> Cc: xml2rfc@ietf.org
> Subject: Re: [xml2rfc] BibTeX Citation in xml
>
>
>
> On 9/25/19 2:18 PM, Carsten Bormann wrote:
>> On Sep 25, 2019, at 20:10, Carsten Bormann <cabo@tzi.org> wrote:
>>> Something is very broken with the XML2RFC you are using (or with a firewall you are going through).
>> I get
>>
>>      [DUPLEX]   Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>>                 Keyed Duplex with Built-In Multi-user Support", Advances
>>                 in Cryptology - ASIACRYPT 2017 pp. 606-637,
>>                 DOI 10.1007/978-3-319-70697-9_21, 2017.
>>
>> (Oops, should have used your label instead of DUPLEX.)
>>
>> Oh, xml2rfc 2.26.0
>>
>> Retrying with xml2rfc 2.30.0:
>>
>>      [DUPLEX]   Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>>                 Keyed Duplex with Built-In Multi-user Support", Advances
>>                 in Cryptology - ASIACRYPT 2017 pp. 606-637,
>>                 DOI 10.1007/978-3-319-70697-9_21, 2017.
>>
>> Hmm, works for me.  (This is with Python V3 on a High Sierra Mac.)
> I am using xml2rfc v2.30.0, Python V2 on my Fedora 30 system.
>
> And when I try:  https://xml2rfc.tools.ietf.org/
>
> I get the same problem:
>
>      [ASIACRYPT-2017]
>                 Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>                 Keyed Duplex with Built-In Multi-user Support", Advances
>                 in Cryptology a&#128;&#147; ASIACRYPT 2017 pp. 606-637,
>                 DOI 10.1007/978-3-319-70697-9_21, 2017.
>
>
> xml attached
>
>


From nobody Wed Sep 25 13:40:53 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E1B1201DE for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 13:40:52 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 9SmsTNlfl_l3 for <xml2rfc@ietfa.amsl.com>; Wed, 25 Sep 2019 13:40:49 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A99120018 for <xml2rfc@ietf.org>; Wed, 25 Sep 2019 13:40:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6B2B5615EB; Wed, 25 Sep 2019 16:40:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wqGWrcNkha9N; Wed, 25 Sep 2019 16:40:38 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9C53C60029; Wed, 25 Sep 2019 16:40:38 -0400 (EDT)
From: Robert Moskowitz <rgm@htt-consult.com>
To: Jim Schaad <ietf@augustcellars.com>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com> <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com> <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org> <F43BC3B4-D1AE-47D1-A2E5-7EBCCDBFF4C7@tzi.org> <d1f43ef6-ba8b-cc30-c1fd-1b27edde24f4@htt-consult.com> <01bf01d573d5$e0012f60$a0038e20$@augustcellars.com> <f7186618-524f-3092-0e4e-52649a467fb6@htt-consult.com> <01c201d573dd$a47cb2e0$ed7618a0$@augustcellars.com>
Message-ID: <15aff92d-e240-cb46-08ee-9797645e55fa@htt-consult.com>
Date: Wed, 25 Sep 2019 16:40:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <01c201d573dd$a47cb2e0$ed7618a0$@augustcellars.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/YU5OQ3bLjqnW3_iQlcbRRN64c7A>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 20:40:52 -0000

On 9/25/19 4:13 PM, Jim Schaad wrote:
> Should just need to
>
> 1) uninstall your current xml2rfc so it is not in P2
> 2) install xml2rfc using "pip3"
> 3) if the right directories are in you path then xml2rfc will run the 
> same way. If you prefix it with python then you need to prefix it with 
> python3

I did all that and still get the character error:

$ pip uninstall xml2rfc
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 
2020. Please upgrade your Python as Python 2.7 won't be maintained after 
that date. A future version of pip will drop support for Python 2.7.
Uninstalling xml2rfc-2.30.0:
   Would remove:
     /home/rgm/.local/bin/xml2rfc
/home/rgm/.local/lib/python2.7/site-packages/xml2rfc-2.30.0-py2.7.egg-info
     /home/rgm/.local/lib/python2.7/site-packages/xml2rfc/*
Proceed (y/n)? y
   Successfully uninstalled xml2rfc-2.30.0

[rgm@lx140e drafts]$ pip3 install --user xml2rfc
Collecting xml2rfc
   Using cached 
https://files.pythonhosted.org/packages/5f/e9/af485545982f617820814ba60d7908747233f18fc2502cdf2204234e6831/xml2rfc-2.30.0.tar.gz
Collecting google-i18n-address>=2.3.2 (from xml2rfc)
   Downloading 
https://files.pythonhosted.org/packages/b4/e6/581d5a206a3cb04cdb75d51a979487a5718aa0fd3b30caf762719e21b12a/google_i18n_address-2.3.5-py2.py3-none-any.whl 
(773kB)
     100% |████████████████████████████████| 778kB 3.3MB/s
Requirement already satisfied: html5lib>=1.0.1 in 
/usr/lib/python3.7/site-packages (from xml2rfc) (1.0.1)
Collecting intervaltree!=3.0.0,>=2.1.0 (from xml2rfc)
   Downloading 
https://files.pythonhosted.org/packages/e8/f9/76237755b2020cd74549e98667210b2dd54d3fb17c6f4a62631e61d31225/intervaltree-3.0.2.tar.gz
Collecting kitchen>=1.2.6 (from xml2rfc)
   Using cached 
https://files.pythonhosted.org/packages/d9/ca/3365cb1160533be8c8b57dbfd6502f367d35e30935ee89a003c664740714/kitchen-1.2.6.tar.gz
Requirement already satisfied: lxml!=4.3.1,>=2.2.8 in 
/usr/lib64/python3.7/site-packages (from xml2rfc) (4.2.5)
Collecting pycountry!=19.7.15,>=1.8 (from xml2rfc)
   Downloading 
https://files.pythonhosted.org/packages/16/b6/154fe93072051d8ce7bf197690957b6d0ac9a21d51c9a1d05bd7c6fdb16f/pycountry-19.8.18.tar.gz 
(10.0MB)
     100% |████████████████████████████████| 10.0MB 1.1MB/s
Collecting pyflakes>=0.8.1 (from xml2rfc)
   Downloading 
https://files.pythonhosted.org/packages/84/f2/ed0ffb887f8138a8fe5a621b8c0bb9598bfb3989e029f6c6a85ee66628ee/pyflakes-2.1.1-py2.py3-none-any.whl 
(59kB)
     100% |████████████████████████████████| 61kB 6.3MB/s
Requirement already satisfied: requests>=2.5.0 in 
/usr/lib/python3.7/site-packages (from xml2rfc) (2.21.0)
Requirement already satisfied: setuptools>=18.0 in 
/usr/lib/python3.7/site-packages (from xml2rfc) (40.8.0)
Requirement already satisfied: six>=1.4.1 in 
/usr/lib/python3.7/site-packages (from xml2rfc) (1.12.0)
Requirement already satisfied: webencodings in 
/usr/lib/python3.7/site-packages (from html5lib>=1.0.1->xml2rfc) (0.5.1)
Collecting sortedcontainers<3.0,>=2.0 (from 
intervaltree!=3.0.0,>=2.1.0->xml2rfc)
   Downloading 
https://files.pythonhosted.org/packages/13/f3/cf85f7c3a2dbd1a515d51e1f1676d971abe41bba6f4ab5443240d9a78e5b/sortedcontainers-2.1.0-py2.py3-none-any.whl
Requirement already satisfied: chardet<3.1.0,>=3.0.2 in 
/usr/lib/python3.7/site-packages (from requests>=2.5.0->xml2rfc) (3.0.4)
Requirement already satisfied: idna<2.9,>=2.5 in 
/usr/lib/python3.7/site-packages (from requests>=2.5.0->xml2rfc) (2.7)
Requirement already satisfied: urllib3<1.25,>=1.21.1 in 
/usr/lib/python3.7/site-packages (from requests>=2.5.0->xml2rfc) (1.24.3)
Installing collected packages: google-i18n-address, sortedcontainers, 
intervaltree, kitchen, pycountry, pyflakes, xml2rfc
   Running setup.py install for intervaltree ... done
   Running setup.py install for kitchen ... done
   Running setup.py install for pycountry ... done
   Running setup.py install for xml2rfc ... done
Successfully installed google-i18n-address-2.3.5 intervaltree-3.0.2 
kitchen-1.2.6 pycountry-19.8.18 pyflakes-2.1.1 sortedcontainers-2.1.0 
xml2rfc-2.30.0

[rgm@lx140e drafts]$ xml2rfc draft-moskowitz-hip-new-crypto-01.xml
Warning: Illegal character replaced in string: &#128;
Warning: Illegal character replaced in string: &#147;
  Created file draft-moskowitz-hip-new-crypto-01.txt

Note that my python2.7 dir is still there dispite it saying it would 
delete it..

ls -ls /home/rgm/.local/lib
total 8
4 drwx------. 3 rgm rgm 4096 Sep 12 09:06 python2.7
4 drwxrwxr-x. 3 rgm rgm 4096 Sep 25 16:16 python3.7

ls -ls /home/rgm/.local/lib/python2.7/site-packages/
total 4
4 drwxrwxr-x. 2 rgm rgm 4096 Sep 12 09:06 xml2rfc-2.27.1-py2.7.egg-info


>
>
> -----Original Message-----
> From: Robert Moskowitz <rgm@htt-consult.com>
> Sent: Wednesday, September 25, 2019 12:39 PM
> To: Jim Schaad <ietf@augustcellars.com>; 'Carsten Bormann' <cabo@tzi.org>
> Cc: xml2rfc@ietf.org
> Subject: Re: [xml2rfc] BibTeX Citation in xml
>
> I lost my notes on how to run xml2rfc under python3. Plus I probably 
> have to run pip under P3 first?
>
> On 9/25/19 3:17 PM, Jim Schaad wrote:
>> Run away from Python v2 as soon as you want something other than 
>> ASCII - it does not like Unicode by default and it is easy to get the 
>> programming wrong.
>>
>> -----Original Message-----
>> From: xml2rfc <xml2rfc-bounces@ietf.org> On Behalf Of Robert Moskowitz
>> Sent: Wednesday, September 25, 2019 11:33 AM
>> To: Carsten Bormann <cabo@tzi.org>
>> Cc: xml2rfc@ietf.org
>> Subject: Re: [xml2rfc] BibTeX Citation in xml
>>
>>
>>
>> On 9/25/19 2:18 PM, Carsten Bormann wrote:
>>> On Sep 25, 2019, at 20:10, Carsten Bormann <cabo@tzi.org> wrote:
>>>> Something is very broken with the XML2RFC you are using (or with a 
>>>> firewall you are going through).
>>> I get
>>>
>>> [DUPLEX] Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>>> Keyed Duplex with Built-In Multi-user Support", Advances
>>> in Cryptology - ASIACRYPT 2017 pp. 606-637,
>>> DOI 10.1007/978-3-319-70697-9_21, 2017.
>>>
>>> (Oops, should have used your label instead of DUPLEX.)
>>>
>>> Oh, xml2rfc 2.26.0
>>>
>>> Retrying with xml2rfc 2.30.0:
>>>
>>> [DUPLEX] Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>>> Keyed Duplex with Built-In Multi-user Support", Advances
>>> in Cryptology - ASIACRYPT 2017 pp. 606-637,
>>> DOI 10.1007/978-3-319-70697-9_21, 2017.
>>>
>>> Hmm, works for me. (This is with Python V3 on a High Sierra Mac.)
>> I am using xml2rfc v2.30.0, Python V2 on my Fedora 30 system.
>>
>> And when I try: https://xml2rfc.tools.ietf.org/
>>
>> I get the same problem:
>>
>> [ASIACRYPT-2017]
>> Daemen, J., Mennink, B., and G. Van Assche, "Full-State
>> Keyed Duplex with Built-In Multi-user Support", Advances
>> in Cryptology a&#128;&#147; ASIACRYPT 2017 pp. 606-637,
>> DOI 10.1007/978-3-319-70697-9_21, 2017.
>>
>>
>> xml attached
>>
>>
>



From nobody Wed Sep 25 13:42:07 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADAD120018; Wed, 25 Sep 2019 13:42:06 -0700 (PDT)
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, SPF_HELO_NONE=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 LF5ptY0nYSCb; Wed, 25 Sep 2019 13:42:04 -0700 (PDT)
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 B1A97120124; Wed, 25 Sep 2019 13:42:04 -0700 (PDT)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1iDE6u-0004WP-Ev; Wed, 25 Sep 2019 13:42:04 -0700
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: <E1iDE6u-0004WP-Ev@durif.tools.ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Wed, 25 Sep 2019 13:42:04 -0700
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/KpbAkKxAubsq31kfxRVKgDxMBvA>
Subject: [xml2rfc] New xml2rfc release: v2.31.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 20:42:07 -0000

Hi,

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

Release notes:

xml2rfc (2.31.0) ietf; urgency=medium

  This release adds a feature to help with conditional line breaking
  inside table cells, and tweaks the layout of text in cells slightly.  It
  also fixes an incorrect line-break point and second-line indentation for
  long section titles in the v3 text formatter.  From the commit log:

  * Fixed an issue with leading and trailing space padding in table cells, 
    and refined it to consider the alignment setting.

  * Modified the text formatter to accept &zwsp; as a potential line-break 
    point.

  * Included zwsp in allowed special characters (in addition to nbsp, nbhy, 
    word-joiner and line-separator).

  * Fixed the line-breaking and second-line indentation of section titles 
    in v3 text output.

  * The start of an emacs nXML mode schema which explicitly mentions 
    xinclud in a couple of places.

  * Removed code left in pdf.py by mistake, and set options.pdf=True when 
    in the PdfWriter.

 -- Henrik Levkowetz <henrik@levkowetz.com>  25 Sep 2019 13:38:34 -0700

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.31.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Wed Sep 25 13:57:25 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7651201E3; Wed, 25 Sep 2019 13:57:10 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 d9BojBwNe-Qs; Wed, 25 Sep 2019 13:57:08 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF25120124; Wed, 25 Sep 2019 13:57:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 21F39615EB; Wed, 25 Sep 2019 16:57:07 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id M9LB6qV35MOY; Wed, 25 Sep 2019 16:57:01 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3DE9260029; Wed, 25 Sep 2019 16:56:57 -0400 (EDT)
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
References: <E1iDE6u-0004WP-Ev@durif.tools.ietf.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <445c7666-57bb-cb3b-f95e-e2186aea92a7@htt-consult.com>
Date: Wed, 25 Sep 2019 16:56:53 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <E1iDE6u-0004WP-Ev@durif.tools.ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/W98AdJpARziXC4m5g0fIRP0KF4g>
Subject: Re: [xml2rfc] New xml2rfc release: v2.31.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 20:57:10 -0000

This does not fix my character problem (probably was not intended to do 
that):

$ xml2rfc draft-moskowitz-hip-new-crypto-01.xml
Warning: Illegal character replaced in string: &#128;
Warning: Illegal character replaced in string: &#147;
  Created file draft-moskowitz-hip-new-crypto-01.txt

$ xml2rfc --version
xml2rfc 2.31.0


On 9/25/19 4:42 PM, Henrik Levkowetz wrote:
> Hi,
>
> This is an automatic notification about a new xml2rfc release,
> v2.31.0, generated when running the mkrelease script.
>
> Release notes:
>
> xml2rfc (2.31.0) ietf; urgency=medium
>
>    This release adds a feature to help with conditional line breaking
>    inside table cells, and tweaks the layout of text in cells slightly.  It
>    also fixes an incorrect line-break point and second-line indentation for
>    long section titles in the v3 text formatter.  From the commit log:
>
>    * Fixed an issue with leading and trailing space padding in table cells,
>      and refined it to consider the alignment setting.
>
>    * Modified the text formatter to accept &zwsp; as a potential line-break
>      point.
>
>    * Included zwsp in allowed special characters (in addition to nbsp, nbhy,
>      word-joiner and line-separator).
>
>    * Fixed the line-breaking and second-line indentation of section titles
>      in v3 text output.
>
>    * The start of an emacs nXML mode schema which explicitly mentions
>      xinclud in a couple of places.
>
>    * Removed code left in pdf.py by mistake, and set options.pdf=True when
>      in the PdfWriter.
>
>   -- Henrik Levkowetz <henrik@levkowetz.com>  25 Sep 2019 13:38:34 -0700
>
> 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.31.0'
>
> Regards,
>
> 	Henrik
> 	(via the mkrelease script)
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc


From nobody Wed Sep 25 14:09:34 2019
Return-Path: <henrik@levkowetz.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0128A1207FD; Wed, 25 Sep 2019 14:09:17 -0700 (PDT)
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, SPF_HELO_NONE=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 LWlvVHQAr_oM; Wed, 25 Sep 2019 14:09:15 -0700 (PDT)
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 C156C12022C; Wed, 25 Sep 2019 14:09:15 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:52828 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 1iDEXC-0005Ec-Ni; Wed, 25 Sep 2019 14:09:15 -0700
To: Robert Moskowitz <rgm@htt-consult.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
References: <E1iDE6u-0004WP-Ev@durif.tools.ietf.org> <445c7666-57bb-cb3b-f95e-e2186aea92a7@htt-consult.com>
Cc: rfc-markdown@ietf.org
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <0b295bd9-8f2a-6eb9-bf04-911f5635aeab@levkowetz.com>
Date: Wed, 25 Sep 2019 23:09:06 +0200
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: <445c7666-57bb-cb3b-f95e-e2186aea92a7@htt-consult.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UqOvv7TkHCdI9aSmqKo8IaeA4CsnHFVNu"
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, rgm@htt-consult.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/3WRuwv3TBiy0dz_exfXzn5BpZrw>
Subject: Re: [xml2rfc] New xml2rfc release: v2.31.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 21:09:18 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UqOvv7TkHCdI9aSmqKo8IaeA4CsnHFVNu
Content-Type: multipart/mixed; boundary="lSrBoTnhW8BtGF7NMwhrL1xiDsrBodaK2";
 protected-headers="v1"
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Robert Moskowitz <rgm@htt-consult.com>, xml2rfc-dev@ietf.org,
 xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-ID: <0b295bd9-8f2a-6eb9-bf04-911f5635aeab@levkowetz.com>
Subject: Re: [xml2rfc] New xml2rfc release: v2.31.0
References: <E1iDE6u-0004WP-Ev@durif.tools.ietf.org>
 <445c7666-57bb-cb3b-f95e-e2186aea92a7@htt-consult.com>
In-Reply-To: <445c7666-57bb-cb3b-f95e-e2186aea92a7@htt-consult.com>

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

Hi Bob,

On 2019-09-25 22:56, Robert Moskowitz wrote:
> This does not fix my character problem (probably was not intended to do=
=20
> that):
>=20
> $ xml2rfc draft-moskowitz-hip-new-crypto-01.xml
> Warning: Illegal character replaced in string: &#128;
> Warning: Illegal character replaced in string: &#147;
>   Created file draft-moskowitz-hip-new-crypto-01.txt

No, this release addressed some issues raised by the RFC-Editor staff.

FWIW, if you intend to move to v3, the seriesInfo name (where the
problem is, in this case) will not allow non-ASCII characters.  The
most straightforward approach is to include the reference information
in your document directly, and replace the unicode en-dash with an
ASCII dash:

<reference anchor=3D'ASIACRYPT-2017' >
  <front>
    <title>Full-State Keyed Duplex with Built-In Multi-user Support</titl=
e>
    <author initials=3D"J." surname=3D"Daemen" fullname=3D"Joan Daemen">
      <organization></organization>
    </author>
    <author initials=3D"B." surname=3D"Mennink" fullname=3D"Bart Mennink"=
>
      <organization></organization>
    </author>
    <author initials=3D"G." surname=3D"Van Assche" fullname=3D"Gilles Van=
 Assche">
      <organization></organization>
    </author>
    <date year=3D"2017"/>
  </front>
  <seriesInfo name=3D"Advances in Cryptology - ASIACRYPT 2017" value=3D"p=
p. 606-637"/>
  <seriesInfo name=3D"DOI" value=3D"10.1007/978-3-319-70697-9_21"/>
</reference>

The more general solution (which isn't available immediately) is that the=

bibxml7 script is modified to transcode non-ASCII punctuation to ASCII
equivalents.

xml2rfc does this for body text, to avoid unnecessary issues with smart
quotes etc., but it does not look at attribute values in reference entrie=
s
when doing this.  I don't know, maybe it should.  Or maybe not.


Regards,

	Henrik



>=20
> $ xml2rfc --version
> xml2rfc 2.31.0
>=20
>=20
> On 9/25/19 4:42 PM, Henrik Levkowetz wrote:
>> Hi,
>>
>> This is an automatic notification about a new xml2rfc release,
>> v2.31.0, generated when running the mkrelease script.
>>
>> Release notes:
>>
>> xml2rfc (2.31.0) ietf; urgency=3Dmedium
>>
>>    This release adds a feature to help with conditional line breaking
>>    inside table cells, and tweaks the layout of text in cells slightly=
=2E  It
>>    also fixes an incorrect line-break point and second-line indentatio=
n for
>>    long section titles in the v3 text formatter.  From the commit log:=

>>
>>    * Fixed an issue with leading and trailing space padding in table c=
ells,
>>      and refined it to consider the alignment setting.
>>
>>    * Modified the text formatter to accept &zwsp; as a potential line-=
break
>>      point.
>>
>>    * Included zwsp in allowed special characters (in addition to nbsp,=
 nbhy,
>>      word-joiner and line-separator).
>>
>>    * Fixed the line-breaking and second-line indentation of section ti=
tles
>>      in v3 text output.
>>
>>    * The start of an emacs nXML mode schema which explicitly mentions
>>      xinclud in a couple of places.
>>
>>    * Removed code left in pdf.py by mistake, and set options.pdf=3DTru=
e when
>>      in the PdfWriter.
>>
>>   -- Henrik Levkowetz <henrik@levkowetz.com>  25 Sep 2019 13:38:34 -07=
00
>>
>> 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.31.0'
>>
>> Regards,
>>
>> 	Henrik
>> 	(via the mkrelease script)
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/xml2rfc
>=20
>=20


--lSrBoTnhW8BtGF7NMwhrL1xiDsrBodaK2--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2L13IACgkQTptXS4+7
Fxr8rg//YQrfxXd9+Yh/4GqYL90LqiBUyScx50LCy91t6rcamHXOh/qksbqSjeRI
8EaSqWEEtvR9tdU2pUwWwWYPWf7lHNNHKJ+NLVCbHmc3Orqc64jBGnjhGB9av2D9
6QD0+mV/pxqAOsJrWAsI6fXjsjUL2HJG9QbchrNOqA/MUh8FLwafkd2g4D3NswwZ
K1TQIrrsCTkJrFEpykV0ZSE3MJ8DlNfYrB1unGLwQ1tEIXcC+j+cl3dmBEcUs2Gy
ssvV6wpMv7Nc5TYFYxiwFjJ9u2y4Qiej7ApzcFoSOG3FL/0fbtySF3oyLjDbMMr6
gPVBa/u1E1suDfb3GbIKuKSS1Mqt5OrFcEw4DOQGax8UyLCQRrj20/+8OM+opijR
7wqST282RMVXC/BrDlwgW/1yjJdFRaJ3FPIfIXfZx+IkY2/+DD30mNRTta078ZEq
yTiNKYlpdlyEyUUx/1m05aA1T9diJNdPVgj1tSponfx7uYNjVd3eTU4Tve2X7Ymx
j7hD31KRhCBzvLPFBtVEDlcEfSgoOThJF84C1ON4y2n2Mrn1SiAcfuqAqsalevj9
2Tx1DaI+TrTBmpmIuWzqACQDFil1VBwUa1qfuWw++92KRMf+WCgl4aYto9d63CTS
21vC1/L+A3/hnV3lclNHnd/qIVe2ry1Nn43QdVkgvoDzTyM6HBA=
=B75v
-----END PGP SIGNATURE-----

--UqOvv7TkHCdI9aSmqKo8IaeA4CsnHFVNu--


From nobody Wed Sep 25 14:32:18 2019
Return-Path: <rgm@htt-consult.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A71412004E; Wed, 25 Sep 2019 14:32:05 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 h_XFQfrZu8Di; Wed, 25 Sep 2019 14:32:03 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2A6120026; Wed, 25 Sep 2019 14:32:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DD35E615EB; Wed, 25 Sep 2019 17:32:01 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id m16yIZqn7mPL; Wed, 25 Sep 2019 17:31:54 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2C03A60029; Wed, 25 Sep 2019 17:31:52 -0400 (EDT)
To: Henrik Levkowetz <henrik@levkowetz.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
References: <E1iDE6u-0004WP-Ev@durif.tools.ietf.org> <445c7666-57bb-cb3b-f95e-e2186aea92a7@htt-consult.com> <0b295bd9-8f2a-6eb9-bf04-911f5635aeab@levkowetz.com>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <7031eb32-97b6-83f6-c359-7cb57d06fa64@htt-consult.com>
Date: Wed, 25 Sep 2019 17:31:44 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <0b295bd9-8f2a-6eb9-bf04-911f5635aeab@levkowetz.com>
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/6Nkhu17rRkZNFSsHEwCDTGUwptE>
Subject: Re: [xml2rfc] New xml2rfc release: v2.31.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 21:32:05 -0000

Hello Henrik,

On 9/25/19 5:09 PM, Henrik Levkowetz wrote:
> Hi Bob,
>
> On 2019-09-25 22:56, Robert Moskowitz wrote:
>> This does not fix my character problem (probably was not intended to do
>> that):
>>
>> $ xml2rfc draft-moskowitz-hip-new-crypto-01.xml
>> Warning: Illegal character replaced in string: &#128;
>> Warning: Illegal character replaced in string: &#147;
>>    Created file draft-moskowitz-hip-new-crypto-01.txt
> No, this release addressed some issues raised by the RFC-Editor staff.
>
> FWIW, if you intend to move to v3, the seriesInfo name (where the
> problem is, in this case) will not allow non-ASCII characters.  The
> most straightforward approach is to include the reference information
> in your document directly, and replace the unicode en-dash with an
> ASCII dash:
>
> <reference anchor='ASIACRYPT-2017' >
>    <front>
>      <title>Full-State Keyed Duplex with Built-In Multi-user Support</title>
>      <author initials="J." surname="Daemen" fullname="Joan Daemen">
>        <organization></organization>
>      </author>
>      <author initials="B." surname="Mennink" fullname="Bart Mennink">
>        <organization></organization>
>      </author>
>      <author initials="G." surname="Van Assche" fullname="Gilles Van Assche">
>        <organization></organization>
>      </author>
>      <date year="2017"/>
>    </front>
>    <seriesInfo name="Advances in Cryptology - ASIACRYPT 2017" value="pp. 606-637"/>
>    <seriesInfo name="DOI" value="10.1007/978-3-319-70697-9_21"/>
> </reference>

I will use this as a quick fix so I can get this submitted.

> The more general solution (which isn't available immediately) is that the
> bibxml7 script is modified to transcode non-ASCII punctuation to ASCII
> equivalents.

This sounds like the best path, as there will be other citations that 
will have non-ASCII codes.

> xml2rfc does this for body text, to avoid unnecessary issues with smart
> quotes etc., but it does not look at attribute values in reference entries
> when doing this.  I don't know, maybe it should.  Or maybe not.

But then if it is put into xml2rfc, it fixes it there and does not 
interfere with whatever else bibxml7 is used for?

Thanks

>
>
> Regards,
>
> 	Henrik
>
>
>
>> $ xml2rfc --version
>> xml2rfc 2.31.0
>>
>>
>> On 9/25/19 4:42 PM, Henrik Levkowetz wrote:
>>> Hi,
>>>
>>> This is an automatic notification about a new xml2rfc release,
>>> v2.31.0, generated when running the mkrelease script.
>>>
>>> Release notes:
>>>
>>> xml2rfc (2.31.0) ietf; urgency=medium
>>>
>>>     This release adds a feature to help with conditional line breaking
>>>     inside table cells, and tweaks the layout of text in cells slightly.  It
>>>     also fixes an incorrect line-break point and second-line indentation for
>>>     long section titles in the v3 text formatter.  From the commit log:
>>>
>>>     * Fixed an issue with leading and trailing space padding in table cells,
>>>       and refined it to consider the alignment setting.
>>>
>>>     * Modified the text formatter to accept &zwsp; as a potential line-break
>>>       point.
>>>
>>>     * Included zwsp in allowed special characters (in addition to nbsp, nbhy,
>>>       word-joiner and line-separator).
>>>
>>>     * Fixed the line-breaking and second-line indentation of section titles
>>>       in v3 text output.
>>>
>>>     * The start of an emacs nXML mode schema which explicitly mentions
>>>       xinclud in a couple of places.
>>>
>>>     * Removed code left in pdf.py by mistake, and set options.pdf=True when
>>>       in the PdfWriter.
>>>
>>>    -- Henrik Levkowetz <henrik@levkowetz.com>  25 Sep 2019 13:38:34 -0700
>>>
>>> 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.31.0'
>>>
>>> Regards,
>>>
>>> 	Henrik
>>> 	(via the mkrelease script)
>>>
>>> _______________________________________________
>>> xml2rfc mailing list
>>> xml2rfc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/xml2rfc
>>


From nobody Wed Sep 25 14:54:57 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C58120804; Wed, 25 Sep 2019 14:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 WY4F-wVsbQpA; Wed, 25 Sep 2019 14:54:36 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6B01200A4; Wed, 25 Sep 2019 14:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x8PLsLOS027488; Wed, 25 Sep 2019 23:54:26 +0200 (CEST)
Received: from [192.168.217.102] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 46dsK96B0pz1Bp8; Wed, 25 Sep 2019 23:54:21 +0200 (CEST)
Content-Type: multipart/alternative; boundary=Apple-Mail-282014A4-6050-4EA6-BDC5-11D901BB25CB
Mime-Version: 1.0 (1.0)
From: Carsten Bormann <cabo@tzi.org>
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <0b295bd9-8f2a-6eb9-bf04-911f5635aeab@levkowetz.com>
Date: Wed, 25 Sep 2019 23:54:21 +0200
Cc: Robert Moskowitz <rgm@htt-consult.com>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org, rfc-markdown@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <1D90CB28-78B2-4521-9D69-EAE387296E4B@tzi.org>
References: <E1iDE6u-0004WP-Ev@durif.tools.ietf.org> <445c7666-57bb-cb3b-f95e-e2186aea92a7@htt-consult.com> <0b295bd9-8f2a-6eb9-bf04-911f5635aeab@levkowetz.com>
To: Henrik Levkowetz <henrik@levkowetz.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/PgTJAxLwikSkUbm8C6EPVLm4JZM>
Subject: Re: [xml2rfc] [xml2rfc-dev]  New xml2rfc release: v2.31.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 21:54:39 -0000

--Apple-Mail-282014A4-6050-4EA6-BDC5-11D901BB25CB
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

It sure should. That en-dash *is* part of the Seriesinfo, and if rfcxml deci=
des to be unreasonable about that, the tools should help (especially given t=
hat you already have the code to regress the body text into the last century=
).=20

Sent from mobile, sorry for terse

> On 25. Sep 2019, at 23:09, Henrik Levkowetz <henrik@levkowetz.com> wrote:
>=20
>  I don't know, maybe it should.  Or maybe not.

--Apple-Mail-282014A4-6050-4EA6-BDC5-11D901BB25CB
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">It sure should. That en-dash *is* part of the Seriesinfo, and if rfcxml decides to be unreasonable about that, the tools should help (especially given that you already have the code to regress the body text into the last century).&nbsp;<br><br><div id="AppleMailSignature" dir="ltr">Sent from&nbsp;<span style="font-size: 13pt;">mobile, sorry for terse</span></div><div dir="ltr"><br>On 25. Sep 2019, at 23:09, Henrik Levkowetz &lt;<a href="mailto:henrik@levkowetz.com">henrik@levkowetz.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div dir="ltr">&nbsp;I don't know, maybe it should. &nbsp;Or maybe not.</div></blockquote></body></html>
--Apple-Mail-282014A4-6050-4EA6-BDC5-11D901BB25CB--


From nobody Thu Sep 26 00:44:58 2019
Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B6E12080F for <xml2rfc@ietfa.amsl.com>; Thu, 26 Sep 2019 00:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 w0mn6EhWJViw for <xml2rfc@ietfa.amsl.com>; Thu, 26 Sep 2019 00:44:54 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFBF1200FB for <xml2rfc@ietf.org>; Thu, 26 Sep 2019 00:44:54 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46f6QY0Ztbz10D4; Thu, 26 Sep 2019 09:44:53 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <01bf01d573d5$e0012f60$a0038e20$@augustcellars.com>
Date: Thu, 26 Sep 2019 09:44:52 +0200
Cc: Robert Moskowitz <rgm@htt-consult.com>, xml2rfc@ietf.org
X-Mao-Original-Outgoing-Id: 591176690.7978981-fb174182640f7eb68e11ba7e7d7cabb0
Content-Transfer-Encoding: quoted-printable
Message-Id: <48C24C57-23C4-4E0E-B89A-FA39FF72FF5F@tzi.org>
References: <28e0c62f-7c9a-cd80-9b5b-b07e174a620f@htt-consult.com> <dce2ae66-e148-a5c8-5f45-71de79d39677@htt-consult.com> <61f9b1b9-b20e-dec1-9b75-958e6ae7b4aa@htt-consult.com> <47575705-D614-4404-868C-9E14225EE3D8@amsl.com> <09e84fb4-bbe5-a09a-8847-505a34d2f0b2@htt-consult.com> <452A1CAC-FFA5-45FC-A9A2-52994A121C66@tzi.org> <F43BC3B4-D1AE-47D1-A2E5-7EBCCDBFF4C7@tzi.org> <d1f43ef6-ba8b-cc30-c1fd-1b27edde24f4@htt-consult.com> <01bf01d573d5$e0012f60$a0038e20$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/adjstssZMwtKXF-tUeFeA_odWWc>
Subject: Re: [xml2rfc] BibTeX Citation in xml
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 07:44:56 -0000

On Sep 25, 2019, at 21:17, Jim Schaad <ietf@augustcellars.com> wrote:
>=20
> Run away from Python v2 as soon as you want something other than ASCII =
- it does not like Unicode by default and it is easy to get the =
programming wrong.

Well, it is easy to get the programming wrong in any language :-)

The empirical data we have so far doesn=E2=80=99t point to Python v2 =
being the problem, this time.

There appears to be a real mojibake issue around <?rfc include=3D=E2=80=A6=
?> in xml2rfc, and that needs to be fixed.

(There also needs to be a decision to make the authoring side of RFCXML =
beyond-ASCII-resilient in text-carrying attributes(*) and not just in =
text content, but that is a separate issue.)

Gr=C3=BC=C3=9Fe, Carsten

(*) Which are a mistake that you are taught to avoid in XML 101, but =
it=E2=80=99s what we have in RFCXML today.


From nobody Thu Sep 26 23:33:18 2019
Return-Path: <miek@miek.nl>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2E1200CC for <xml2rfc@ietfa.amsl.com>; Thu, 26 Sep 2019 23:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.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 xYhGESfz0uGP for <xml2rfc@ietfa.amsl.com>; Thu, 26 Sep 2019 23:33:16 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 AA43D1200B9 for <xml2rfc@ietf.org>; Thu, 26 Sep 2019 23:33:15 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id p7so5214104wmp.4 for <xml2rfc@ietf.org>; Thu, 26 Sep 2019 23:33:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=0bMj9b0vgm1u5cAhKw5muiNJCGJZllB0RHu+wsWuFeg=; b=R7jPtHoFuHHW5e+tK5uiCoVc5ZB6fIhtB8GpxGHoBDq2euJh12JUvTjbPHkePAnz35 QfSqdGMkeNmYo0Wn/3L8gdRciSGraAzryqYD5hPKuXXjsaZ52k03DyuuKhg/Otpy9ktt qF0RyWT+RKlyLmo2guId41vnKH68OHwhqBeIixxeWOJ97bZSBZENdLrD+JiD9poUF5NR 3X+d21oRw5VdO/b28O/Y9QkdhKq+kpchrkx7OYxsV/yWyZJQs4NKimUxM3Wpf3Cu+0Nn YoDvNyXH9LSoflFLrqE7kjx3W3PmkCo70GYLNMChPrw2+iYHu29ogNm8JQLZdFn5OMar Jpog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=0bMj9b0vgm1u5cAhKw5muiNJCGJZllB0RHu+wsWuFeg=; b=WQv+qVAApHw/Mgw9oRZ6PwlizAfB3VAsIfcIeONOfKFxlj+vxxhoMW1315HxI9NfY6 gRDA2k0tES51dtTwsqV7Ccgme2VajDa5Y0c00HGnb6ghvXp74fTzAOhVSawR206jtpNB ve8OcGIuorMSN74jE9DL+gxSjPvL/8pNBH/CvuMQjfojQXzBT5jxQ7waal8bIBaauoqC mpEFx4d9Qdm4Qd7n9nBllHwI23Ar6CaTGQgAfSZNPtFBSpGvhtvfhB3u92vup2Fj5mP+ qoq8b51am1/7DBXB0/1SlUOxkohpF9VdhqX2H0ilqo0sgCDj3Mwx02xq7YQ/Wq2IlHrT Sj3w==
X-Gm-Message-State: APjAAAVt58Ex5tG5WfxIkqMQ2dFSq0NPbp2Jgo/w+OPuyoQGSPxWFFAh iHPGO//+vJgcyhNrHiIRVLn8TkxUckAe2g==
X-Google-Smtp-Source: APXvYqxZOKvZobv6zuH8AHLUS0YiVw2lz66SjYgaSpIOZrH6hE+4jQF19XM3uEV5TJsRNSW3kkwhLQ==
X-Received: by 2002:a1c:a617:: with SMTP id p23mr5853151wme.166.1569565993581;  Thu, 26 Sep 2019 23:33:13 -0700 (PDT)
Received: from miek.nl (router.mikrotime.com. [81.187.237.61]) by smtp.gmail.com with ESMTPSA id y186sm8586916wmd.26.2019.09.26.23.33.12 for <xml2rfc@ietf.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2019 23:33:12 -0700 (PDT)
Date: Fri, 27 Sep 2019 07:33:12 +0100
From: Miek Gieben <miek@miek.nl>
To: IETF xml2rfc <xml2rfc@ietf.org>
Message-ID: <20190927063312.GA18869@miek.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/YsnCRb1twxqxh28kTNC2Z6gL8yg>
Subject: [xml2rfc] metadata.min.js
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2019 06:33:18 -0000

Hi all, I was just playing with the html output of xml2rfc and noticed that not 
having 'metadata.min.js' with the html file makes a difference in the 
renderering. Notable the top header of the RFC fails to display (has bits like 
Status: and More Info: )

Does this mean the html *alone* is not authoritative? 

/Miek

--
Miek Gieben


From nobody Fri Sep 27 00:27:01 2019
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4557A1200BA for <xml2rfc@ietfa.amsl.com>; Fri, 27 Sep 2019 00:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.525
X-Spam-Level: 
X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYlruhU7k4jU for <xml2rfc@ietfa.amsl.com>; Fri, 27 Sep 2019 00:26:57 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30191200B9 for <xml2rfc@ietf.org>; Fri, 27 Sep 2019 00:26:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1569569211; bh=cEe9pr3S6r77xrR0xZFarEz7dBskbq53uK8Ue9SVfQw=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=XWztoPnB09Kbynd8aOGYC9gbRcj+56TTmKvCNH0s0mNJVkE4MLhb8+xphcp5oZ8Xz 2Vb2bltO2RU3liuW6VI5LeVKQZId+9+i91vxKVTsSTWAq+vOeqEryVCLicN0vXlGzc IlTrE55vaNmZ+0+73lbyjwk0WDHg5sXRW7yuRv6E=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McYCl-1hapra1jiv-00d1oK; Fri, 27 Sep 2019 09:26:51 +0200
To: Miek Gieben <miek@miek.nl>, IETF xml2rfc <xml2rfc@ietf.org>
References: <20190927063312.GA18869@miek.nl>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <156cc9ac-4262-59a4-ad9e-56869f98ec0e@gmx.de>
Date: Fri, 27 Sep 2019 09:26:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20190927063312.GA18869@miek.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:We0lihM+TDwvvoxBFrKb1KOpVuTToIaceUHxd5k4FUWApqNC9sE wybiulX5CzLAIYzLFzJGAFjgJaBafUwymJX79Tz8ee7LnmVZPQAnts7kYbwyzMKbS92WnKS +QjsqNi5NOwmyzhhA/iWxy5ttBtKr0ABMbM+I7ZA/IYON0pujF6Lt7J6kKkEh9mcC/qremH QCcCMas2sjJ+/THsXgU1g==
X-UI-Out-Filterresults: notjunk:1;V03:K0:mVXpVGXtlLw=:XlOdCaardKl2wPyXalJGpU vqFbN8tx7vdOO1+MMFft8dqlmc15DW9knRYhL7ecrS0i4mc49hrIaEt2FjQufO/crAQJRBTbj Uf98e6uweji26vlqjeYi6WK4i8j2gKikYoAmJva2eA+KEpM9uNDjIv3Ugks2Bp7L7Sd0c91IZ YF0/vMtHNvny4HhWTsdRPllf+nTb8faLLotmzYSqQxiJ+/qUNZ3QmcvI5d0XqaMmy//ST7G5j BLJfkdxo4XB6dY6BfWpP1sHuLjNyZmuOtXLWY3nrPw+pKKx24hAORZe4vwXLpyOiajlLoqR2v Opy9IBJQE8b1Rtb9yIc42vXo42AXhBk4DLf8ZgZjWr0rWH2f52ODRuNZhKMUIcqkbN74ubvKg 2a81YSsNyk2op6/z5PiXtSw0Ljx68ZHia0l86zKMsXUzHKEXYBT0srADyw7fpGXdJzuKXIAMo ywotKyO1rZFZJUQGwoAKq3vGykaUX4GgSkCmjPlL5mZPAz2hkh75Y8MHArBv6m8EM+E47nGeY btBej5CwytRGzF2exDBCzX6SEjXuTxdPg0keH2zleLCz1fbJstWduuyNhCn9F5vfVXWiErltO KEu5fJXljTfa4oVYBxm8VRb9Gne0ogaYAJ4qLXATyClz+DQuM7pJfDEmnowsPbI/TgbCHch4T 9Vhj9FUfzpE5Z23ns9YgnGiZ5jiObwOQioMGfjBt4t7OvkNFAf7rWHOwphBIgHGQv40QHawxW vPc83/p3JrAxNrlDKOlj5j76TVi19XmY7SIY3+Kv3yosehQFiaJf6jQa9gd/KuEjXxzSOOGxN 2mm75bCLk0GqVw8OxaEQDsX0oz+M4crNGg4Aet11jtvA0KwdxGyCNTdk3Y0hN0cWKWVpdvQz+ NqIP0yIkbBMKvVdFUlOWEe2el2dUK/uUNMBLOoAVLtlwzOgkqqpYTajxq2dPpgMuYJddz2iDZ sEAmLotULvplCAitw0YY+gMZ/gMZD3QO158CA05gZsBMuCOMSBZo6b9uBs/GcDTV+XMx6NPEN WP1L+ps1kLHoVgyvy1ctrPskR0rmZJbFawgyavVPnW5cdCP8SzB6kJfKbiwT75SGyUPwuBioT ZL6MxmBLK+zikPjZrE7NiGpda4Uo+mUC1Bty5s02f9cxHBZ2VScWZc6M8J0O1Ak9id8DFJv0t UTM0kQoKEw19agca6ElKhFEDsM9aI0Q4OLj5wQOPz0f14EUa3mQrJuCRhPW3y3hgZZ+vggmGg v8lij7mUHXFL6WnfOac2I8IuBsarko+4BdwEMNr1xDi+q69SkTJFVZB0M15E=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/sJLbTKcd1agbA0uforM-KogDOG4>
Subject: Re: [xml2rfc] metadata.min.js
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2019 07:26:59 -0000

On 27.09.2019 08:33, Miek Gieben wrote:
> Hi all, I was just playing with the html output of xml2rfc and noticed
> that not having 'metadata.min.js' with the html file makes a difference
> in the renderering. Notable the top header of the RFC fails to display
> (has bits like Status: and More Info: )
>
> Does this mean the html *alone* is not authoritative?
> /Miek

These are annotations that are not actually part of the RFC (neither
XML, nor HTML). If they were, they would be part of the XML.

Best regards, Julian


From nobody Fri Sep 27 00:38:35 2019
Return-Path: <miek@miek.nl>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD34120098 for <xml2rfc@ietfa.amsl.com>; Fri, 27 Sep 2019 00:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.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 UUqTeE0jWXir for <xml2rfc@ietfa.amsl.com>; Fri, 27 Sep 2019 00:38:32 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 6D698120045 for <xml2rfc@ietf.org>; Fri, 27 Sep 2019 00:38:32 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id w2so1205611qkf.2 for <xml2rfc@ietf.org>; Fri, 27 Sep 2019 00:38:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5sxTYLBlIzu3NXA37ygrgt60R7R+ueApBRGF4rp0hCE=; b=VV0dyFOFnkzduSLO5JtyDOLrgETPwaNnWC8m5ZxQooqR2GQqH5quvlIPCjPnu6b+Ga a+wZopcWVzxj55vXW5UlwBkrHBErHpGv5XWLiQEhnr+vSnjtp+eoWJ3LO+2BXUBOaHqD Wtorg5pp3KcmtlfuFsFb5bl0lKIDoIMgpYvyLwfGyUk8rhWslvHvz8umY8TUys1R/HQN OrhCPATs9ybOdRsk2qEP2oZnV3QK7SqL8ua1jTcIY7HNfwTERchGd+T3IyWF5eMF3U+B Bg5Yrfws6La8WBOmHLjAF3RQcddi/SFFOdvplsN+9FyUgmidHPlRI/sTWHg7Q4vbASO8 xwWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5sxTYLBlIzu3NXA37ygrgt60R7R+ueApBRGF4rp0hCE=; b=KcHyKsBkYYqC5fsifaM7NYTqO05jVXwIWJGIV+9Y10D+BIf2aTMfYmeHiVfRB2V/Lz CVqDWST0NUb0e1pzSdSdcTjrlExVRg+1xk1fhcrq6mNhQIma5F+5LMdY5gKIYJRLfRYD 6vfSv7JKPltCIJJVRVrY6QHBbkKwUszCMGbcGYEzBDw3fsdSSjrnNrNxWBzjgBeYBUfK v2nI7rBStO9vU2rY3MN/TvWGFEaDFvXgp7jFJKZUpZ18W2FqUp6Bx7eS4weJWqN61/gg 2ZHDRXliqlF9BjT54fMpOks6Y2oS7MdIw9fEPKNRJ7TTEO4nf49MyNc9IEu7CWmxqkFE 4tBA==
X-Gm-Message-State: APjAAAXVHun/0/T7kpR34g3O5qTwvnfYF+7+GdnFM06NC+x1iYqALGpC f7JQ1MmO+hxzPeRiczbuBybJzJvveGTCxIgrtqM/hg==
X-Google-Smtp-Source: APXvYqwJsMvu5O0wOrkdN24e2timGOtaiRl4y3KUfspBBk5P3Ml5ayb4ovqoGQrt7sb0txd2VVUsvkP3QiGbvOqt754=
X-Received: by 2002:a37:f70f:: with SMTP id q15mr3129206qkj.426.1569569911164;  Fri, 27 Sep 2019 00:38:31 -0700 (PDT)
MIME-Version: 1.0
References: <20190927063312.GA18869@miek.nl> <156cc9ac-4262-59a4-ad9e-56869f98ec0e@gmx.de>
In-Reply-To: <156cc9ac-4262-59a4-ad9e-56869f98ec0e@gmx.de>
From: Miek Gieben <miek@miek.nl>
Date: Fri, 27 Sep 2019 08:31:55 +0100
Message-ID: <CAJrXxANy7WshGBZUUNW2va1k08kVMvFVGB3FXOcg0XT0OXm8=A@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: XML2RFC Interest Group <xml2rfc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000001622e059383f9c3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/fkPtTeyouvX5yWvQcYQU3PsBMeI>
Subject: Re: [xml2rfc] metadata.min.js
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2019 07:38:34 -0000

--00000000000001622e059383f9c3
Content-Type: text/plain; charset="UTF-8"

Thanks for clarifying.

On Fri, 27 Sep 2019, 08:26 Julian Reschke, <julian.reschke@gmx.de> wrote:

> On 27.09.2019 08:33, Miek Gieben wrote:
> > Hi all, I was just playing with the html output of xml2rfc and noticed
> > that not having 'metadata.min.js' with the html file makes a difference
> > in the renderering. Notable the top header of the RFC fails to display
> > (has bits like Status: and More Info: )
> >
> > Does this mean the html *alone* is not authoritative?
> > /Miek
>
> These are annotations that are not actually part of the RFC (neither
> XML, nor HTML). If they were, they would be part of the XML.
>
> Best regards, Julian
>

--00000000000001622e059383f9c3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Thanks for clarifying.</div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 27 Sep 2019, 08:26 Julian R=
eschke, &lt;<a href=3D"mailto:julian.reschke@gmx.de">julian.reschke@gmx.de<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27.09.2019 08:33,=
 Miek Gieben wrote:<br>
&gt; Hi all, I was just playing with the html output of xml2rfc and noticed=
<br>
&gt; that not having &#39;metadata.min.js&#39; with the html file makes a d=
ifference<br>
&gt; in the renderering. Notable the top header of the RFC fails to display=
<br>
&gt; (has bits like Status: and More Info: )<br>
&gt;<br>
&gt; Does this mean the html *alone* is not authoritative?<br>
&gt; /Miek<br>
<br>
These are annotations that are not actually part of the RFC (neither<br>
XML, nor HTML). If they were, they would be part of the XML.<br>
<br>
Best regards, Julian<br>
</blockquote></div>

--00000000000001622e059383f9c3--

