Information Document 18-E

ITU-T Study Group 2May 2002

QUESTION: Q.1/2SOURCE: TSBTITLE: UNIVERSAL COMMUNICATIONS IDENTIFIER (UCI)

(by Mike Pluke, ETSI)

The purpose of this document is to provide background information on the Universal Communication Identifier code.

ETSIUniversal Communications Identifier (UCI)

Mike Pluke

Castle Consulting Ltd.Leader of ETSI Specialist Task Forces 180 & 200

The Universal Communications Identifier(UCI)

the rationale for an identifier such as the UCI;

the key drivers that have shaped the UCI and its support environment;

an explanation of the framework that supports UCI;

a brief comparison with other similar initiatives of interest to ITU-T SG2;

an overview of the development of the UCI within ETSI;

the ITU-T SG2 issues?

I will cover:

Today’s identifier complexities

Which of these is Mike Miles?

Some important user requirements (I)

have a single communication identifier for every significant life role;

check the authenticity of the description of the people you communicate with (or see when they use aliases);

keep your identifier when adding services or changing suppliers;

have control over the release of your own information.

You should be able to:

should be associated with you (or your role) - not hardware, services, 3rd parties, or service suppliers;

should provide a meaningful description of you (in a way you wish to be described);

can be added to communications networks and services with the very minimum amount of re-engineering.

A UCI:

Some important user requirements (II)

Nothing currently fits the specification

Current identifiers were judged against the user requirements developed by ETSI Specialist Task Force STF157

None of today’s identifiers (e.g. phone numbers, email addresses, IM addresses) meet these requirements

Other identifier proposals (e.g. IETF URNs) also fail to meet the requirements

It was concluded that a new identifier would be needed

Support for a new identifier

A new identification scheme with new capabilities needs a new support environment

The new support environment should not mean large changes to existing systems

The identifier support environment must be considered as an overlay to existing communications systems

Existing support environment

Support for communications largely comes from the networks, protocols and applications associated with individual communication types (e.g. telephony networks, SMTP mail protocols)

Users can control their telephone communications using supplementary services

Users can control their email communications using mail redirection and filtering in email clients

Instant messaging systems allow control by manual selection of availability settings and with “buddy lists”

The types of controls and the range of different control mechanisms are as varied as the different types of communication

Users cannot cope well with such a range of controls

The UCI support environment

the identity (UCI) of people attempting to communicate with the user;

the date and time when communication is attempted;

the urgency of the communication;

whether the originator of a communication has a work or a personal status;

the user’s preferences for how they wish to be reached (which services and which terminals).

The UCI support environment allows the control of communications based upon at least the following:

The UCI

Is a 3-part data structure

A unique role identifier (unroid) – numeric – E.164- essential to establish communication

A persona element (persel) – not unique – alphanumeric description of UCI owner- most useful for the end-user

A status element (statel) – multiple status indications giving key details about the UCI and its owner – helps the user decide the most appropriate way to communicate

Only the unroid is required in all “signalling” flows

UCI elements

The Personal User Agent (PUA) – this acts on the user’s behalf in controlling communication set-up

The PUA contains the user’s preferences and rules The PUA only talks to its owner, other PUAs and SAs

The Service Agent (SA) – this is the interface to existing networks and services

The SA only talks to PUAs and its own network/service

Terminals, identification mechanisms, etc.

Relationship between UCI elements

PUA Provider 2

P U A

P U A

P U A

P U A

P U A

Network Infrastructure

Service Provider / Network Operator 1

User 1/ Terminal A

PUA Provider 1

P U A

P U A

P U A

P U A

P U A

P U A

User 4/ Terminal B

User 2/ Terminal A

User 3/ Terminal A

2 1 4 3

User 4/ Terminal A

Network Infrastructure

Network Infrastructure

Service Agent

Service Agent

Service Agent

P U A

Service Provider / Network Operator 2

Service Provider / Network Operator 3

Simplified UCI operation

= registration association

Simplified UCI operation

X

X

Simplified UCI operation

Jane selects Dan’s UCI and sends it

Simplified UCI operation

Initiatives similar to UCI (I) - UPT

Like UCI, UPT does: have a single identifier for a range of services; assume a common interface for controlling a range of

services,

but, UPT does not: have any concept of identifying the true name of the

UPT subscriber; allow the authenticity of any association between a

personal name and a UPT identifier to be verified; integrate non-telephony services such as email very

effectively.

Initiatives similar to UCI (II) - ENUM

Like UCI, ENUM does: have a single E.164 number associated with a range of

services; have a global scope.

but ENUM does not have any concept of identifying the true name of the ENUM

subscriber; allow the authenticity of any association between a

personal name and an ENUM identifier to be verified; allow individual communications identifiers to be hidden

(as the NAPTR record is public) – a spammer’s charter!; provide inherent protection from distributed denial of

service (DDoS) attacks (as the NAPTR record is public).

Intercommunication in UCI is strictly controlled between Users, their PUAs and SAs – this should help eliminate threats such as DDoS

UCI work in ETSI

STF157: Looked at user requirements, the definition of a UCI, and a first look at a UCI architecture;

STF180: Is defining the UCI architecture in more detail, is specifying usage scenarios and is examining security issues from the end-user’s perspective

STF199: Is looking at implementation issues across communications platforms and security from the service provider perspective

STF200: Is looking at the usability issues of end-user control of their communications environment

Issues for ITU-T SG2

Allocation of identifiers – in particular the globally unique E.164 “unroid” element of the UCI

Service aspects of UCI – it is multi-service, it is global

…

Thank you

Contact: Mike.Pluke@castle-consult.com