Subject: Getting the latest version of an RFC specification

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Mar 2017 06:51:04 -0500

G'day.

The RFC labeling model is to assign a unique serial number to a static 
document.  A new version of a spec gets a new serial number. This basic 
model has the benefit of both simplicity and predictability.

To this we've added an overlay model, using Obsoletes/ObsoletedBy. This 
makes it dramatically easier to see that something has been obsoleted 
and to find its replacement.

However the seeing and the finding are an essentially manual process. 
One must go to the online older document, then notice the Obsoleted By 
tag and then click to follow it.

Sometimes it would be helpful for the requester to be able to say 'give 
me the latest' more easily.

So I'm wondering whether the IETF should consider adding a citation 
feature for this.

Something like:

      https://tools.ietf.org/html/rfc822/latest

would display the contents of:

      https://tools.ietf.org/html/rfc5322

by having the fetching system automatically traversing the Obsoleted By 
links in RFC 822 and then RFC 2822.

Some sort of display banner would flag this, to help the user see that 
they are getting a different version than they cited.

Thoughts?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Yoav Nir <[email-masked]>
Date: Wed, 29 Mar 2017 07:19:41 -0500

Hi, Dave

This is definitely doable, although I’d prefer that /latest redirect to the latest rather than display it.

I question how useful it is.  The obsoletes/obsoletedBy relationship is semantically overloaded. Consider the header of RFC 4306:

   Obsoleted by: 5996
   Updated by: 5282
   Request for Comments: 4306
   Obsoletes: 2407, 2408, 2409

RFC 5996 defines IKEv2, same as RFC 4306, but the three RFCs that 4306 obsoletes define the protocol IKEv1, a different protocol.

So what should https://tools.ietf.org/html/rfc2407/latest <https://tools.ietf.org/html/rfc2407/latest> return?  2407, because that is the latest RFC defining IKEv1, or 5996 (actually, 7296) because it’s the latest IKE?

The 822 —> 2822 —> 5322 path is one we should follow. I’m not sure the same applies to different versions of a protocol.

Yoav

> On 29 Mar 2017, at 6:51, Dave Crocker <[email-masked]> wrote:
> 
> G'day.
> 
> The RFC labeling model is to assign a unique serial number to a static document.  A new version of a spec gets a new serial number. This basic model has the benefit of both simplicity and predictability.
> 
> To this we've added an overlay model, using Obsoletes/ObsoletedBy. This makes it dramatically easier to see that something has been obsoleted and to find its replacement.
> 
> However the seeing and the finding are an essentially manual process. One must go to the online older document, then notice the Obsoleted By tag and then click to follow it.
> 
> Sometimes it would be helpful for the requester to be able to say 'give me the latest' more easily.
> 
> So I'm wondering whether the IETF should consider adding a citation feature for this.
> 
> Something like:
> 
> by having the fetching system automatically traversing the Obsoleted By links in RFC 822 and then RFC 2822.
> 
> Some sort of display banner would flag this, to help the user see that they are getting a different version than they cited.
> 
> 
> Thoughts?
> 
> d/
> --
> Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Mar 2017 07:34:31 -0500

On 3/29/2017 7:19 AM, Yoav Nir wrote:
> I question how useful it is.  The obsoletes/obsoletedBy relationship is
> semantically overloaded. Consider the header of RFC 4306:

Yoav,

Thanks for the thoughtful (and quick) response.  Yes, the total model 
and application of its details are more complicated.  But I found myself 
relying on a very simple distinction:

If someone wants to do research and explore old stuff, they can still do 
that.  The can still merrily wander the link sequences.

However "Obsoleted By" means "don't use the old stuff".

So if one merely wants to get (or wants to cite) the most recent version 
of what they /should/ use, then the feature I'm suggesting will support 
that.  More easily and reliably than can happen now.

d/

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Mar 2017 09:12:10 -0400

Dave,

--On Wednesday, 29 March, 2017 07:34 -0500 Dave Crocker
<[email-masked]> wrote:

>> I question how useful it is.  The obsoletes/obsoletedBy
>> relationship is semantically overloaded. Consider the header
>> of RFC 4306:
> 
> Yoav,
> 
> Thanks for the thoughtful (and quick) response.  Yes, the
> total model and application of its details are more
> complicated.  But I found myself relying on a very simple
> distinction:
> 
> If someone wants to do research and explore old stuff, they
> can still do that.  The can still merrily wander the link
> sequences.
> 

Sadly, while it should, it doesn't.  The community has allowed
several situations to occur in which a document is obsoleted,
some of its sections are not replaced with newer material, and
those sections continue to be referenced, occasionally
normatively, from other documents.  An even more common case
occurs when 

 * RFC X is published
 * RFY Y is published sometime later, normatively
	referencing RFC X
 * RFC Z is published, obsoleting RFC X.   

It is now unclear whether, until RFC Y is replaced, whatever it
specifies should be used in conjunction with the relevant parts
of RFC X or with the implementer's guess as to what the
specification of RFC Ybis, referencing RFC Z and modified
consistently, would be.  Sometime that is easy and obvious,
sometimes, especially when Z changes protocol behavior or data
structures from X rather than just being a clarification, it is
not.

To make things a bit more complicated, replacement of a document
is not always one-one.   We consolidate documents in
updates/replacements, sometimes we split them, and more complex
relationships, while not common, have happened.  In some of the
forking cases, we have part of RFC A replaced by RFC C and
another part replaced by RFC D and, because the historical
metadata  doesn't make it convenient, list only C as doing the
obsoleting so a simple link based  on the metadata would be
misleading.

One can sensibly argue that we shouldn't let those kinds of
entanglements happen.  But it is what we do.  In the extreme
case, the normative reference from Y to to X should imply that
the request to publish Z should go into normative reference hold
in the RFC Editor queue until Ybis is ready for publication.
But we don't do that.   More realistically, I think the real
question is "what do I need to use to properly implement this
specification today?".  Explorations of that question are what
lead us to summary roadmap documents or associated Applicability
Statements.  They are also what led to to the "ISD" proposal and
similar ideas, where the _standard_ (even, that WG concluded, at
the Proposed level) would be a summary document independent of
RFC numbers with appropriate links and, as necessary,
explanation.

In the past, I've argued that, if a document is published with
"Obsoletes XYZ", it needs to contain a section that sorts all of
those issues out.  I've gotten zero traction.

I fear that, unless there were a case by case analysis of each
document with an "obsoletes" tag, there are enough non-obvious
cases around to create significant risk that you idea would
cause more harm than the added convenience it would provide.
On the other hand, if the incoming IESG were convinced that this
is enough of a problem, it wouldn't be hard to dig the ISD and
other NEWTRK proposals up and update and re-post them.

best,
     john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Mar 2017 08:28:36 -0500

> several situations to occur in which a document is obsoleted,

I fear you are overinterpreting the use of what I'm suggesting or are 
conflating tasks.

Anyone who wants to be, or must be, diligent and thorough still can be.

My suggestion is for the folk who want simple, simplistic, basic access 
to 'the most current' spec.  The concerns you raise do not invalidate 
the suggested mechanism's accomplishment of that goal.

Rather, your concerns highlight the bounded scope of that goal, which 
I'll claim was already there -- but it's ok to emphasize it.  One can 
imagine an IETF Surgeon General's warning sign on the banner when the 
'latest' version is displayed, cautioning against excessive inhaling of 
the contents.

So, yes, the concerns you raise are all entirely valid... for someone 
who must dot all the specification i's and cross all the implementation 
ts, but that's not the target audience for the mechanism I'm suggesting.

d/

---

From: Yoav Nir <[email-masked]>
Date: Wed, 29 Mar 2017 08:56:52 -0500

> On 29 Mar 2017, at 7:34, Dave Crocker <[email-masked]> wrote:
> 
> Thanks for the thoughtful (and quick) response.  Yes, the total model and application of its details are more complicated.  But I found myself relying on a very simple distinction:
> 
> If someone wants to do research and explore old stuff, they can still do that.  The can still merrily wander the link sequences.
> 
> So if one merely wants to get (or wants to cite) the most recent version of what they /should/ use, then the feature I'm suggesting will support that.  More easily and reliably than can happen now.
> 

Right. It is a useful thing (and may be a task for next IETF’s code sprint).  People should just know that they might get surprising results.

Yoav

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 30 Mar 2017 07:19:34 +1000

On 29 Mar 2017 21:52, "Dave Crocker" <[email-masked]> wrote:

G'day.

To this we've added an overlay model, using Obsoletes/ObsoletedBy. This
makes it dramatically easier to see that something has been obsoleted and
to find its replacement.

However the seeing and the finding are an essentially manual process. One
must go to the online older document, then notice the Obsoleted By tag and
then click to follow it.

Sometimes it would be helpful for the requester to be able to say 'give me
the latest' more easily.

So I'm wondering whether the IETF should consider adding a citation feature
for this.

Something like:

Some sort of display banner would flag this, to help the user see that they
are getting a different version than they cited.

Thoughts?

d/

It sounds good, for the most part, as a quick and dirty tool (though a 30x
redirect would probably be better than displaying the ultimate RFC
in-place.)

Out of malign curiosity, what would you expect from:
https://tools.ietf.org/html/rfc1738/latest
<https://tools.ietf.org/html/rfc822/latest> ?

Cheers

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Mar 2017 16:25:43 -0500

On 3/29/2017 4:19 PM, Matthew Kerwin wrote:
> Out of malign curiosity, what would you expect
> from: https://tools.ietf.org/html/rfc1738/latest

cool!  bifurcated obsolescence.  show both 'latest' documents at the 
same time?

d/

---

From: Yoav Nir <[email-masked]>
Date: Wed, 29 Mar 2017 16:40:31 -0500

> On 29 Mar 2017, at 16:19, Matthew Kerwin <[email-masked]> wrote:
> 
> 
> On 29 Mar 2017 21:52, "Dave Crocker" <[email-masked] <mailto:[email-masked]>> wrote:
> G'day.
> 
>      https://tools.ietf.org/html/rfc822/latest <https://tools.ietf.org/html/rfc822/latest>
> 
>      https://tools.ietf.org/html/rfc5322 <https://tools.ietf.org/html/rfc5322>
> 
> bbiw.net <http://bbiw.net/>
> 
> 
> It sounds good, for the most part, as a quick and dirty tool (though a 30x redirect would probably be better than displaying the ultimate RFC in-place.)
> 
> Out of malign curiosity, what would you expect from: https://tools.ietf.org/html/rfc1738/latest <https://tools.ietf.org/html/rfc822/latest> ?

That one is terribly wrong. Generic URL is obsoleted by the telnet URL and the Gopher URL?  And then, after being “obsoleted", it is still updated by three separate RFCs, the latest of which 12 years later?

But there are examples that are properly tagged.  https://tools.ietf.org/html/rfc2616 <https://tools.ietf.org/html/rfc2616> is obsoleted by a series of six RFCs.

Yoav

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Mar 2017 16:44:08 -0500

On 3/29/2017 4:40 PM, Yoav Nir wrote:
> But there are examples that are properly tagged.
>  https://tools.ietf.org/html/rfc2616 is obsoleted by a series of six RFCs.

So to attempt a more serious suggestion -- remembering that the whole 
idea here was KISS:  If the Obsoleted-By field contains multiple 
pointers, then present this fact to the user and request that the select 
one.

d/

---

From: Yoav Nir <[email-masked]>
Date: Wed, 29 Mar 2017 17:04:06 -0500

Yeah, like instead of redirecting to the next stop, present a page with a list of the obsoleting RFCs (name + title) and a link to each, like:

RFC 2616 is obsoleted by the following RFCs:
   o RFC 7230 <https://tools.ietf.org/html/rfc7230/latest> - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
   o RFC 7231 <https://tools.ietf.org/html/rfc7231/latest> - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

and so on….

> On 29 Mar 2017, at 16:44, Dave Crocker <[email-masked]> wrote:
> 
> So to attempt a more serious suggestion -- remembering that the whole idea here was KISS:  If the Obsoleted-By field contains multiple pointers, then present this fact to the user and request that the select one.
> 
> d/
> 
> 
> --
> Dave Crocker

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Mar 2017 07:38:57 +0200

On 2017-03-29 13:51, Dave Crocker wrote:
> ...

FWIW, a related (ans so far unanswered) question is how to present the 
updated/obsoleted information in the new HTML variant of the RFC format.

tools.ietf.org generates as static header block such as:

> [Docs] [txt|pdf] [draft-ietf-http-v...] [Diff1] [Diff2] [Errata]
>
> Obsoleted by: 7230, 7231, 7232, 7233, 7234, 7235          DRAFT STANDARD
> Updated by: 2817, 5785, 6266, 6585                          Errata Exist

-- <https://tools.ietf.org/html/rfc2616>

rfc2629.xslt inserts similar information dynamically (querying 
tools.org), example:

	<https://greenbytes.de/tech/webdav/rfc2616.html#rfc.status>

(details in 
<https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc-editor.meta-data>).

Best regards, Julian