[Standards] XEP 0174 (Link Local Messaging) Feedback
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.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards