Re: Unhelpful draft names

Nobody’s perfect.  I’ve been around the IETF since before there were IDs
and recently I managed to not get it quite right, which is why there is
currently both a draft-borman-tcp4way-00.txt and a
draft-borman-tcpm-tcp4way-01.txt.

Rather than focusing only on making sure everyone follows the conventions the
the right way the first time, it’d be nice to have an easy way to fix it.
When submitting an ID, it’d be nice to be able to specify a different named
document that this one replaces, so that the old one would be removed when
the new one is posted, just as what happens today when a new revision is
posted.  The tool already notifies the authors of the previous revision
when a new revision is posted, it could do the same thing for the previously
named document.  That way the rename wouldn’t happen unless the previous
author approved it.

And as previously suggested, a pop-up window to just say “are you sure?” with
a couple of examples if the name doesn’t follow the conventions would be useful
to prevent some mistakes, but a rename would allow mistakes to be easily fixed
and get the old name out of the I-Ds directory.

                -David Borman 

> On Mar 9, 2015, at 10:15 PM, Brian E Carpenter 
> <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
>
> Allison,
>
> On 10/03/2015 15:56, Allison Mankin wrote:
> > As Yoav mentioned, the authors are new attendees, and the work is targeted
> > to an IRTF group at that. I have an acquaintance with them and hope they
> > aren't reading this, but how do folks think this outcry about seems as a
> > welcome to do work here?
> I worried about that before sending my note, but decided that an invented
> example was not persuausive. If there's a fault, it's "ours" for not
> making the convention a bit more apparent to newcomers. That's what needs
> fixing.
>
>   Brian
>
>
> > On Mar 9, 2015 10:37 PM, "Brian E Carpenter" 
> > <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
> > wrote:
> >
> > > On 10/03/2015 10:08, Jari Arkko wrote:
> > > > Brian,
> > > >
> > > > Are you suggesting that we should try to prevent the IETF
> > > > participants from being clever with the naming of their
> > > > drafts and protocols? Good luck with that :-)
> > > I wouldn't want to do that, for sure.
> > >
> > > > I think the current status is actually pretty reasonable -
> > > > although if Jordi doesn’t know about the convention
> > > > then we should perhaps advertise it more widely.
> > > Yes. And the draft submission page would be a good place to
> > > have a pointer to the advertisement.
> > >
> > > > However, I’m not sure stricter *rules* about
> > > > the file names will buy us that much. And
> > > > we already enforce the use of draft-ietf-* only
> > > > for adopted documents, which I think is the useful
> > > > case.
> > > I wouldn't go further than having the tool throw up an
> > > "Are you sure?" dialogue box if it sees a name with only
> > > one component after "draft-".
> > >
> > >    Brian
> > > > Personally, I look at the drafts that are discussed
> > > > on the list or are on the agenda, not because they
> > > > have someone’s name on them… in any case,
> > > > given that there are usually multiple authors,
> > > > looking for interesting material based on
> > > > someone’s last name isn’t really going to
> > > > work on merely based on the file name. Similarly,
> > > > often there is no working group yet for a topic,
> > > > so we end up with draft-someone-newtopic-00.txt.
> > > > I wouldn’t mind a warning based on seeing
> > > > draft-oneword-00.txt in the submission tool…
> > > > but I also wouldn’t it rate it very highly in the
> > > > overall priorities of tool support.
> > > >
> > > > Jari

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information is not 
permitted unless such privilege is explicitly granted in writing by Quantum. 
Quantum reserves the right to have electronic communications, including email 
and attachments, sent across its networks filtered through anti virus and spam 
software programs and retain such messages in order to comply with applicable 
data security and retention requirements. Quantum is not responsible for the 
proper and complete transmission of the substance of this communication or for 
any delay in its receipt.