Hybrid resolvers and the shape of an identifying token
12-16-2010, 02:30 PM
Post: #16
RE: Hybrid resolvers and the shape of an identifying token
Again, let's not confuse IDONS identifiers with the labels people and applications will use locally to refer to them. IDONS identifers are for the machines. Labels/names coupled to IDONS identifiers are what humans will normally deal with at the application level, just as most (non-techies) don't deal routinely with dotted quad IP addresses.

--Lauren--

Lauren Weinstein
[email protected]
GCTIP Founder
Visit this user's website Find all posts by this user
12-21-2010, 06:40 AM
Post: #17
RE: Hybrid resolvers and the shape of an identifying token
(12-16-2010 02:30 PM)lauren Wrote:  Again, let's not confuse IDONS identifiers with the labels people and applications will use locally to refer to them. IDONS identifers are for the machines. Labels/names coupled to IDONS identifiers are what humans will normally deal with at the application level...

Lauren, I've got a question about the intented scope of IDONS:

Shall IDONS mapping IDONS identifiers to "ip addresses" (or whatever means to address the other end of the communication link), or shall it map user input (names/labels) to IDONS identifiers?
Find all posts by this user
12-21-2010, 08:49 AM
Post: #18
RE: Hybrid resolvers and the shape of an identifying token
(12-21-2010 06:40 AM)jfw Wrote:  Lauren, I've got a question about the intented scope of IDONS:

Shall IDONS mapping IDONS identifiers to "ip addresses" (or whatever means to address the other end of the communication link), or shall it map user input (names/labels) to IDONS identifiers?

Both are necessary.

--Lauren--

Lauren Weinstein
[email protected]
GCTIP Founder
Visit this user's website Find all posts by this user
12-24-2010, 12:58 AM (This post was last modified: 12-24-2010 01:06 AM by eternaleye.)
Post: #19
RE: Hybrid resolvers and the shape of an identifying token
(I'm backlogging - I replied to this post as I read it)

(12-13-2010 03:58 PM)bug1 Wrote:  Just to throw some other ideas around, instead of banning a character required by ICANN's hostnames, we could including one of their banned characters in our hostnames, but then if they change their rules it can hurt us.

This is probably what would work best, for a few reasons. First, though, I'm going to invalidate the 'they can hurt us' bit. The restrictions on characters in domain names are not because of ICANN; they don't have the power to change them. They are specified in the relevant IETF RFCs for DNS and are fantastically unlikely to change. So using something explicitly banned (like the humble underscore) is basically entirely safe. If it's made mandatory in all IDONS addresses, it is impossible for one to be confused with the other.

One reason it would work well is that it's unambiguous, as stated above. A second is that it's trivially detectable in any software that does lookups, not just 'obvious to humans'. Another is that it offers ICANN no way to mess it up

However, this is really only a solution for identifiers, not names. We can't honestly expect all names to contain some character - it's boilerplate, and I have yet to meet someone who thought adding more of that is good. I hope I never do.
Find all posts by this user
 


Forum Jump: