[Gzz] Informal namespace for pseudo-random identifiers

[B. Fallenstein]

Hello everyone,

attached, please find an application form for an informal URN namespace 
containing randomly generated ids. (Background: Our research group is 
developing a program, Gzz, which assigns global identities to objects 
created at runtime; as there is no guarantee that we are on the 'net or 
have been assigned a global client id or some such beforehand, we have 
to have a purely algorithmic way of creating identities.)

Any comments would be appreciated. It would be helpful if you could keep 
the gzz-dev mailing list in the cc: when replying.

Thanks,
- Benja

   Namespace ID:
      To be assigned.

   Registration Information:

      Version 1
      Date: <insert when submitting to IANA>

   Declared registrant of the namespace:

      Name:    University of Jyväskylä Hyperstructure Group
      Address: Dept. of Mathematical Information Technology
               University of Jyväskylä
               PO. Box 35 (Agora)
               FIN-40014 Jyväskylä
               Finland

      Contact: B. Fallenstein <address@hidden>

   Declaration of syntactic structure:

      The identifier structure is:

         urn:<assigned number>:<random number>[:<local part>]

      where <random number> is a string consisting of at least 26 of the
      following characters: Lowercase (a-z) and uppercase (A-Z) letters,
      digits (0-9), the hyphen (-) and the plus sign (+). If present, the
      optional <local part> is an arbitrary string of characters allowed
      in a URN without escaping.

      The <random number> is a pseudo-random number (160 or more bytes)
      encoded in base64 [RFC-2045]. As slashes (/) are not currently allowed
      as part of URNs, hyphens (-) are used instead. The padding
      character (=) is not used.

      The <local part> is a counter, intended to allow
      re-use of a pseudo-random number; this allows a program to generate
      only one pseudo-random number per session, only incrementing a counter
      each time a new identifier is generated. Compression of documents
      containing many different identifiers of this form is improved if
      some of the identifiers share the <random number> part.

      Use of the <local part> for anything except counting is
      strongly discouraged.

      Examples of possible URNs in this namespace include:
          urn:urn-n:-URS6S2A3+chjjHVlTkQ9KT5nu
          urn:urn-n:JtTCacwJ1e1N0yqTULRG7C1GLq:4
          urn:urn-n:Od4rB2QNOLt1e5wITWSJ+9U2Ve+Zon6N3d:17

      (In these examples, urn-n is a placeholder for the namespace id
      to be assigned by IANA. The examples are not URNs in actual use.)

   Relevant ancillary documentation:

      RFC 2045 [RFC-2045] defines the base64 encoding. Note that the
      hyphen (-) is used instead of the slash (/).

   Identifier uniqueness considerations:

      Provided that the source of pseudo-random data used is good enough,
      it can be reasonably assumed that identifiers are unique
      (for example, SHA-1 [FIPS-180-1] also assumes uniqueness of 160 byte
      identifiers).

   Identifier persistence considerations:

      Users must not re-assign an identifier. This is not a problem, since
      they are free to create new identifiers at any time.

   Process of identifier assignment:

      Identifiers can be informally assigned by users at any time. There is
      no central authority assigning identifiers or specifying meaning for
      them. New identifiers are created when a user or program wants to
      name some entity globally without contacting a naming authority first.
      Examples include RDF resources [RDF] and XML namespace names
      [XML-namespaces]. Users specify meaning for identifiers by starting
      to use them, for example in an RDF graph.

      If local parts are not used, an identifier is created by generating
      160 or more bits of pseudo-random data from a trusted source and
      encoding them in base64, using the characters allowable in the
      <random number> part as defined above. If local parts are used,
      the <random number> part is generated beforehand (usually when
      the program generating the identifiers is started, or when the first
      identifier in a particular session is created); each time a new
      identifier is needed, a counter is incremented and used as the
      <local part>.

   Process for identifier resolution:

      None specified.

      Note that the namespace is primarily meant for resources that are only
      named, not resolved (such as XML namespace names).

   Rules for Lexical Equivalence:

      The normal rules for lexical equivalence of URNs apply.

   Conformance with URN Syntax:

      No special considerations.

   Validation mechanism:

      The namespace-specific string (nss) must abide the following
      ABNF [RFC-2234] grammar:

         nss           = random-number / (random-number ":" urn-string)

         random-number = 26*base64

         urn-string    = ALPHA / DIGIT / other

         base64        = ALPHA / DIGIT / "+" / "-"

         other         = "(" / ")" / "+" / "," / "-" / "." /
                         ":" / "=" / "@" / ";" / "$" /
                         "_" / "!" / "*" /  "'"

   Scope:

      Global.



   References:

      [FIPS-180-1]
         NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
         http://csrc.nist.gov/fips/fip180-1.txt (ascii)
         http://csrc.nist.gov/fips/fip180-1.ps  (postscript)

      [RDF]
         RDF Model and Syntax.
         http://www.w3.org/TR/1999/REC-rdf-syntax-19990222

      [RFC-2045]
         Freed, N., and Borenstein, N., "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet
         Message Bodies", RFC 2045, November 1996.

      [RFC-2234]
         Crocker, D., and Overell, P., "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

      [XML-Namespaces]
         Namespaces in XML.
         http://www.w3.org/TR/1999/REC-xml-names-19990114