Subject: Re: [httpwg/http-extensions] Use the I-D Template (#448)

From: HTTP issue updates <[email-masked]>
Date: Sat, 09 Dec 2017 04:48:19 +0000 (UTC)

I find xm2rfc's current HTML output disgusting, and as far as I can tell, it doesn't integrate properly into the page HTML (@mnot).

If the concern is running Java, then let's just switch to xsltproc.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350423813

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 09 Dec 2017 07:49:14 +0000 (UTC)

You can find the current output [here](http://mikebishop.github.io/http-extensions/new-template/); I have trouble seeing this as "disgusting." They're almost exactly equivalent, from a cursory glance -- slightly different font, maybe?  And better styling on the TOC in the new template, but that's a matter of aesthetics.  Can you expand on "doesn't integrate properly into the page HTML"?

Java is certainly a pain every time I have to spin up a new machine, but much bigger is maintainability.  See the [equivalent page in the current repo](http://httpwg.github.io/http-extensions/), in which only two drafts are actually shown, and they're not even two that are currently active in the repo.  The Makefile has to be manually updated for each new draft, rather than simply detecting the drafts as they're added, and even then clearly only builds them rather than adding them to the index.

The current version never cleans up old drafts in gh-pages, doesn't build output for branches other than master, doesn't enable you to submit draft versions by tagging and pushing, and so on and so forth.

Sure, you/someone could build all those things into the current version, but... why?  Martin's already done it; let's just steal his code and be done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350430890

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 09 Dec 2017 01:22:45 -0800

I was referring to the default output that we used to have in the repo recently for the live-ranges extension.

With "doesn't integrate properly into the page HTML" I was referring to "doesn't integrate properly into the page HTML" I meant http://httpwg.org/specs/ which I thought was including drafts as well.

I have no objects to changing the build process so that more of it is automated; but that should not affect which actual tools are used.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350436499

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 09 Dec 2017 03:13:06 -0800

FWIW, some measurements for converting XML to HTML (for secondary certs):

- rfc2629.xslt on Saxon: 3.4s
- xml2rfc: 1.7s
- rfc2629.xslt on xsltproc: 0.3s

So if the primary concern was performance, xsltproc seems to be a clear winner.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350449958

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 10 Dec 2017 21:20:17 +0000 (UTC)

@reschke, last time I ran an end-to-end test, the XSLT variants lost big time because of the dependencies.  That should go away with the docker image though.

BTW, i-d-template#117 should be fixed and xsltproc available.  Have you checked Mike?  It should be easy to see any speed difference, though you have to be careful with some of the caching rules (retriggers FTW).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350582423

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 11:05:14 -0800

I'm still failing with xsltproc on the Header Structure -- for some reason, it's not able to load the XMLs for the references, even though what appears to be the same documents are being referenced by other docs.  But that's not a problem with the Dockerfile, it's an issue running locally as well.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350824389

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 19:12:42 +0000 (UTC)

How does it fail? Silently? Error messages?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350826553

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 19:20:19 +0000 (UTC)

Here's what I'm seeing:

```
xsltproc --novalid lib/rfc2629.xslt draft-ietf-httpbis-header-structure.xml > draft-ietf-httpbis-header-structure.htmltmp
warning: failed to load external entity "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"
draft-ietf-httpbis-header-structure.xml:499: parser error : Failure to process entity RFC7230
&RFC7230;
         ^
draft-ietf-httpbis-header-structure.xml:499: parser error : Entity 'RFC7230' not defined
&RFC7230;
         ^
```
And it continues in that fashion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350828765

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 19:23:50 +0000 (UTC)

Yep.  It looks like for the ones that are building properly, kramdown-rfc2629 is downloading the references and embedding them in the XML.  This draft gets these at the beginning...  `<!ENTITY RFC7230 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml">` followed by `&RFC7230;` in the references section.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350829752

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 11:24:17 -0800

Just opened 

  https://bugzilla.gnome.org/show_bug.cgi?id=791491

(this was actually reported to me a few days ago, but I didn't make the connection...)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350829887

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 11:30:38 -0800

Apparently, adding

    stand_alone: yes

does the in-lining trick.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350831718

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 11:32:28 -0800

Yes, why this isn't the default is baffling.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350832218

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 11:36:02 -0800

Might make sense if you convert from MD to XML with the goal to continue editing the XML.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350833298

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 20:00:54 +0000 (UTC)

Great catch -- added a fix to use stand_alone on the xslt branch.  So, with a sample size of one so far, new-template took 32 seconds total on the most recent build, while xslt took 28 seconds.  Resulting output for [xslt](http://mikebishop.github.io/http-extensions/xslt/) and [xml2rfc](http://mikebishop.github.io/http-extensions/new-template/) is very similar.

While I do like the second better aesthetically, the primary goal here is maintainability and shared code; I can live with that.  Should I change the PR to be off the xslt branch instead?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350840551

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 23:51:40 +0000 (UTC)

Styling the XSLT output is easier, but it would a different stack to run.  I'd say that since it will make some of the things Julian relies on easier, we should pick xslt.

That reminds me, I can add a cache for the xslt to the template and get further speed gains.  Maybe some other time.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350897310

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 15:52:31 -0800

martinthomson approved this pull request.

You should get chair approval here.

> @@ -1,143 +1,11 @@
-xml2rfc ?= "xml2rfc"
-saxpath ?= "lib/saxon9.jar"
-saxon ?= java -classpath $(saxpath) net.sf.saxon.Transform -l
-kramdown2629 ?= XML_RESOURCE_ORG_PREFIX=https://xml2rfc.tools.ietf.org/public/rfc kramdown-rfc2629
+LIBDIR := lib

Add USE_XSLT := true here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#pullrequestreview-82680567

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 15:55:16 -0800

MikeBishop commented on this pull request.

-xml2rfc ?= "xml2rfc"

Yes, that's the extra commit on the other branch.  :-)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#discussion_r156236677

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 23:55:49 +0000 (UTC)

@MikeBishop pushed 2 commits.

ec6fd45  Use XSLT
0bb37c9  Header structure stand_alone

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/448/files/25d642aeb7654b1dc18c57344b15b9a611e25881..0bb37c9d3189a428d576162e9662422fe6d48c35

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 16:02:58 -0800

I've merged the XSLT branch into this one, so the PR now uses `xsltproc` within Martin's I-D template.  I agree with Martin that this needs chair approval:  @mnot, @mcmanus?

Note too that a lot of the speed gains come from running in Martin's Docker container on Circle -- the Travis build times for this branch are already improved (90-120 seconds vs. 120-150 seconds), but not as good as Circle (30-40 seconds).  I've been testing my fork of this repo against Circle.

I don't believe I have sufficient access to switch the repo from Travis to Circle, and you can't do that in a PR anyway, so that's definitely a chair action.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350899489

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 12 Dec 2017 00:10:39 +0000 (UTC)

mnot approved this pull request.

LGTM. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#pullrequestreview-82683935

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 12 Dec 2017 00:13:09 +0000 (UTC)

Switching over; please stand by...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350901263

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 16:16:09 -0800

(Note that Circle won't see anything to do on master until this PR is merged.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350901746

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 12 Dec 2017 00:16:22 +0000 (UTC)

Merged #448.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#event-1382582130

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 16:18:19 -0800

All green. Only used one container.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350902107

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 12 Dec 2017 00:19:19 +0000 (UTC)

Travis hook deleted.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350902273

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 12 Dec 2017 00:24:17 +0000 (UTC)

I did a push, seems to have worked. However, the HTML files are in different places from where they used to be -- we *can* update the links, but changing links is kind of uncool.

Also, I think `SUBMITTING.md` needs an update...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350903143

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 12 Dec 2017 00:27:00 +0000 (UTC)

Maybe instead of generating `draft-ietf-httpbis-*.html` we could generate `*.html`? That would reduce the number of links we need to change.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350903614

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 12 Dec 2017 02:49:57 +0000 (UTC)

Also - I strongly suspect that building issues.json on every push is going to burn through Github's rate limiting. Can we limit it, or at least assure that we recover from 429 gracefully?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350928743

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 21:44:28 -0800

I have rate limiting on issues.json, though we still hit the rate cap occasionally.

We can add rules for generating `*.html`.  That's a fairly simple exercise.  It's something like:

```make
latest:: a.html b.html c.html
a.html: draft-ietf-httpbis-a.html 
        cp $< $@
# etc...
```

We might do better, but it's a little sketchy.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350951568

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 22:00:32 -0800

That should work; it's just for the existing drafts, going forward we can use the "full" names.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-350953749

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 13 Dec 2017 01:19:00 +0000 (UTC)

ping. Links still broken.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-351249802

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 13 Dec 2017 06:29:59 +0000 (UTC)

I've updated SUBMITTING.md; please review.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-351296390

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 13 Dec 2017 06:50:08 +0000 (UTC)

Hmm. I just commited bcp56bis-00, and it builds locally, and on Circle, but doesn't upload the drafts to `gh-pages`. Any idea why @martinthomson?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-351299924

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 13 Dec 2017 06:24:44 -0800

Have you set a value for GH_TOKEN in the build configuration?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-351405709

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 13 Dec 2017 09:17:28 -0800

Re: the *\*ahem\**, see https://github.com/martinthomson/i-d-template/pull/119.  It wound up being easier to do inside the template as something that the parent repo could opt into, than to have the parent repo try to force extra things into gh-pages.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-351459826

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 13 Dec 2017 12:59:22 -0800

Ah, that's right - GH_TOKEN set, thanks.

It looks like gh_issues is built even for pull requests; is there a way to only do it for master?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-351520248

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 13 Dec 2017 21:01:46 +0000 (UTC)

Yes, though I don't much see the point, other than as another form of rate limiting.

You can check the branch in the step.  I think that the variable is CIRCLE_BRANCH.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/448#issuecomment-351520850