[Standards] Link-Local Messaging comments
sjoerd at luon.net
Thu Mar 22 14:25:40 UTC 2007
On Wed, Mar 21, 2007 at 05:04:11PM -0600, Peter Saint-Andre wrote:
> >One ``crazy'' option to allow clients to update to a newer spec without
> >breaking compatibility might be to define a new version field for the TXT
> >records and deprecate txtvers. It does make sense a little bit because it
> >never define what a client should do/expect when it saw a txtvers it
> >didn't know about.
> Right. But do we even need versioning here? I have my doubts. In that
> case we just leave txtvers at 1 forever and leave it at that.
I can only see one reason for versioning. It ensures that the keys actually
have the meaning you think they have :)
For example client A uses some custom fields. And at some later point in time
a field with the same name is added to the spec.. Now if client A and the spec
don't agree what that field means, things could break badly..
If there would be a version other clients can detect that while A has a
certain field, it wasn't defined in the spec version it uses and ignore the
field. Versioning makes the spec more future-proof in a sense.
But to be honest, i don't feel very strongly about this. No versioning would be
fine by me, i just hope we then never end up in a situation as in the above
Adding custom fields might not be that uncommon btw. For OLPC we're at least
going to a color field to the presence (which isn't so usefull outside OLPC)
and maybe some signature field for extra security (which might be usefull
Do not seek death; death will find you. But seek the road which makes death
-- Dag Hammarskjold
More information about the Standards