[Standards] Link-Local Messaging comments
stpeter at jabber.org
Mon Mar 26 19:46:01 UTC 2007
Sjoerd Simons wrote:
> 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.
Sure. Naturally we could also establish a registry of TXT records and
people could register fields with that even if they are not in the spec.
That is probably the right way to go anyway.
Any objections to my changing the spec so that it calls for the XMPP
Registrar to create a registry?
> 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 :)
If we control the registry (which we would) then the XMPP Registrar
would ensure that we have no collisions.
> 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).
Sure, register 'em and off we go. :)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards