[Tools-discuss] Re: PDF [Re: Tools team meeting tomorrow 9 July 2024 1800 UTC]

[Carsten Bormann <[e-mail]>]

Hi Robert,

Thank you for responding to this.

On 8. Jul 2024, at 23:29, Robert Sparks <[e-mail]> wrote:
> 
> 
> On 7/8/24 1:34 PM, Carsten Bormann wrote:
>> On 8. Jul 2024, at 20:27, Robert Sparks <[e-mail]> wrote:
>>> The agenda and the beginnings of notes for the meeting is available at https://notes.ietf.org/tools-team-20240709. Details will continue to be added up to and during the meeting.
>> This discusses expensive resources (“endpoints”) for building PDF forms of documents.
>> 
>> Could we maybe stop pdfizing things in weird ways and simply build the correct PDF form on I-D submission?
>> The current state is just such a waste of time.
> 
> This glosses over a lot, so lets dig a little:
> 
> - by "correct PDF form" I assume you mean what xml2rfc would produce given xml input.

Yes.
Something good enough to judge what the RFC editor will ultimately publish.

> What about drafts that are still being submitted as text only

I personally don’t care.  OK, you have to do *something*.

> - do we stop providing any pdf form of those? What about drafts and RFCs from more than 5 years ago?

So do something.  PDF-printing the .TXT seems to have worked so far.

> - The expensive part is running the pdf creating software (currently weasyprint) and moving that expense to draft posting time vs the first time someone accesses the pdf document just moves the expense around.

The expense is trivial (*).  The difference is whether I have to wait while the data is generated on demand or they can be provided immediately (or already is on my laptop via rsync).  I sure value my time more than that trivial expense.

> It might even make the total expense higher if no-one every asks for the pdf of a particular version of a draft.

That is true, but probably not relevant (*).

> - One sharp edge is running the pdf creating software over provided svg (even with our badly constructed restrictions on the SVG). We know of extant submissions that cause the pdf generation call to fail to return.

I can imagine that.  No soup for these drafts then (fall back to PDF-printing the TXT).

Grüße, Carsten

(*) conservative estimate: 2000 active I-Ds, each submitted 10 times per year, at 20 s of CPU per ingestion.
That is about 111 CPU hours per year, or < $10/yr on AWS at retail prices?
You writing your response already cost more...