[Standards] Link-Local Messaging comments
stpeter at jabber.org
Mon Mar 26 19:51:35 UTC 2007
Sjoerd Simons wrote:
> On Wed, Mar 21, 2007 at 11:47:16PM -0600, Peter Saint-Andre wrote:
>> If we don't use txtvers then it's unnecessary. But it would be helpful
>> to better define the status of each TXT record. Here's what I would say:
>> txtvers (hardcoded to "1")
> I'd actually make most of this list optional, except for txtvers which should
> be deprecated. node, last, ver probably should be only there if the client
> supports discovery, thus i'd say optional, otoh you could say that supporting
> discovery is recommended :)
> As nick is what ``should'' ends up in the roster, it might make sense to
> recommend this?
> Might make sense to recommend. Also please document which status a client
> which a status field has (salut currently assumes avail, gajim offline)
You mean the default status?
> Should be deprecated imho.
>> What do you think?
> I'm not sure how you grouped these. If i may guess, you gave priority to the
> fields ``required'' by some of the current implementations.
So it seems. Either that or random association. :)
> I looked at it without considering current implementations. In which case
> nick should really be recommended as that's what should be presented to the
> end-user. (and maybe status, node, ver and ext but see comments above for
> Things like 1st, last, email and jid are things which the end-user really
> needs to decide if he wants to publish them, so i don't think it makes sense to
> recommend those.
> I'm not sure which way of looking at it is more correct though :)
If we create a registry, implementations can pick and choose which TXT
records they want to support. Then the spec simply needs to specify a
policy for handling TXT records or their absence, like "don't break if
you don't receive any given TXT record", potentially with the exception
of the fields we really think are important, such as nick -- but even
that is not necessary I think because link-local messaging could be used
by all sorts of interesting non-human entities that won't have a nick.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards