Subject: [Rfid] Version numbering

From: Scott Barvick <[email-masked]>
Date: Mon, 18 Jul 2005 09:13:30 -0400

As I hear of more implementations of SLRRP starting to happen, it seems
that we need to decide what we put in the version field while the spec
is still an I-D.     

To date, we've just been specifying the draft number as the version, and
that is what is in the SourceForge code, but that doesn't seem like the
way to continue, especially when we have only allocated 3 bits to it.  

One proposal would be to just use '0' for all pre-standard versions and
not try to match up functionality with version numbering any more
granularly than that.   

Another approach would be to take another bit for the version, but that
seems like overkill given the well understood extensibility mechanisms
that allow for the protocol to grow without requiring the version to
change.

We could also start with 0 but all decide that a more significant change
in the draft would cause us to go to 1 even if we are still in draft
state.  We could then rev it again as we take it toward a standard.  We
wouldn't necessarily bump it for each draft, but basically we'd be
accepting the fact that a bump in version number was necessary for the
set of implementations out there, and that our initial version number in
a standard might just be greater than 1.

Other thoughts?

Scott

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

---

From: Marshall Rose <[email-masked]>
Date: Mon, 18 Jul 2005 19:23:35 +0530

> not try to match up functionality with version numbering any more

that is the best choice. all versions of a protocol prior to RFC  
publication are equally obsolete.

/mtr

---

From: Bud Biswas <[email-masked]>
Date: Mon, 18 Jul 2005 07:10:31 -0700 (PDT)

Scott:
 
I would like to see the current version as 0 as opposed to draft number (I think Reva is using the draft number at this point for version field) and let's consider that current draft (.02) is the version 0. Implementors should remember that current draft has a different header structure compared to older drafts. That means draft 0 will not interoperate with draft 2. I had some problems in interoperating with draft 0 and draft 2 implementations.
 
Thanks.
 
Bud Biswas

Scott Barvick <[email-masked]> wrote:

Other thoughts?

Scott

Polaris Networks
your source for rfid test tools