Subject: [newtrk] draft-ietf-newtrk-docid-00.txt

From: John C Klensin <[email-masked]>
Date: Thu, 23 Mar 2006 12:32:23 -0500

Scott,

Would it be appropriate to initiate the sequence of events
leading to an IETF Last Call on this document?  Since it seems
to be intertwined with issues techspec has on its agenda, it
would be useful to see if we can reach consensus and move on it
on a timeframe consistent with theirs.

thanks,
       john
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Mar 2006 11:55:14 +0200

Personal opinion: I think this is a simple and practical idea
that would help in the short term.

One comment:

> The current alphabetic code is "STD".  This
>    document is agnostic on whether that code should be retained or a new
>    one developed and used.

I don't think that can be left open. Personally, I think we have no
reason to switch from STD. Thus, RFC 793 would be STD-0007-is
and RFC 2822 would be STD-0011-ps, I think.

(On a purely practical matter, do we want leading zeros in the
designators? Hyphens? Dates?)

     Brian

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 27 Mar 2006 06:06:06 -0600

My apologies for dwelling on minutia... replies inline.

Spencer

From: "Brian E Carpenter" <[email-masked]>

> that would help in the short term.

Agreed.

> and RFC 2822 would be STD-0011-ps, I think.

At the risk of conflating analysis with cynicism, if we don't have a reason 
to switch from STD, it's because very few people are using them now :-(

> designators? Hyphens? Dates?)

Leading zeros will instantly generate scripts that assume four-digit (or 
whatever) STD numbers, giving us our own "Y10K" problem at some point, so I 
vote "no". On this.

It's not possible to refer unambiguously to an STD that had latter documents 
added to it, without a date ("did you mean the old STD, or the new one?"), 
so I vote "yes" on the date.

If we have that much information in an STD, we would need hyphens or some 
other separator. 

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Mar 2006 07:38:06 -0500

--On Monday, 27 March, 2006 11:55 +0200 Brian E Carpenter
<[email-masked]> wrote:

>>    document is agnostic on whether that code should be
>>    retained or a new one developed and used.
> 
> I don't think that can be left open. Personally, I think we
> have no reason to switch from STD.

I wasn't proposing to leave it open; I just didn't want to try
to make a decision in a -00 draft and touch off a controversy
about _that_ (reference my comments about the boundary between
nitpicking and complaining about lack of detail during the
genarea meeting).
However, the rules for STD were very specific and applied only
to full standards.  Using the same term for a different set of
rules could cause confusion.  The argument for a change in
identifier name may apply less strongly to docids than it did
for what we now call ISDs, but it seems to me that some of them
still apply. 

The other issue is that, if we were to consider this as a
process experiment rather than a permanent change (which the
current draft does not suggest), we should have a way to back
out.  If we used different identifiers, we could just lose them.
If we repurpose STD, we are more or less stuck.    I don't,
personally, consider the latter a problem, but others may
disagree.

So I'd like to hear comments from others, but I do not feel
strongly about this, one way or the other.

> Thus, RFC 793 would be STD-0007-is

This illustrates one of the anomalies.  I don't know that it is
a problem, but we need to be aware of it...  While RFC 2822
would be STD-0011-ps, RFC 822 would be STD-0011-is.  I probably
should have called this out in the draft as unresolved as well
-- clearly it cannot be left open.
 
> designators? Hyphens? Dates?)

Personally, no preference on the zeros.  If we do add them, how
many: a four-digit number may not suffice forever and that may
be on argument for _not_ using leading zeros.  Hyphens
separating the components seem wise.  As far as a date is
concerned, I'd personally prefer not, since it leads us down the
path toward either document identifiers (we already have one of
those) or ISDs (my preference, but perhaps more rules and
complexity).  But I don't think it makes a lot of difference if
others have strong preferences.

     john

.