[Standards] XEP 0174 (Link Local Messaging) Feedback
stpeter at jabber.org
Wed Mar 21 17:53:43 UTC 2007
Sjoerd Simons wrote:
> On Tue, Mar 20, 2007 at 02:59:09PM -0600, Peter Saint-Andre wrote:
>> Chris Mullins wrote:
>>> 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").
I did a lot of research on this at one point and concluded that the mdns
spec was being a bit cagey about it. :) But I will research it again and
post with my conclusions.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards