Subject: [newtrk] Meeting discussion of ISDs- part 2 - probable agreement

From: John C Klensin <[email-masked]>
Date: Mon, 15 Nov 2004 14:49:51 -0500

This is the second of several summaries of my notes from last
week's discussion of ISDs.   This note covers things that we did
not get to but about which I believe there is basic agreeement
even though the words probably need tuning.  Other notes, to be
posted shortly, will cover areas that are still very much under
discussion (or where disagreements are known to exist).  My
current intention is to update and repost the I-D in about a
week, reflecting whatever we know by then.

* The base format of ISDs is XML, and the XML form is
  expected to be available to interested readers/searchers
  to facilitate automated processingb and tool-building.
  It is expected that classical ASCII and HTML forms will
  be made generally available as well.

* One way to state the goals for ISDs (not the only one) is to
  be able to change the process and status metadata for a
  document without changing the document itself.  This is
  consistent with the intent of current mechanisms but
  significantly expands the capabilities to include, e.g.,
  additional descriptive metadata rather than just
  categorical information.

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Nov 2004 21:16:42 -0600

Hi, John,

Again, I think I agree, but want to make sure...

>  additional descriptive metadata rather than just

I have been talking about version numbers of a protocol versus version 
numbers of a specification for the protocol (say, if we find an 
introduction too confusing and rewrite it, that would change the 
version number for the specification, but not the version number for 
the protocol itself).

Am I talking about the same kind of thing you're talking about here? 

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Nov 2004 09:54:06 +0100

Spencer Dawkins wrote:
> introduction too confusing and rewrite it, that would change the version 
> number for the specification, but not the version number for the 
> protocol itself).
> 

I suggest that if we use dates rather than version numbers, a lot
of emotion and potential confusion will be avoided.

     Brian
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Nov 2004 06:39:37 -0600

> of emotion and potential confusion will be avoided.

Yes, of course, with the further advantage that protocol versions, 
protocol specification vintage dates, and ISD vintage dates won't be 
confused (we don't have a LOT of protocols that use version numbers IN 
the protocol effectively, but do have some).

I realized that I'd left out that case after hitting "send", so I 
agree this will avoid confusion in the future, since it's already 
confused me in the past :-o

Spencer 

.

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 Nov 2004 19:38:51 -0800

> of emotion and potential confusion will be avoided.

Presumably we're going to keep the old versions, ala CVS? if so, then 
this requires that they be labelled by date, to facilitate extraction by 
date.

Joe