[Standards] XEP 0174 (Link Local Messaging) Feedback
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
> >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  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").
Those who can, do; those who can't, simulate.
More information about the Standards