[Standards] XEP 0174 (Link Local Messaging) Feedback

Peter Saint-Andre stpeter at jabber.org
Tue Mar 20 20:59:09 UTC 2007

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?

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

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


Peter Saint-Andre
XMPP Standards Foundation

-------------- 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/20070320/cecc175a/attachment.bin>

More information about the Standards mailing list