Re: [mdnsext] Discussion of BoF during Berlin IETF

"Albrecht, Harald" <> Tue, 11 June 2013 12:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1D7621F96C2 for <>; Tue, 11 Jun 2013 05:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.248
X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oGtxnXwt01UV for <>; Tue, 11 Jun 2013 05:08:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5886621F96F7 for <>; Tue, 11 Jun 2013 05:08:14 -0700 (PDT)
Received: from (localhost []) by (8.13.6/8.13.6) with ESMTP id r5BC8CIL003156 for <>; Tue, 11 Jun 2013 14:08:12 +0200
Received: from ([]) by (8.13.6/8.13.6) with ESMTP id r5BC8BBD001420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Tue, 11 Jun 2013 14:08:12 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 11 Jun 2013 14:08:11 +0200
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 14:08:11 +0200
From: "Albrecht, Harald" <>
To: "" <>
Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF
Thread-Index: AQHOYSnHoLNfrYhO9UyyRiqKaj691Jkmr/9wgAnC/jCAAAG3AA==
Date: Tue, 11 Jun 2013 12:08:10 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E36F274013087B4EA05E08EB50375039020533DEFTHW99EK5MSXww9_"
MIME-Version: 1.0
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Jun 2013 12:08:28 -0000


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?

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
Gleiwitzer Str. 555
90475 Nürnberg, Deutschland
Tel: +49 911 895-3847
Fax: +49 911 895-2105

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 []
Gesendet: Dienstag, 11. Juni 2013 13:56
An: Albrecht, Harald
Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF


On 2013-06-11, at 5:08 AM, "Albrecht, Harald" <<>> 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).


Michael Sweet, Senior Printing System Engineer, PWG Chair