[Standards] Link-Local Messaging comments

Sjoerd Simons 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 
> >was
> >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
example :)

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
outside OLPC). 

Do not seek death; death will find you.  But seek the road which makes death
a fulfillment.
		-- Dag Hammarskjold

More information about the Standards mailing list