Search
Portal Page
Help|
An attempt to structure the field.
|
|
12-16-2010, 01:22 PM
Post: #16
|
|||
|
|||
RE: An attempt to structure the field.
(12-16-2010 09:16 AM)lauren Wrote: I would strongly recommend against rushing into any implementations at this time. Very premature. I'm also seeing in this Forum some references to ...particular law... -- that are not in sync with what I hope is my fairly robust understanding of the related issues. I see your point - and agree wholeheartedly. (Prototyping ohir's proposal, as I intent, would be no more that "put it into my calculator and check for gross mistakes".) Further I second your intentions to steer clear of political and legal issues. Therefore I'm supporting the idea to lay the ground work for a machine executable "contract language" (under "practical issues" No.2), which governs the registration policy. (more detailed at here at "Ideas" #3. This would allow us to lay the ground and defer all politics to users ("those who enter contracts"). (12-16-2010 09:16 AM)lauren Wrote: A key reason for decoupling "random string" identifiers from the names that people and applications use to refer to them, is to move trademark issues out of the namespace. For the very same reason I'm proposing to self verifying identifiers - the "random" strings - as identity tokens referring to a (particular alias created by a) person and an arbitrary number of dictionaries, each subject to whatever applicable law. I don't see any chance to get trademark issues out of the dictionary. That's all trademarks are about. Neither I see, why the mere reference to a random string could ever be a trademark violation. (12-16-2010 09:16 AM)lauren Wrote: The reason trademarks have become such a big problem on the Internet isn't that there are 1000s of ACMEs -- because there are and trademark disputes between them in the brick and mortar world are relatively rare. The problem is that the existing DNS grossly overloads any possible DNS namespaces by creating a situation where there is enormous competition for single "identifiers" (which are directly human readable at the global level) on the Internet. If I was asked to rephrase the last sentence in my words, I'd say: The problem is that the existing usage of DNS grossly overloads any possible DNS namespaces by creating a situation where there is enormous competition for single "identifiers" (which are directly human readable at the global level) on the Internet. -- Plus: I'd underline global level. I agree with rev412 that there would need to be a change (visible to the end user) that "from now on" this expectation of a global namespace is no longer worth a cent. "From now on": that will be when "Dr. med. Grandma" can use it just like that. Right before that point in time I foresee the trademark issues popping up. Either they are dealt with in the way the judge decides, or the system is dead. Therefore in the long term I'd expect: settlement on a registration policy. No. Probably one per jurisdiction. Short(er) term: the "enabling technology"; availability+usability over name resolution at the client device and at the same moment comply with local law: if "R" is not allowed by local authority (whoever that may be) publication of the records will just not happen. (12-16-2010 09:16 AM)lauren Wrote: IDONS, by banishing that model to the pages of technology history, does not create such scarcity at all. Will there still be trademark disputes? Sure, but likely only of the "traditional" variety that are not Internet specific. Once again: I could not find better words! |
|||
|
|
12-17-2010, 01:16 AM
Post: #17
|
|||
|
|||
RE: An attempt to structure the field.
(12-14-2010 03:45 PM)jfw Wrote:(12-14-2010 03:28 PM)rev412 Wrote: In the model of Name -> Identifier -> IP Address, what goes in a URL's host field or the host part of an email address is the Identifier (or a textual representation thereof). The mapping of Identifier -> IP Address is one/none. Absolutely! If we can't achieve this - if the user is ever exposed to raw hashes - we've failed, and users will not adopt our solution. |
|||
|
|
|
12-17-2010, 09:34 PM
(This post was last modified: 12-17-2010 09:36 PM by Joe.)
Post: #18
|
|||
|
|||
RE: An attempt to structure the field.
(12-17-2010 01:16 AM)simon_brooke Wrote:(12-14-2010 03:45 PM)jfw Wrote:(12-14-2010 03:28 PM)rev412 Wrote: In the model of Name -> Identifier -> IP Address, what goes in a URL's host field or the host part of an email address is the Identifier (or a textual representation thereof). The mapping of Identifier -> IP Address is one/none. I respectfully disagree. What's the point in having a Name at all if not to use it? Regardless of whether the Identifier is implemented as a raw hash, random string, etc., the user should not normally be using it. Users should use the Name in web browsing, emails, etc. To use the Identifier instead of the Name completely circumvents a level of indirection. We would essentially be reinventing DNS's single level mapping. As an aside, the relationship "Identifier -> IP Address" cannot be 1:1 unless we somehow disallow multi-homed computers (requires 1:many) and at least some forms of paid hosting (requires many:1). - Joe |
|||
|
|
|
12-18-2010, 07:49 AM
Post: #19
|
|||
|
|||
RE: An attempt to structure the field.
(12-17-2010 09:34 PM)Joe Wrote:(12-17-2010 01:16 AM)simon_brooke Wrote:(12-14-2010 03:45 PM)jfw Wrote:(12-14-2010 03:28 PM)rev412 Wrote: In the model of Name -> Identifier -> IP Address, what goes in a URL's host field or the host part of an email address is the Identifier (or a textual representation thereof). The mapping of Identifier -> IP Address is one/none. Joe: I completely fail to see, what you disagree with. As far as I understand, you, simon_broke, rev412 and me agree in the quoted text, that there needs to be a multi level (or recursive) mapping. N:M. Since this breaks the current expectations of applications, something has to be invented to decentralize the new duty of resolving the conflict. |
|||
|
|
|
12-18-2010, 08:22 AM
Post: #20
|
|||
|
|||
RE: An attempt to structure the field.
(12-18-2010 07:49 AM)jfw Wrote: Joe: I completely fail to see, what you disagree with. I don't actually think so, or at least it can be hidden inside the resolver library. We essentially need to rewrite the gethostbyname() library call. This way, every application that calls gethostbyname to resolve a DNS name will automatically be able to resolve an IDONS name or identifier as well. |
|||
|
|
|
12-18-2010, 08:52 AM
(This post was last modified: 12-18-2010 09:00 AM by jfw.)
Post: #21
|
|||
|
|||
RE: An attempt to structure the field.
(12-18-2010 08:22 AM)simon_brooke Wrote:(12-18-2010 07:49 AM)jfw Wrote: Joe: I completely fail to see, what you disagree with. Hiding in the resolver library would be great. I posted at idons.askemos.org "my" view of the whole picture. Also I have an easy time to imagine how to implement the "server" side. But at this time my limited brain comes up with view options for this resolver library integration. All not very pleasing. Let's assume a desktop system: If it can not find a prefered solution for a name, it might pop up a dialog. Good to start with. But I have the habit to read some news via RSS. Interesting headlines get a click. On my netbook it sometimes takes quite a while until it responds. Easily 4-7 pending. -- Will I end up with half a dozend dialog options asking me which of those 40 name resolutions I'd like to connect to? Even worse a server. I don't want to think of the idea, that each spam mail could trigger an adminstrator mail about trust in the sender! Summary: how could the resolver client library manage a user interface to deal with the uncertainty, which of the known "DNS roots" allowed to resolve a name. (In case of conflict that is. I see little problems to resolve .google if the all but one of the dictionaries I subscribed resolve it. I see a "minor conflict" if there is a google,de and a google,com - which could be solved using a kind of weight. It becomes worse if I was to distrust the domain in question so much, that I want to redirect all access via tor and "filter by cooperation" unwanted direct access. The real problem I see comes up, when my news site points me to a 20 new projects on earth. Each served from their own "DNS root".) --- Eddited to add: Maybe this all adds up to one simple question: Should the system resolve unknown names at all (as DNS does)? Or should it only resolve a name, iff it can find a (short enough) path from itself to the named entity (crypto hash or alike)? (A breadth first search of linked dictionaries, aborting after lever X.) |
|||
|
|
|
12-18-2010, 12:30 PM
Post: #22
|
|||
|
|||
RE: An attempt to structure the field.
(12-18-2010 07:49 AM)jfw Wrote:(12-17-2010 09:34 PM)Joe Wrote:(12-17-2010 01:16 AM)simon_brooke Wrote:(12-14-2010 03:45 PM)jfw Wrote:(12-14-2010 03:28 PM)rev412 Wrote: In the model of Name -> Identifier -> IP Address, what goes in a URL's host field or the host part of an email address is the Identifier (or a textual representation thereof). The mapping of Identifier -> IP Address is one/none. Sorry. I should proofread my posts better - especially when I post late at night. I was disagreeing with rev412's assertions that A) what goes in the host part of an email address or URL is the Identifier; and B) the mapping of Identifier -> Address is 1:1. The only reason I can foresee exposing users to an Identifier would be to provide a permanent/persistent URL which would continue to be available if the publishing entity was acquired, changed its Name, etc. My reasons for disagreeing with the "1:1" assertion are in the previous post. |
|||
|
|
|
12-18-2010, 12:43 PM
Post: #23
|
|||
|
|||
|
RE: An attempt to structure the field.
Best to think of the IDONS Identifier much like an IP dotted quad address. It's there, but under normal circumstances most users don't see it, use it directly, or have to worry about it the vast majority of the time.
--Lauren-- Lauren Weinstein [email protected] GCTIP Founder |
|||
|
|
12-18-2010, 02:01 PM
Post: #24
|
|||
|
|||
RE: An attempt to structure the field.
(12-18-2010 12:30 PM)Joe Wrote: I was disagreeing with rev412's assertions that A) what goes in the host part of an email address or URL is the Identifier; and B) the mapping of Identifier -> Address is 1:1. Whatever goes in the host part of an email address or a URL needs to be the fixed name of a host. That is, it's the name you can give out to people and it doesn't change when you change Internet service providers or name service providers. It's a name that is going to be translated with high reliability to the IP address of the host you mean and it will do so with no further human interaction. If you make that name be human friendly, then it's going to be populated with words that are trademarks. Some have argued that the trademark problem isn't worth solving. I disagree; I think it is worth addressing this long-standing problem. However, just because I argue for putting a non-friendly name in the host of of URLs and email addresses does not mean that I think users ought to be exposed to them. Just as we've added a translating layer on top of IP addresses so that users don't have to deal with IP addresses directly, first hosts.txt and now DNS, so I think a good user interface would show user friendly names, not the binary gibberish that a proper database key is likely to look like. I note that email systems are already starting to do this. I see them often display a nickname from my address book for any email addresses listed there rather than showing me the raw 822 address. As for the 1:1 thing, you're completely correct. I was trying to convey the idea that given an Identifier it would map to the IP address of a single host. Yes, that host might have multiple IP addresses. We probably should include the ability for a name which is really a distributed service to return the addresses of any of the servers that can provide the service. And on the other side, of course a host may have more than one name or Identifier. So I was just wrong to say it was 1:1. |
|||
|
|
|
12-18-2010, 03:43 PM
Post: #25
|
|||
|
|||
|
RE: An attempt to structure the field.
There is no reason for an identifer to map to a single IP address, any more than it is necessary for a domain name to map to a single IP address. An identifier "merely" needs to convey enough information to access the authoritative servers that contain the detailed breakdown of servers and IP addresses for a given entity, much as "nameserver" listings under conventional DNS do now. But of course, nameserver info in DNS is centrally based, and in IDONS it would not be.
And again, I believe you are misunderstanding the fundamental nature of most Internet-based trademark disputes. They are not the result of mere name use in most cases of concern to us, but result from competition for restricted domain name space, which would not exist under the IDONS model. More properly, these are not trademark disputes per se typically, but disputes over name usage under the jurisdiction of the UDRP. --Lauren-- Lauren Weinstein [email protected] GCTIP Founder |
|||
|
|
|
12-18-2010, 05:51 PM
Post: #26
|
|||
|
|||
|
RE: An attempt to structure the field.
I never meant to imply that an Identifier would map to only a single IP address. Really. Truely. Honestly. I was horribly mistaken in saying 1:1 mapping in trying to say what I was trying to say. I take it back again. Undo, undo, undo.
At some point in the naming system there needs to be a name that identifies a host. That name wants to be persistent and globally unique, thus suitable for being used as a key into whatever lookup scheme is devised. That's the important name and the translation of that to an IP Address is the important mechanism. If that name is human friendly words, there will be disputes over who gets the "good ones". There's not really any practical restriction to the size of the namespace in the DNS. The restriction is there because everyone, worldwide, wants to be in a second-level domain. So there's a fight over who gets apple.com (or peta.org, oh that was funny). Neither would accept apple.freds-naming-service.weekendwarrior.org. Someone thought that .biz was going to make things better; the two Apples could have apple.com and apple.biz. Yeah, right. If you use words as the key to your database lookup, you're going to have the trademark problem. The shorter labels are going to be considered prime real-estate. And yes, I understand that most disputes aren't really trademark disputes as such but that's a convenient label by which to refer to the problem. |
|||
|
|
|
12-18-2010, 07:13 PM
Post: #27
|
|||
|
|||
RE: An attempt to structure the field.
(12-18-2010 05:51 PM)rev412 Wrote: I never meant to imply that an Identifier would map to only a single IP address. Really. Truely. Honestly. I was horribly mistaken in saying 1:1 mapping in trying to say what I was trying to say. I take it back again. Undo, undo, undo. I believe you, dude. :-) We're good here. (12-18-2010 05:51 PM)rev412 Wrote: At some point in the naming system there needs to be a name that identifies a host. That name wants to be persistent and globally unique, thus suitable for being used as a key into whatever lookup scheme is devised. That's the important name and the translation of that to an IP Address is the important mechanism. If that name is human friendly words, there will be disputes over who gets the "good ones". We still disagree here, though. Although persistence is always nice, names will still come and go. But the big deal is that there's no requirement for globally unique Names. If I call my computer (Joe-Comp), then everyone associated with me in my various communities (Chess) or (Work) or (School) should be able to resolve (Joe-Comp). But at the same time, there's no reason you shouldn't be able to name your computer (Joe-Comp) if you want to without conflicting with my computer's name. The gotcha is that transitioning to locally (rather than globally) unique names introduces the problem of how you can resolve my computer's address if you're not in one of my communities. Here we'll rely on two points: 1) There's a very good chance that you'll never need to resolve my computer name and it simply doesn't matter. This will hold for the vast majority of cases. 2) If there is a real need for you to resolve my computer name, you should be able to it by my community associations, e.g. (Bay Area Chess)(Joe-Comp) or (University of X)(Joe-Comp). This is similar to a DNS FQDN. I'll call it an IDONS MQN (More Qualified Name). (12-18-2010 05:51 PM)rev412 Wrote: There's not really any practical restriction to the size of the namespace in the DNS. The restriction is there because everyone, worldwide, wants to be in a second-level domain. So there's a fight over who gets apple.com (or peta.org, oh that was funny). Neither would accept apple.freds-naming-service.weekendwarrior.org. Someone thought that .biz was going to make things better; the two Apples could have apple.com and apple.biz. Yeah, right. Agreed. This is the crux of the DNS namespace problem: A) Everybody wants a 2nd level domain name; and B) within the same TLD, 2nd level domain names must be unique. (12-18-2010 05:51 PM)rev412 Wrote: If you use words as the key to your database lookup, you're going to have the trademark problem. The shorter labels are going to be considered prime real-estate. Once the transition is made to locally unique names, this becomes much less of a problem. - Joe |
|||
|
|
|
12-18-2010, 07:49 PM
Post: #28
|
|||
|
|||
|
RE: An attempt to structure the field.
Joe is homing in on the class of paradigm I have in mind. I would add that the issue of "community discovery" as described above is where I would expect search engines, directories, and other similar players to have major roles.
--Lauren-- Lauren Weinstein [email protected] GCTIP Founder |
|||
|
|
|
12-18-2010, 09:36 PM
Post: #29
|
|||
|
|||
|
RE: An attempt to structure the field.
The community naming sure looks a whole lot like a two-level hierarchy to me. I'd guess the difference is that those community names also don't have to be globally unique. How do you handle the naming conflicts? We have (Apple)(Joe-Comp) and (Apple)(Joe-Comp). And just imagine how many communities called (My Friends) there would be.
I'm actually in favor of this idea of communities. I like that they're essentially a flat space (as far as I can tell), that all communities exist on the same level in the system, and they're administered locally (I'm reading a bit between the lines here and maybe projecting a bit but I think that's the idea). But I still think you're going to end up needing a way to name those communities reliably. I think people are going to want to be able to send an email address or a URL to someone and expect that it'll just work. I don't know how to do that without globally unique and reasonably persistent names of some sort. |
|||
|
|
|
12-18-2010, 11:32 PM
(This post was last modified: 12-18-2010 11:33 PM by Joe.)
Post: #30
|
|||
|
|||
|
RE: An attempt to structure the field.
Not a two-level hierarchy, but rather associations. The community names don't have to be unique since the number of associations is arbitrary. To use your example, (Music companies)(Apple)(Joe-Comp) and (Orchards)(Apple)(Joe-Comp) would resolve the conflict. Or if I'm not sure which (Apple), but I know that you work there I might use (rev412)(Apple)(Joe-Comp) or even just (rev412)(Joe-Comp).
The way I see it, IDONS name resolution will be similar to DNS forwarding, but with a TTL and a distance. If you send a request to resolve (Joe-Comp) to an IDONS server, it will go through the following (high-level) steps: 1) If it can directly resolve the name, return the MQN (More Qualified Name) with a distance of 0, otherwise... 2) If it can resolve the name via cache, return the cached MQN and distance, otherwise... 3) Decrement the TTL. 4) If the TTL is 0 return "Name Not Found", otherwise... 5) Forward the request with the decremented TTL to all associated IDONS servers. 6) Discard all "Name Not Found" responses. 7) If there are no remaining responses, return "Name Not Found", otherwise... 8) Sort the responses by distance and increment the distance for each response 9) Prefix its (Name) to each MQN, and return the set. There should also be logic included to dampen forwarding back to an IDONS server that is currently resolving the same request. The client will examine the final response set and decide the final result based on distances, history, Bayesian filtering of each community name, etc. As long as I'm describing the client side, I'll go ahead and say that I'm very reluctant to introduce any kind of a client interface as mentioned in other parts of this discussion board. There's a *lot* of name resolution that happens on servers where nobody is at the keyboard (or where there isn't a keyboard at all). I have every confidence that the client will be able to return reasonable results without making Grandma answer name resolution questions. - Joe |
|||
|
|
|
« Next Oldest | Next Newest »
|
