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

[Jay Daley <[e-mail]>]

> On 28 May 2022, at 21:31, John C Klensin <[e-mail]> wrote:
> 
> 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?

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

> 
> 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
> <[e-mail]> 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
> [e-mail]
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> 

-- 
Jay Daley
IETF Executive Director
[e-mail]

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