{{{
#!comment
NB! Make sure that you follow the guidelines: http://trac.posccaesar.org/wiki/IdsAdiEditing
}}}

[[TracNav(TracNav/RdsWip)]]

= RDS/WIP Identifier Generator =

There has long been a need for an identifier generator in this project, and so we now have one with a [https://secure.ids-adi.org/registry?registry-op=ui user interface here].

= Features =

 * Allocates identifiers in a given name space (you supply the base URI ending in #).
 * All identifiers are stored in their name space in a single triplestore.
 * All identifiers have the form RNNNNNNNNNN where NNNNNNNNNN are digits and R is literal.
 * NNNNNNNNNN will never start with a zero.
 * NNNNNNNNNN will never contain a sequence NNN of three of the same digits.
 * NNNNNNNNNN will never contain any digit more than three times.
 * NNNNNNNNNN is allocated with a strong random number generator (PRNG seeded from an RNG).
 * The date of the allocation is recorded.
 * Allows explicit binding to other URIs for reconciliation.
 * There is intentionally no support for allocating "sequences" of identifiers.
 * There is intentionally no support for allocating "bulk" identifiers.
 * Uses HTTP CGI GET for operations and XML for results.

= Principles =

 * No one can choose their identifier.
 * No one can inadvertently create implicit knowledge by "owning" a block of identifiers - knowledge should be explicit, reservation blocks denied.
 * No one can create "de facto" maps by allocating sequences that relate to other existing identifiers (again, to avoid creating implicit knowledge).
 * Identifiers are of the same length (at least until "slots" become too sparse to find quickly, which will likely happen when its about 80% full).
 * Prized numbers (like 1000000000 or 9999999999) will be never be allocated.
 * While <base-uri>RNNNNNNNNNN is already recorded, it will go back and try another number - so it can never acquire duplicates (synchronization protects against race conditions).
 * Supports machine interfacing.

= Design Choices =

 * Identifiers exist in two stages: created and fixated.
 * In the "created" stage, only the owner can add bindings,
   or release the identifier.
 * In the "fixated" stage, no-one can release the identifier
   and any authenticated party can add bindings.
 * There's no way to "unfixate" an identifier -
   it is permanently published.
 * There is no "search" for existing identifiers - this
   service is not intended to be an index of definitions -
   users are intended to utilize the base URI endpoint for
   that sort of task.

= Governance =

 * Any abuse of the system (ie. trying to circumvent the principles) should result in suspension of the service for the offending user and revocation of the abusing allocations.

= Usage Policy for RDS/WIP =

Since this was intended for the RDS/WIP, but has broader applicability (really for managing IDs of that fixed form in any namespace), then we need to come up with some policies for the RDS/WIP usage of this service:

 * The URI of the service - https://secure.ids-adi.org/registry

 * The protocol - CGI for now.
 
 * Authentication - LDAP on server - user must be in rdswip_registry group.

 * The base URIs to allocate identifiers against appear on the [wiki:RdsWipDomains] page.

= Future Features =

 * In the "created" state, the identifier will only be visible
   to the grant list (by default, just the creator).

 * There will be three separate log trails: per user,
   per identifier and for the whole registry.

 * Log items for identifiers in the "created" state will only
   be visible to the creator.

 * Comments may be able to be added to identifiers
  (only by the grant list).

 * Comments may be able to be added to base URIs.

= Agenda =

 * Do we need to broaden the concept of "prized numbers" (exclusions) to include patterns like 1234567890 or 3838385544?



[[Image()]]