Subject: Tombstones in the I-D directory: who needs them?

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 16 Feb 2005 15:16:19 +0100

Hi,

one question for all of you:

- all the information that is in the I-D tombstone files is now available 
through the "I-D Database lookup tool"
- the critical information is also available through the "all_id.txt" file 
for those who prefer mirrors

Apart from the principle of "don't change things suddenly" - can anyone 
think of a reason why we need to keep the tombstone files around any more?

                    Harald

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 16 Feb 2005 10:27:57 -0500

In message <CEE7C774A3FECA2A7B050A38@[192.168.1.59]>, Harald Tveit Alvestrand w
>think of a reason why we need to keep the tombstone files around any more?

Personally, I find them convenient.  When I see a reference to a draft 
I need to read -- often via the bibliographic citations in another 
draft -- I do 'ls -l draft-foo-*' in my personal mirror.  The tombstone 
tells me I need to see an RFC instead.  Sure, I can check the 
all_id.txt file or (if I'm online) the lookup tool, but it's an extra 
step that I generally don't do today.

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 16 Feb 2005 11:38:07 -0500

On Wednesday, February 16, 2005 03:16:19 PM +0100 Harald Tveit Alvestrand 
<[email-masked]> wrote:

> - the critical information is also available through the "all_id.txt"
> file for those who prefer mirrors
>

I expect most people retrieve internet drafts via FTP or from an 
automatically-maintained local mirror.  Most of these people already know 
the filename they're looking for, so they don't need much more of a 
database than pattern-matching and tab-completion.  So they may not already 
be using the database tool (or the previous search interface), and in fact 
it may not even be available to them -- I take a mirror of the I-D 
repository with me on my laptop, so I can read documents on the train on 
the way to IETF meetings.  So, there is some use for tombstones to tell 
those people that the document they're looking for is expired.

At the same time, it seems silly to keep them around basically forever. 
There are tombstones for plenty of long-forgotten abandoned documents, 
which clutter up the I-D repository and make current things harder to find.

So I'd suggest keeping tombstones for "recent" documents, but getting rid 
of them for anything older than some threshold.  Of course, we can argue 
indefinitely about what the threshold should be; I'll let someone else take 
up that issue...

-- Jeff

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 16 Feb 2005 15:10:10 -0500

Hi,

I have occassionally found the tombstones useful when trying to recall
the author or title of a proposal that was not taken up by a WG, and
which might have some useful insight into a current problem. This is a
very infrequent usage, however. 

How expensive is it to keep the tombstone files around? Does it hurt
to do so?

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Harald Tveit 
> Alvestrand
> Sent: Wednesday, February 16, 2005 9:16 AM
> To: [email-masked]
> Subject: Tombstones in the I-D directory: who needs them?
> 
> Hi,
>

---

From: Mark Allman <[email-masked]>
Date: Wed, 16 Feb 2005 15:21:55 -0500

I actually find these things to be a little irritating at times.  I keep
a mirror here using the rfc-eds rsync service, without deleting old
drafts so I can run diffs and such.  Every once in a while I run across
the case where there has been a "lull" and so there is a tombstone where
a draft that I want to see (/diff against) used to be.  It's not a huge
problem, but it's bitten me and if the info is available elsewhere then
I'd be happy if these things were discontinued.

But, I also recognize the benefits that others have mentioned.

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

From: David R Oran <[email-masked]>
Date: Wed, 16 Feb 2005 15:22:32 -0500

I find the "is now RFC mumble" tombstone to be quite useful. I don't 
find expiration tombstones useful, and in fact they complicate my 
archive directory since I have to keep the last two versions of an I.D. 
in order to keep one with the text in it. (Yes, I know I could guess 
from the length...). One can tell an expired I.D. from the dates in the 
header of the last one anyway.

My 2 pesetas, for what it's worth.

Dave.

> 		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 16 Feb 2005 22:53:52 +0100

> How expensive is it to keep the tombstone files around? Does it hurt

It's not expensive in terms of operations - all the code that maintains 
them is already written. But it's another 10.000 files in the I-D 
directories, which has to be maintained and mirrored - and clutter up my 
auto-completion when I access my I-D copy from an Unix shell.

You can get all the author info and so on (and more) from the new I-D 
database access tool.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 16 Feb 2005 18:14:21 -0800

Along the same lines as Dave, I find the "is now RFC XXXX" tombstone 
very useful.  I also find the "was replaced by draft-xxx-foobar" to be 
occasionally useful as well (especially when tracking down work in a 
group I don't follow regularly, or work which jumps WGs).

The "this draft is expired" tombstone provides me with no useful data.

thx,
-r

On Feb 16, 2005, at 12:22, David R Oran wrote:

> archive directory since I have to keep the last two versions of an 
> I.D. in order to keep one with the text in it. (Yes, I know I could 
> guess from the length...). One can tell an expired I.D. from the dates 
> in the header of the last one anyway.
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 17 Feb 2005 09:47:29 +0100

> think of a reason why we need to keep the tombstone files around any more?

When writing scripts which works on (my mirror of) the drafts directory,
the tombstones are sometimes a nuisance, and sometimes useful.  From
this perspective it would be more useful, and less of a nuisance, if
the tombstone files adhered to a strict format, so it was easy to
filter them out when needed, or extract information when needed.

As long as not all information provided by the tombstones are available
in all_id.txt or some other part of the mirror, the online tool is not
a good replacement when running scripts over the corpus. (I've tried
to request a full extract of all information from the online tool,
for scripting purposes, very recently, and that failed...)  Running
one request against the online database for each individual draft in
the corpus seems silly, and would probably make a 1-minute script run
for hours... 
(umm, let's see, ~ 12700 drafts * 3 seconds response time = 10 1/2 hours...)

	Henrik

---

From: Matt Mathis <[email-masked]>
Date: Thu, 17 Feb 2005 10:22:32 -0500 (EST)

There is one function for which tombstones are important: without them a
natural sync configuration archives ID's by default.  The tombstones serve to
flush expired drafts, and force people who are violating the policy to do so
explicitly.

One can imagine several different tombstones:
1) expired, no known update
2) updated by draft  NN+1
3) updated by new -00 draft (different base name)
4) published as RFCxxxx
Furthermore this is really a state machine: 1 could be replaced by any of the
others at any time.....

I detect unreasonable complexity for the value.

How about a constant minimalist tombstone: "This draft is history, see the
expired draft database at .....".   To reduce the clutter, the tombstones could
be removed after 6 months or a year.

BTW: I think an expired draft database might be substantially different than
the main ID tracker.  It can be something simple now, and evolve as we have a
better sense of exactly how it is used.  To be most useful it would have to
carry all of the above annotations, as well as allowing authors to annotate
their own expired drafts.  e.g. "The main ideas from this draft have been
merged into ....."  or "I am seeking additional authors to help..."

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by people who think they know
"The Truth" and use force to apply it to others.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 17 Feb 2005 16:41:40 +0100

Matt:

1) We have an "expired drafts" database (as of last week).

2) the all_id.txt file in the I-D directories lists the state of every 
draft that has ever existed, including the RFC number if appropriate

3) the tombstones have version numbers = the last draft + 1. So they don't 
cause a flush in the "natural sync configuration".

4) we have the 4 different tombstones today (except 2, which is implicit)

so I have trouble evaluating your comments against what exists today....

--On torsdag, februar 17, 2005 10:22:32 -0500 Matt Mathis <[email-masked]> 
wrote:

> natural sync configuration archives ID's by default.  The tombstones
> serve to flush expired drafts, and force people who are violating the
> policy to do so explicitly.
>
> Furthermore this is really a state machine: 1 could be replaced by any of
> the others at any time.....
>
> expired draft database at .....".   To reduce the clutter, the tombstones
> could be removed after 6 months or a year.
>
> BTW: I think an expired draft database might be substantially different
> than the main ID tracker.  It can be something simple now, and evolve as
> we have a better sense of exactly how it is used.  To be most useful it
> would have to carry all of the above annotations, as well as allowing
> authors to annotate their own expired drafts.  e.g. "The main ideas from
> this draft have been merged into ....."  or "I am seeking additional
> authors to help..."
>
> Thanks,
> --MM--

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 17 Feb 2005 10:04:32 -0800

I don't really care what we do here but one idea people may or may not like
(and has probably been suggested before) ....

If you named the tombstone files with a version of -99, it would be easy for
people who hated them to remove them.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 17 Feb 2005 15:34:28 -0500

Harald,

> 1) We have an "expired drafts" database (as of last week).

I believe the database dump (currently in TSV format) addresses many
of the concerns people have listed.

I'm personally a fan of being able to track back old, expired proposals.
The fact that many people's repositories will delete the last version
of the draft with the tombstone has been a problem for me more than
once.  In this sense, I'm happy to see tombstones go away.

-- 
Jeff Haas 
NextHop Technologies

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 17 Feb 2005 16:04:27 -0800

Seeing the ongoing "tombstone" thread, can't say I care much either way
(I wouldn't miss them).

But what I think would be a great addition would be access to html-formatted
drafts in the official repository. Perhaps this has been mentioned before?

This is *not* a motion to replace .txt with .html as the preferred format.
It is *not* a motion to make .html required.

But with tools like xml2rfc, having html drafts is increasingly more common.
Now, they're sooo much easier to read/browse/navigate than .txt that I prefer
them hands down. Unfortunately, it depends on the author(s) taking the extra step
to *also* put up an html copy in some obscure but personal web site. Officially,
they do not exist.

Suggestion:

	Allow draft submissions in html (in addition to the required .txt).
	If there is an html submission at the same time as the .txt, have
	both placed in the ID repository, and include URLs to both in the
	official announcement.
	Same for RFCs.
	The new database would produce pointers to both .txt and .html docs.

-gabriel

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Feb 2005 19:59:08 -0500

> 	The new database would produce pointers to both .txt and .html docs.

I'd suggest an alternative: permit submission of .xml in addition to .txt.  If 
the secretariat's execution of xml2rfc on the .xml produces identical output 
to the .txt, then provide other formats.  if it does not match, reject submission.

This avoids questions of the .html differing materially from the .txt, and also allows
for other formats to be generated.

						- Bill

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 17 Feb 2005 21:15:05 -0500

>drafts in the official repository. Perhaps this has been mentioned before?

I'll have to check my calendar, but I think this discussion is right on 
time -- it's supposed to happen annually, right?  But I thought the 
usual venue was the IETF list....

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 17 Feb 2005 18:35:59 -0800 (PST)

Hi,

Would anyone else find it useful to have a link on each WG Charter page to
the associated pages of notes (meeting minutes and presentations) from the
Proceedings of when the WG met?  For example, the syslog WG met last in
Seoul.  If someone wishing to join this fascinating discussion were to
poke around in the archives of the Proceedings, they would not know which
meetings to find the notes of our thought provoking and stimulating
discourse.  While I do keep these things on the "Additional syslog Page",
I think that they would be more appropriately displayed on the IETF WG
page.  This would be similar to referencing the link to the mailing list
archives, which is a another way to see the course of the discussions.  I
figure that it would be a lot of work for the people who maintain the IETF
web pages to do this, but it just seems to me that having a link from the
Charter page directly to the Proceedings notes would be helpful to people
looking to get a grasp on the high points of the WG.

Thanks,
Chris

---

From: Rob Austein <[email-masked]>
Date: Thu, 17 Feb 2005 21:39:04 -0500

> usual venue was the IETF list....

only since we used up the tcp-ip list. :)/2

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 17 Feb 2005 22:59:56 -0500

In message <[email-masked]>, Chris Lonvick 
>looking to get a grasp on the high points of the WG.

That would be great.  Just last week, I could have used that info for a 
particular WG.

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 18 Feb 2005 13:10:41 +0900

Dear all,

I vote for it. Many people who have interest in only 1 or few WG and who
don't know much about the IETF progress ask me where they can find more
information. In the NEMO WG, we put the minutes on our additional page,
but I would find very relevant to link the proceedings (minutes and
presentations) of past meetings AND agenda of the next meeting from the
charter web page.

Thierry.

> Would anyone else find it useful to have a link on each WG Charter
> page to the associated pages of notes (meeting minutes and
> presentations) from the Proceedings of when the WG met?  For example,
> the syslog WG met last in Seoul.  If someone wishing to join this
> fascinating discussion were to poke around in the archives of the
> Proceedings, they would not know which meetings to find the notes of
> our thought provoking and stimulating discourse.  While I do keep
> these things on the "Additional syslog Page", I think that they would
> be more appropriately displayed on the IETF WG page.  This would be
> similar to referencing the link to the mailing list archives, which is
> a another way to see the course of the discussions.  I figure that it
> would be a lot of work for the people who maintain the IETF web pages
> to do this, but it just seems to me that having a link from the
> Charter page directly to the Proceedings notes would be helpful to
> people looking to get a grasp on the high points of the WG.
> 
> Thanks,
> Chris

---

From: Aaron Falk <[email-masked]>
Date: Thu, 17 Feb 2005 20:29:03 -0800

Chris Lonvick wrote:
> Proceedings of when the WG met?  

I think it would be great!  Retroactive would be preferable but even
if it started now it would be of use.

--aaron

---

From: Tim Bray <[email-masked]>
Date: Thu, 17 Feb 2005 17:56:53 -0800

> It is *not* a motion to make .html required.

Why not?  I am on record as disapproving of "the IETF’s misguided 
insistence on publishing key documents in a format (66-line 80-column 
ASCII) that is outdated, unusable, and offensive. Outdated because it 
sneers at the ability of computers, for some decades now, to use 
proportional fonts, which have been shown repeatedly to improve the 
efficiency of information transfer from page to brain. Unusable because 
a substantial proportion of people, including me, can never get the 
bloody things to print properly with the right page breaks (well, they 
say, use the PDF of the ASCII... argh, words fail me). And offensive 
because it restricts its character set to that of English speakers. I’m 
sorry, if a draft editor’s name is correctly spelled André or you want 
to consider a currency in € instead of $, well, the IETF is just not 
interested in those concerns. Bah." 
(http://www.tbray.org/ongoing/When/200x/2004/08/01/RFCusage).

I don't understand why this offensive Anglocentrism is allowed to 
persist.  The "A" in ASCII stands for American, which I didn't think 
the IETF was. -Tim

---

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Feb 2005 22:14:15 -0800

Tim,
	This isn't even a decent rant.  As Rob has indicated,
we have had thundering tirades on this subject.  We have heard words of anger
to shake the walls of Jericho; we have heard words of anguish to wring tears
from the hard-hearted and sobs of pain from the iron-faced, goose-stepping
minions of fascist Anglocentrism.  Please, if you're going to
jump into the debate with emotional appeals, bump it up a notch.
	Personally, I think the format is a tool.  It has its uses, and it
has its deficits.  The IETF doesn't choose all the tools it works with,
and it doesn't make what choices it can make with sneers, offense,
or ethnocentrism in mind.  For the RFC series, the RFC editors have
largely argued that continuity is a benefit; if you have the materials
at hand to read one RFC, you have the materials to read (or translate,
or excerpt, or sort, or pretty-print, or whatever) any of them.  You
may disagree that this should be the primary consideration or argue
that the correct choice is to invest in an update of the whole series,
but the idea behind it does have some merit.  And the idea that the
document series that feeds into standards track publication should
have similar characteristics also has some merit, as it makes it
easier to ensure that what was agreed and what is published are the
same.
	If the IETF and its partners agree to update the series to
use a new format/tool for this purpose, we would still need to ensure
that the result retained continuity even as the format changed.
That might result in UTF-8 as a base character set, but the language
would remain English.  It also might result in a tool that permitted
figures, but it would still remain the case that the document would
have to be clear with figures omitted.  In other words, I am not
sure switching to sgml, postscript, pdf, or any of the other
candidates would do anything to calm the ire of those who
truly feel their forms of expression are excluded.  To put it
another way, are you sure you're fighting the right battle?
			regards,
				Ted Hardie

At 5:56 PM -0800 2/17/05, Tim Bray wrote:
>Why not?  I am on record as disapproving of "the IETF's misguided 
>insistence on publishing key documents in a format (66-line 
>80-column ASCII) that is outdated, unusable, and offensive. Outdated 
>because it sneers at the ability of computers, for some decades now, 
>to use proportional fonts, which have been shown repeatedly to 
>improve the efficiency of information transfer from page to brain. 
>Unusable because a substantial proportion of people, including me, 
>can never get the bloody things to print properly with the right 
>page breaks (well, they say, use the PDF of the ASCII... argh, words 
>fail me). And offensive because it restricts its character set to 
>that of English speakers. I'm sorry, if a draft editor's name is 
>correctly spelled André or you want to consider a currency in ¤ 
>instead of $, well, the IETF is just not interested in those 
>concerns. Bah."

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 18 Feb 2005 00:23:50 -0800

> usual venue was the IETF list....

Hmmm... Were I to apply my anti-sarcasm filter to make your answer more
palatable, I presume it would look like this:

	To answer your question: Yes. It has been mentioned before.

In which case, that's good info, thanks. Even better info would be the status of such
proposal.

-gabriel

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Feb 2005 09:58:40 +0100

Hi Bill,

> for other formats to be generated.

This is pretty darn close to what the requirements say for the proposed
automated draft submission handling (draft-ietf-tools-draft-submission-07.txt)

I don't know what kind of schedule is in place for building this tool,
but with that in place we should have what you propose: acceptance of
.xml source with submissions, verification that the .xml produces the
.txt, and generation of HTML.  The one thing the draft does not REQUIRE
is that html be provided in the archives - we saw that as a policy
decision, rather than a tool decision.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Feb 2005 10:47:26 +0100

> if it started now it would be of use.

As mentioned earlier, I've been working on a prototype of WG pages
which lists the drafts of the workgroup, with status information,
and grouped sensibly.

In addition to listing the drafts belonging to a WG, I've also put
in past agendas, and intend top put in links to minutes from past
meetings.

The plan is also to make it possible for chairs to edit the agenda
for the current meeting on-line, to be able to update it with last-
minute changes and information, and provide a shadow all-ietf agenda
which links to these individual WG agendas.  References to drafts
and URLs in the agendas will be converted to HTML links, for easier
browsing.

This is meant to be a prototype; if the concept is successful the
tools team expects the functionality to be taken over by the regular
IETF support function.

I expect to be ready to send an announcement and URL to the wgchairs
list later today, for first comments.

	Henrik

---

From: Tim Bray <[email-masked]>
Date: Fri, 18 Feb 2005 07:52:32 -0800

On Feb 17, 2005, at 10:14 PM, Ted Hardie wrote:

> The IETF doesn't choose all the tools it works with,
> or ethnocentrism in mind.

I suspect those defending the ASCII-only policy do in fact believe that 
they are not acting in a malicious way.  It's just that they're wrong.

>  For the RFC series, the RFC editors have
> largely argued that continuity is a benefit

Undeniable.  My opinion (evidently a minority) is that clarity, 
usability, and internationalization are greater virtues than 
continuity.  Heh, during the great Civil Rights wars last century in 
America, the side that eventually lost had much recourse to arguments 
based essentially on "continuity".

>  You
> but the idea behind it does have some merit.

The idea of retroactively updating the whole series seems completely 
impractical to me.

> would remain English.

I am not arguing that (a) RFCs should basically look that much 
different or (b) a change away from English.

>   In other words, I am not

I think that the current IETF practice is stupid, inefficient, and 
bigoted.  Yes, I think that fighting against stupidity, inefficiency, 
and bigotry is, in general, the right battle.

And, since I don't think that anyone should throw stones without 
offering alternatives, I think that the RFCs should be available in a 
format much like the HTML output of xml2rfc, with external stylesheets 
and scripts being absolutely forbidden, so that it's self-contained, 
and (maybe) images also forbidden (sigh).  I would be happy to 
volunteer to commit time to an effort to help in the implementation of 
such a format that would preserve the current virtue of 
self-containment, improve on the current state of the art in 
printability, and achieve a basic level of world citizenship. -Tim

---

From: James Carlson <[email-masked]>
Date: Fri, 18 Feb 2005 13:19:51 -0500

> based essentially on "continuity".

That sounds about a hairs-breadth from being just a flame rather than
a constructive comment.  It might be nice to stick to the topic of
file formats rather than wandering off into questions of ethnic or
racial equality.

> and (maybe) images also forbidden (sigh).  I would be happy to 

I would argue just as strongly against any such move.  The official
business of the IETF is performed on the mailing lists, not on web
pages.  Anything that hinders that process -- such as being utterly
unable to quote anything in context -- should not be permitted.

I think being able to type language-specific accent marks down in the
"Author" section ranks fairly low among the features required to
produce interoperable implementations.

-- 
James Carlson, IP Systems Group?               <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Randall Gellens <[email-masked]>
Date: Fri, 18 Feb 2005 10:22:17 -0800

At 5:56 PM -0800 2/17/05, Tim Bray wrote:

>  X-Mailer: Apple Mail (2.619.2)

> page breaks

I notice you're using a Mac.  Have you tried printing with BBEdit? 
Even BBEdit Light (the free version) prints I-Ds and RFCs properly. 
(Plus, if you like to print and put in a three-ring binder,  you can 
set the "1-inch gutter" option to have it leave an extra inch for the 
holes.)

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 18 Feb 2005 20:13:41 +0000

> unable to quote anything in context -- should not be permitted.

I am completely fine when it comes to text, but do you propose
that we do about difficulty of drawing satisfactory diagrams?

Stewart

---

From: Sam Hartman <[email-masked]>
Date: Sun, 20 Feb 2005 21:51:38 -0500

>>>>> "Stewart" == Stewart Bryant <[email-masked]> writes:

    >> I would argue just as strongly against any such move.  The
    >> official business of the IETF is performed on the mailing
    >> lists, not on web pages.  Anything that hinders that process --
    >> such as being utterly unable to quote anything in context --
    >> should not be permitted.
    >> 

    Stewart> I am completely fine when it comes to text, but do you
    Stewart> propose that we do about difficulty of drawing
    Stewart> satisfactory diagrams?
Well, at least for the next year, if you want to get your document
past the IESG, your document needs to be completely clear independent
of any diagram.  I'm willing to consider exceptions, but so far I'm
not aware of anything where I would consider it acceptable for the
text not to be sufficient without diagrams.

That said, I don't have objections to ways of having better diagrams
provided that we do not start relying on them too much.

--Sam