Re: The Great Naming Debate (was Re: The internet architecture)

[Keith Moore <moore at network-heretics.com>]

Bryan Ford wrote:
> You seem to be assuming that my proposal was to disallow such
> "visibility into the network" entirely, but that wasn't my intent at
> all.  I just would like it to become no longer _mandatory_ for every
> application to know about the structure IP addresses in order to
> accomplish anything.

> In short, I don't think either the current fascist extreme of an
> "IP-address-only API" or the opposite fascist extreme of a
> "DNS-name-only protocol stack" is very appealing; we need an environment
> in which different kinds of names/addresses/identities can coexist.  

Ah, it seems I read far too much into what you wrote earlier.  I
certainly don't think it should be mandatory for all applications that
use the network to know about the structure of IP addresses. The beef I
had was with the various forms of "all apps should always use DNS names"
arguments.

Note that with getaddrinfo(), arguably they _don't_ need to know about
the structure of IP addresses.  The getaddrinfo() routine allocates a
sockaddr_xx structure of appropriate type for each address found, but
the pointers returned are (as far as the caller knows) to generic
sockaddr structures.  The caller can simply pass a pointer to this
structure to connect().  And the idea was clearly to insulate apps from
having to know about the structure or size of addresses, without
compromising their flexibility.   For several reasons, I don't happen to
think that tFrom ietf-bounces at ietf.org  Sun Dec 14 21:25:27 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-web-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 835403A69A2;
	Sun, 14 Dec 2008 21:25:27 -0800 (PST)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 289503A699E
	for <ietf at core3.amsl.com>; Sun, 14 Dec 2008 21:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ybqLiMqdhd9T for <ietf at core3.amsl.com>;
	Sun, 14 Dec 2008 21:25:26 -0800 (PST)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131])
	by core3.amsl.com (Postfix) with ESMTP id 137263A69A2
	for <ietf at ietf.org>; Sun, 14 Dec 2008 21:25:26 -0800 (PST)
Received: from lust.indecency.org (adsl-155-127-210.tys.bellsouth.net
	[72.155.127.210]) by m1.imap-partners.net (MOS 3.10.3-GA)
	with ESMTP id BFS64716 (AUTH admin at network-heretics.com)
	for ietf at ietf.org; Sun, 14 Dec 2008 21:24:15 -0800 (PST)
Message-ID: <4945E9FB.2000307 at network-heretics.com>
Date: Mon, 15 Dec 2008 00:24:11 -0500
From: Keith Moore <moore at network-heretics.com>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bryan Ford <brynosaurus at gmail.com>
Subject: Re: The Great Naming Debate (was Re: The internet architecture)
References: <C15AE32B-E564-4C93-86FF-40EF203E673A at mpi-sws.org>
	<49382030.5020704 at network-heretics.com>
	<2788466ED3E31C418E9ACC5C316615572FFBEF at mou1wnexmb09.vcorp.ad.vrsn.com>
	<49384BCF.2080600 at network-heretics.com>
	<C3937105-9315-42E7-97B1-E96292AB81BD at gmail.com>
In-Reply-To: <C3937105-9315-42E7-97B1-E96292AB81BD at gmail.com>
Cc: tae at ietf.org, ietf at ietf.org
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

Bryan Ford wrote:
> You seem to be assuming that my proposal was to disallow such
> "visibility into the network" entirely, but that wasn't my intent at
> all.  I just would like it to become no longer _mandatory_ for every
> application to know about the structure IP addresses in order to
> accomplish anything.

> In short, I don't think either the current fascist extreme of an
> "IP-address-only API" or the opposite fascist extreme of a
> "DNS-name-only protocol stack" is very appealing; we need an environment
> in which different kinds of names/addresses/identities can coexist.  

Ah, it seems I read far too much into what you wrote earlier.  I
certainly don't think it should be mandatory for all applications that
use the network to know about the structure of IP addresses. The beef I
had was with the various forms of "all apps should always use DNS names"
arguments.

Note that with getaddrinfo(), arguably they _don't_ need to know about
the structure of IP addresses.  The getaddrinfo() routine allocates a
sockaddr_xx structure of appropriate type for each address found, but
the pointers returned are (as far as the caller knows) to generic
sockaddr structures.  The caller can simply pass a pointer to this
structure to connect().  And the idea was clearly to insulate apps from
having to know about the structure or size of addresses, without
compromising their flexibility.   For several reasons, I don't happen to
thinhe result works very well, but the intent was there.  If it
turns out to not work well enough to prevent apps from needing to peek
into addresses, maybe the problem isn't the API, but rather that there
are subtle differences between v4 and v6 that nevertheless matter to
applications.

Keith

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


k that the result works very well, but the intent was there.  If it
turns out to not work well enough to prevent apps from needing to peek
into addresses, maybe the problem isn't the API, but rather that there
are subtle differences between v4 and v6 that nevertheless matter to
applications.

Keith

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf