From nobody Mon Jan  1 10:10:31 2018
Return-Path: <ietf@augustcellars.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5D9126D05 for <xml2rfc-dev@ietfa.amsl.com>; Mon,  1 Jan 2018 10:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YhFWSt_rnNiG for <xml2rfc-dev@ietfa.amsl.com>; Mon,  1 Jan 2018 10:10:28 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EC21267BB for <xml2rfc-dev@ietf.org>; Mon,  1 Jan 2018 10:10:28 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 1 Jan 2018 10:08:47 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: <paul.hoffman@icann.org>
CC: <xml2rfc-dev@ietf.org>, 'Nevil Brownlee' <n.brownlee@auckland.ac.nz>
Date: Mon, 1 Jan 2018 10:10:09 -0800
Message-ID: <023001d3832b$c4316440$4c942cc0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdODJAzC0Mc2J6kaTgaSM2qZLO7ykQ==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/FrUGYXCjZeE4ov_J-N1D8nAECCI>
Subject: [xml2rfc-dev] Questions about the artwork element
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jan 2018 18:10:30 -0000

Paul,

I am going through the artwork element and trying to figure out how things
should be specified and how things are arranged.

There are a lot of ways of specifying where an SVG artwork is to be obtained
from, but that seems to be very logical.   However, I am having a problem
with trying to figure out how, where and when an alternative description is
supposed to appear.

If you read carefully and between the lines, then one would know to place
the alternative description in the <desc> element of the SVG if you use one
(section 2.5.2).   Except that this is not what the second paragraph of
section 2.5 says. That being said, there are two additional locations where
one can place the alternative description.  In the body of the <artwork>
element and in the alt attribute of the <artwork> element.  This means that
I am not sure what the order of using multiple items would be.

First guess,

1. If there is <desc> element in the SVG, use that otherwise do step 2.
2. If there is a src attribute, use the body if it is not empty otherwise
use the alt attribute if present
3. Use the alt attribute if present

As such it would appear that currently, the only time that the alt attribute
should normally be used only for an alternative for ASCII line art.

In all of these cases, it appears that the alternative description is
intended to be a single long text string that would be the intended format.
This means that one cannot use some of the features of formatting that might
be useful in presenting the alternative description in text.  These might be
multiple paragraphs, bullet points and so forth.  While one can do these
there is no concept of having any automatic line wrapping when this is done.

Questions:

1.  Are there situations where the alt attribute is really needed?
2.  Is the order of displaying alternative descriptions correct?  Or should
all be displayed if all exist?
3.  Is there a better way of doing formatting for the alternative
description?
4.  Not sure if this is for you or Nevil, but an SVG can have multiple
<desc> elements.  Is there a defined way that these should be combined
together to form the alternative text?  Is that a function of the XML2RFC
document or of the format that the artwork is presented in?


Jim




From nobody Tue Jan  2 10:13:48 2018
Return-Path: <ietf@augustcellars.com>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A441127876 for <xml2rfc-dev@ietfa.amsl.com>; Tue,  2 Jan 2018 10:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nQ2ofmXB0kcT for <xml2rfc-dev@ietfa.amsl.com>; Tue,  2 Jan 2018 10:13:44 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA7E124B17 for <xml2rfc-dev@ietf.org>; Tue,  2 Jan 2018 10:13:44 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 10:12:13 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: <paul.hoffman@icann.org>
CC: 'Nevil Brownlee' <n.brownlee@auckland.ac.nz>, <xml2rfc-dev@ietf.org>
References: <023001d3832b$c4316440$4c942cc0$@augustcellars.com>
In-Reply-To: <023001d3832b$c4316440$4c942cc0$@augustcellars.com>
Date: Tue, 2 Jan 2018 10:13:36 -0800
Message-ID: <028f01d383f5$6a240cd0$3e6c2670$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI3D8ILmTloxYoYmTDUJBYxWqqP06KZysmg
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/RjW76rw2kMqjEXR3wjNdtRB8cTI>
Subject: Re: [xml2rfc-dev] Questions about the artwork element
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jan 2018 18:13:47 -0000

A follow up to these questions

RFC 7991 the grammar says:

   Alternatively, the "src" attribute allows referencing an external
   graphics file, such as a vector drawing in SVG or a bitmap graphic
   file, using a URI.  In this case, the textual content acts as a
   fallback for output representations that do not support graphics;
   thus, it ought to contain either (1) a "line art" variant of the
   graphics or (2) prose that describes the included image in sufficient
   detail.

However RFC 7998 the prep tool says:

      If an <artwork> element has a "src" attribute, and the element
       has content, give an error.

These two statements are in direct conflict.

Jim



> -----Original Message-----
> From: xml2rfc-dev [mailto:xml2rfc-dev-bounces@ietf.org] On Behalf Of Jim
> Schaad
> Sent: Monday, January 1, 2018 10:10 AM
> To: paul.hoffman@icann.org
> Cc: 'Nevil Brownlee' <n.brownlee@auckland.ac.nz>; xml2rfc-dev@ietf.org
> Subject: [xml2rfc-dev] Questions about the artwork element
> 
> Paul,
> 
> I am going through the artwork element and trying to figure out how things
> should be specified and how things are arranged.
> 
> There are a lot of ways of specifying where an SVG artwork is to be
obtained
> from, but that seems to be very logical.   However, I am having a problem
> with trying to figure out how, where and when an alternative description
is
> supposed to appear.
> 
> If you read carefully and between the lines, then one would know to place
> the alternative description in the <desc> element of the SVG if you use
one
> (section 2.5.2).   Except that this is not what the second paragraph of
> section 2.5 says. That being said, there are two additional locations
where
> one can place the alternative description.  In the body of the <artwork>
> element and in the alt attribute of the <artwork> element.  This means
that I
> am not sure what the order of using multiple items would be.
> 
> First guess,
> 
> 1. If there is <desc> element in the SVG, use that otherwise do step 2.
> 2. If there is a src attribute, use the body if it is not empty otherwise
use the
> alt attribute if present 3. Use the alt attribute if present
> 
> As such it would appear that currently, the only time that the alt
attribute
> should normally be used only for an alternative for ASCII line art.
> 
> In all of these cases, it appears that the alternative description is
intended to
> be a single long text string that would be the intended format.
> This means that one cannot use some of the features of formatting that
> might be useful in presenting the alternative description in text.  These
might
> be multiple paragraphs, bullet points and so forth.  While one can do
these
> there is no concept of having any automatic line wrapping when this is
done.
> 
> Questions:
> 
> 1.  Are there situations where the alt attribute is really needed?
> 2.  Is the order of displaying alternative descriptions correct?  Or
should all be
> displayed if all exist?
> 3.  Is there a better way of doing formatting for the alternative
description?
> 4.  Not sure if this is for you or Nevil, but an SVG can have multiple
<desc>
> elements.  Is there a defined way that these should be combined together
to
> form the alternative text?  Is that a function of the XML2RFC document or
of
> the format that the artwork is presented in?
> 
> 
> Jim
> 
> 
> 
> _______________________________________________
> xml2rfc-dev mailing list
> xml2rfc-dev@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev


From nobody Tue Jan  2 10:29:05 2018
Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C877412D7F1 for <xml2rfc-dev@ietfa.amsl.com>; Tue,  2 Jan 2018 10:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bPdOlmqMYxT for <xml2rfc-dev@ietfa.amsl.com>; Tue,  2 Jan 2018 10:29:02 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F72912D7EF for <xml2rfc-dev@ietf.org>; Tue,  2 Jan 2018 10:29:01 -0800 (PST)
Received: from [192.168.178.20] ([93.217.114.119]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LvV1X-1evq1Y1Jq7-010ZU7; Tue, 02 Jan 2018 19:27:55 +0100
To: Jim Schaad <ietf@augustcellars.com>, paul.hoffman@icann.org
Cc: xml2rfc-dev@ietf.org, 'Nevil Brownlee' <n.brownlee@auckland.ac.nz>
References: <023001d3832b$c4316440$4c942cc0$@augustcellars.com> <028f01d383f5$6a240cd0$3e6c2670$@augustcellars.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <42864c1b-be6a-881d-3624-de28b8f850fc@gmx.de>
Date: Tue, 2 Jan 2018 19:27:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <028f01d383f5$6a240cd0$3e6c2670$@augustcellars.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:axbqBvq+Q8ERR0UDzhjVIAkpz48Z68TLQdygdYyULUgvasTWt8V +ZiedGiBtO2FuGetqZpICTM5U9DzrFvJPfCGmPaHQyw25NkJHpAWpMiwRAjsvqvx7D59Gvn wBDLtq5fD6Hn/rkRyxtPFPvg6eoU6tZ7wupT8/ejIOfSPNfs9gmY/egvSnEAjazdiP351yy V9H+rJDqVi+xc0Ozq2wBg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:TmDd6B/VGow=:19MoDHgb73TdpMMFr4s487 mbbFrpLzwIdmV+jpILzvw17IrAQW//9lB8RG5jR0sH9gweQjfZotuVp0m/y2inINDt+hcxvaD d0OEzj18VwnAPZ1bJAV55OEeVBnE8r4p2GPXWXqGhDqeufqIAeQgcFfM9jYK/TcxtaOv9gIOb IZwzOTRvLQbDAw5PrszNXApk681aEwZ7e3cWop2hAjquM3WtjnLid/jLMs/dD8YOmtZylf4z0 0mU7UyJcczTT6HEM54x+VtzEmrXzm4fO42YCkjV08cknBiMZU99jPbO4CIw1bedk83KIRuraI LEdIGs9pXQD/br3bKjtaiiu7X/m6hg/nIUn4KW3dceu1UipiVb+InRTplCbEiwI6XsTysbjk0 o4DKEW3SOVai0MiaHcCSGzOBkobR9JvLKTsHQaq9rgDjxw+tFon8QtjaFM9kkiTvTcKglnFXK 6vaS1k+dcfwjuNMiLJHGg+/Dd04W0O6XWlW73GTXRkYthjDBSy+FmjLoavVI1yuhTguRrwRVo +GfB1OoR+O1hiqnAmlAF8ViPW0Gz2Br9jsukXg4AiVGxDZhetx7+OxzVztTPp+tgc955r5SMl MLad1dgstF1TAHcg91xjZMhG1BrnfpGg/g6P8j7rtVSSS0TyaWR0WmOSvLYQTfOEw4J7vnJdO IUNWz3tfJ0rPJ295PJInpn2McaJXJdCM43Pwi11paNxnHa8aTg4jxDUfv/ge0wH1i2dA8Mj9N k9Ngg0/k1p/HXI7R09Fd0vdaIKIVeXRyWt9iV7h6axDQHE2iq9g1q2D+bVptzV3sUQSMJFdu3 Lw4Scb3NEFY+m7oiUxRyNs0Y9oPkdQZc9JpIZqnsBlSP/unrbk=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/WrtJX5p-lJCRTIHaKwbFnwnALJw>
Subject: Re: [xml2rfc-dev] Questions about the artwork element
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jan 2018 18:29:04 -0000

On 2018-01-02 19:13, Jim Schaad wrote:
> A follow up to these questions
> 
> RFC 7991 the grammar says:
> 
>     Alternatively, the "src" attribute allows referencing an external
>     graphics file, such as a vector drawing in SVG or a bitmap graphic
>     file, using a URI.  In this case, the textual content acts as a
>     fallback for output representations that do not support graphics;
>     thus, it ought to contain either (1) a "line art" variant of the
>     graphics or (2) prose that describes the included image in sufficient
>     detail.
> 
> However RFC 7998 the prep tool says:
> 
>        If an <artwork> element has a "src" attribute, and the element
>         has content, give an error.
> 
> These two statements are in direct conflict.
> 
> Jim

I recommend opening tickets at <https://github.com/rfc-format>.

Best regards, Julian


From nobody Mon Jan 15 00:31:45 2018
Return-Path: <mail+ietf@gundogan.net>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92CB126CF9 for <xml2rfc-dev@ietfa.amsl.com>; Mon, 15 Jan 2018 00:31:44 -0800 (PST)
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, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3vsQXuebgoE for <xml2rfc-dev@ietfa.amsl.com>; Mon, 15 Jan 2018 00:31:43 -0800 (PST)
Received: from kaus.uberspace.de (kaus.uberspace.de [185.26.156.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1781200FC for <xml2rfc-dev@ietf.org>; Mon, 15 Jan 2018 00:31:42 -0800 (PST)
Received: (qmail 24870 invoked from network); 15 Jan 2018 08:31:39 -0000
Received: from localhost (HELO localhost) (127.0.0.1) by kaus.uberspace.de with SMTP; 15 Jan 2018 08:31:39 -0000
Date: Mon, 15 Jan 2018 09:31:37 +0100
From: Cenk =?utf-8?B?R8O8bmRvxJ9hbg==?= <mail+ietf@gundogan.net>
To: xml2rfc-dev@ietf.org
Message-ID: <20180115083137.GA8290@cgundogan.localdomain>
Mail-Followup-To: xml2rfc-dev@ietf.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt"
Content-Disposition: inline
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/h3S8QSNoJWboo3185Pu3CbvUIxQ>
Subject: [xml2rfc-dev] Online xml2rfc error
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2018 08:31:45 -0000

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

Hi,

In case it's not reported yet, I am facing a problem [1] using the
online tool [2] to convert an xml to plain text. The error message in
[1] is displayed on the resulting web site after hitting the "Submit"
button.

Cheers,
Cenk


[1]:
Generating Text output in ASCII format
Expanding internal references and generating Text

Using XML_LIBRARY=3D/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/b=
ibxml:/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/bibxml2:/home/w=
ww/tools.ietf.org/tools/xml2rfc/web/public/rfc/bibxml3:/home/www/tools.ietf=
=2Eorg/tools/xml2rfc/web/public/rfc/bibxml4:/home/www/tools.ietf.org/tools/=
xml2rfc/web/public/rfc/bibxml5:/home/www/tools.ietf.org/tools/xml2rfc/web/p=
ublic/rfc/bibxml6:/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/bib=
xml7:/home/www/tools.ietf.org/tools/xml2rfc/web/public/rfc/bibxml8

Traceback (most recent call last):
  File "/usr/local/bin/xml2rfc", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", =
line 2912, in <module>
    @_call_aside
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", =
line 2898, in _call_aside
    f(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", =
line 2925, in _initialize_master_working_set
    working_set =3D WorkingSet._build_master()
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", =
line 644, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", =
line 657, in _build_from_requirements
    dists =3D ws.resolve(reqs, Environment())
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", =
line 830, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'xml2rfc=3D=3D2.8.4' distribution w=
as not found and is required by the application

[2] https://xml2rfc.tools.ietf.org/

--=20
Cenk G=C3=BCndo=C4=9Fan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: cenk.guendogan@haw-hamburg.de
Web: https://www.inet.haw-hamburg.de/

--pf9I7BMVVzbSWLtt
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCAAdFiEEO3dMsPVVAdvZ+Oc2o9vC90TUhNIFAlpcZuUACgkQo9vC90TU
hNIC+hAArQZdDXvmAj/QCo7AbyP6cIo33Y/cMbQWlcIXMvR7QiZQ53sVi9HOHS4i
Ub6PSOFxkExZcO3UdERZab1ly6muz1YIpNbzfQ1gdiDH3pdDhiGGbTz8pe9V/Cvh
etM22jzEg1ihm4U98+IjBoxeFIeq6TeLFSe7m8Mrq8rNZRUXN30Sm0QgHY7ppkqt
Gt5MOs6KKU2P2UG+LKn/VraPQcShkL36+Ahft7sX4o6zzxW3UDgf7JWliPrYDXGy
wTpb3k0EiXExZcryFOM7uQNRB15JkAbmhUO2065GvmPnfbD5guKHfIU3alT18V9U
9ulOKWcZLTXDt5VTuLkgg9FdJWQfZA/m4dobhsbPrfNw4mZiXb1fF2qtBz7+CPkG
E94M9nDdKmAo59Lw8cJvNfKq/Qv/EF9pO5Ly+9fnFvTR5M4/LqMBzO7BtWxghnbE
midlUF/uMLIBuPbSCGYe7ijLAHwvuTOqPNBoPQvW7JSnO3mXiC05qOgRHQRRYJaA
8OmL3cDRJiT+rLOaI0qc2fnxUqzBtrZSBqZYaH4vHONrGd7ftbEs+Rw2E0heuzS/
nCKMFmEc66MpsONlxeLC5FJaskwbEv2QkwcegTBZ+mKNge5Imp+YbHGDJVu8bVNh
LGR6HtjNohKcatdsJCw1pR7+LZuPDDj4M+ynFPqGSgEazHWsLaw=
=Rxyz
-----END PGP SIGNATURE-----

--pf9I7BMVVzbSWLtt--