RE: future of identifiers

Larry Masinter <> Fri, 01 November 2013 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50D3611E813A for <>; Fri, 1 Nov 2013 15:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.098
X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rk+utQGrmq3N for <>; Fri, 1 Nov 2013 15:34:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 83B0711E80E9 for <>; Fri, 1 Nov 2013 15:34:42 -0700 (PDT)
Received: from ([]) by ([]) with SMTP ID; Fri, 01 Nov 2013 15:34:42 PDT
Received: from ( []) by (8.12.10/8.12.10) with ESMTP id rA1MYZWY016555; Fri, 1 Nov 2013 15:34:36 -0700 (PDT)
Received: from ( []) by (8.12.10/8.12.10) with ESMTP id rA1MYY6A025490; Fri, 1 Nov 2013 15:34:34 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Fri, 1 Nov 2013 15:34:34 -0700
From: Larry Masinter <>
To: "Fred Baker (fred)" <>, Jari Arkko <>
Date: Fri, 01 Nov 2013 15:34:36 -0700
Subject: RE: future of identifiers
Thread-Topic: future of identifiers
Thread-Index: AQHO1LTRdqeJ7pMTBkGukKPpV2N3gpoRIRKA///SPLA=
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " Discussion" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Nov 2013 22:34:49 -0000

Identifiers are just strings (or data structures serialized as strings). As such, they
have no meaning other than as a string of characters or bytes.

What gives an identifier meaning, what imbues it with the property of identifying
something, is the service guarantee of the organization or system that promises
widely accepted authority to tell anyone who asks what the string means, in the
contexts that the string is expected to be used (aka 'resolution' of the identifier.)

The future of "identifier technology" is really the future of identifier resolution

> it might be a good thing if we were to first identify what needs to be identified.

"Everything" needs to be identified. 

> I think RFC 1992's model of an identifier (a string of some kind that identifies an
> application API, and moves with the API) makes a lot of sense.

For an API to "move" there have to be two APIs, the old one and the new one,
and for someone to believe that the new one is the "same" as the old one, only 
newer. But this is a judgement call, there's nothing intrinsic.

> Such a thing
> would, for example, simplify VM motion in data centers. Taking that model into
> information-centric/name-based networking, one could imagine it being a
> string that an application uses to identify itself when it expresses interest in a
> class of data.

When I imagine that, I also imagine two different APIs that use the
same string, and what authority I would have to look to, in order to
help me decide which one is right.

> If it's something along those lines, I doubt that it's in any character set, and by
> the way, while it might have a current-set-of-ip-addresses, it's not an IP
> address or the EID component of one. I could imagine it being almost anything
> that can be built into a string, and then signed using an 802.1AR certificate or
> one from another source.

Every finite data structure can be serialized. 

> I could imagine law enforcement "expressing interest" in an interesting party's
> communications. Or the mafia, or the person's spouse. There might be some
> interesting security angles.
> But seriously, I'd suggest we start from first principles before thinking about
> solutions here. What needs to be identified, and what characteristics does it
> have?
> On Oct 29, 2013, at 7:38 AM, Jari Arkko <> wrote:
> > For background, when I visited the ICANN meeting last summer, they were
> about to launch a set of panels to advice themselves about key topics in coming
> years. I promised to join one of them, on identifier technology innovation
> (along with a few other IETFers). The topic for this effort is future evolution of
> DNS and other identifiers, including relevant security and management aspects.
> The viewpoint is primarily to look at this from ICANN's angle, but of course the
> matter is interesting to us others as well.
> >
> > And perhaps we at the IETF should also understand the same things. Hence
> this e-mail.
> >
> > I have some ideas on what some of these trends might be. But what do the
> rest of you think? Where is identifier technology going, and what new things
> are on the horizon? What do we need to do with IDNs? 

One serious problem with IDNs is the incompatibility with IRIs. While the IRI
spec called for %xx-hex encoding the UTF-8 of non-ASCII characters, IDNs
use punycode, thus leading to the unfortunate situation where an IRI processor
has to guess about whether the authority part of an IRI should be converted
to punicode before passing on a URI to a legacy system that doesn't support
IRIs.   One "fix" would be to insist operationally that the percent-hex-encoded
UTF8 transliteration of a Unicode string be accepted equivalently to the
punicode encoding during DNS lookups.