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.arkko@xxxxxxxxx> 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.