[Standards] XEP 0174 (Link Local Messaging) Feedback

Sjoerd Simons sjoerd at luon.net
Wed Mar 21 00:29:00 UTC 2007

On Tue, Mar 20, 2007 at 02:59:09PM -0600, Peter Saint-Andre wrote:
> Chris Mullins wrote:
> >Great XEP, solving a cool problem that enables fun stuff! J
> >
> > 
> >
> >The discovery of users using broadcast DNS seems like it?s being done 
> >the hard way. I?m not terribly familiar with IPv6, but what I do know 
> >indicates there are IPv6 features that would go a long way towards 
> >solving this problem. Anyone here know IPv6 well enough to say yay or 
> >nay to this? I do understand that this is already running in the wild, 
> >and that the adoption of IPv6 Features, even if a good match, may not 
> >make sense?.
> In part this spec simply documents current usage of _presence._tcp for 
> presence, which in the past was mainly done with IPv4. I also am not 
> knowledgeable enough about IPv6 to speak intelligently about it. But are 
> you suggesting that we would have two different mechanisms for 
> link-local presence, one for IPv4 and the other for IPv6?

No, mdns is exactly the same for IPv4 and IPv6. You just need to lookup AAAA
records for IPv6 and A for IPv4, just like you do with unicast DNS.. But these
are details that your platfoms mdns implementation should take care of 
for you. 

> >Port Choice is going to be difficult given today's firewalls ? everyone 
> >runs a filewall, and as a result, nothing will work right. Alluding to 
> >the need to use UPnP to drill a few local holes would be a good thing.
> How an entity determines which port to use seems like an implementation 
> issue. However it might be helpful to point implementors to technologies 
> that can make that easier. Any suggestions other than UPnP?

Uhm, i might be missing something. But why would you need to cross a firewall
when everyone is on one network segment talking directly to each-other?  Afaik
UPnP is only for drilling holes through remote firewalls.. 

For link-local all one need is to do is to listen on a port that's not blocked
by your local firewall. 

> >The International Considerations in the XEP seem very strange to me. The 
> >XEP mentions: ?However, as mentioned above, the "machine-name" portion 
> >of the <Instance> portion MUST NOT contain characters outside the 
> >US-ASCII range.?. I?m curious as to why this machine name wouldn?t 
> >follow standard IDNA rules and be punycoded. This would allow Unicode 
> >characters to work just fine, and keep all our International friends happy.
> I looked at the relevant specs for a long time and determined that we 
> needed to follow those rules. Refer to RFC 1035. I didn't find any 
> wiggle room in the specs on this point (i.e., DNS-SD does not refer to 
> IDNA, only to RFC 1035). So it seemed best to be conservative.

RFC1035 refers to traditional unicast DNS, the rules for Mdns are slightly
different. The latest mdns specification [0] says the following in section 18:

   Multicast DNS is a new protocol and doesn't (yet) have old buggy
   legacy implementations to constrain the design choices. Accordingly,
   it adopts the simple obvious elegant solution: all names in Multicast
   DNS are encoded using precomposed UTF-8 [RFC 3629]. The characters
   SHOULD conform to Unicode Normalization Form C (NFC) [UAX15]: Use
   precomposed characters instead of combining sequences where possible,
   e.g. use U+00C4 ("Latin capital letter A with diaeresis") instead of
   U+0041 U+0308 ("Latin capital letter A", "combining diaeresis").

0: http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
Those who can, do; those who can't, simulate.

More information about the Standards mailing list