On Wednesday, March 02, 2005 06:39:24 PM -0500 stanislav shalunov
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
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
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.).
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
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+(_at_)cmu(_dot_)edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
Ietf mailing list