4 Detailed service description

29.199-133GPPOpen Service Access (OSA)Parlay X web servicesPart 13: Address list managementTS

The present document defines two related interfaces, one to manage the groups themselves – creation, deletion, query and access right management. The second interface manages the members within a group, supporting add, delete and query operations.

Addresses are not created using this service, they must already exist.

4.1 Group URI format

A group URI is consistent with the style defined in RFC 2396 [7], supporting the following URI style which is used in schemes such as sip and mailto:


The group URI consists of the following discrete elements:

Scheme: selected by the provider of the group URI.

Group name: following the conventions of RFC 2396 [7].

Suffix: may be added by Service Provider (if allowed by creation operation) to create a unique name when the Prefix + Group name already exists.

Sub-domain: defined by the requester, this is contained within the domain provided by the service provider.

Domain: defined by the Service Provider, and cannot be specified by the application.

This definition of a group URI enables flexibility on the part of the Service Provider and the Requester, while ensuring unique groups are created and providing transparency of implementation of group storage.

The following are some group URI examples.

  • sip:salesteam@sales.acme.anytelco.com
  • sip:salesteam1@sales.acme.anytelco.com
  • mailto:fieldservice@cityofaustin.anytelco.com
  • group:mailroom@bldg001.acme.anytelco.com

These examples show (1)(2) use of prefix to create unique names, (1)(3) use of different defined schemes, and (4) use of a service provider defined scheme.

4.2 Address list usage in services

When a service has a requirement to support groups of address lists, it may satisfy this requirement by utilizing network managed groups. The group URI is passed to the service, and this group URI is resolved to the set of URIs contained within the group. If one or more group URIs are provided in a set of URIs to a service, the service will replace each group URI with its set of contained URIs, and the service processing will apply to the unique union of URIs generated.

If supported by the service policy, zero or more of the set of URIs contained within a group may be themselves group URIs, which would also be resolved. Thus, in this case, the list of URIs that the service would process would be the union of individual URIs (as a set with no duplicates).

Unless specifically defined in the semantics of a service, the expected semantic for the results of a service operation will be presented as the results for the set of URIs as processed (the union of non-group and group provided URIs), without group URIs included in the result. This eliminates a variety of complexity issues including duplicate URIs in multiple groups and the differences between a group URI and a URI referring to an endpoint.