Subject: [Tools-discuss] draft submitted source versions

From: Tom Pusateri <[email-masked]>
Date: Fri, 22 Nov 2019 13:39:51 -0500

Is there anyway to tell if the TXT version was created from the submitted XML or was uploaded separately?

If an XML version is submitted, is there any reason to allow DRAFT AUTHORS to submit alternate versions still?

Thanks,
Tom

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: [RFC State] <draft-ietf-dnssd-push-25> has been added to the RFC Editor database
> Date: November 22, 2019 at 11:46:25 AM EST
> To: [email-masked], [email-masked]
> Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> 
> Author(s),
> 
> We have received notice that your document draft-ietf-dnssd-push-25 has
> been approved for publication as an RFC.  The document has
> been added to the RFC Editor queue and you can check the status at
> <https://www.rfc-editor.org/current_queue.php>
> 
> If you submitted your XML file using the I-D submission tool, we have
> already retrieved it.  If you did not submit the XML file via the I-D
> submission tool, or if you have an updated version (e.g., updated
> contact information), please send us the XML file at this time.  Please
> attach the file and specify any differences between the approved I-D 
> and the document that the XML produces.  We recommend using xml2rfc
> <http://xml2rfc.ietf.org/> to create your document.
> 
> This should help increase the pace with which documents move through
> the RFC Editor queue. 
> 
> Please let us know if you have any questions.
> 
> Thank you.
> 
> The RFC Editor Team
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Nov 2019 13:01:39 +1300

> If an XML version is submitted, is there any reason to allow DRAFT AUTHORS to submit alternate versions still?

Well, before answering that, I have two supplementary questions.

1. What happens if the author submits a.xml and a.txt, but the xml file doesn't convert properly?

2. What happens if the author submits a.xml and a.txt, but the converted xml file is different from a.txt?

    Brian
> 
> Thanks,
> Tom
> 
> 
>> Begin forwarded message:
>>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **[RFC State] <draft-ietf-dnssd-push-25> has been added to the RFC Editor database*
>> *Date: *November 22, 2019 at 11:46:25 AM EST
>> *To: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
>> *Cc: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
>>
>> Author(s),
>>
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]
>

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 22 Nov 2019 19:12:09 -0500

> On Nov 22, 2019, at 7:01 PM, Brian E Carpenter <[email-masked]> wrote:
> 

So, ideally, I think we should accept either .xml or .txt.

What would make sense to me is:

If an .xml is submitted, it is run through xml2rfc and if there’s errors, it’s rejected and no draft is published. The author can choose to submit a .txt instead but not a broken xml.
If it’s accepted, it is converted to all of the formats including txt, pdf, html.

If a .txt is submitted, do whatever checks you do today but don’t accept any other files for submission. The .txt is converted to html and pdf as today. This comes with all the known problems of these conversions today.

Notes this is only for author submissions with no special publishing privileges.

Tom

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Nov 2019 08:37:53 +0100

Tom Pusateri <pusateri=[email-masked]> wrote:
    > Is there anyway to tell if the TXT version was created from the
    > submitted XML or was uploaded separately?

    > If an XML version is submitted, is there any reason to allow DRAFT
    > AUTHORS to submit alternate versions still?

If the XML won't format because the references.* files are AWOL, then
allowing the author to upload the TXT version lets them get around that.

This happened to me last week.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 25 Nov 2019 19:28:35 -0500

> On Nov 25, 2019, at 6:57 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Sure but then don’t accept the XML AND the TXT. If the XML is bad, reject it and accept the TXT.

Otherwise you have two different source documents and there should be only one.

Tom

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Nov 2019 10:52:16 +0100

> Otherwise you have two different source documents and there should be only one.

Yes, I see this problem, but I see a bigger problem of archival.

And then we don't have the XML file available, and we don't get a record of
why the XML didn't format. (In my case, because reference.* files were
missing)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Nov 2019 11:22:27 +0100

On 27.11.2019 10:52, Michael Richardson wrote:
> ...

Archiving XML with external dependencies is problematic anyway :-) (ok,
archival not necessary, but assuming that the archived document can be
used to re-create the same output files)

Best regards, Julian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 27 Nov 2019 08:30:33 -0800

Julian,

> On Nov 27, 2019, at 2:22 AM, Julian Reschke <[email-masked]> wrote:
> 

I have mixed feeling about this topic.

For submitting an Internet draft, I am not sure it matters very much.  We don’t currently require XML, the TXT is enough.  I personally always submit TXT and XML, but I assume the XML is not processed if I also submit a TXT file.   I would like to know if the two don’t match, but my main goal in submitting an ID is to get it published.  I suspect if it is common that the XML doesn’t produce a TXT file that matches, some folks would just stop submitting the XML, especially as it gets near an ID deadline.

RFCs are a very different matter.  There I assume we want the XML.   It would be a big problem if the XML didn’t produce the same TXT file, as it was the TXT file that people used to review the draft and approve it.

We might want to add a step (to IDnits?) where the XML and TXT are verified.   That would avoid problems later in the publicaiton process.

Bob

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 27 Nov 2019 11:48:49 -0500

> On Nov 27, 2019, at 11:30 AM, Bob Hinden <[email-masked]> wrote:
> 
> Julian,
> 

So I used to submit both XML and TXT and then I started thinking, if I am submitting XML, then why am I submitting TXT too, so I started only submitting XML and this works fine.

So that led me to wonder if the TXT was a by-product of the XML, then isn’t it causing confusion to submit them both and to suggest that if the XML is submitted and it checks out, then not to accept the TXT.

I think there should be a way to suggest that XML is desired and if received, sufficient, but not required.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 27 Nov 2019 11:53:43 -0500

> On Nov 27, 2019, at 11:48 AM, Tom Pusateri <pusateri=[email-masked]> wrote:
> 
> 
> 
>> On Nov 27, 2019, at 11:30 AM, Bob Hinden <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Julian,
>> 
>>> On Nov 27, 2019, at 2:22 AM, Julian Reschke <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> Tom Pusateri <pusateri=[email-masked] <mailto:pusateri=[email-masked]>> wrote:

I would even go a step further (than most of you) and say that authors should submit their source version. If that’s markdown using the kramdown-rfc2629 pre-processor, then submit markdown.

I know that might be a burden for the tools team but I think that the people who maintain those tools would pitch in.

Tom

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 27 Nov 2019 18:08:48 +0100

> I think there should be a way to suggest that XML is desired and if received, sufficient, but not required.

The datatracker draft submission page says:

 "Either a plain-text document or a valid .xml file which can be processed by
  the xml2rfc processor *must* be provided.

  If no .txt file is provided, one will be generated from the .xml file.
  
  Other file types are optional."

There are a number of valid options that can be used when processing .txt
from an xml2rfc files, which will result in slightly different (and valid)
.txt files.  Checking the result of converting submitted XML to .txt with
submitted .txt is thus non-trivial.

Since there's no requirement to submit XML, people can submit any .txt they
like.  And since we haven't seen a problem with XML / text mismatch, I don't
think there is a problem to be solved here.  It's in authors' interest to
provide good XML and text documents.

Any changes in the proposed direction seems to just make it harder for
authors to submit drafts, and likely to encourage authors to *not* submit
XML.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Nov 2019 18:32:55 +0100

> I would even go a step further (than most of you) and say that authors should submit their source version. If that’s markdown using the kramdown-rfc2629 pre-processor, then submit markdown.

Hi Tom,

if people are submitting the XML output of kramdown-rfc2629, they are also submitting the markdown input, which is hidden in a comment in the XML output.  That, of course, may not survive the downconversion from authoring-XML to publishing-XML (“preptool”), but if the submitted authoring-XML is preserved as is, so is the markdown.  (Extract using kramdown-rfc-extract-markdown.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Nov 2019 18:44:51 +0100

> authors to submit drafts, and likely to encourage authors to *not* submit

+100.

Grüße, Carsten

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 27 Nov 2019 12:59:17 -0500

> On Nov 27, 2019, at 12:08 PM, Henrik Levkowetz <[email-masked]> wrote:
> 
> 

Sure, I get it.

I’m just thinking about good software engineering practices and tracking the source documents instead of the generated documents. I’m sure this will come up again when a real problem exists.

Thanks,
Tom

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 28 Nov 2019 10:14:29 +1100

On Thu, Nov 28, 2019, at 04:59, Tom Pusateri wrote:
> I’m just thinking about good software engineering practices and 
> tracking the source documents instead of the generated documents. I’m 
> sure this will come up again when a real problem exists.

The answer here is likely more complex than a .md file.  I refer you to the source of the recent RFC 8448 (https://github.com/tlswg/draft-ietf-tls-tls13-vectors) which shows that the draft is built by first downloading then compiling some software.  The output is a bunch of hex, but the process involves more than simply running kramdown-rfc2629.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Nov 2019 06:52:36 +0100

> authors to submit drafts, and likely to encourage authors to *not* submit

Indeed.

(There are much more important issues with the v3 conversion that need
attention).

Best regards, Julian