[Standards] Link-Local Messaging comments

Peter Saint-Andre stpeter at jabber.org
Tue Mar 13 18:31:30 UTC 2007


Sjoerd Simons wrote:
> Hi,
> 
>   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[0], 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 
>   scheme. 

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:

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-01.html#streams-attr

>   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.

Done.

Updated version on the way.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070313/a846e23c/attachment.bin>


More information about the Standards mailing list