Re: [mdnsext] Discussion of BoF during Berlin IETF

Michael Sweet <msweet@apple.com> Tue, 11 June 2013 15:04 UTC

Return-Path: <msweet@apple.com>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D5A21F9607 for <mdnsext@ietfa.amsl.com>; Tue, 11 Jun 2013 08:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.598
X-Spam-Level:
X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLMdZ1m2kS7v for <mdnsext@ietfa.amsl.com>; Tue, 11 Jun 2013 08:04:24 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 60F8C21F86FB for <mdnsext@ietf.org>; Tue, 11 Jun 2013 08:04:24 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_y9IfC11NyMSsmEgNipPWtg)"
Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MO800AOZHURSTE0@mail-out.apple.com> for mdnsext@ietf.org; Tue, 11 Jun 2013 08:04:03 -0700 (PDT)
X-AuditID: 11807153-b7f3c6d000007b32-86-51b73c60e688
Received: from [17.153.48.156] (Unknown_Domain [17.153.48.156]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 08.6F.31538.16C37B15; Tue, 11 Jun 2013 08:04:02 -0700 (PDT)
From: Michael Sweet <msweet@apple.com>
In-reply-to: <E36F274013087B4EA05E08EB50375039020533@DEFTHW99EK5MSX.ww902.siemens.net>
Date: Tue, 11 Jun 2013 11:04:05 -0400
Message-id: <F08FF248-D321-46AF-B55D-3BC33DC20FB6@apple.com>
References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <E36F274013087B4EA05E08EB5037503901820D@DEFTHW99EK5MSX.ww902.siemens.net> <22635.1370439768@sandelman.ca> <CABOxzu20VrSc1_HGzPZgjQk5=tuGObn+MFjGrCriijhNck6P=w@mail.gmail.com> <E36F274013087B4EA05E08EB5037503901F483@DEFTHW99EK5MSX.ww902.siemens.net> <7EDAF229-930C-428D-B7F7-F9C52E854033@apple.com> <E36F274013087B4EA05E08EB50375039020533@DEFTHW99EK5MSX.ww902.siemens.net>
To: "Albrecht, Harald" <harald.albrecht@siemens.com>
X-Mailer: Apple Mail (2.1508)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUiONNgjm6SzfZAg66HEhZfT/5htzi55BST xZFvsQ7MHltP/mDzWLLkJ5PH9pOTmAKYo7hsUlJzMstSi/TtErgyVvW8Yio4vICx4tDExewN jHu7GLsYOTkkBEwktt3ZwgZhi0lcuLceyObiEBLoZZL49XMzWJGwgLXEyuMfwWxeAT2Jpf/m ANkcHMwCCRLrZ4SAhNkE1CR+T+pjBbE5BcIkdq24xw5iswioSvy/d4kFxGYW0JRY+n8t1Bgb iTmL9jJC7Gpkkfi3sAfsCBGQgy4/YAGZLyEgK7Hzd9IERr5ZSDbPQtg8C2yqtsSyha+ZIWwD iaedr1gxxfUl3rybw7SAkW0Vo0BRak5ipbFeYkFBTqpecn7uJkZQ2DYUBu9g/LPM6hCjAAej Eg/vAbPtgUKsiWXFlbmHGCU4mJVEeN9YAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzBldvCxQS SE8sSc1OTS1ILYLJMnFwSjUwiqjOX2dYnn0kI3wmq/ZP218WPv/YGdKao3tYF0pFrxPee/ex 4yUP5uP9ComSS4JZq4+kvFuy3Oipl9ivxOc/rI4+/NAx/ajoxItTspk3fmk9uIrtwpYfN7eL XFcynDHxZE7OageviIWCbFPNT/THGay+yyr4XuLWl6ur5nd9FEs52zB9WUXFZiWW4oxEQy3m ouJEAFxM3YlXAgAA
Cc: "mdnsext@ietf.org" <mdnsext@ietf.org>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 15:04:33 -0000

Albrecht,

On 2013-06-11, at 8:08 AM, "Albrecht, Harald" <harald.albrecht@siemens.com> wrote:
> Michael,
>  
> thank you very much for the clarification. What I see as a big stumbling block in service discovery usage are such architectural issues that can basically make a good idea unworkable, at least in some environments. Do you have more information as to what Microsoft does? From reading their MSDN pages I could not get a clear picture whether they are tripping into the same pit as the glibc does and I unfortunately lack some knowledge in order to fully understand what’s going on in the mDNS resolver DLL. Can you provide some insight?

From MSDN [2]:

On Windows 8 and Windows Server 2012, the getaddrinfo function provides support for IRI or Internationalized Domain Name (IDN) parsing applied to the name passed in the pNodeName parameter. Winsock performs Punycode/IDN encoding and conversion. This behavior can be disabled using the AI_DISABLE_IDN_ENCODING flag discussed below.

On Windows 7 and Windows Server 2008 R2 or earlier, the getaddrinfo function does not currently provide support for IRI or Internationalized Domain Name (IDN) parsing applied to the name passed in thepNodeName parameter. Winsock does not perform any Punycode/IDN conversion. The wide character version of the GetAddrInfo function does not convert a Unicode name to Punycode format as per RFC 3490. The wide character version of the GetAddrInfo function when querying DNS encodes the Unicode name in UTF-8 format, the format used by Microsoft DNS servers in an enterprise environment.

So for current Windows, applications automatically get the encoding applied for traditional DNS unless they specify otherwise - basically the "opt out" approach for applications that are written specifically to do their own "DNS thing".  And if I fully understand the Windows namespace provider interface :) the mDNS provider will likely just get the original, unencoded name and will be able to Do The Right Thing...  But I have to admit that I haven't tested this myself to see whether it works for real on Windows 8 (it does on Windows 7 but then IDN isn't supported directly on Windows 7...)

........

[2] http://msdn.microsoft.com/en-us/library/windows/desktop/ms738520(v=vs.85).aspx

>  
> My impression is that the face-to-face meeting in Berlin will surely have some very interesting topics to discuss – or rather, where I hope to learn more about so I don’t put forward too many dumb questions.
>  
> -- Harald
> 
> Siemens AG
> Industry Sector
> Industry Automation Division
> Industrial Automation Systems
> I IA AS CTO DH 1
> Gleiwitzer Str. 555
> 90475 Nürnberg, Deutschland
> Tel: +49 911 895-3847
> Fax: +49 911 895-2105
> mailto:harald.albrecht@siemens.com
> 
> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter Löscher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
>  
>  
>  
> Von: Michael Sweet [mailto:msweet@apple.com] 
> Gesendet: Dienstag, 11. Juni 2013 13:56
> An: Albrecht, Harald
> Cc: mdnsext@ietf.org
> Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF
>  
> Albrecht,
>  
> On 2013-06-11, at 5:08 AM, "Albrecht, Harald" <harald.albrecht@siemens.com> wrote:
> ... 
> My analysis bases on the GNU libc as one example, other implementations may differ very well (and most probably will). Code base is glib 2.17 as available from the FSF ftp servers. I tried to make sure that I did not make any (gross) mistakes in my analysis. However, caveat emptor, and if you find errors in my analysis please explain them to us so I (and maybe others) can learn.
>  
> As a user of getaddrinfo, I know for sure that the AI_IDN flag is a non-standard glibc extension.  And IMHO it is a poorly thought-out addition to the API - such decisions need to be made in the underlying resolvers (all those plugins you can specify in /etc/nsswitch.conf for "hosts") and not in the application which then needs to have a much greater understanding of which DNS is being used, etc.  The original proposal [1] gives some background on the addition, but I personally would not rely on the application asking the system to Do The Right Thing (tm).
>  
> ........
> [1] http://www.gnu.org/software/libidn/getaddrinfo-idn.txt
>  
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>  
> _______________________________________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair