Re: [mdnsext] Discussion of BoF during Berlin IETF

Michael Sweet <msweet@apple.com> Tue, 11 June 2013 11:56 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 5D1F421F9607 for <mdnsext@ietfa.amsl.com>; Tue, 11 Jun 2013 04:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=4.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 ZLgLG8ZbhBeL for <mdnsext@ietfa.amsl.com>; Tue, 11 Jun 2013 04:56:13 -0700 (PDT)
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 109A021F8EFE for <mdnsext@ietf.org>; Tue, 11 Jun 2013 04:56:12 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_criQg+O3ib9x9j4J3Mclcg)"
Received: from relay6.apple.com ([17.128.113.90]) 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 <0MO8002EW950VOS1@mail-out.apple.com> for mdnsext@ietf.org; Tue, 11 Jun 2013 04:55:55 -0700 (PDT)
X-AuditID: 1180715a-b7f506d000007d18-65-51b71049c5c8
Received: from [17.153.48.48] (Unknown_Domain [17.153.48.48]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 57.BF.32024.A4017B15; Tue, 11 Jun 2013 04:55:55 -0700 (PDT)
From: Michael Sweet <msweet@apple.com>
In-reply-to: <E36F274013087B4EA05E08EB5037503901F483@DEFTHW99EK5MSX.ww902.siemens.net>
Date: Tue, 11 Jun 2013 07:55:53 -0400
Message-id: <7EDAF229-930C-428D-B7F7-F9C52E854033@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>
To: "Albrecht, Harald" <harald.albrecht@siemens.com>
X-Mailer: Apple Mail (2.1508)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUiONPAQNdbYHugwe8/YhZfT/5htzi55BST xZFvsQ7MHltP/mDzWLLkJ5PH9pOTmAKYo7hsUlJzMstSi/TtErgyNq/4wFJwUKdi59ndLA2M u9W6GDk5JARMJD4dmcIEYYtJXLi3nq2LkYtDSKCbSaL53mp2kISwgLXEyuMfGUFsXgE9iaX/ 5oDZzAIJEufu3mIBsdkE1CR+T+pjBbE5BcIktr25zgxiswioSkxoecsCUa8psfT/Wqg5NhJL G+4wQyxrY5bY+HQdWJEI0EXbLj8AsjmALpKV2Pk7aQIj3ywkq2chWQ1ha0ssW/iaGcLWk3jZ 9I4dU1xX4uK6SYwLGNlWMQoUpeYkVprpJRYU5KTqJefnbmIEhW1DYdQOxoblVocYBTgYlXh4 Of5vDRRiTSwrrsw9xCjBwawkwivJuD1QiDclsbIqtSg/vqg0J7X4EKM0B4uSOG9I9bZAIYH0 xJLU7NTUgtQimCwTB6dUA+O0P/8Oc32OOHZUSbNGQFmCj6P/SapnwEqZ3EBu01ea/S8jXAor vxxT+HFWttuq8b78V40IcbFO50rr+Va3/Djrnp/852nutOByUu5vrf6gSxPnuhkd0dw/oeX2 3JWvJB416ghIHPi1ZKpi2TIhpf+eBSq3eZLPLWJ0+aShYqJ66pJA053ln5VYijMSDbWYi4oT ARWl9e1XAgAA
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 11:56:20 -0000

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