Presentation on theme: "Information Document 18-E ITU-T Study Group 2 May 2002 QUESTION:Q.1/2 SOURCE:TSB TITLE:UNIVERSAL COMMUNICATIONS IDENTIFIER (UCI) (by Mike Pluke, ETSI)"— Presentation transcript:
Information Document 18-E ITU-T Study Group 2 May 2002 QUESTION:Q.1/2 SOURCE:TSB TITLE:UNIVERSAL COMMUNICATIONS IDENTIFIER (UCI) (by Mike Pluke, ETSI) The purpose of this document is to provide background information on the Universal Communication Identifier code.
ETSI Universal 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:
Todays 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 todays 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 users 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 users behalf in controlling communication set-up The PUA contains the users 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.
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 spammers 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-users 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
Your consent to our cookies if you continue to use this website.