[Standards] Link-Local Messaging comments
stpeter at jabber.org
Tue Mar 13 18:31:30 UTC 2007
Sjoerd Simons wrote:
> 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.
Cool. Thanks for the feedback.
> 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.
I've modified the text and noted that the IP address may be either an
IPv4 address or an IPv6 address.
> 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.
IMHO you should use real service discovery methods (XEP-0030/XEP-0115)
instead of the "vc" stuff. That's there for backwards-compatibility only.
> 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.
Require in what sense? Does something break over the wire if the user
does not input a 1st and/or last? Or is it "required" only in the GUI?
> 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
Sure. First and last name are not culturally-sensitive, either.
> 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.
Probably some people / entities put a nickname as the first name, but I
agree that it would be better to have a dedicated nickname field. Added
to the spec.
> 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.
Ah. I'll change that, since we modified it in rfc3920bis too:
> 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.
Updated version on the way.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards