[Standards] Link-Local Messaging comments

Sjoerd Simons sjoerd at luon.net
Tue Mar 13 22:32:51 UTC 2007


On Tue, Mar 13, 2007 at 12:31:30PM -0600, Peter Saint-Andre wrote:
> Sjoerd Simons wrote:
> >  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.

Good point. But to map XEP-0115 to link-local we need to define some field(s)
in the presence as announced on dns-sd to advertise the clients capabilities.

Maybe add capabilities, version, extensions fields with the same meaning as
respectively the node, ver and ext attributes as defined in section 4.1 of
XEP-0115 ?

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

Only ``required'' in the UI. Applications like iChat, Adium and Gaim
don't show your presence unless you've got those fields. So it could indeed be
regarded as an bug in their implementation... Maybe a node in the spec about
this would be good

> Updated version on the way.

Thanks!
  Sjoerd
-- 
The opposite of a correct statement is a false statement. But the opposite
of a profound truth may well be another profound truth.
		-- Niels Bohr



More information about the Standards mailing list