Grid Identifiers Spec

From Second Life Wiki
Jump to: navigation, search

Open Grid Identifier Notation

Draft 1
June 2008
Notice: This draft is for public comment.
David Jung (Cenji Neutra) Apez Corp cenji.neutra AT
Copyright 2008, Apez Corp. All rights reserved.
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. See for details.
The explosion in the number of virtual worlds, particularly those based on the OpenSimulator effort inspired by Second Life®, has given rise to the need for a universal and widely adopted notation for identifying distinct virtual worlds and their components. This document details such a scheme.
As of June 2008, this document is a work in progress. Community input is solicited in order to mold this scheme into one that many parties agree to adopt and support.
This proposal is a 3rd-party community effort and it's presence on the Second Life wiki in no way implies the endorsement or participation of Linden Lab or its employees in any official capacity.
Please use the Discussion page for comments.

UPDATE: Please see the Discussion first.


To illustrate the need for a standardized notation for identifying virtual worlds and their major components, we look to analogy with the early development of the Internet itself. In the early days of the Internet, each host had a host file, which was simple a text file that contained a list of the known Internet connected hosts, their IP addresses and host names. The hosts file was centrally maintained, manually updated and distributed to all Internet hosts. It served two distinct purposes:

  • It provided a way to map human readable host names to IP addresses
  • It served as a place where people could look to see what hosts existed on the early Internet

As the number of hosts on the Internet grew, it became apparent that a centralized mechanism would not be adequate as the Internet grew. From that realization grew the Domain Name System (DNS) and search engine services. The DNS serves as a distributed implementation of a look-up service and search engines provide a way for people to discover what is available on the Internet (or Web).

Currently, there likely only a hundred or so long-lived persistent virtual worlds of significant size operating. If virtual worlds are to become a significant piece of the future of the Internet, we would expect their numbers to grow significantly, as has happened with the early Internet.

What this document details is a simple notation to identify major components of virtual worlds, analogous to the way host names identify web-sites on the modern World Wide Web. For example, "net.mygrid.main" represents a valid grid identifier.

How those names are used, the services that may exist to map identifiers to hosts or other resources related to the identified virtual world components and how the mappings are managed, is beyond the scope of this document.

It should be noted, however, that one practical motivation for the development of this notation was a need for it during the development of a lookup service that, among other things, will provide a (centralized) service for mapping identifiers of known virtual worlds to their corresponding resources. For example, mapping SecondLife and OpenSimulator based grid identifiers to their corresponding initial login URL.

Grid Identifiers

Identifier Notation

The identifier notation comprises a simple string of period separated labels, like the subdomains of DNS domain names. Each label should conform to the standards set forth for domain names (see RFC-1034). For example (and informally):

  • Labels are comprised of ASCII characters A-Z, a-z, 0-9 and the dash "-" character
  • Labels are compared case-insensitive
  • Internationalization of labels should be handled by applications according to Internationalizing Domain Names in Applications (IDNA; see RFC-3490)
  • The complete sequence of 'dotted' labels is referred to as a Grid Identifier or GI.
    • While the identifiers are intended to be used to identify other major components of virtual worlds for which the term 'grid' doesn't necessary technically apply, the terminology was chosen to closely match popular usage of the underlying lay concept being captured in order to facilitate dissemination of the idea.

The identifier space

  • The root of a GI is the left-most label (before the first period).
    • Like DNS domain names, OGI identifiers are intended to form a hierarchical system. Whereas the root or terminal label for a DNS domain name is at the right of the domain, the left-most GI label is the 'root' in order to avoid confusion with domain names.
  • The only allowable root labels are the top-level DNS subdomains (TLDs), such as "com", "net", "org", "biz" etc.
    • These could potentially be expanded or even diverge from the set of TLDs in the future, but it isn't envisioned to be necessary in the medium term.

Identifier types

  • Grid identifiers are divided into types "grid", "region" and "agent".
    • GIs of all types occupy a single name space (an identifier must be unique regardless of type)
    • The number of types can be expanded as necessary
  • A "region" type GI must have the letter "r" as the last character in the right-most label
    • Region type identifiers are used to identify that part of a virtual world responsible for simulation of the virtual environment
    • In SLGOGP terminology this is known as the "region domain".
    • While not mandated, it is suggested that the right-most label end in "-r".
  • An "agent" type GI must have the letter "a" as the last character in the right-most label
    • Agent type identifiers are used to identify that part of a virtual world that encompasses the representation of agents and their associated resources (typically agents who act in the world on behalf of people)
    • In SLGOGP terminology this is known as the "agent domain".
    • While not mandated, it is suggested that the right-most label end in "-a".
  • A "grid" type GI cannot have the last letter of the right-most label end in "a" or "r" and cannot contain a dash "-"
    • Grid type identifiers are used to identify an independent virtual world as a whole. This would typically comprise both the simulation of the virtual environment and a default service for the representation and management of avatars.

For example, valid OGIs are "com.secondlife.agni" (grid GI), "biz.apez.grid-a" (agent GI) and "org.osgrid.main-r" (region GI).

Expected practice

This section does not form part of the OGI specification, but appears in order to inform implementers of the ways in which GIs are envisioned to be used.

  • Due to the obvious mapping between GIs and DNS domain names via reversal of the label ordering, it is expected that an ideal initial mechanism for assigning authority over GIs by any name mapping service providers would be to require control over the corresponding DNS domain insofar as there exist corresponding subdomains.
    • The requirements for domain control 'proof' could in turn piggy-back on the established 3rd-party identity certifiers, such as those established for issuing domain SSL certificates.
  • Except where a precedent already exists, region type GIs are expected to always end in "-r" and agent type GIs in "-a".
  • It will be common for a grid GI to have corresponding agent type and region type GIs that are identical except for a "-a" and "-r" suffix respectively.
    • For example, a reasonable guess as to the agent type GI for the grid "biz.apez.grid" (if one exists) would be "biz.apez.grid-a".
  • Typical uses for GIs might be:
    • Lookup of common resources associated with grid, such as the region GI, 'defacto' agent GI, web-site address, standard services provided etc
    • Lookup of common resources associated with agent GIs, such as the login URL for SLGOGP agent domains.
    • Machine 'readable' representation for configuration information
      • Such as UI mappings between human readable grid names, such as "Second Life" and the associated GI to be used with lookup services, for presentation in user agent clients
    • Lookup and discovery of grid inter-component trust relationships, such as which other agent services a particular region service allows agents to login from
      • For example, determining that org.osgrid.main-r allows login and inventory asset sharing between avatars from org.osgrid.main-a and com.secondlife.agnia