** GUP main functionalities **

In this section we detail the various functionalities identified in document
TS << put doc number here>>.

	      [[ put picture here ]]
	

	-- "Protocol Handler" functionality
the role of the protocol handler functionality is to support the protocols
accepted by the various data stores in order to make data stores
available to the GUP infrastructure for queries and updates.
In particular, the implementation details of the data stores are
hidden from the GUP infrastructure.
As examples, LDAP, SOAP, AT are protocols that may be needed to
interface with existing data stores.

	-- "Data Transformer" functionality
the role of the data transformer functionality is to map data stored in the
data stores to the GUP data format (XML) and vice versa.
For incoming requests (read) the data transformation will map data
stored in the data store into the XML representation defined by the
GUP Schema. For incoming updates (writes), the data transformation
will map XML GUP data into the data format used in the data store.

	-- "Component Broker" functionality
the role of the component broker functionality is to provide application
with information about which data store to use to retrieve a user
profile component.

Note that for a given component, there might be more than one location
(e.g. in the case of replication).

	-- "Component Register" functionality
the role of the component register is to permit data stores to register
the location of a given user profile component.
This information will be used by the component broker.

Note that implicitly the "component broker" and the "component
register" need to share a "mapping table" which maps user profile
components into data stores.

	-- "Authorization & Authentication" functionality
the role of the AA functionality is to offer a suite of authentication and
authorization mechanisms.
This functionality will be used by applications to authenticate to the GUP
infrastruture in order to query and/or update use profile components.
This functionality will also be used to define how profile components will
be accessed.
	
Note: we argued wether or not authentication is only required on the
application side. We raised this issue to SA1.

	-- "Synchronization" functionality
the role of the synchronization functionality is to support the need for
replication of data between network elements (on the Home Network and
the VASP) and UEs.
Among other things, the functionality will need to support the various
synchronization protocols and mechanisms.	
The functionality supports the notions of "master copy" and "slave copy".

	-- "Component Proxy" functionality
the role of the component proxy functionality is to take care of the case
where some data store may not be reachable at all times (e.g. UE
disconnected from the network).
The component proxy provides means to access a user profile component
in the case where the location of this component (as returned by the
"component broker" is not reachable). 	

	-- "Point of Access" functionality
the role of the point of acccess functionality is to offer a single point
of entry for applications which need to interact with GUP.   

	-- "Privacy Control" functionality	[TO BE DISCUSSED]
the role of the privacy control functionality is to allow the user to
define how her user profile information is going to be accessed.  This
functionality involves the management of user policies/preferences related
to the "privacy shield" and the enforcement of such policies.


** GUP enablement **

In this section we describe how a data store can be made part of GUP
by implementing the functionalities required by the GUP reference architecture.

The "GUP enablement" of a given data store (e.g. HLR, location server,
etc.) requires the following actions:

1- implement the protocol handler functionality for the given data store
The protocol handler will permit to access the data store using the
protocols understood by the data store (e.g. LDAP protocol, SOAP, AT commands).

2- implement the "data transformation" functionality for the given data store

3- have the data store register the component to the "component register" 
In order to make the user profile information in the data store
available to GUP, the data store needs to register the component to
the GUP "component register". This information will be used later by
the "component broker" to tell applications where to look for profile
components.

** GUP data stores **

In this section we give some example of GUP data stores:

In the Home Network:
   - HLR
   - HSS
   - GMLC (location)
   - MMS relay server

In the VASP network
   - calendar information
   - e-wallet
   - address book

In the UE
   - terminal settings