At 09:09 PM 7/29/2002 -0700, Peter Deutsch wrote: >I believe it's time the >IETF recognizes that it's time to move beyond what are >really the politics of ICANN and focus on the technical >issues surrounding extending the current technologies to >make them more useful. If we do that without touching the >legacy systems for now, fine but this would imply the need >to set up some alternative roots for experimentation and >proof of concept. peter, I would suggest that exploration need not require an "alternate root" if the extension is within the framework of DNS (new class of object for example). John Klensin and others have expressed themselves on the merits and weaknesses of that approach. What is important, I think, is to avoid the creation of conflicting naming schemes within a given framework. However, if we begin by asking the question, "what objects need identifiers that we do not or cannot now identify?" we might indeed discover alternative identifier mechanisms. It would be helpful for a variety of operational and probably technical reasons for any such new scheme not to conflict syntactically with existing ones, I believe. The Directory-service notion is one dimension in which to explore. Keywords are another although thus far they have understandably required a context in which to be interpreted since they all appear to have a common and simply syntax (cf: AOL keywords, Real-Names keywords, etc). The DNS provides a method for associating a relatively simple syntactic construct with a host on the Internet (or an internet). These names can be embedded within the larger construct of URLs to refer to objects and processes that exist on (in?) those hosts. One might want a richer vocabulary for referencing objects (cf. Bob Kahn's Handle System) in which the identifier is associated not only with an object but also with a variable amount of meta-data about the object's ownership, accessibility, etc. It strikes me as a useful principle to try not to make things like DNS more complex in seeking to explore and invent these new concepts if only to avoid making existing and relatively simple things more complex. Domain names seem to work pretty well for hosts and WWW URLs, but in the latter case, a broken link caused by the disappearance of an object at a host or even the host itself makes the longevity of the binding less than satisfactory. Perhaps other methods of expressing and implementing the binding of name to object would be useful, but I would argue against making DNS more complex to accommodate, if this extension also made the pre-existing use of DNS more complicated. The experience with the notion of Internationalized Domain Names has made clear how dependent DNS is on the simplicity of the USASCII encoding and how hard it is to make what one might have thought would be a simple extension to a richer range of character encodings. So to reiterate, I believe it would be a very useful exercise to catalog the various name/thing binding notions and to try to articulate what additional functionality we might wish to achieve, then examine options for achieving them without breaking or making unnecessarily more complex our existing binding tools. That view suggests that "alternate root" may not be the right starting point, if by that term one means alternate root of the same DNS mechanism we already have. The syntactic and potential semantic confusion (e.g. using an identifier in the wrong context) does not seem worth the price. However, a new identifier space whose context can be clearly placed through syntactic clues, might provide a platform for exploration without or at least with less disruption. Vint