[Standards] Link-Local Messaging comments
sjoerd at luon.net
Thu Mar 8 14:57:09 UTC 2007
As XEP-0174 is on it's last call, i thought it would be a good time to sent
in some of my comments about it :).. For the record, i'm the author of the
link-local messaging component in Telepathy, which is going to be used on
the One Laptop Per Child machines.
Section 3 states that each client MUST publish an A record in mdns. An ipv6
only client will obviously only publish a AAAA record. so it's probably best
to require either an A, AAAA or both.
Table 2 in section 3.1 states that if the user is able to do audio, video
and/or conference calls it should respectively put V, A and/or C in it's vc
TXT record. But what standard(s) to use for the actual call is omitted. The
only implementation of this i know currently is iChat and that uses a some
proprietary stuff for the call... Would be great if the standard to use for
the call would be specified (jingle audio/video?), otherwise you have no idea
if trying to call actually has a chance to succeed at all.
The same table also mention the 1st and last field. Both are optional
according to the XEP, but most implementation i've seen require them (or at
least one of them) to be available. Mostly because they want to expose a
friendly name to the user and just concatinate these to fields to do that.
So there is a slight mismatch between the current reality and the
specification here. What worries me more though is that there is no way
specified to communicate names that doesn't fit into the first/last name
scheme. E.g. for things like bots or people who don't want to put their real
name in but just a nick. One solution could be to add an alias/nickname
field with the specific purpose to be the default name to present to
end-users in the roster.
In section 6 it says that the stream opening should have no 'to' or 'from'
attributes. Which is kinda unfortunate. This means that when someone opens a
new connection to me, the only information i have is the ip the connection
originated from. If the machine where the connection originated from has
multiple presence, i'll have to wait untill the first stanza containing a
'from' attribute is received before i can link a connection to a presence..
If there would be a 'from' attribute in the stream opening, it would
obviously be much easier/elegant.
Also <stream:features /> as in XMPP isn't part of the stream opening. It
would be nice if that was added, so we could potentially negotiate say ssl
and or sasl in the same way as normal XMPP does.
Let us not look back in anger or forward in fear, but around us in awareness.
-- James Thurber
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Standards