Subject: [xml2rfc] v3 questions/comments

From: Michael Tuexen <[email-masked]>
Date: Sun, 8 Mar 2020 22:42:38 +0100

Dear all,

I'm in the process of converting an Internet Draft from xml v2 to v3 and found some issues
using the translator from http://xml2rfc.tools.ietf.org/experimental.html:

* When not having the docName attribute in <rfc/>, the tool is complaining that this attribute is missing.
  According to https://tools.ietf.org/html/rfc7991#section-2.45.3 it is deprecated.

* When not specifying the submissionType attribute in <rfc/>, the tool is complaining that
  this attribute is missing.
  According to https://tools.ietf.org/html/rfc7991#section-2.45.12 the default is "IETF",
  so my understanding is that I don't need to specify it when I want to use IETF.

* When not having a category attribute in <rfc/>, the tool is stopping processing because
  "Expected a valid category for submissionType='IETF', one of std,info,historic,bcp,exp, but found 'None'"
  According to https://tools.ietf.org/html/rfc7991#section-2.45.1 this is deprecated.
  It refers to using the <seriesInfo/>, where "Internet-Draft" would be acceptable.

* When using <author initials='M.' surname='Tüxen' asciiSurname='Tuexen' fullname='Michael Tüxen' asciiFullname='Michael Tuexen'>
  instead of <author initials='M.' surname='Tuexen' fullname='Michael Tuexen'>
  I would expect in the plaintext or v3-plaintext output the ASCII representation being used.
  However, the umlauts do appear, so the generate text is not ASCII.
  That the umlauts appear in the HTML output is expected and works.

* When using <dl hanging="false">, which should be OK according to
  https://tools.ietf.org/html/rfc7991#section-2.20.2
  the translator responds with "Error: Invalid attribute hanging for element dl, at /rfc/middle/section[3]/dl"

Since this is my first usage of v3, it is possible that some of the issues above are related to mistakes
made by me.

Any comments appreciated.

Best regards
Michael

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 9 Mar 2020 13:18:45 +0100

Hi Michael,

>   According to https://tools.ietf.org/html/rfc7991#section-2.45.3 it is deprecated.

Yes.  It was always expected that implementation and use would require a
7991bis.  I assembled some of my implementation notes in 
https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes .

This point and the third point below are similar in this respect, and reflect
some of the changes that have been made after 7991.  

>   so my understanding is that I don't need to specify it when I want to use IETF.

This may be the case for the v3 output, but the v2v3 converter needs it to
make sure that the output is correct.

>   That the umlauts appear in the HTML output is expected and works.

Non-ASCII is now accepable also in .txt format too, so this should be OK.

>   the translator responds with "Error: Invalid attribute hanging for element dl, at /rfc/middle/section[3]/dl"

I will need your v2 XML source to debug this; could you send it, please?

> Since this is my first usage of v3, it is possible that some of the
> issues above are related to mistakes made by me.

Things look mostly the way they should, except for the <dl> error, which
I'd like to debug.

Best regards,

	Henrik

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 9 Mar 2020 14:17:44 +0100

> On 9. Mar 2020, at 13:18, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi Michael,
> 
OK. Wouldn't it make sense to file an errata for this?

> make sure that the output is correct.
OK. Not critical, since it is a warning.
> Non-ASCII is now accepable also in .txt format too, so this should be OK.
Ahh, I see. UTF-8 is now the format. What is then the intention of the asciiSurname?
> Things look mostly the way they should, except for the <dl> error, which
Sent to you offlist.

Best regards
Michael

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 9 Mar 2020 15:08:34 +0100

Hi Michael,

> OK. Wouldn't it make sense to file an errata for this?

Not at the moment; these will eventually be captured in a 7991bis document.

> Ahh, I see. UTF-8 is now the format. What is then the intention of

If the non-ASCII surname contains characters outside the Latin script block,
it is used within parentheses, see https://www.rfc-editor.org/rfc/rfc8694.txt .
For surnames that use all Latin script characters, the asciiSurname has no
function.  Input during implementation of the new format indicated that
common paper publication practice was to render Latin script names as-is,
without ASCIIfication.
 
>> I will need your v2 XML source to debug this; could you send it, please?

Received; thanks.

Best regards,

	Henrik

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 9 Mar 2020 15:38:58 +0100

> On 9. Mar 2020, at 15:08, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi Michael,
> 
OK.
> common paper publication practice was to render Latin script names as-is,
Thanks for the clarification.
>>> I will need your v2 XML source to debug this; could you send it, please?
Let me know if you have any comments/questions.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 9 Mar 2020 19:22:10 +0100

> common paper publication practice was to render Latin script names as-is,
OK. I now used the umlauts. When submitting the I-D, the Idnits tool warns:
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There are 7 instances of lines with non-ascii characters in the document.

Should it be relaxed?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 9 Mar 2020 19:24:31 +0100

> common paper publication practice was to render Latin script names as-is,
... and I can't submit an update with changing my Name from Tuexen to Tüxen.
I think the tool thinks the submitter has changed although the e-mail address
stayed the same. So not using Umlauts for now...

Best regards
Michael

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 9 Mar 2020 19:40:52 +0100

Hi Michael,

> stayed the same. So not using Umlauts for now...

Huh.  And that's actually unexpected.

Could you send me the XML which was not accepted, for debugging, please?

Best regards,

	Henrik

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 9 Mar 2020 19:55:11 +0100

> On 9. Mar 2020, at 19:40, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi Michael,
> 
Sent directly.

Thanks for working on the tool!

Best regards
Michael

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Mar 2020 15:49:43 +0100

On 08.03.2020 22:42, Michael Tuexen wrote:
 > ...
 >    the translator responds with "Error: Invalid attribute hanging for
element dl, at /rfc/middle/section[3]/dl"
 > ...

There is no 'hanging' attribute on <dl> (anymore), see
<https://greenbytes.de/tech/webdav/rfc2629xslt/draft-iab-rfc7991bis-01.html#element.dl>
and also <https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/77>.

Best regards, Julian

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 10 Mar 2020 16:08:23 +0100

> On 10. Mar 2020, at 15:49, Julian Reschke <[email-masked]> wrote:
> 
> 
Hi Julian,

OK, I did not know that the current specification is hosted by your company and not
on an IETF Website. It would be great to have a link from the website of the tool to
the specification I can use.

<dl newline="true"> produces, what I was looking for:

Private-Address (Priv-Addr)
   The private address that is known to the internal host.

Internal-Port (Int-Port)
   The port number that is in use by the host holding the Private-
   Address.

...

But the description in the text says:

newline="true" indicates that the term is to the left of the definition,
while newline="false" indicates that the term will be on a separate line.

Isn't that the opposite of what is happening?

Best regards
Michael

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Mar 2020 16:20:39 +0100

> the specification I can use.

Is is not *hosted* there, it's just a copy.

The doc of course is on ietf.org as well (I just prefer my version of
the HTML).

> Isn't that the opposite of what is happening?

Yes. See
<https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/77> -- an
open issue that was raised first over 13 months ago.

Best regards, Julian

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 10 Mar 2020 16:42:09 +0100

> On 10. Mar 2020, at 16:20, Julian Reschke <[email-masked]> wrote:
> 
OK, I see. Thanks for the clarification.

It would be great, if there is a link to https://tools.ietf.org/html/draft-iab-rfc7991bis
at http://xml2rfc.tools.ietf.org/experimental.html.

That way one can look up stuff in the latest revision of the spec.
> open issue that was raised first over 13 months ago.
OK. Then I hope https://tools.ietf.org/html/draft-iab-rfc7991bis will be updated
sometime.

Best regards
Michael