A possible docutils' issue with certain IETF mailarchive URIs ?

--00000000000034ad3a0638c88c1a
Content-Type: multipart/alternative; boundary="00000000000034ad390638c88c18"

--00000000000034ad390638c88c18
Content-Type: text/plain; charset="UTF-8"

Hello Docutils Community,

I use 'docutils' to organize my notes as HTML files - and - store links for
later review.

I noted issues with certain IETF mailarchive URIs already a while ago - but
- only now took the time to follow up & create a simple test file (see
attachment) demonstrating the issue.

This file contains two IETF mailarchive URI instances. - The first one is
processed without an issue - and - the second one is processed with an
error. - That is, when I create the HTML file I receive the following
'Docutils System Message':

###

[user@fedora-python-study-vm vransmayr]$
[user@fedora-python-study-vm vransmayr]$ docutils test-IETF-URI-issue.rst
test-IETF-URI-issue.html
test-IETF-URI-issue.rst:18: (ERROR/3) Unknown target name: "k4-l4mk7qa".
[user@fedora-python-study-vm vransmayr]$

###

For me it is not clear, if the second mailarchive URI really does 'violate'
the reStructuredText Markup Specification - or - if it is a 'docutils'
issue.

Looking forward to your feedback !

With kind regards,

Viktor

PS: This issue occurs in docutils version 0.21.2 as well as 0.22rc5 ...

--00000000000034ad390638c88c18
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello Docutils Community,</div><div><br></div><div>I =
use &#39;docutils&#39; to organize my notes as HTML files - and - store lin=
ks for later review.</div><div><br></div><div>I noted issues with certain I=
ETF mailarchive URIs already a while ago - but - only now took the time to =
follow up &amp; create a simple test file (see attachment) demonstrating th=
e issue.</div><div><br></div><div>This file contains two IETF mailarchive U=
RI instances. - The first one is processed without an issue - and - the sec=
ond one is processed with an error. - That is, when I create the HTML file =
I receive the following &#39;Docutils System Message&#39;:=C2=A0</div><div>=
<br></div><div>###</div><div><br></div><div><span style=3D"font-family:mono=
space">[user@fedora-python-study-vm vransmayr]$ <br>[user@fedora-python-stu=
dy-vm vransmayr]$ docutils test-IETF-URI-issue.rst test-IETF-URI-issue.html=
<br>test-IETF-URI-issue.rst:18: (ERROR/3) Unknown target name: &quot;k4-l4m=
k7qa&quot;.<br>[user@fedora-python-study-vm vransmayr]$=C2=A0<br></span></d=
iv><div><br></div><div>###</div><div><br></div><div>For me it is not clear,=
 if the second mailarchive URI really does &#39;violate&#39; the=C2=A0reStr=
ucturedText Markup Specification - or - if it is a &#39;docutils&#39; issue=
.</div><div><br></div><div>Looking forward to your feedback !</div><div><br=
></div><div>With kind regards,</div><div><br></div><div>Viktor</div><div><b=
r></div><div>PS: This issue occurs in docutils version 0.21.2 as well as 0.=
22rc5 ...</div><div><br></div></div>

--00000000000034ad390638c88c18--
--00000000000034ad3a0638c88c1a
Content-Type: text/x-rst; charset="US-ASCII"; name="test-IETF-URI-issue.rst"
Content-Disposition: attachment; filename="test-IETF-URI-issue.rst"
Content-Transfer-Encoding: base64
Content-ID: <f_mcj0n4c20>
X-Attachment-Id: f_mcj0n4c20

PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT0KVGVzdCBpbnN0YW5jZSBmb3IgYW4gSUVURiBtYWlsYXJjaGl2ZSBVUkkgaXNzdWUgaW4g
J2RvY3V0aWxzJz8KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT0KCiMjIyBFeGFtcGxlIG9mIGFuIFVSSSB3aXRob3V0IHRoZSBpc3N1
ZSAuLi4KCiogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pcHBtLWFzeW1tZXRyaWNhbC1wa3RzLTA4
LnR4dAoqICoqUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgd2l0aCBBc3ltbWV0cmljYWwgVHJhZmZp
YyBVc2luZyBTVEFNUCoqCiogU1RBTVAgLSBTaW1wbGUgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1l
bnQgUHJvdG9jb2wKKiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2ktZC1h
bm5vdW5jZS9UbGpXOVZfc0l6UUoxUHBPNGF4a0ttaVdDWkkvCiogLT4gaHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHBtLWFzeW1tZXRyaWNhbC1wa3RzLwoqIC0t
PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaXBwbS1h
c3ltbWV0cmljYWwtcGt0cy0wOAoKIyMjIEV4YW1wbGUgb2YgYW4gVVJJIHdpdGggdGhlIGlzc3Vl
IC4uLgoKKiBJLUQgQWN0aW9uOiBkcmFmdC1ob2ZmbWFuLW5vbi1yZmMtcmVmcy0wMC50eHQKKiAq
KlJlZmVyZW5jZXMgaW4gUkZDcyBhbmQgSUFOQSBSZWdpc3RyaWVzKioKKiBodHRwczovL21haWxh
cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2ktZC1hbm5vdW5jZS9rNC1MNG1LN1FhXy1GM3N2bUY2
dUZLS1BaNkkvCiogLT4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaG9m
Zm1hbi1ub24tcmZjLXJlZnMvCiogLS0+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2h0bWwvZHJhZnQtaG9mZm1hbi1ub24tcmZjLXJlZnMtMDAK
--00000000000034ad3a0638c88c1a
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--00000000000034ad3a0638c88c1a
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline