[avahi] Re: Avahi daemon dies on certain hostnames

[Marc Krochmal]

On Apr 7, 2006, at 5:49 AM, Lennart Poettering wrote:

> On Fri, 07.04.06 13:31, Iván Sánchez Ortega (i.sanchez at mirame.net)  
> wrote:
>
>> El Sábado 01 de Abril de 2006 16:29, Lennart Poettering escribió:
>> [...]
>>> The scheme you suggest isn't invertible. There needs to be a way to
>>> detect whether a sanitized string has been escaped or not.
>>
>> Don't worry about invertibility: Apple does not.
>>
>> I managed to get my hands over a iBook G4 today, and tried to set  
>> its hostname
>> to "fóobar". Interestingly, the mDNS response has another charset,  
>> and it
>> does not kill Avahi. Check the attachments at http://avahi.org/ 
>> ticket/21
>>
>> Seen that, I agree with the idea of "f*ck^H^H^H^Hignore devices  
>> with non-UTF8
>> hostnames".
>>
>> However, at some point, MacOS X converts "fóobar.local" into "f- 
>> obar.local".
>> I'll post a screenshot of that ASAP. I wonder how Apple deals with  
>> name
>> collisions... :-/
>
> These are actually two different things. One thing is how to deal with
> hostnames with invalid UTF8 that are recieved from other hosts, and
> the other is how to mangle the local hostname before publishing it on
> the LAN. Ther former mapping requires perfect bijectiveness, the
> latter doesn't.
>
> It's perfectly valid for Apple to mangle the local host name the way
> they do. However, I don't think it really is necessary. One could
> publish an UTF8-Domain here directly. As long as it is correct UTF8 i
> see no problem here.

Right.  The Mac OS X user interface prevents you from entering a  
local hostname with non-ascii characters by automatically converting  
everything into letters, digits and hyphens.  If you could manage to  
bypass this and enter non-ascii characters, then Mac OS X would  
advertise the raw UTF-8, instead of using something like IDN.  mDNS  
was designed before IDN was fully standardized, and the mDNS authors  
aren't big fans of it, so we made the decision to use UTF-8 as the  
encoding scheme on the wire, since we didn't have any backward  
compatibly issues, which was one of the stated reasons for the  
necessity of IDN in DNS.

We're still contemplating how to handle this for wide-area discovery,  
but our current implementation uses UTF-8 for wide-area as well.   
Note that BIND 9 servers allow you to specify full UTF-8 domain names  
in zone files and this works, meaning you can query for raw UTF-8 on  
the wire and the server responds as expected.

-Marc