Re: sockets APIs extensions for Host Identity Protocol

der Mouse <mouse@Rodents.Montreal.QC.CA> Mon, 14 May 2007 15:53 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hncr7-00049T-RK; Mon, 14 May 2007 11:53:01 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hncr6-00049H-Kc for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 11:53:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hncr6-000496-Aq for discuss@apps.ietf.org; Mon, 14 May 2007 11:53:00 -0400
Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hncr4-0005h1-ST for discuss@apps.ietf.org; Mon, 14 May 2007 11:53:00 -0400
Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA02624; Mon, 14 May 2007 11:52:57 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200705141552.LAA02624@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
Date: Mon, 14 May 2007 11:40:49 -0400
To: discuss@apps.ietf.org
Subject: Re: sockets APIs extensions for Host Identity Protocol
In-Reply-To: <Pine.SOL.4.64.0705090046320.18946@kekkonen.cs.hut.fi>
References: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi> <31BC7A8C1A51004A84E08DEF@[10.1.110.5]> <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA> <Pine.SOL.4.64.0705090046320.18946@kekkonen.cs.hut.fi>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

> I am curious.  Even though this is irrelevant for the discussion, can
> be more specific on what is broken with getaddrinfo?

The major annoyance it has for me is the requirement that, to quote the
manpage for the version I use, "[i]n this hints structure all members
other than ai_flags, ai_family, ai_socktype, and ai_protocol must be
zero or a NULL pointer".  This requires the app to either have a static
struct addrinfo around or to know the complete list of members of the
struct - and it's completely unnecessary as far as I can see.  (It
makes sense to have some kind of extensibility hook, but that could be
done with a bit in ai_flags, or at least listing the fields that have
to be zeroed rather than requiring it of all except a list.)

Not a big problem, true.  But annoying.  (Apparently the getaddrinfo()
I've got used to doesn't suffer from most of the brokennesses outlined
in this thread.  If I had to deal with them I'd have a lot more to say
here, I'm sure.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B