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
services.
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
<jari(_dot_)arkko(_at_)piuha(_dot_)net> 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.