Subject: [Tools-discuss] indication of internet-draft status

From: stanislav shalunov <[email-masked]>
Date: 02 Mar 2005 18:39:24 -0500

Context: The IETF Tools team works on requirements for various
automated tools for the IETF.  Many of the tools have to deal with
internet-drafts; in these cases, the information whether an
internet-draft is a working group draft or a personal draft is
important.  The mechanism by which such information is kept thus needs
to be known to the tools and, correspondingly, reflected in the
requirements.

There appear to be at least three conceivable ways of keeping the
information about internet-draft status:

1. Internet-draft name: working group internet-drafts are always named
   "draft-ietf-*", while personal drafts do not match this pattern.
   For a working group internet-draft, the third component of the file
   name is the working group abbreviation.  When a personal
   internet-draft becomes a working group item, or when a working
   group item is no longer one, or when an internet-draft changes the
   working group, the internet-draft gets republished under a new
   name, without exception.  (This could be automated in a way that
   would ensure that name history is consistently and reliably
   captured.)

2. Metadata kept separately: the file name has nothing to do with the
   status, which is kept separately.  The file name is stable and
   never changes (other than the version number).  The working group
   status is prominently indicated by all tools (in announcement
   subject lines, etc.).

3. Current situation: technically, (2) (however, name stability isn't
   enforced or actively encouraged).  Informally, (1) for most working
   groups.  Many (most?) participants infer (1).  Tools penalize
   non-"draft-ietf-*" working group internet-drafts by making their
   working group status less prominent.

For the purposes of specifying the requirements for tool development,
it is necessary to know which way to keep the information.  It is
rather obvious that (1) and (2) are both vastly preferable to (3).
The choice between (1) and (2) is less clear.

Advantages of (1):

* simpler;

* matches existing expectations of most participants;

* makes working group status automatically prominent.

Advantages of (2):

* cleaner;

* allows tracking of document history better and easier.

It appears that the Tools team has a slight preference of (1) in favor
of (2) because of the existing convention (but (2) is perfectly
workable; it would simply require a bit of an education effort).
However, (3) appears so much inferior to either (1) or (2) that
proponents of (1) and (2) would both be reasonably expected to be
willing to compromise so that (3) is avoided.

With this in mind, we would like to raise the question:  Which way of
keeping the status should the Tools team use in the requirements for
the tools it is specifying?

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed with 0.06479891g of NaCl.

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Mar 2005 18:51:59 -0500

> Which way of

"2. Metadata kept separately"

a) it's often desirable and occasionally necessary to allow drafts to
change from individual to wg and vice versa (or for that matter from one
wg to another, as sometimes happens) without having to change the
filename

b) you're going to need to keep separate metadata for other reasons
anyway - you may as well put all of the metadata in one place rather
than have some of it in the filename and some of it elsewhere.

c) more generally, the tools should exist to support the work rather than
impose arbitrary restrictions on the work.  which is not to say that the 
tools should not impose restrictions on how the metadata is used.  but
if you put some of the metadata in the filename, and tools depend on it
being there, it's going to be harder to change, because some of the
constraints on the use of that metadata will be artifacts of how the
metadata is stored, rather than constraints chosen in such a way as to
support IETF's work.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Mar 2005 19:08:54 -0500

>    status is prominently indicated by all tools (in announcement

This vastly oversimplifies the situation, not leastwise by assuming that WG 
affiliation is the only interesting piece of metadata.  There are really a 
lot of questions here:

- MUST draft filenames change to reflect WG ownership?
- MUST the "title" part of a draft be unique across all drafts?
- Does the version number reset to 00 when WG ownership changes?
- Which deadlines apply when?  Is this based on version or history?
- If a filename changes, how are the old and new files tied together?

A lot of these are policy issues, not really within the scope of defining 
tools behaviour.  Good tools will be able to deal with the various possible 
answers as we adjust policy based on whining and experimentation.

With regard to design and implementation of tools, I think there is a 
principle which applies here.  Filenames are JUST NAMES; their value is in 
their meaning to the humans who use them.  They are not metadata, and 
software should not infer metadata from filenames any more than it should 
infer what services a host provides from its domain name (see other 
thread).  Any I-D metadata needed by tools should be maintained in a 
suitable database, separate from the filenames, which tools should use 
_only_ to access files and as user-visible labels.

Note that this principle does not require either (1) or (2) above, and it 
certainly does not require (3).  In fact, it has the flexibility to support 
any of these scenarios, by making tools NOT CARE about what policies we 
choose to adopt for filenames.  This is appropriate; tools should never 
dictate policy.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Mar 2005 19:11:10 -0500

> "2. Metadata kept separately"

Good grief.  You managed to say basically the same things as me, but more 
clearly and in half as much text.

-- Jeff