Subject: [Tools-discuss] disappearing IDs on www.ietf.org

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2020 11:32:12 -0400

I had given a link to a document:
 https://www.ietf.org/id/draft-richardson-opsawg-securehomegateway-mud-04.html

I thought I was smart and modern to give them the HTML rendered link.
But, two hours later, I found a few stupid typos and posted -05.
The -04 content above went away.  This is a surprising change from how
tools.ietf.org copy behaves.

I'm not sure what to suggest here.

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 10 Sep 2020 17:41:18 +0200

Hi Michael, 

> tools.ietf.org copy behaves.

The URL path that behaves the same way as tools.ietf.org/id/ is this:

  https://www.ietf.org/archive/id/

Best regards,

	Henrik

> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2020 13:45:24 -0400

Henrik Levkowetz <[email-masked]> wrote:
    >> But, two hours later, I found a few stupid typos and posted -05.  The
    >> -04 content above went away.  This is a surprising change from how

    >   https://www.ietf.org/archive/id/

okay.
  "archive" because that's where the draft goes after it's no longer current.

1) Would some kind of 30x redirect make sense?
2) Or maybe a custom 404 error document that suggested maybe look there?
   {obviously, both are somewhat active content, which may be undesireable}

I think that we need to think about how to deal with the many different links
we have.  (this is a group question, not a Henrik-only question...)

In the meantime, I guess the DT status page is the best way to refer to a
document.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Sep 2020 19:50:20 +0200

> On 2020-09-10, at 17:41, Henrik Levkowetz <[email-masked]> wrote:
> 
> Signed PGP part
> Hi Michael, 
> 

Right.  A reference to https://www.ietf.org/id/draft-richardson-opsawg-securehomegateway-mud-04.html currently only gives a generic 404 page.
What it maybe should do is a display a switch page that provides a brief explanation about expiry and replacement of I-Ds and then offers links to

— the archive page https://www.ietf.org/archive/id/draft-richardson-opsawg-securehomegateway-mud-04.html
— the current page https://www.ietf.org/id/draft-richardson-opsawg-securehomegateway-mud-05.html (or the RFC), if any

Also, we should design most places that give out the https://www.ietf.org/id/draft-richardson-opsawg-securehomegateway-mud-04.html link to instead give out a timeless link like https://www.ietf.org/id/draft-richardson-opsawg-securehomegateway-mud.html (which currently doesn’t work).

Cool URIs don’t change: https://www.w3.org/Provider/Style/URI.html

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Thu, 10 Sep 2020 13:16:36 -0500

Note that the current draft also appears in the archive.

The two different pools come from the notions of having an 
ID-repository, where expired drafts go away, and an ID-archive.

Active IDs are added to the repository and the archive at the same time.

When a draft is expired, revised, or replaced, it is removed from the 
repository of active IDs.

RjS

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2020 16:09:39 -0400

> repository of active IDs.

The surprise is perhaps that a non-expired, but replaced-draft is removed.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 10 Sep 2020 15:53:43 -0500

> The surprise is perhaps that a non-expired, but replaced-draft is removed.
Can you expand? Why is that surprising? The replaced draft is no longer 
active.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Sep 2020 08:57:18 +1200

An interesting little twist in this problem caught me recently.
I resolved to include SVG diagrams in a draft, but not ones
that can be represented correctly in ASCII art. So what to put in
the .txt format? Well, I thought so cleverly, a pointer to the
HTML version would be nice.

That's fine as long as the URL for the HTML version works.

See the result by looking at draft-carpenter-eligibility-expand-04.txt
and trying to look at the figures. (No such problem in the -05 version,
until -06 comes out.)

Regards
   Brian

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Sep 2020 17:37:19 -0400

> On Sep 10, 2020, at 4:09 PM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

Michael, this is not new.  It has worked this way as long as I have been involved with the IETF.

Russ

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Sep 2020 23:41:48 +0200

> Michael, this is not new.  It has worked this way as long as I have been involved with the IETF.

… which is probably one of the reasons the tools URIs became the standard way of doing things.

(I still believe my suggestions earlier in the thread are the right way to handle this.)

Grüße, Carsten

---

From: Bob Hinden <[email-masked]>
Date: Thu, 10 Sep 2020 15:38:08 -0700

Somewhat related to disappearing IDs.   We had a w.g. draft expire today.  It disappeared from

https://datatracker.ietf.org/wg/6man/documents/

The authors are working on an update, but I think that adopted w.g. drafts should not disappear from the w.g. document page if they expire.  They are still w.g. drafts (that is, we won’t need to do another adoption call).

Can this be fixed?

Bob

> On Sep 10, 2020, at 2:41 PM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Sep 2020 11:25:09 +0200

Am 10.09.2020 um 19:50 schrieb Carsten Bormann:
> ...
> ...

+1

That said, we absolutely need a stable URI template for HTML versions of
*any* draft, be it current or expired, and no matter whether it was
generated as v3 HTML output or just htmlized.

Otherwise, a formatter does not have sufficient information what links
to generate for "deep links" into internet drafts, or in references.
This is likely the reason why xml2rfc still generates links to
tools.ietf.org, although www.ietf.org has the "modern" HTML version.

(and the same is true for rfc2629.xslt, but here the default can be
overriden on a case-by-case basis).

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Sep 2020 09:36:21 -0400

> The authors are working on an update, but I think that adopted w.g. drafts should not disappear from the w.g. document page if they expire.  They are still w.g. drafts (that is, we won’t need to do…

There is no need for an additional call for adoption.  When the revision is posted, it will appear in the list.

Russ

---

From: Bob Hinden <[email-masked]>
Date: Fri, 11 Sep 2020 07:30:50 -0700

Russ,

> On Sep 11, 2020, at 6:36 AM, Russ Housley <[email-masked]> wrote:
> 
>> 

I knew that, but I would like to see w.g. drafts not time out on the w.g. status page.   Once adopted they have official status.  I think we do this for drafts sent to the IESG.

Bob

---

From: Robert Sparks <[email-masked]>
Date: Fri, 11 Sep 2020 09:53:56 -0500

I've created https://trac.tools.ietf.org/tools/ietfdb/ticket/3078

---

From: Robert Sparks <[email-masked]>
Date: Fri, 11 Sep 2020 10:20:32 -0500

Note the comment I added.

Right now if a group abandons a draft, the current behavior (where the 
draft disappears when it expires) could be considered a feature.

With the change, chairs will have to be more careful about explicitly 
marking abandoned drafts.

RjS

On 9/11/20 9:53 AM, Robert Sparks wrote:
>>> On Sep 11, 2020, at 6:36 AM, Russ Housley<[email-masked]>  wrote:
>>>
>> bugs athttp://tools.ietf.org/tools/ietfdb
>> or send email [email-masked]
>>
>> or send email [email-masked]
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Sep 2020 12:29:59 -0400

> Can you expand? Why is that surprising? The replaced draft is no longer

It's a behaviour change.

Yes, but
  1) it hasn't expired.!!
  2) there is no redirect, just a 404.
  3) old documents stuck around on tools.ietf.org, so the links didn't go
     stale,but the header would say that it was not the most recent draft.

rfcdiff could never work if we removed replaced drafts.
In fact, we keep the expired ones around forever, which certainly helps us
with rfcdiff!

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Sep 2020 12:34:06 -0400

> Michael, this is not new.  It has worked this way as long as I have been involved with the IETF.

from the FTP/rsync site, yes, sorta.
If you were coming that way, then you'd get a directory listing, showing the
replacement draft next to it.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 11 Sep 2020 11:51:31 -0500

>      > Can you expand? Why is that surprising? The replaced draft is no longer
No - it's been that way for years.
> In fact, we keep the expired ones around forever, which certainly helps us

So - use /archive/id/

That tree has exactly all the properties you are asking for.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 11 Sep 2020 10:14:20 -0700

Robert,

> On Sep 11, 2020, at 8:20 AM, Robert Sparks <[email-masked]> wrote:
> 
> Right now if a group abandons a draft, the current behavior (where the draft disappears when it expires) could be considered a feature.
> 
> With the change, chairs will have to be more careful about explicitly marking abandoned drafts.

I agree, with this change they will see the abandoned drafts in the list of w.g. drafts and will be reminded to formally abandon them.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 11 Sep 2020 10:25:49 -0700

I wanted to point out that when 6MAN did the update to the IPv6 spec that became RFC8200, each new draft incorporated one specific updating RFC.    This made it easy to see what the changes were.   Having each draft available was very helpful to see the changes and see what the diffs were from the previous draft.  In this case, a new draft was not replacing the previous draft.  This work was done in 2015-2017.

I hope this is still possible.

Bob

> On Sep 11, 2020, at 9:29 AM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 11 Sep 2020 12:30:51 -0500

> I hope this is still possible.
Yes. There hasn't actually been a change.

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Sep 2020 14:59:19 -0400

> I knew that, but I would like to see w.g. drafts not time out on the w.g. status page.   Once adopted they have official status.  I think we do this for drafts sent to the IESG.

I disagree.  If the I-D has expired, it should not be shown there.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Sep 2020 15:16:19 -0400

> No - it's been that way for years.

Yes, I appreciate that the www.ietf.org links acted that way.
But, www.ietf.org didn't have HTML rendering from HTML "for years"
The DT pointed at tools.ietf.org for many things, and those URLs didn't expire.

    > So - use /archive/id/

So, then can we please point to that URL in the DT?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Sep 2020 15:17:44 -0400

> I disagree.  If the I-D has expired, it should not be shown there.

We are asking that it be in the list, marked as expired.
Chairs can remove it from the list, if it is abandonned.
Otherwise, they can bug authors to either update, or abandon.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Sep 2020 10:38:40 +1200

> The DT pointed at tools.ietf.org for many things, and those URLs didn't expire.

Well, yes, that's the change and (IMNSHO) the proof that the tracker has
always had it wrong, as far as user convenience goes.

This isn't really a tools-discuss problem, since the datatracker is simply
doing what RFC2026 implies, i.e. disappearing a draft when it is replaced:

"At any time, an
 Internet-Draft may be replaced by a more recent version of the same
 specification, restarting the six-month timeout period...
 ...Internet-Drafts have no formal status, and are
 subject to change or removal at any time."

So don't request a change in the datatracker, request a change in RFC2026.
Something like "Replaced or expired drafts are retained as a record of
discussion and for verification of prior art claims."

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Sep 2020 10:47:59 +1200

> Otherwise, they can bug authors to either update, or abandon.

Yes. Robert's note on the ticket is correct. A common case (I've experienced
it as an author quite recently) is that WG discussion has subsided, the draft
is probably not ready for WGLC, and the authors have had other priorities.
The expiry event is useful because it wakes up the authors and chairs, but
the document needs to stay visible until a decision is taken to update it,
do the WGLC as-is, or abandon it.

(Actually there are other options: in my case, the decision was to fold the
material into another WG draft. But the whole point is to avoid *accidental*
loss of the draft.)

   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Sep 2020 10:31:21 +0200

> I disagree.  If the I-D has expired, it should not be shown there.

A little Saturday metacomment:

This is a nice example of “process confabulation”, designing software for what SHOULD happen, not for what actually DOES (and NEEDS TO) happen.

Our discussion of Internet-Drafts is dominated by what I’ll call the “Expiry Doctrine” — Internet-Drafts expire and then no longer exist.  Since this doctrine is obviously unworkable per se, we patch it up by providing a separate archive of expired drafts.

What actually happens is that URLs for Internet-Drafts are generated by various pieces of software (email, web pages) and propagate into other places.  At the time they are first generated, these Internet-Drafts are not expired yet.  The expiry doctrine makes us delete the data behind these URLs at expiry time, making the URLs we use for Internet-Drafts *unstable* URIs.

The archive can be addressed by *stable* URIs, but these are not the ones generated during the pre-expiry usage of Internet-Drafts.  Stable URIs need to be generated manually, which mostly does not happen at the time the URIs propagate into various places.

The tools server has been providing stable URIs throughout for Internet-Drafts (both for a single draft and for an entire series of revisions), which is probably a strong reason most people have been using tools server URIs (and still continue to do so) instead of the unstable “official” URIs to link to Internet-drafts.  Since the tools server has not been updated for the v3 world, there is now more incentive to use the “official” infrastructure, and the problems caused by the process confabulation surface once again.

The only true fix is to stop constraining ourselves by the expiry doctrine, and instead design the systems for what we are actually doing (and want to be doing!) with them.  Bridge pages like the ones I proposed are more patches and may restore some workability while continuing to pay lip service to the expiry doctrine and enduring the problems it creates.

How do we represent the (desirable) aspects of expiry without trying, unsuccessfully, to live the expiry doctrine?
By making expiry (and replacement) a dynamic *property* of a draft.  (Note that there is text in each draft that describes the current value of this property based on the current date — this text is actually more likely untrue than true, and this has caused all kinds of problems with people taking the text at face value.  Instead it should point to a resource where the true current state can be ascertained.)

I cannot finish this note without noticing how all this is not in the domain of the RFC editor — we have kept the domain of authoring and progressing documents out of this domain and are continuously baffled by the process discontinuities that the cliff between authoring and publishing creates.  We need to think about the entire process of RFC creation in a unified way to reduce the obstacles.

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Sat, 12 Sep 2020 11:57:20 -0500

One minor, but I think important, tweak to your commentary.

> Our discussion of Internet-Drafts is dominated by what I’ll call the “Expiry Doctrine” — Internet-Drafts expire and then no longer exist.  Since this doctrine is obviously unworkable per se, we pat…
The archive is _all_ drafts, not just expired ones - the active ones are 
there too. It is the stable thing you are asking for already. The 
question I'm hearing is do we point more things at that by default.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Sep 2020 08:31:47 +1200

> This is a nice example of “process confabulation”, designing software for what SHOULD happen, not for what actually DOES (and NEEDS TO) happen.

And what SHOULD happen is defined in RFC2026, our most basic process document.
I don't think we can blame the official tools for following the official rules.
There are 14 RFCs that update RFC2026 already, so one more can't do much harm.

   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Sep 2020 23:50:57 +0200

On 2020-09-12, at 18:57, Robert Sparks <[email-masked]> wrote:
> 
> The archive is _all_ drafts, not just expired ones - the active ones are there too. It is the stable thing you are asking for already. The question I'm hearing is do we point more things at that by default.

Yes, I should have made this more clear.

Still, the archive does not tell me what the current status is — it only has the (mostly wrong) expiry language in it.

(People do get upset quickly when the legacy tools scripts manage to miss a status update on a tools I-D, for good reasons.)

So, yes, I’ll continue to rsync over the archive, but I also would like to have a web page I can hand out links to that combines the archived I-D with information about whether it is current, has been updated, replaced, expired, published as an RFC, etc.  And I would like that web page to be the canonical home of an I-D.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Sep 2020 20:28:33 -0400

> A little Saturday metacomment:

Were you in the shower again today, to have such deep thoughts?

    > What actually happens is that URLs for Internet-Drafts are generated by
    > various pieces of software (email, web pages) and propagate into other
    > places.  At the time they are first generated, these Internet-Drafts
    > are not expired yet.  The expiry doctrine makes us delete the data
    > behind these URLs at expiry time, making the URLs we use for
    > Internet-Drafts *unstable* URIs.

    > The archive can be addressed by *stable* URIs, but these are not the
    > ones generated during the pre-expiry usage of Internet-Drafts.  Stable
    > URIs need to be generated manually, which mostly does not happen at the
    > time the URIs propagate into various places.

+1

    > By making expiry (and replacement) a dynamic *property* of a draft.
    > (Note that there is text in each draft that describes the current value
    > of this property based on the current date — this text is actually more
    > likely untrue than true, and this has caused all kinds of problems with
    > people taking the text at face value.  Instead it should point to a
    > resource where the true current state can be ascertained.)

Since the draft knows when it expires, maybe it could mark itself.
As, I don't really want to put in JS into HTML generated WG drafts, I wonder
how to do this with CSS.
A simple way I can think of is to reference some CSS file that includes the
date of expiry.... [oh my I didn't know we import google hosted fonts]
And there is JS in there already. Oh. Unhappy face.
Do HTML generated RFCs have JS in them?

Anyway, I had mind something like:
   <link href="202009.css" rel="stylesheet" type="text/css">

which would go into every draft issues in September, and six months after 2020-09-30, would
make the draft have an expired mark on it.

    > I cannot finish this note without noticing how all this is not in the
    > domain of the RFC editor — we have kept the domain of authoring and
    > progressing documents out of this domain and are continuously baffled
    > by the process discontinuities that the cliff between authoring and
    > publishing creates.  We need to think about the entire process of RFC
    > creation in a unified way to reduce the obstacles.

Agreed.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Sep 2020 20:37:01 -0400

> There are 14 RFCs that update RFC2026 already, so one more can't do much harm.

I think we should really amend section 2.2.
We write:

   An Internet-Draft that is published as an RFC, or that has remained
   unchanged in the Internet-Drafts directory for more than six months
   without being recommended by the IESG for publication as an RFC, is
   simply removed from the Internet-Drafts directory.

I think that we should change "removed" to "expired"

1) We are forced to keep them for IPR reasons.
2) rfcdiff can't work if the old copy isn't somewhere.

Is www.ietf.org/id the actual "internet-drafts" directory?
I note that RFC2026 does not explicitely say "FTP" :-)

BTW: Was there a point where people anon-FTP'ed into ftp.ietf.org, and just
uploaded drafts on their own?  When I started in 1995, one would email them
to the secretariat-type entity, and wait a day or so.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Sep 2020 12:24:10 +0200

Am 12.09.2020 um 18:57 schrieb Robert Sparks:
>> This is a nice example of “process confabulation”, designing software
>> for what SHOULD happen, not for what actually DOES (and NEEDS TO) happen.
>>
>> Our discussion of Internet-Drafts is dominated by what I’ll call the
>> “Expiry Doctrine” — Internet-Drafts expire and then no longer exist.
>> Since this doctrine is obviously unworkable per se, we patch it up by
>> providing a separate archive of expired drafts.

Actually, the archive is all the draftf that have been submitted as v3
XML. So generic code can't decide what to link to without inspecting the
link target first.

Best regards, Julian

---

From: Robert Sparks <[email-masked]>
Date: Sun, 13 Sep 2020 11:23:32 -0500

> XML. So generic code can't decide what to link to without inspecting the
No - the archive is all drafts, but v3 html won't exist for drafts that 
weren't submitted as v3 xml. Is that what you meant?

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 13 Sep 2020 18:28:26 +0200

On 2020-09-13, at 18:23, Robert Sparks <[email-masked]> wrote:
> 
> No - the archive is all drafts, but v3 html won't exist for drafts that weren't submitted as v3 xml. Is that what you meant?

It would be useful to be able for a tool to take a draft name (or an RFC number) and offline-generate a URI to a (what is likely to be an interstitial) page that explains the status and either points to or includes the HTML (v3-generated or, if that doesn’t exist, htmlized out of .txt).

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Sun, 13 Sep 2020 11:33:43 -0500

> It would be useful to be able for a tool to take a draft name (or an RFC number) and offline-generate a URI to a (what is likely to be an interstitial) page that explains the status and either poin…
For clarity - why isn't that the datatracker page for the draft?

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 13 Sep 2020 18:46:58 +0200

> For clarity - why isn't that the datatracker page for the draft?

Well, contrast

https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/

with

https://tools.ietf.org/html/draft-ietf-cbor-7049bis

The latter *is* the draft, with some status information (albeit somewhat cryptic for the uninitiated) prepended.
The datatracker page is a bit like a bugzilla page — tons of information, tons of affordance alternatives, little guidance (and two pages of the draft at the end even if drafts no longer really are meant to have pages).

Nobody who is confronted for the first time with the bugzillaish datatracker page will know what to click.  This is not a useful page to have in the references section of a paper, or to reference from a blog article.

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Sun, 13 Sep 2020 11:50:53 -0500

> https://tools.ietf.org/html/draft-ietf-cbor-7049bis

How about https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-14?

(Which is what Henrik was evolving from the tools htmlization, but the 
header information could also appear over a v3 rendering).

---

From: Nico Williams <[email-masked]>
Date: Sun, 13 Sep 2020 14:49:00 -0500

> been involved with the IETF.

It used to be that way, then we stopped removing them, and now we're
doing it again?

Having older I-Ds available is very useful for archeological-like
research.  Just leave them be.

Nico
--

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 13 Sep 2020 22:13:08 +0200

More like: 
> It used to be that way, then we stopped removing them, and now we’re
> designing our software as if we still were.

Grüße, Carsten

---

From: Nico Williams <[email-masked]>
Date: Sun, 13 Sep 2020 15:41:08 -0500

> > designing our software as if we still were.

I don't understand just what you mean here.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Sep 2020 16:47:38 -0400

> (Which is what Henrik was evolving from the tools htmlization, but the header
    > information could also appear over a v3 rendering).

Yes, so this is the html-itization via DT.
vs HTML rendering of the ID.
I like that it has all the status info, but I find it much less readable than
other formats, because it has such wide horizontal empty gutters.

It has some header across the top, but if you try to use them you wind up
elsewhere, and then you can't via the headers, get back.

    >> Nobody who is confronted for the first time with the bugzillaish
    >> datatracker page will know what to click.  This is not a useful page to
    >> have in the references section of a paper, or to reference from a blog
    >> article.

While I understand Carsten's bugzilla reference, many others might not.

Robert, I think that what we are saying is that the DT document page has
reached a point where it has been too sophisticated for newcomers, and
non-IETFers.   We, IETFers, would like to point people to the new beautifully
rendered HTML copies, but we need:
  1) stable URL, despite revision of documents, or:
  2) unstable URL, with status and forward pointers

In both cases, we need a pointer to the DT page.

{While HTML4 FRAMEs are never a good answer, this sure feels like it might be
a reasonable question}

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Sep 2020 23:03:47 +0200

> weren't submitted as v3 xml. Is that what you meant?

Yes. There should be HTML for all drafts, no matter how they were submitted.

(FWIW: this is true for the equivalent RFC Editor page, which has V3
HTML if available, otherwise HTMLized text)

Best regards, Julian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Sep 2020 17:11:20 -0400

> I don't understand just what you mean here.

The IDs have always, and will continue to disappear from the
"internet-drafts" directory.
By this, I mean the FTP site at %ftp ftp://ftp.ietf.org/internet-drafts/
the rsync site at rsync.ietf.org::internet-drafts
and now, the HTML rendered ones at https://www.ietf.org/id/

We have had, for more than a decade, other archives of expired drafts.
Robert points out that they are https://www.ietf.org/id/archive/

The discussion is that we need a stable URL that points to the latest version
and/or redirects and/or provides a status tombstone with links.
Because the DT page is just too much for non-IETFers.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 14 Sep 2020 02:41:54 -0700

Hi Carsten,
At 01:31 AM 12-09-2020, Carsten Bormann wrote:
>How do we represent the (desirable) aspects of 
>expiry without trying, unsuccessfully, to live the expiry doctrine?
>By making expiry (and replacement) a dynamic 
>*property* of a draft.  (Note that there is text 
>in each draft that describes the current value 
>of this property based on the current date — 
>this text is actually more likely untrue than 
>true, and this has caused all kinds of problems 
>with people taking the text at face 
>value.  Instead it should point to a resource 
>where the true current state can be ascertained.)

There was an IETF discussion about the expiration 
of I-Ds.  That led to a change where expired I-Ds 
were replaced with a "tombstone" file unless 
there is a newer version of the I-D.

>I cannot finish this note without noticing how 
>all this is not in the domain of the RFC editor 
>— we have kept the domain of authoring and progressing documents out of this

Yes.

Regards,
S. Moonesamy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Sep 2020 11:44:44 +0200

> As, I don't really want to put in JS into HTML generated WG drafts, I wonder

There's JS in the V3 HTML of RFCs, so why not in Internet Drafts?

(As an exercise I just added that in rfc2629.xslt; example output:
<https://greenbytes.de/tech/webdav/draft-ietf-httpbis-semantics-09.html#rfc.status>).

Yes.

> make the draft have an expired mark on it.

a) That would treat all drafts from one month the same way, and

b) It would not address the case where the draft actually has been
replaced by a newer version.

Best regards, Julian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Sep 2020 15:33:08 -0400

In writing my IETF108 report, I went back to the agenda for IETF108 for a
particulary WG. (Gendispatch in the case), and I wanted to remember who
the exact authors of the draft involved were.  I clicked on the link in the
agenda.

https://www.ietf.org/proceedings/108/agenda/agenda-108-gendispatch-03.html

Oops.  The draft has been replaced.  404 on https://www.ietf.org/id/draft-carpenter-eligibility-expand-03.html
I at least, know what to do.  Some external person, who wants to know what
the IETF has been doing... well, this will really really look unprofessional.

We really really do need the ability to see the version of that document that was discussed
at that session.  So, we need to use the archive link everywhere.
I note that for the first draft, the WG chairs used the tools link for
whatever reason.

**I can't think of a use case where the expiring URL version would ever be useful**

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 22 Sep 2020 22:36:16 -0400

Carsten Bormann <[email-masked]> writes:
> This is a nice example of "process confabulation", designing software

It also comes from confusing the position and role of a draft within the
IETF standards process with the position and role of a version of a
draft within the entire sphere of IETF-related technical activies.
Within the standards process, a draft that hasn't been updated within
six months may as well not exist, to do anything with it a new version
must be submitted; within what I might call "reality", every version of
every draft has value forever.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Sep 2020 14:59:52 +1200

> every draft has value forever.

Why not write a short BCP to update RFC2026 to reflect that reality?
Then there might be a chance of the tools catching up.

What we have learned over a number of years is that drafts have archival
value and may be of interest years after they were written; and this can
apply to all versions, not just the most recent version. That's
inconsistent with the rules, so we should change the rules.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Sep 2020 20:05:40 -0700

> On Sep 22, 2020, at 8:00 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Or correct your misconception. 

Value to the community includes their expiry. If they persist, we can all stop wasting time and publish to arXiv instead. 

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Sep 2020 15:37:26 +1200

On 23-Sep-20 15:05, Joe Touch wrote:
> Value to the community includes their expiry. 

Yes. That's a label, and I wouldn't suggest to change that label.

   Brian

> If they persist, we can all stop wasting time and publish to arXiv instead. 
> 
> Joe
>

---

From: Joseph Touch <[email-masked]>
Date: Wed, 23 Sep 2020 08:18:19 -0700

> On Sep 22, 2020, at 8:37 PM, Brian E Carpenter <[email-masked]> wrote:
> 
>>> On Sep 22, 2020, at 8:00 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

So what exactly are you suggesting to change?

If expiration is treated as “just a label", then it has no meaning.

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Sep 2020 17:21:50 +0200

> So what exactly are you suggesting to change?

The way we refer to our artifacts.

We need a stable reference to a specific revision of some document (independent of what future states it might have in our status FSM).

We need a stable reference to a sequence of revisions (including potentially future ones including derivations) of some document.

The former *SHOULD* include a reference to the latter.

(We also need to keep the documents themselves somewhere, which is what the archive does for us.)

> If expiration is treated as “just a label", then it has no meaning.

*All* the meaning is in labels, so I don’t understand that statement.

Grüße, Carsten

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Sep 2020 09:27:57 -0700

> On Sep 23, 2020, at 8:22 AM, Carsten Bormann <[email-masked]> wrote:
> 
> We need a stable reference...

Drafts are drafts unless they’re not. 

Drafts expire unless they don’t. 

Treating them as artifacts in need of a stable reference means they’re not drafts anymore. They’re just versions. 

So assign RFC numbers when they’re initially submitted and allow rev numbers or don’t. 

But if they’re not drafts, again we should just publish them to arXiv and skip all the irrelevant IETF mechanism. 

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Sep 2020 18:52:41 +0200

> Drafts are drafts unless they’re not. 

We have learned for a few decades that there are multiple perspectives on that, none of which can be ignored.  A patent lawyer has a different perspective than a software archeologist (a.k.a. implementer) than a standards developer.

> Drafts expire unless they don’t. 

Again, there are different perspectives.
Saying your’s is the only one we should care about because that is how we SHOULD work, while we DO work differently, is the classic case of process confabulation.

Having labels 

> Treating them as artifacts in need of a stable reference means they’re not drafts anymore. They’re just versions. 

They are versions of drafts!

> So assign RFC numbers when they’re initially submitted and allow rev numbers or don’t. 

Nonsense.  The label “RFC” is meaningful and should only be used for documents that are no longer “drafts”.

> But if they’re not drafts, again we should just publish them to arXiv and skip all the irrelevant IETF mechanism. 

Nonsense.  The IETF process is useful in producing labels such as “RFC”, “Standards Track”, “obsoletes”, “Updates”, etc.

What’s the point of drawing these strawmen?

Grüße, Carsten

---

From: Joseph Touch <[email-masked]>
Date: Wed, 23 Sep 2020 10:00:20 -0700

> On Sep 23, 2020, at 9:52 AM, Carsten Bormann <[email-masked]> wrote:
> 

Yes, but patent lawyers don’t necessarily need stable links; they need access to an archive, which they already have.

> Nonsense.  The label “RFC” is meaningful and should only be used for documents that are no longer “drafts”.

By making links to drafts stable, the label RFC becomes less meaningful as a distinction. As you and Brian claim, then becomes “just a label”.

> What’s the point of drawing these strawmen?

I am actually trying to figure out whether to post updates to pending drafts via a process that is increasingly diverging into its own, idiosyncratic full publication process or stop wasting my time and just go straight to arXiv.

You and Brian make a very strong case for the latter.

Joe

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 23 Sep 2020 10:21:47 -0700

Why on earth are you having this debate on, of all places, the Tools 
Team list? This is wide acknowledgement that different people strongly 
disagree on the topic. If you want something to actually change, take it 
(again...) to the IAB or IESG.

--Paul Hoffman