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

From: Eric Burger <[email-masked]>
Date: Fri, 4 Mar 2005 18:11:22 -0500

I would add that it is much easier to track the history of a document if it
keeps it's name as it gets passed through Individual->WG A->WG B->Back to
Individual, rather than discovering that some draft has been discussed
thoroughly before (under a different name).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jeffrey Hutzelman
> Sent: Wednesday, March 02, 2005 7:09 PM
> To: stanislav shalunov; [email-masked]
> Cc: [email-masked]
> Subject: Re: indication of internet-draft status
> 
> 
> 
> 
> On Wednesday, March 02, 2005 06:39:24 PM -0500 stanislav shalunov 
> <[email-masked]> wrote:
> 
> > 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.).
> 
> 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
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

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

---

From: "Alex Rousskov" <[email-masked]>
Date: Mon, 07 Mar 2005 11:48:26 -0700

On Fri, 2005/03/04 (MST), <[email-masked]> wrote:

> I would add that it is much easier to track the history of a document if  
> it keeps it's name as it gets passed through Individual->WG A->WG  
> B->Back to

Constant name makes tracking easier if you do manual tracking and  
interested in all the states of the named draft. In many other cases, it  
is arguably harder. For example, if I am only interested in official WG A  
documents, then I do not care about "individual" and "WG B" states. I  
believe the "ease" of tracking becomes a non-issue if tracking is done by  
software; only interface (i.e., ability to specify what is it that you  
want to track) matters then.

This is an argument for removing all state information from draft names. A  
draft name becomes a persistent opaque identifier so that meta-info can  
change at will and nobody tries to extract meta-info from the draft name.

While I am almost sure that opaque identifiers are a better design, I am  
not sure IETF can support such a significant departure from the current  
state. I am sure many people rely on draft filenames too much to make such  
a transition easy. On the other hand, we can, in theory, provide access  
based on both old-name and opaque-id during the transition period (with an  
automated N:1 mapping).

Alex.