Subject: [Tools-discuss] Getting the "current" version of things

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Sep 2021 11:11:08 -0500

We have a rough edge at making it easy to say "I want the current agenda 
for FOO" or "I want the current draft text for draft-bar".

tools.ietf.org had a 404 handler on many of the things it served to map 
to the current version. The datatracker gives the current version, but 
doesn't make it easy to get a raw document (instead of the metadata 
page) for use with other tools, like rfcdiff.

Solving this with a 404 handler at www.ietf.org/archive/id (or any of 
the other places we look for things at www.ietf.org) has a bad 
interaction with using cloudflare to help get what should be static 
resources out as quickly as possible.

I want to separate the dynamic things from the invariant things.

I'm currently thinking of adding an endpoint somewhere, likely at first 
in the datatracker, and maybe later as a standalone service, that looks 
like:

{some prefix}/latest/{docname-without-version}

Remember, docnames can be for drafts, agendas, slides, whatever...

that will redirect (using a temporary redirect) to the current version 
of the named document in "best" format available, and allowing variants like

{some prefix}/latest/{docname-without-version}/txt

to force the format.

These would redirect to places that serve invariant things very efficiently.

Software like rfcdiff can take a bare docname and internally use this 
service to get the most recent thing.

People can keep tabs open pointed to agendas through this service to be 
sure to get whatever is current as a meeting approaches.

Thoughts?

RjS

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Sep 2021 18:14:25 +0200

Right direction...

> On 2021-09-07, at 18:11, Robert Sparks <[email-masked]> wrote:
> 
> adding an endpoint somewhere

Can we design the URIs for ease of use as opposed to ease of implementation?
Can we do this right so this becomes doc.ietf.org?

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Sep 2021 11:17:15 -0500

> Can we do this right so this becomes doc.ietf.org?
I think what I've proposed is compatible with that goal. Do you see 
something there that introduces impedance?

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 07 Sep 2021 09:36:04 -0700

> Thoughts?

I would very much like this. It was one of the main reasons I created 
the IETF CLI project (https://github.com/paulehoffman/ietf-cli) a while 
back. It is for a different purpose (opening drafts and RFCs locally in 
an editor), but it had the same background request.

FWIW, I have just updated the project so that when you open an RFC, you 
automatically find out of there are drafts that intend to update or 
obsolete the RFC. If you use the CLI and have suggestions, I'm always 
open to them.

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Sep 2021 18:41:42 +0200

On 2021-09-07, at 18:17, Robert Sparks <[email-masked]> wrote:
> I think what I've proposed is compatible with that goal. Do you see something there that introduces impedance?

Only the examples with /latest and /txt in them.

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Sep 2021 11:48:29 -0500

> Only the examples with /latest and /txt in them.

So lets dig into this, recognizing that we're talking now towards some 
future thing, and not necessarily the next step.

If you had doc.ietf.org, what do you envision the URLs there _would_ 
look like?

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Sep 2021 18:55:20 +0200

On 2021-09-07, at 18:48, Robert Sparks <[email-masked]> wrote:
> 
> If you had doc.ietf.org, what do you envision the URLs there _would_ look like?

Short, memorable, stable.

https://doc.ietf.org/rfc8610      (default form, HTML probably)
https://doc.ietf.org/rfc8610.pdf  

Note that the HTML forms do have a short header that is informed by the tools “htmlized” metadata header.  If someone wants the canonical form published by the RFC editor, they can go there (helped by links in the metadata header).

https://doc.ietf.org/draft-ietf-core-data-ct
Redirects to:
https://doc.ietf.org/draft-ietf-core-data-ct-04

(the latter is stable)

https://doc.ietf.org/agenda-interim-2021-cbor-16-cbor
Redirects to:
https://doc.ietf.org/agenda-interim-2021-cbor-16-cbor-01/

etc.

Now, it also would be interesting to get a search function like tools.ietf.org has:

https://doc.ietf.org/agenda-cbor-16
https://doc.ietf.org/data-ct

(Again, redirect to the longer forms.)

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Sep 2021 12:07:16 -0500

> (Again, redirect to the longer forms.)

So lets talk about leveraging a CDN or similar service for the immutable 
things.

With what you have here, you would _always_ have to go through logic at 
this service even if you specified something concrete enough that you 
could pull it from something that served only immutable content 
directly. Scaling of the logic for these things is different.

What if, instead of a single docs.ietf.org we had something like 
docs.ietf.org for the dynamic points, and archive.ietf.org for the 
immutables?

RjS

>
> Grüße, Carsten
>
> ___________________________________________________________
> Tools-discuss mailing list - [email-masked]
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: [email-masked]
> * Report tools.ietf.org bugs to: [email-masked]
> * Report all other bugs or issues to: [email-masked]
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Sep 2021 17:08:56 -0400

> I want to separate the dynamic things from the invariant things.

Sounds good.

    > in the datatracker, and maybe later as a standalone service, that looks

Why start with datatracker if you plan to use another name?
Just start with the name, and update DNS when it's a different server?

    > of the named document in "best" format available, and allowing variants

Sounds perfect.

    > sure to get whatever is current as a meeting approaches.

Given the glitches I've observed with google calendar not updating/caching
calender entries, having a URL for an agenda that doesn't change would help
work around that problem.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide