A Framework and Data Model for Queries about Telephone-Related Queries (TeRQ)
draft-peterson-terq-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Jon Peterson | ||
| Last updated | 2012-07-16 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-peterson-terq-01
Network Working Group J. Peterson
Internet-Draft NeuStar, Inc.
Intended status: Standards Track July 16, 2012
Expires: January 17, 2013
A Framework and Data Model for Queries about Telephone-Related Queries
(TeRQ)
draft-peterson-terq-01
Abstract
As telephone services migrate to the Internet, Internet applications
require access to diverse information about telephone numbers. ENUM,
for example, applied the DNS to the problem of finding URIs for
telephone services on the Internet. The intrinsic limitations in the
query/response semantics of the DNS, however, have often been
strained by the requirements for accessing information about
telephone numbers. This document therefore proposes a protocol-
independent framework and data model for querying and responding to
requests concerning telephone numbers and call routing that allows a
richer expression of both questions and answers.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Peterson Expires January 17, 2013 [Page 1]
Internet-Draft TeRQ Framework July 2012
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Peterson Expires January 17, 2013 [Page 2]
Internet-Draft TeRQ Framework July 2012
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of the Framework . . . . . . . . . . . . . . . . . . 7
4. Transport Independence . . . . . . . . . . . . . . . . . . . . 8
5. The Data Model . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Source . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Query Source . . . . . . . . . . . . . . . . . . . . . 9
5.1.2. Query Intermediary . . . . . . . . . . . . . . . . . . 9
5.1.3. Route Source . . . . . . . . . . . . . . . . . . . . . 10
5.2. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Telephone Number . . . . . . . . . . . . . . . . . . . 10
5.2.2. Service Provider Identifier . . . . . . . . . . . . . 11
5.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. Routing Attributes . . . . . . . . . . . . . . . . . . 11
5.3.2. Administrative Attributes . . . . . . . . . . . . . . 12
5.4. Records . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 12
5.4.2. Authority . . . . . . . . . . . . . . . . . . . . . . 12
5.4.3. Priority . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.4. Expiration . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Response Code . . . . . . . . . . . . . . . . . . . . . . 12
6. Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
12. Informative References . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Peterson Expires January 17, 2013 [Page 3]
Internet-Draft TeRQ Framework July 2012
1. Terminology
In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD",
and "SHOULD NOT", are to be interpreted as described in [RFC2119].
Peterson Expires January 17, 2013 [Page 4]
Internet-Draft TeRQ Framework July 2012
2. Motivation
Telephone numbers remain the worldwide standard identifier for
routing calls and text messages over the Public Switched Telephone
Network (PSTN). As identifiers, however, telephone numbers differ
fundamentally from the identifiers commonly used by Internet
applications. Email, the web and native Voice over IP (VoIP) systems
typically use identifiers that rely on the Domain Name System (DNS)
to resolve a domain portion of the identifier to a particular IP
address; commonly, Uniform Resource Indicators (URIs) with a user and
host component serve this purpose. In order to bridge this gap
between the PSTN and the Internet, the ENUM effort specified a DNS
profile for translating telephone numbers into URIs.
While the ENUM approach suffices for simple number translations, more
complex routing and administrative functions can strain the
capabilities of the DNS. Many of these problems result from the
limiting simplicity of the DNS query string. DNS queries have a
fairly rigid syntax oriented towards the resolution of an atomic name
in a hierarchical namespace. Telephone call routing, however, may
require compound queries that operate on several distinct query
elements that are difficult to cast hierarchically. Many of the
complex query/response mechanisms used in the PSTN are not tied
directly to call routing or establishment, such as finding the
caller's name (CNAM) when a call is received. Moreover, the
centralized and authoritative hierarchy of the DNS proved a poor
match for the actual procedures used to route telephone calls. This
led to work on "infrastructure" ENUM, which assumed private DNS
implementations, each of which could give a different answer to the
same request to translate a telephone number depending on who asked,
or other internal factors. The framework of the SPEERMINT working
group, expanding on these requirements, differentiated the mapping of
a telephone number to a target network (the "Look-up Function") from
the mapping made by the originating network to the proper next-hop to
reach such a target network (the "Location Routing Function"). While
the LUF can be centralized and authoritative, the LRF is necessarily
subjective and localized. In the SPEERMINT model, the routing of a
call may involve an intermediate lookup that operates on a Service
Provider Identifier (SPID) rather than a telephone number. Mapping
these capabilities to ENUM requires security and administrative
practices that further complicate its DNS implementation. The
underlying architectural issues that give rise to all these problems
are detailed in draft-iab-dns-applications.
Despite these difficulties, the need for solutions in this space is
pressing, as many carriers worldwide contemplate migrating their
entire PSTN infrastructure onto the Internet within the next decade.
Further pressures come from emerging Internet communications
Peterson Expires January 17, 2013 [Page 5]
Internet-Draft TeRQ Framework July 2012
providers who never invested in PSTN infrastructure in the first
place, but want access to services related to telephone numbers.
These different communities have diverse requirements. In some
environments, there are performance constraints that would require a
very lightweight binary protocol; in others, applications might
prefer human-readable markup languages suitable for interfacing with
existing APIs.
Therefore, this document proposes a reconsideration of telephone
routing and administration services on the Internet based on a
framework that considers queries and responses in an abstract
architecture. This document specifies no particular syntax or
encoding for queries or responses, but instead describes an
extensible data model for the semantics of queries and responses that
future specifications might encode in accordance with application
needs.
Peterson Expires January 17, 2013 [Page 6]
Internet-Draft TeRQ Framework July 2012
3. Overview of the Framework
This framework specifies an abstract query/response protocol that
enables a Client to send Queries to a Service about telephone numbers
or related telephone services. Queries may pass through one or more
Intermediaries on their way from a Client to a Service; for example,
through aggregators or service bureaus. A Client establishes the
Subject of a Query, and optionally specifies one or more Attributes
of particular interest in order to narrow the desired response. When
a Service receives a Query, it performs any necessary authorization
and policy decisions based on the Source. If policy permits, the
Service generates a Response, which will consist of a Response Code
and one or more Records associated with the Subject. The Service
then sends the Response through the same path that the Query
followed; transactional identifiers set by the Client and Service
correlate the Query to the Response and assist any intermediary
routing.
Peterson Expires January 17, 2013 [Page 7]
Internet-Draft TeRQ Framework July 2012
4. Transport Independence
The data model provided for Queries and Responses in this framework
is independent of any underlying transport or encoding. Future
specifications will define Bindings that specify particular
transports and Encodings for Queries and Responses. In some
deployment environments, for example, a binary encoding and
lightweight transport might be more appropriate than the use of a web
protocol. This specification provides a template of requirements
that must be addressed by any encoding scheme.
It is a design goal of this work that the semantics of Queries and
Responses survive interworking through translations from one encoding
to another; for example, when an Intermediary receives a binary query
from a Client, it should be able to transcode it to an XML format to
send to a Service without discarding any of the original semantics.
[TBD]
Peterson Expires January 17, 2013 [Page 8]
Internet-Draft TeRQ Framework July 2012
5. The Data Model
Every query has a Source and a Subject, and may have one or more
Attributes. Every Response has a Response Code, one or more Records
(containing Attributes), and may have a Subject (if the Subject
differs from that of the Query).
5.1. Source
The Source is a required element in Queries. In this specification,
three categories of Sources are defined: Query Source, Query
Intermediary, and Route Source. At least one of these Sources must
be present in a Query, and multiple Sources are permitted. Responses
do not contain a Source.
Future specifications may extend the set of Source types.
5.1.1. Query Source
Every Query generated by a client has a Query Source, which
identifies the originator of the Query. This represents the logical
identity of the user or service provider who first sent the Query,
rather than the identity of any Intermediate entity. This field is
provided in the Source to authenticate the poser of the Query, so
that the Service can make any necessary authorization decisions as it
formulates a Response.
In some service deployments, an Intemrediary may wish to mask the
Query Source from a Service. The removal of the Query Source is
permitted by TeRQ, but any Intermediary that removes the Query Source
must provide a Query Intermediary for the Source element.
A Query Source element has a Type, which indicates how the logical
identity of the originator of the Query has been represented. The
Type field of the Query Source is extensible. Initial values include
a domain name, a URI and a telephone number.
The Type element of the Query Source is followed by a Value, which
contains the identity. The format of the identity is determined by
the Type.
5.1.2. Query Intermediary
Optionally, Queries may contain one or more Query Intermediary
elements in the Source. A Query Intermediary resides between the
originator of the Query (the Client) and the Service, where it may
aggregate queries, proxy them, transcode them, or provide any related
relay function to assist the delivery of Queries to the Service.
Peterson Expires January 17, 2013 [Page 9]
Internet-Draft TeRQ Framework July 2012
The Query Intermediary element, like the Query Source, contains the
logical identity of the service that relayed the Query. This field
is provided in the Source for those deployments in which the Service
makes an authorization decision based on the identity of the
Intermediary rather than a Query Source.
A Query Intermediary element has a Type, which indicates how the
logical identity of the Intermediary has been represented. The Type
element of the Query Intermediary is extensible. Initial values
include a domain name or a URI.
The Type of the Query Intermediary element is followed by a Value,
which contains the identity. The format of the identity is
determined by the Type.
5.1.3. Route Source
Optionally, Queries may contain a Route Source which identifies a
reference point in the network from which any Routing Attributes in
the response should be calculated. It therefore always designates a
network element, though depending on the circumstances, it may be an
endpoint, a gateway, a border device, or any other agent that makes
forwarding decisions for telephone calls and related services.
A Route Source element has a Type, which indicates how the network
element has been represented. The Type field of the Query Source is
extensible. Initial values include a domain name, an IP address or a
trunk group.
The Type of the Route Source element is followed by a Value, which
designates the network element. The format of the identity is
determined by the Type.
5.2. Subject
All Queries contain a Subject. The Subject contains the resource for
which the originator of the Query is asking the Service to return
Attributes. Responses only contain a Subject if the Subject of the
Response differs from that of the original Query, which may occur
when (for example) the Subject contains a broad range, and the
Service replies with a more narrow Subject. Future specifications
may define alternative Subject elements.
5.2.1. Telephone Number
The Telephone Number element of the Subject contains an encoding of a
telephone number or a telephone number fragment.
Peterson Expires January 17, 2013 [Page 10]
Internet-Draft TeRQ Framework July 2012
A Telephone Number has a Type which designates which sort of
telephone number the element contains. Types defined by this
specification include: E.164, Service Code, Short Code, Prefix,
Nationally-Specific and Unknown.
The Type of the Telephone Number element is followed by a Value,
which contains the telephone number itself. The format of the
identity is determined by the Type.
5.2.2. Service Provider Identifier
A Service Provider Identifier (SPID) may also be the Subject of the
Query, if, for example, in a SPEERMINT-like architecture an initial
resolution has already translated a telephone number into a SPID, and
now the client wishes to find routes or other information related to
the SPID.
A Service Provider Identifier has a Type which designates the sort of
SPID the element contains. SPID types defined by this specification
include: SPID.
5.3. Attributes
Attributes in this data model are all specified as having a Name and
a Value. Individual attributes may contain their own subtyping
mechanisms as required.
Queries optionally contain Attributes; a Query with no specified
Attributes requests that the Service return any Attributes associated
with the Subject. In a Query, the presence of one or more Attributes
limits the scope of the Query to Records about the Subject containing
those Attributes.
Responses contain Attributes within the one or more Record elements.
At least one Record element will always be present in a successful
Response, and thus at least one Attribute will be as well.
Attributes are broadly divided between Routing Attributes and
Administrative Attribtues. Routing Attributes provide information
required to route communications, including URIs.
5.3.1. Routing Attributes
Routing Attributes defined by this document include: voip, sms [TBD]
Peterson Expires January 17, 2013 [Page 11]
Internet-Draft TeRQ Framework July 2012
5.3.2. Administrative Attributes
Administrative Attributes defined by this document include: CNAM,
SPID, dialplan [TBD]
5.4. Records
The Record element appears only in Responses. It exists primarily as
a means to deliver Attributes in answer to Queries, grouping together
Attributes with an Authority and any expiry and preferential data
recommended by the Service.
5.4.1. Attributes
A Record contains an Attribute, which may be either a Routing or
Administrative Attribute.
5.4.2. Authority
The Authority subelement of a Record specifies the source of the
data: either the entity that provisioned the data with the Service or
the external source from which the Service collected the data. Like
the "Query Source" element, the Authority element ideally gives a
logical identity of the source of the data. The format has a Type
followed by a Value, where the format of Values is defined by the
Type. Types defined by this document include: domain name and IP
address.
5.4.3. Priority
Optionally, a Service may specify a weighted Priority associated with
a Record. Priorities are between 0 and 1, with a value of 1 having
the highest priority.
5.4.4. Expiration
Optionally, a Service may specify an absolute time at which a Record
will no longer be valid, should a client or intermediary wish to
cache a Record. In the absence of an Expiration element, Records may
be cached for a maximum of twenty-four hours.
5.5. Response Code
All Responses contain a Response Code.
Response Codes defined by this document include: Success, Subject
Does Not Exist, No Suitable Records Exist for Subject, Subject Syntax
Error, Unknown Attribute, Unauthorized Source, Route Source Topology
Peterson Expires January 17, 2013 [Page 12]
Internet-Draft TeRQ Framework July 2012
Unavailable.
[TBD]
Peterson Expires January 17, 2013 [Page 13]
Internet-Draft TeRQ Framework July 2012
6. Bindings
A TeRQ Binding is an underlying protocol that carries TeRQ Queries
and Responses. Future specifications may define Bindings in
accordance with the procedures in the IANA Considerations sections of
this document.
By underlying protocol, this specification means both transport-layer
protocols as well as any application-layer protocols that the Binding
requires. Thus an example Binding might specify a combination of
TCP, TLS, HTTP and SOAP as the underlying transport for TeRQ.
Alternatively, it might only specify a very lightweight underlying
protocol like UDP. A Binding may be specific to a particular
Encoding, or it may be independent of any Encoding.
Bindings must specify whether they are continuous, transactional or
non-transactional. A continuous Binding creates a persistent
connection between two TeRQ entities over which many, potentially
unrelated, Queries and Responses might flow. Many Bindings defined
for use between an Intermediary and a Service will have this
property, as Intermediaries may aggregate on behalf of many Clients,
and opening a separate transport-layer connection for each new Query
would be inefficient. A transactional Binding creates a temporary
connection between two TeRQ entities for the purpose of fulfilling a
single Query; any Responses to the Query will use the same connection
to return to the sender of the Query. Finally, a non-transactional
Binding does not rely on any sort of connection semantics: the
senders of Queries and Responses will always initiate a new instance
of the Binding to send a message.
This document makes no provision for discovering the Bindings
supported by a TeRQ Client, Intermediary or Service. Intermediaries
may transcode between Bindings if necessary when acting to connect a
Client and a Service, especially if the Client and Service support no
Bindings in common.
A Binding specification must enumerate all categories of metadata
required to establish a connection using a Binding. For some
Bindings, this might comprise soley an IP address and a port; for
other Bindings, this might instead require higher-layer application
identifiers like a URI. This metadata includes any identifiers
necessary for correlating Queries to Responses in a continuous or
non-tractional Binding; any Encoding making use of these Bindings
must specify how it carries those elements.
Bindings must also describe the security services they make
available. If a Binding incorporates TLS, for example, the host
authentication that TLS can provide should be described in the
Peterson Expires January 17, 2013 [Page 14]
Internet-Draft TeRQ Framework July 2012
Binding specification, so that Encodings can potentially make use of
this service to provide some of the semantics of TeRQ.
Peterson Expires January 17, 2013 [Page 15]
Internet-Draft TeRQ Framework July 2012
7. Encodings
A TeRQ Encoding specifies how the Query and Reponse are constructed
syntactically. An Encoding may be specific to a particular Binding,
or it may be specified independently of any Binding.
An Encoding may define an object format; for example, an XML or JSON
object, described with any appropriate schemas, or an ABNF
description. An Encoding might alternatively specify a mapping of
the semantic elements of Queries and Responses on to the existing
fields of headers of a protocol, especially when that protocol has
been defined as an underlying protocol Binding.
Every Encoding must specify how each semantic element of a Query and
Response will be represented. For all baseline TeRQ Attributes and
elements, the Encoding specifies whether values will be text or
binary, how they will be encoded. Many baseline element types (such
as telephone numbers) can appear in different places in a TeRQ
message; Encodings need only specify these common element types once.
[TBD - extract common element types] Due to the extensibilty of TeRQ,
however, future specifications might define element types that an
Encoding does not address. Profiles using those extensions and
Encodings must explain their interaction.
Peterson Expires January 17, 2013 [Page 16]
Internet-Draft TeRQ Framework July 2012
8. Profiles
For particular deployment environments, only one particular Binding,
Encoding and set of Attributes or other extended elements may be
meaningful. Future specifications may therefore define TeRQ
Profiles, which describe a particular deployment environment and the
Binding, Encoding and set of Attributes or elements it requires.
Profiles may be extensible, but any Attributes or elements required
to negotiate support for extensions must be defined within the
Profile.
Peterson Expires January 17, 2013 [Page 17]
Internet-Draft TeRQ Framework July 2012
9. Security Considerations
[TBD]
Peterson Expires January 17, 2013 [Page 18]
Internet-Draft TeRQ Framework July 2012
10. IANA Considerations
This document creates a registry of element and subelements for use
with this framework. This registry is extensible, with an IANA
Registration policy of Specification Required. Any new element
registered must supply the name of the element, the name of the
parent element in the data model, and a code point as described
below.
To facilitate interoperability of binary encodings, this document
specifies a code points associated with all registered elements and
subelements in Queries and Responses. Any new specification that
extends the list of elements or subelements of this framework must
provide a binary code point for their element.
The initial population of this registry is: [TBD]
This document furthermore creates a registry of Response Codes.
[TBD]
Peterson Expires January 17, 2013 [Page 19]
Internet-Draft TeRQ Framework July 2012
11. Acknowledgements
Peterson Expires January 17, 2013 [Page 20]
Internet-Draft TeRQ Framework July 2012
12. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Peterson Expires January 17, 2013 [Page 21]
Internet-Draft TeRQ Framework July 2012
Author's Address
Jon Peterson
NeuStar, Inc.
Email: jon.peterson@neustar.biz
Peterson Expires January 17, 2013 [Page 22]