Subject: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml

From: Megan Ferguson <[email-masked]>
Date: Fri, 23 Jun 2017 18:41:34 -0700

Hi Henrik,

Input file: draft-ietf-bess-evpn-vpws-14
Version: id2xml 1.0.2
Issues: File not originally generated with XML, Copyright section title
Files available: 
https://www.rfc-editor.org/rfc/v3test/draft-ietf-bess-evpn-vpws-14v3.original 
https://www.rfc-editor.org/rfc/v3test/draft-ietf-bess-evpn-vpws-14v3.txt
https://www.rfc-editor.org/rfc/v3test/draft-ietf-bess-evpn-vpws-14v3-rfcdiff.html

Note - the last file is a diff highlighting the changes we made to the original to attempt to parse, 
not the output of xml2rfc (as we were not able to get an XML output) based on your previous feedback.

1) On initial run, the main issue seemed to be the ToC; an XML file could be created, but the ToC appeared as a 
figure and all other text following was missing.

We got the following error: 

Parsing file draft-ietf-bess-evpn-vpws-14v3.xml
ERROR: Unable to validate the XML document: draft-ietf-bess-evpn-vpws-14v3.xml
 <string>: Line 27: Element middle content does not follow the DTD, expecting (section)+, got nothing.

However, once we updated from "Copyright and License Notice" to just "Copyright Notice”, we got hung up on an error:

Converting 'draft-ietf-bess-evpn-vpws-14v3.txt'

draft-ietf-bess-evpn-vpws-14v3.txt(328): Warning: Unexpected title: expected 'Table ...',
   found 'Figure 1: EVPN Layer 2 attributes extended community'.  This looks like a
   texttable that has been entered as a figure.  The generated XML will need adjustment.

draft-ietf-bess-evpn-vpws-14v3.txt(602): Warning: Failed parsing a reference:
   [I-D.ietf-evpn-overlay] Drake, J., "A Network Virtualization
   Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-07,
   (work in progress), December 2016.
Failure converting draft-ietf-bess-evpn-vpws-14v3.txt: 
Traceback (most recent call last):
  File "/usr/bin/id2xml", line 9, in <module>
    load_entry_point('id2xml==1.0.2', 'console_scripts', 'id2xml')()
  File "/usr/lib/python2.7/site-packages/id2xml/run.py", line 222, in run
    xml = parser.parse_to_xml()
  File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 955, in parse_to_xml
    doc = self.document()
  File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 981, in document
    self.root.append(self.back())
  File "<string>", line 2, in back
  File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 559, in dtrace
    ret = fn(self, *params,**kwargs)
  File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2726, in back
    self.read_authors_addresses()
  File "<string>", line 2, in read_authors_addresses
  File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 559, in dtrace
    ret = fn(self, *params,**kwargs)
  File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 1710, in read_authors_addresses
    assert not line or line.txt.strip() == '’
AssertionError

Thank you.

RFC Editor/mf

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 24 Jun 2017 19:09:51 +0200

Hi Megan,

On 2017-06-24 03:41, Megan Ferguson wrote:
> However, once we updated from "Copyright and License Notice" to just
> "Copyright Notice”, we got hung up on an error:

Right.  Fixed in my sources.  The fix will be part of the next release.

As a workaround till that is out, please insert a blank line in front of
each the Email: lines in the Author's Addresses section.

Thanks for the feedback :-) and best regards,

	Henrik

---

From: Megan Ferguson <[email-masked]>
Date: Mon, 26 Jun 2017 15:48:27 -0700

Hi Henrik,

Thank you for the workaround on this one.  Here is the revisit:

Input file: draft-ietf-bess-evpn-vpws-14
Version: id2xml 1.0.2
Issues: File not originally generated with XML, short title formation, xrefs, indentation of lists, RFC reference entry
Files available: 
https://www.rfc-editor.org/rfc/v3test/draft-ietf-bess-evpn-vpws-14v3.original 
https://www.rfc-editor.org/rfc/v3test/draft-ietf-bess-evpn-vpws-14v3.txt
https://www.rfc-editor.org/rfc/v3test/draft-ietf-bess-evpn-vpws-14v3.xml
https://www.rfc-editor.org/rfc/v3test/draft-ietf-bess-evpn-vpws-14v3-rfcdiff.html

1) The “short title” used in the running header seems like it truncates the full title instead of 
populating from the I-D running header?

Original:
VPWS support in EVPN 

id2xml:
Virtual Private Wire Service support in

xml:
	<title abbrev="Virtual Private Wire Service support in ">Virtual Private Wire Service support 
in Ethernet VPN</title>

2) This document uses the lowercase “defined in section x” vs. “defined in Section x”.  These are not 
picked up as <xref targets>.

3) This indentation is a bit different from the original.  

Original:
     Name   Meaning

     P      If set to 1 in multihoming single-active scenarios, it
            indicates that the advertising PE is the Primary PE.
            MUST be set to 1 for multihoming all-active scenarios by
            all active PE(s).

     B      If set to 1 in multihoming single-active scenarios, it
            indicates that the advertising PE is the Backup PE.

     C      If set to 1, a Control word [RFC4448] MUST be present
            when sending EVPN packets to this PE. It is recommended to
            include the control word in the absence of Entropy Label.

id2xml:

      Name  Meaning

         P If set to 1 in multihoming single-active scenarios, it
         indicates that the advertising PE is the Primary PE.  MUST be
         set to 1 for multihoming all-active scenarios by all active
         PE(s).

         B If set to 1 in multihoming single-active scenarios, it
         indicates that the advertising PE is the Backup PE.

         C If set to 1, a Control word [RFC4448] MUST be present when
         sending EVPN packets to this PE.  It is recommended to include
         the control word in the absence of Entropy Label.

xml:

	<t><list style="empty" hangIndent="2">
	<t><list style="hanging" hangIndent="-1"><t hangText="Name">
	Meaning
	<vspace blankLines="0"/>
	<list style="empty"><t>     P      If set to 1 in multihoming single-active scenarios, it
            indicates that the advertising PE is the Primary PE.
            MUST be set to 1 for multihoming all-active scenarios by
            all active PE(s).</t>

	<t>     B      If set to 1 in multihoming single-active scenarios, it
            indicates that the advertising PE is the Backup PE.</t>

	<t>     C      If set to 1, a Control word <xref target="RFC4448"/> MUST be present
            when sending EVPN packets to this PE. It is recommended to
            include the control word in the absence of Entropy Label.</t>

	</list>
	</t>

	</list>
	</t>

	</list>
	</t>

4) The reference entry for RFC 6790 appears in its full form in the References, while the rest appear as, e.g., &RFC4448;.

	<reference anchor="RFC6790"><front>
	<title>The Use of Entropy Labels in MPLS Forwarding</title>
	<author fullname="K. Kompella" initials="K." surname="Kompella">
	</author>

	<author fullname="J. Drake" initials="J." surname="Drake">
	</author>

	<author fullname="S. Amante" initials="S." surname="Amante">
	</author>

	<author fullname="W. Henderickx" initials="W." surname="Henderickx">
	</author>

	<author fullname="L. Yong" initials="L." surname="Yong">
	</author>

	<date month="November" year="2012"/>
	</front>

	</reference>

Thank you.

RFC Editor/mf

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 29 Jun 2017 21:49:21 +0200

Hi Megan,

> Virtual Private Wire Service support in

Right.  If no short title is recognized, the full title is truncated as
needed.  I've now improved the regular expression which permits recognition
of the format used in this draft.  (The trouble was with the day of month in
the date in the header line).
> picked up as <xref targets>.

Yees.  I tried to accept lowercase 'section x' in the draft htmlization
script some years ago, and that increased the incidence of false markup
considerably.

I can change this to accept also 'section' if you wish, but I would not
advice doing so.  Would you reflect on this, and let me know if I should
change this or keep recognising only 'Section' ?

>             include the control word in the absence of Entropy Label.

Yes.  This has the form of a list, but the 'P', 'B', and 'C' indications
aren't recognized as list bullets, or item labels.  I could replicate
the text output by treating this as a figure instead, but that would
make it harder for you to turn this into a list with style='hanging' and
the individual letters as hangText (which I think it should be marked up
as.  I'm wary of trying to actually recognize the single letters as
hangText automatically, as I think it will lead to a lot of false list
identifications elsewhere.

> 	<date month="November" year="2012"/>

Yes.  It doesn't have any series info, which is what I've used as the trigger
for recognizing RFCs and Internet-Drafts.  I could look at the anchor text
if there is no series info, and try to do the right thing.  Would you prefer
that over manually adding the correct series info in the text version?

Thank you for the feedback :-)

Best regards,

	Henrik

> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development
>