DRAFT- InProgress

 Abstract

Commentary:

The  App Directory (AppD) is a service that provides a financial application definition that includes a trusted identifier(s) and associated metadata.  The information registered as part of an application definition supports discovery, launch configuration, intents and context data supporting the use and interoperability of financial applications.  This proposal recommends use of a distributed or detached model to managing application data servicing, where there are (N) AppD services on a network providing information related to a subset of namespace "zones" that align with the financial application identifiers.  This approach encourages independence, scale and responsive provisioning of application definitions. This is modeled from a subset of the public name service "Domain Name System", which has proven reliable and conceptually fit for discovery.

In order to support the discovery of application data stored in a given directory, name space concepts are introduced to both identify the realm of application definitions and AppD service locations that host data.  In simple terms, there has to be a way of discovering the location of the AppD service itself and the associated application definitions that are available from that service.  

This proposal focuses on defining the following key features to support this need:

• Application data discovery through nested namespace approach. (Note: An expanded definition is required outside this proposal)
• AppD service host discovery implementations should support the following requirements;
  1. Discovery through use of DNS SRV record types (RFC2782 ) - **Preferred 
  2. Federated discovery of URI records between AppD services
  3. Statically defined URI records for use within client applications directly

...

For the purposes of this proposal, application data discovery shall be accessible through a unique application identifier (ID) representing a single application represented by a nested namespace syntax using dot notation (e.g. app.sub.root).  It should be noted that a given AppD service may support multiple application namespace "zones" as part of a standard nested naming hierarchy. 

...

zone name {

_service._proto.name. TTL class SRV priority weight port target.

}

• service: the symbolic name of the desired service.  For AppD service, this

...

• mus be identified as "_appd"
• proto: the transport protocol of the desired service; this is usually either TCP or UDP.  For AppD service _tcp must be used.
• name: the domain name for which this record is valid, ending in a dot.  For AppD service,  the name should directly map to the application identifier domain. 
• TTL: standard DNS time to live field.
• class: standard DNS class field (this is always IN).
• priority: the priority of the target host, lower value means more preferred.
• weight: A relative weight for records with the same priority, higher value means more preferred.
• port: the TCP or UDP port on which the service is to be found. For AppD service, TCP should always be used. 
• target: the canonical hostname of the machine providing the service, ending in a dot.  This would be the host where the AppD service is running. 

For AppD Service the SRV record must use the following definitions:

• service = _appd
• proto = _tcp
• name = must map to the domain of the application identifier . Example:  the name for identifier "app1.appd.foo.com" would be "appd.foo.com"

Federated Services

Static configuration

...