Subject: [Tools-discuss] HTML as alternate format for IETF Internet-Draft Submission

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Jan 2012 16:27:59 +0100

<https://datatracker.ietf.org/submit>

...is there a reason why the list of alternate formats does not include 
HTML?

Best regards, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Jan 2012 08:18:44 +1300

> ...is there a reason why the list of alternate formats does not include

As far as I know there is no canonical HTML format for RFCs.

Presonally I prefer what xml2rfc generates.

    Brian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Jan 2012 20:27:46 +0100

> As far as I know there is no canonical HTML format for RFCs.

Well, there's none for PDF and PS but they are accepted.

> Presonally I prefer what xml2rfc generates.

I like xml2rfc as well, but I'd like to be able to point people to "the" 
HTML version generated by the author for review. Right now people host 
them on private pages, and that seems to be suboptimal.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Sun, 29 Jan 2012 13:32:06 -0600

> Presonally I prefer what xml2rfc generates.

The canonical format is .txt.  There's no canonical roff, HTML, PDF,
PostScript or any other format.  I don't mean to say that everyone
should use xml2rfc -- I understand that some old I-Ds that are still
around might pre-date xml2rfc, and not everyone enjoys editing
documents in XML.  But I don't see many alternatives -- perhaps a
TeX<->XML? that would make LyX a viable I-D/RFC editor, which would be
oh-so-neat.  Or perhaps a set of macros for LyX that makes it output
.txts that pass I-D nits.

In any case, the current status quo works for me.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Jan 2012 20:41:24 +0100

> In any case, the current status quo works for me.

I just realized that I managed to confuse the list :-)

Of course I don't want to promote publishing in custom HTML formats. 
xml2rfc's HTML output works, although I of course prefer what 
rfc2629.xslt generates.

The proposal is about allowing the author to upload the generated HTML 
version so it has a public URI on the IETF site.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Sun, 29 Jan 2012 14:18:27 -0600

> version so it has a public URI on the IETF site.

IMO if you want HTML then submit .xml and let the server generate the
other formats from it.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Jan 2012 21:19:19 +0100

On 2012-01-29 21:18, Nico Williams wrote:
> On Sun, Jan 29, 2012 at 1:41 PM, Julian Reschke<[email-masked]>  wrote:

Well, the server doesn't.

And even if we did, I wouldn't want the default xml2rfc output.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Sun, 29 Jan 2012 14:28:35 -0600

> Well, the server doesn't.

Why not?

> And even if we did, I wouldn't want the default xml2rfc output.

Why not?

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Jan 2012 21:34:08 +0100

On 2012-01-29 21:28, Nico Williams wrote:
> On Sun, Jan 29, 2012 at 2:19 PM, Julian Reschke<[email-masked]>  wrote:

Because nobody has implemented yet. FWIW, as many of the XML files being 
submitted are incomplete, it would be a good way to encourage submission 
of complete files.

>> And even if we did, I wouldn't want the default xml2rfc output.

I already said so a few mails ago: because I prefer the output of 
rfc2629.xslt, in particular as it provides many features that xml2rfc 
does not have (for details, see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extensions>).

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 29 Jan 2012 21:34:54 +0100

> Well, the server doesn't.

It would be a SMOP to [install your XSLT into the server -- already done --, and to] make sure every XML is delivered with the PI to reference it.
Then we need some code to resolve the cross-origin SYSTEM entities (xmllint -noent?).
Finally, there should be an IDNITS check for valid XML...

I really like looking at drafts in rfc2629.xslt processed form, so much that I usually generate standalone XML that doesn't use cross-origin SYSTEM entities.
(kramdown-rfc2629 has an option for generating that form.)  But for the people who like to embed the xml.resource.org entities into the XML, the above would be necessary.

(E.g., look at
http://tools.ietf.org/id/draft-6man-udpzero-00.xml
for a draft that has the cross-origin problem and therefore doesn't show references right, and at
http://tools.ietf.org/id/draft-aayadi-6lowpan-tcphc-01.xml
for a draft that doesn't but unfortunately isn't even valid, and at
http://tools.ietf.org/id/draft-abarth-cake-00.xml
for how a standalone draft looks like.  Nice.
)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Jan 2012 21:40:05 +0100

> Then we need some code to resolve the cross-origin SYSTEM entities (xmllint -noent?).

And the PI include directives. And references to local includes the 
author did not submit.

> Finally, there should be an IDNITS check for valid XML...

Absolutely. On the other hand, people will come with pitchforks when the 
ID submission starts to complain.

> ...

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 29 Jan 2012 21:44:37 +0100

> Absolutely. On the other hand, people will come with pitchforks when the ID submission starts to complain.

I think it should complain, adding in a few well-chosen insults (HTML5 can include voice snippets, too), but accept the "XML" anyway (renaming it to .broken-xml in the process).

Grüße, Carsten

---

From: Nico Williams <[email-masked]>
Date: Sun, 29 Jan 2012 15:25:13 -0600

On Sun, Jan 29, 2012 at 2:40 PM, Julian Reschke <[email-masked]> wrote:
> And the PI include directives. And references to local includes the author
> did not submit.

Nowadays I always make sure mine don't reference any local resources.
Making the server process the XML would help get others to do the
same.

---

From: Nico Williams <[email-masked]>
Date: Sun, 29 Jan 2012 15:26:03 -0600

> submission starts to complain.

It could start by warning, not failing.  That wouldn't cause any revolutions.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Jan 2012 22:28:52 +0100

On 2012-01-29 22:25, Nico Williams wrote:
> On Sun, Jan 29, 2012 at 2:40 PM, Julian Reschke<[email-masked]>  wrote:

+1

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 29 Jan 2012 15:49:35 -0800

On 1/29/2012 11:41 AM, Julian Reschke wrote:
> The proposal is about allowing the author to upload the generated HTML version
> so it has a public URI on the IETF site.

As you note, we allow uploading ADDITIONAL versions for other, non-txt formats. 
  I agree it means that we should allow it for an html version, too.

It might be worth a moment, to ask whether any or all of these other formats 
should have some conventions imposed on them?  I could readily believe that the 
fact that they are secondary and that we seem to be doing fine without 
specifying the non-txt conventions, that it might not be worth the effort to do 
it now.

Thought it worth posing the question, though.  For example, most html versions 
use html rather minimally.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net