Subject: Re: [rfc-i] Meta decorations in generated HTML

From: John C Klensin <[email-masked]>
Date: Sat, 28 May 2022 16:31:23 -0400

John, Eliot,

Combining the recent exchange about large code blocks and
stability with Eliot's comment about tracking policy sources, a
question: how does additional tagging interact with long-term
stability/archival issues?  If the answer is that this is a
matter of what gets generated for the HTML version only and that
the XML is not affected at all, I suppose it is not an issue.
But the conversation about intentionally stable URLs and hosting
images at the datatracker at ticket 776 caused me to wonder.
One of the ways of looking at the RFC stability problem is to
ask whether, if the IETF were to implode and the entire tree of
names and associated files and data vanish, would documents and
all of their content still be accessible and usable without
editing or hunting expeditions?

Of course the question of how likely the IETF is to implode is
independent of  the above question.

thanks,
   john

--On Saturday, May 28, 2022 08:17:29 +0200, Eliot Lear
<[email-masked]> wrote:

> Hi John,
> 
> Since this looks like it can nearly all be automated, it
> mostly looks  good to me.? Two points:
> 
>   * The independent stream doesn't have a logo, and neither
> does the nascent Editorial stream.? We should probably
> have something (I'm referring to PR#777).
>   * Once we start adding metadata tags like this, it'd be good
> to find some way to track the policy sources so that we
> can track changing requirements.
> 
> Eliot
> 
> On 25.05.22 02:37, John R Levine wrote:
>> We have two xml2rfc tickets asking to add more meta tags in
>> the  rendered HTML of RFCs.
>> 
>> Ticket 757 is mine
>> https://github.com/ietf-tools/xml2rfc/issues/757
>> 
>> It asks for the meta tags that Google Scholar uses. I know
>> these are  the right tags because I added them to the
>> HTML-ized versions of older  RFCs which are now at long last
>> showing up in Google Scholar.
>> 
>> Tickets 776 and 777 are from Mark Nottingham 
>> https://github.com/ietf-tools/xml2rfc/issues/777
>> 
>> It asks for Open Graph metadata (see https://ogp.me/) which
>> makes  links display nicely on Facebook, Twitter, some
>> Wordpress sites, and  probably other places.? The should work
>> also for the HTML rendered  versions of I-D's.
>> 
>> Are there other meta tags that people would find useful?? Do
>> we agree  that we want the OG tags?? We already agreed on the
>> Google Scholar  tags about a decade ago but it took a while
>> to get around to it.
>> 
>> If we like the OG tags, should I arrange to add them to the
>> HTMLized  versions of pre-XML RFCs?

_______________________________________________
rfc-interest mailing list
[email-masked]
https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "John Levine" <[email-masked]>
Date: 28 May 2022 18:15:15 -0400

>the XML is not affected at all, I suppose it is not an issue.

As I thought I said several times, it is in the HTML only.  Both
the tags Scholar uses and the OG tags have been stable for at
least a decade.

>editing or hunting expeditions?

Good questions. The text version is text, the PDF is PDF/A-3 which
should render in any compatible PDF viewer. RFC 7992 says 

      The HTML document will be self-contained, without requiring
      external files for images, CSS, JavaScript, or the like.

But in fact the rendered HTML includes
https://www.rfc-editor.org/js/metadata.min.js, and imports three fonts
from Google. I think the HTML will display legibly if none of those
are available but I haven't checked.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Sat, 28 May 2022 19:05:15 -0400

John,

Thanks for your patience.  I, unfortunately, have not had time
to read every posting on this list carefully and, when I get
overextended, sometimes do not follow it for weeks at a time.
Glad part of the question was useful and thanks for the answer
to that.

best,
   john

--On Saturday, May 28, 2022 18:15 -0400 John Levine
<[email-masked]> wrote:

>> stability with Eliot's comment about tracking policy sources,
>> a question: how does additional tagging interact with
>> long-term stability/archival issues?  If the answer is that
>> this is a matter of what gets generated for the HTML version
>> only and that the XML is not affected at all, I suppose it is
>> not an issue.
> 
> As I thought I said several times, it is in the HTML only.
> Both the tags Scholar uses and the OG tags have been stable
> for at least a decade.
> 
>> But the conversation about intentionally stable URLs and
>> hosting images at the datatracker at ticket 776 caused me to
>> wonder. One of the ways of looking at the RFC stability
>> problem is to ask whether, if the IETF were to implode and
>> the entire tree of names and associated files and data
>> vanish, would documents and all of their content still be
>> accessible and usable without editing or hunting expeditions?
> 
> Good questions. The text version is text, the PDF is PDF/A-3
> which should render in any compatible PDF viewer. RFC 7992
> says 
> 
>       The HTML document will be self-contained, without
> requiring       external files for images, CSS, JavaScript, or
> the like.
> 
> https://www.rfc-editor.org/js/metadata.min.js, and imports
> three fonts from Google. I think the HTML will display legibly
> if none of those are available but I haven't checked.
> 
> R's,
> John

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 30 May 2022 09:03:04 +1000

> are available but I haven't checked.

I have.  It works fine.

(The fonts should be hosted alongside the HTML though.  It used to be that relying on Google's CDN was better, but that is now slower and less private.)

---

From: Jay Daley <[email-masked]>
Date: Mon, 30 May 2022 12:24:27 +0100

> On 28 May 2022, at 21:31, John C Klensin <[email-masked]> wrote:
> 
> John, Eliot,
> 

The question of "what if X implodes" could be asked of any organisation.  In our context it could equally be asked of the IETF, the RFC Editor, the IAB, the LLC, the IETF Trust, etc.  I say 'equally' because the risk of each imploding is so small as to be practically indistinguishable and because the fates of each are so closely intertwined.  The solution to the persisting access problem therefore has to sit outside of the IETF (in its widest sense) entirely.  Luckily, this has been recognised for many years and all our RFCs are both proactively and reactively deposited in multiple external archives, many of which are found with a trivial search. 

The additional tagging does indeed only apply to the generated HTML and not the XML, but the questions then become - how important is that tagging (metadata) to future discoverability, is it true metadata or derived data (i.e. can it be inferred from the RFC) and does that new metadata need to be included with any external archive deposit. I’m sure John and the RPC have this in hand.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 30 May 2022 16:42:23 -0400

It appears that Jay Daley  <[email-masked]> said:
>The additional tagging does indeed only apply to the generated HTML and not the XML, but the questions then become - how important is
>that tagging (metadata) to future discoverability, is it true metadata or derived data (i.e. can it be inferred from the RFC) and does
>that new metadata need to be included with any external archive deposit. I’m sure John and the RPC have this in hand.

The HTML metadata we're talking about is all derived mechanically from the XML, other than the proposed
logo images that the OG data would point to.

We have agreements with the Computer History Museum and the National
Library of Sweden to keep mirror archives of RFCs. I have recently
confirmed with the CHM that they are doing so, but I haven't been able
to find a contact in Sweden. If anyone has any contacts there, please
let me know. (I know which IETFers live in Sweden, no need to tell me
again.)

R's,
John

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 31 May 2022 08:11:26 +0900

Hello John, others,

> let me know. (I know which IETFers live in Sweden, no need to tell me

This is good to know. Somewhere in the future, it might also be good to 
look at https://archiveprogram.github.com, and in particular 
https://arcticworldarchive.org.

Regards,   Martin.