working group snippets need updating

[ghwood]

The WG snippets need updating in a few ways.

1) the URLs built on the "Acronym field" currently take the form of https://datatracker.ietf.org/wg/FOO when the current base URL should be https://datatracker.ietf.org/group

2) the "list subscribe" field currently only accepts email addresses (even when updating existing WG snippets) when it should be a URL

[mgax]

2. the "list subscribe" field currently only accepts email addresses (even when updating existing WG snippets) when it should be a URL

Should the field always be an http(s) URL? There are some email values currently in the database, e.g. bpf@ietf.org, mls@ietf.org. Perhaps they should be converted to their web page equivalent (e.g. https://www.ietf.org/mailman/listinfo/bpf)? And while I'm at it, should I convert http URLs to https?

[ghwood]

Given, recent and upcoming changes, I'm looking at @rjsparks to confirm that the place to point folks to subscribe to an IETF mail list should always be on the web and use HTTPS.

[mgax]

And while I'm at it, should I convert http URLs to https?

To clarify, I'm not suggesting an automated way to generate the URLs, but rather a one-time data migration. Perhaps it's a bit overkill given there are so few WG snippets in the database.

I guess the most important question is whether the "list subscribe" field should still allow email values, and if so, would it be fine to reformat them as actual mailto: URLs, so that the database values are all valid URLs.

[ghwood]

got it. And, looking at this a little closer, the main thing is to allow "list subscribe" to be URLs. There are so few of these (and I'm not recalling exactly how/where they are used—and some may actually be for concluded WGs where the email list is no longer available for subscription—that we'll need to review and update them manually anyway.

[rjsparks]

Yes, we will always advertise the web mechanic for managing subscriptions going forward, whether an email based mechanic to do so exists or not.

[rjsparks]

a data migration for any URLs pointing into ietf.org, iab.org, irtf.org, rfc-editor.org make sense - those will all redirect to https anyhow. If there are any that point to domains out of our control, we don't know whether https will work without a manual check.

[mgax]

There are so few of these (and I'm not recalling exactly how/where they are used

Looking at the References Index, the only page that currently displays a Working Group snippet is the homepage:

• On the Featured Working Group box, it displays the list_email field of the MLS WG (it renders as a link which, when clicked, opens an email composer, to send a message to the mailing list).
• On the Featured RFC box, it displays the RFC 9420 RFC snippet, which references the MLS working group snippet, but no content from the MLS WG snippet is displayed in this box.

It's possible for Standard pages to reference a Mailing list signup snippet, which in turn may reference a Working group snippet. In that case, the list_subscribe link will be displayed under the main content.

[rjsparks]

Not trying to change the work here (yet), but I do have to point out that this is building a redundant set of data with the datatracker and that the data can get stale. I wonder if there's already the general notion of a snippet that takes a field (or two) and uses an API to go get the fill-in data from somewhere else. If so, when does that API fetch take place? (I ask, because for this snippet, providing an acronym like "dispatch" and then pulling values out of https://datatracker.ietf.org/api/v1/group/group/?acronym=dispatch might make more sense in the long run, though Greg might want to add a richer description.

[mgax]

I wonder if there's already the general notion of a snippet that takes a field (or two) and uses an API to go get the fill-in data from somewhere else. If so, when does that API fetch take place?

@rjsparks there's no such built-in mechanism; if data were to be pulled from an external source, we would go for an ad-hoc solution, like creating a management command to sync records, and running it periodically (e.g. daily). The initial sync would happen when the snippet is created.

Two issues come to mind, which are not necessarily specific to syncing from datatracker.ietf.org, which I've missed in the initial audit:

• Cloudflare cache invalidation seems to be configured, but not for a Docker setup, and it doesn't account for children of index pages, or snippets being used in pages. If the cache max-age is low, this might not be a problem though, but it seems to be set to 4 hours:

  % curl -sI https://www.ietf.org/ | grep -i Cache-Control
  cache-control: public, max-age=14400

• In case the sync goes wrong, there seems to be no centralised mechanism to capture errors. Sentry is used in various ietf-tools repositories, but it was removed from wagtail-website.

[rjsparks]

The management command based sync is what we have been ripping out (perhaps it was done badly the first time). I don't want to return there without a discussion about architecture that's larger than this current project.

We need to defer discussion of central capture for the moment - our new architecture plans for that are still being worked out.

Is correcting automated CF cache invalidation a reasonable separate task to add to the current project?

[mgax]

Is correcting automated CF cache invalidation a reasonable separate task to add to the current project?

Yes, it looks like it might fit within the timeframe, let's add it tentatively.