Re: [Rswg] [Ext] typesetting is fun, It is time to get rid of PDF

[John C Klensin <[e-mail]>]

Jay,

One small observation, while, I think, agreeing with you...

--On Saturday, April 13, 2024 22:45 +0100 Jay Daley
<[e-mail]> wrote:

> 
>> On 13 Apr 2024, at 00:57, Brian E Carpenter
>> <[e-mail]> wrote:
>> 
>>> Okay, legals calls are for lawyers and their clients. But neither
>>> you nor the RSWG are the client. If there was a legal issue, it
>>> is most likely the IETF or its associated organizations that are
>>> at risk - they are the client.  If this is an actual legitimate
>>> concern of yours, ask Jay for the IETF's input. Either way, not
>>> a decision for this group.
>> 
>> Exactly. I think that each party that is likely to receive
>> subpoenas needs to *formally* state their requirement after
>> getting legal advice from their own counsel. Then the RSWG can
>> formulate an appropriate formal requirement in a draft that we
>> submit to the RSAB.
>> 
>> Which parties? I suggest the IETF Trust, IETF LLC, the RPC and the
>> Secretariat. (The RPC and the Secretariat are not part of the
>> LLC.) Given the copyright statement in some older RFCs, to be
>> complete we'd have to include the ISOC, except that PDF is already
>> published for those RFCs.
> 
> The LLC has ultimate legal responsibility here so the LLC can
> indeed answer this.
> 
> This is not a question of "what are we legally required to
> produce in response to a declaration request" but more about the
> practical considerations of what we produce.
> 
> Our responses to declaration requests are largely of the form
> "RFC/I-D X was available at time T". This is nearly always
> provided in the form of a PDF, but sometimes a hard copy.   Most
> importantly it is a single document with the three key things -
> declaration, signature and, if requested, a copy of the RFC/I-D in
> question.  That encapsulation provides a guarantee of authenticity
> of the included RFC/I-D. 
> 
> If the reply were to be in any other format and a copy of the
> RFC/I-D requested as part of it then the complications of providing
> the same guarantee are simply not worth it. Therefore, even if RFCs
> are no longer published in PDF format, a PDF would be provided.
> That would mean a PDF being manually created from either the plain
> text or HTML rendering.  I assume the HTML to ensure that diagrams
> are included but I may be wrong.  Given the low volume of requests,
> this is not a problem.  
> 
> What is worth considering more, is how this would work if two
> changes to the policy took place - to stop producing PDFs as a
> matter of course, and to allow versions of RFCs  In that case, and
> assuming we needed the HTML to ensure diagrams are included, copies
> of the HTML of each version need to be kept, and either a copy of
> that rendered into HTML is kept with it, or there needs to be a
> guarantee that these can be rendered into PDF when needed even if
> that is forty years later.  There may also be a requirement to
> protect against subtle tampering with the HTML.

If you report "RFC/I-D X was available at time T" and included a copy
of the document in PDF form, logic (without any claim to legal
reasoning) suggests that the PDF represent the document as seen by
people at time T.  If the PDF is generated by processing HTML, even
for time T, the results may differ somewhat for different browsers
and local configurations.  If the time of the request is enough after
T that HTML (the language, not our initial/official version of the
RFCXML for the document) and conventions about how to render it in
browsers had changed, then the LLC (or RPC) has to either have enough
tools around to render the PDF in what would have been its original
form or you would need to provide the PDF from a more recent
rendering and, I would assume, a rather careful explanation.  

To avoid trying to think about that in legal terms, think about an
economic analogy: if an object had a particular price in 1924, or
even 1824, we would rarely report that price inflation-adjusted to
today without an explanation and would probably need to supply the
original price as part of the explanation.  The analogy to our
documents doesn't fit and is more complicated in two important ways:
we are talking about whole documents, not a single value (or ever set
of values, a table, or the like) and trying to supply both the
hypothetical original and current derived forms would mean that the
original would need to be generated anyway.

> Given all that fuss, I can imagine it being much easier to store a
> PDF of the HTML of any archived version at the time of archiving.

The comment above certainly does not change that conclusion.  It
merely reinforces it.  

> To summarise, there is no legal issue here at all.

I'm actually not certain of that, but here I have to tiptoe into
legal territory.  You are certainly correct if the LLC receives and
responds to the requests.  But, as I understand it the Trust is still
legally separate from the LLC and is still the legal owner of the
documents.  If that is correct, a request could reasonably be
addressed to it/them.  Presumably that changes nothing else about
either your comments or mine because they would need to find, or get
the RPC (or someone else) to produce, the documents to be delivered.
Or they could find a legally appropriate was to redirect the request.
Life under that scenario would be much less complicated if they had
access to an archived version of the PDF created at the time of RFC
publication than if they had to generate it or respond to the court
order or other request in a way that said "we are the owners of this
document but the LLC is responsible for it".  

 best,
   john