idnits 2.17.1 draft-peterson-terq-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2015) is 3215 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 833, but not defined == Missing Reference: 'Syntax TBD' is mentioned on line 675, but not defined == Unused Reference: 'RFC3324' is defined on line 853, but no explicit reference was found in the text == Unused Reference: 'RFC3325' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC4474' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'RFC4916' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'RFC5039' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'RFC5727' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'RFC6461' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 910, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar, Inc. 4 Intended status: Standards Track July 6, 2015 5 Expires: January 7, 2016 7 A Framework and Information Model for Telephone-Related Queries (TeRQ) 8 draft-peterson-terq-04 10 Abstract 12 As telephone services migrate to the Internet, Internet applications 13 require access to diverse information about telephone numbers. ENUM, 14 for example, applied the DNS to the problem of finding URIs for 15 telephone services on the Internet. The intrinsic limitations in the 16 query/response semantics of the DNS, however, have often been 17 strained by the requirements for accessing information about 18 telephone numbers. This document therefore proposes a protocol- 19 independent framework and information model for querying and 20 responding to requests concerning telephone numbers and call routing 21 that allows a richer expression of both questions and answers. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 7, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Number Translation with Multiple Authorities . . . . . . 5 73 3.2. Customer name queries . . . . . . . . . . . . . . . . . . 5 74 3.3. Pre-port validation . . . . . . . . . . . . . . . . . . . 6 75 3.4. Caller-ID Spoofing prevention . . . . . . . . . . . . . . 6 76 3.5. Prefix-based route caching . . . . . . . . . . . . . . . 7 77 3.6. Inventory search . . . . . . . . . . . . . . . . . . . . 7 78 3.7. Motivation for Extensions . . . . . . . . . . . . . . . . 7 79 3.7.1. SPEERMINT Number Translation . . . . . . . . . . . . 7 80 4. Overview of the Framework . . . . . . . . . . . . . . . . . . 8 81 5. Transport Independence . . . . . . . . . . . . . . . . . . . 8 82 5.1. Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 83 5.2. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.3. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6. The Information Model . . . . . . . . . . . . . . . . . . . . 11 86 6.1. Source . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 6.1.1. Query Source . . . . . . . . . . . . . . . . . . . . 11 88 6.1.2. Query Intermediary . . . . . . . . . . . . . . . . . 12 89 6.1.3. Route Source . . . . . . . . . . . . . . . . . . . . 12 90 6.2. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 6.2.1. Telephone Number . . . . . . . . . . . . . . . . . . 13 92 6.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . 13 93 6.4. Records . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . 14 95 6.4.2. Authority . . . . . . . . . . . . . . . . . . . . . . 14 96 6.4.3. Priority . . . . . . . . . . . . . . . . . . . . . . 14 97 6.4.4. Expiration . . . . . . . . . . . . . . . . . . . . . 14 98 6.5. Response Code . . . . . . . . . . . . . . . . . . . . . . 14 99 6.6. Signature . . . . . . . . . . . . . . . . . . . . . . . . 15 100 7. Element Types . . . . . . . . . . . . . . . . . . . . . . . . 15 101 7.1. Telephone Number Type . . . . . . . . . . . . . . . . . . 15 102 7.1.1. TN Range Type . . . . . . . . . . . . . . . . . . . . 15 103 7.2. Domain Name Type . . . . . . . . . . . . . . . . . . . . 15 104 7.3. Uniform Resource Indicator (URI) Type . . . . . . . . . . 15 105 7.4. Internet Protocol (IP) Address Type . . . . . . . . . . . 16 106 7.5. Service Provider Identifier (SPID) Type . . . . . . . . . 16 107 7.6. Trunk Group Type . . . . . . . . . . . . . . . . . . . . 16 108 7.7. Display Name Type . . . . . . . . . . . . . . . . . . . . 16 109 7.8. Expiry Type . . . . . . . . . . . . . . . . . . . . . . . 16 110 7.9. Priority Type . . . . . . . . . . . . . . . . . . . . . . 16 111 7.10. Extension Type . . . . . . . . . . . . . . . . . . . . . 17 112 8. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 17 113 8.1. Routing Attributes . . . . . . . . . . . . . . . . . . . 17 114 8.2. Administrative Attributes . . . . . . . . . . . . . . . . 17 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 117 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 118 12. Informative References . . . . . . . . . . . . . . . . . . . 18 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 121 1. Terminology 123 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 124 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 126 2. Motivation 128 Telephone numbers remain the worldwide standard identifier for 129 routing calls and text messages over the Public Switched Telephone 130 Network (PSTN). As identifiers, however, telephone numbers differ 131 fundamentally from the identifiers commonly used by Internet 132 applications. Email, the web and native Voice over IP (VoIP) systems 133 such as SIP ([RFC3261]) typically use identifiers that rely on the 134 Domain Name System (DNS) to resolve a domain portion of the 135 identifier to a particular IP address; commonly, Uniform Resource 136 Indicators (URIs) with a user and host component serve this purpose. 137 In order to bridge this gap between the PSTN and the Internet, the 138 ENUM ([RFC6116]) effort specified a DNS profile for translating 139 telephone numbers into URIs. 141 While the ENUM approach suffices for simple number translations, more 142 complex routing and administrative functions can strain the 143 capabilities of the DNS. Many of these problems result from the 144 limiting simplicity of the DNS query string. DNS queries have a 145 fairly rigid syntax oriented towards the resolution of an atomic name 146 in a hierarchical namespace. Telephone call routing, however, may 147 require compound queries that operate on several distinct query 148 elements that are difficult to cast hierarchically. Many of the 149 complex query/response mechanisms used in the PSTN are not tied 150 directly to call routing or establishment, such as finding the 151 caller's name (CNAM) when a call is received. Moreover, the 152 centralized and authoritative hierarchy of the DNS proved a poor 153 match for the actual procedures used to route telephone calls. 155 This led to work on "infrastructure" ENUM ([RFC5067]), which assumed 156 private DNS implementations, each of which could give a different 157 answer to the same request to translate a telephone number depending 158 on who asked, or other internal factors. The framework of the 159 SPEERMINT working group ([RFC6406]), expanding on these requirements, 160 differentiated the mapping of a telephone number to a target network 161 (the "Look-up Function") from the mapping made by the originating 162 network to the proper next-hop to reach such a target network (the 163 "Location Routing Function"). While the LUF can be centralized and 164 authoritative, the LRF is necessarily subjective and localized. In 165 the SPEERMINT model, the routing of a call may involve an 166 intermediate lookup that operates on a Service Provider Identifier 167 (SPID) rather than a telephone number. Mapping these capabilities to 168 ENUM requires security and administrative practices that further 169 complicate its DNS implementation. The underlying architectural 170 issues that give rise to all these problems are detailed in 171 [RFC6950]. 173 Despite these difficulties, the need for solutions in this space is 174 pressing, as many carriers worldwide contemplate migrating their 175 entire PSTN infrastructure onto the Internet within the next decade. 176 Further pressures come from emerging Internet communications 177 providers who never invested in PSTN infrastructure in the first 178 place, but want access to services related to telephone numbers. 179 These different communities have diverse requirements. In some 180 environments, there are performance constraints that would require a 181 very lightweight binary protocol; in others, applications might 182 prefer human-readable markup languages suitable for interfacing with 183 existing APIs. 185 Therefore, this document proposes a reconsideration of telephone 186 routing and administration services on the Internet based on a 187 framework that details queries and responses in an abstract 188 architecture. This document specifies no particular syntax or 189 encoding for queries or responses, but instead describes an 190 extensible information model for the semantics of queries and 191 responses that future specifications might encode in accordance with 192 application needs. 194 3. Use Cases 196 This section records several motivating use cases for the TeRQ 197 framework. 199 3.1. Number Translation with Multiple Authorities 201 An Internet-based VoIP client places a call destined for a telephone 202 number. An end user and a service provider both want to provision 203 data against the same telephone number; for example, a service 204 provider might want to provision an endpoint address on an Internet 205 gateway for the number, whereas an end user might want to provision 206 the preferred voicemail service for the number. A directory service 207 can permit multiple authorities to provision data for the same 208 telephone number; clients query this service. Clients who query for 209 this data might have a trust relationship with either authority or 210 both. When a client launches a query, it should receive in response 211 any records that authorities authorize the client to receive, 212 allowing the client to decide what it should trust and use. As the 213 multiple authorities provision records at the directory, they sign 214 those records, and when the client receives a response it validates 215 the signatures on the records and trusts those records, or not, based 216 on its association with the signer, independent of any security 217 relationship with the directory. 219 Translations should be available for nationally specific numbers, 220 including freephone numbers. 222 A very similar use case could also be constructed for SMS routing 223 (including short codes). 225 3.2. Customer name queries 227 An Internet gateway receives a call from the PSTN. The gateway wants 228 to put the calling number (IAM CIN) into the username portion of the 229 From header field value of a SIP request, and also to populate the 230 display-name of that header field. The gateway therefore launches a 231 query to a CNAM service, which may or may not be the same as any 232 services used for number translation. The CNAM service only accepts 233 requests from authorized parties with whom it has a billing 234 relationship. Since the Internet gateway launching the query is only 235 one of many gateways in its administrative domain, not every gateway 236 will have a trust relationship n with the CNAM service. Instead, the 237 gateways send their requests to a local intermediary which aggregates 238 requests and maintains a trust relationship with the CNAM service. 240 Ideally, if the gateway uses the same service for number translation 241 and for CNAM, it should be able to place both requests in the same 242 message: one for the called number, flagged for translation, and one 243 for the calling number, flagged for CNAM. 245 Under high volumes, the intermediary maintains a transport connection 246 to the CNAM service, rather than opening a new socket and re- 247 negotiating security for each individual request. The intermediary 248 may also bundle multiple numbers into a single request, and expect to 249 get back a response with multiple records associated with those 250 numbers. In both cases, a transaction number is used to match 251 requests to responses. 253 Finally, the intermediary authenticates sources of traffic and 254 authorizes only gateways to receive responses, as CNAM data is 255 sensitive and the CNAM service may charge for transactions. 257 3.3. Pre-port validation 259 A mall kiosk that sells cellular telephones has a customer that wants 260 to purchase a new phone and port their old number onto the phone. 261 Porting needs to be validated on the spot and typically completed in 262 a very short time frame (say within fifteen minutes). The new 263 service provider for the number needs to make a query to an 264 intercarrier communications process (ICP) service to validate the 265 customer with the old service provider. In order to validate the 266 port, the new service provider needs to submit the telephone number, 267 the customer's name and customer's zip code. The ICP needs to 268 respond either confirming that the customer information is correct 269 for the number in question or not. 271 The responses to ICP queries are potentially privacy-sensitive. It 272 is not feasible for every mall kiosk to have a direct relationship 273 with this database, therefore requests go through an intermediary 274 which has a trust relationship with the ICP service. 276 3.4. Caller-ID Spoofing prevention 278 An SMS service bureau receives an SMS message from a particular 279 telephone number. It wants to be able to consult an authoritative 280 service to ascertain whether or not that calling number is allocated 281 and SMS capable. The bureau sends a request to the service to 282 determine if the number in question exists and has an SMS capability. 283 Only if a record is returned proving that the number is SMS capable 284 does the bureau forward the SMS to its destination. 286 A similar use case could be constructed for voice calls. For more on 287 these similar use cases, see [RFC7340]. 289 3.5. Prefix-based route caching 291 A soft client on a tablet attempts to call out to a telephone number. 292 The client has a pre-existing association with a service that 293 performs number translation on its behalf; the client knows the 294 address of an intermediary belonging to the service, and has security 295 credentials to pass requests through that intermediary. When the 296 intermediary forwards the request to the service, the service returns 297 a response indicating that the entire thousand-block to which that 298 number belongs is routed to an enterprise with an Internet PBX. The 299 intermediary receives this response along with a time-to-live and 300 caches the response locally. When subsequent requests come in from 301 clients, the intermediary can match the requests against this prefix, 302 and return the appropriate response without needing to consult the 303 service. 305 3.6. Inventory search 307 A Internet service provider provisions many telephone numbers within 308 a given number range. The provider later wants to verify which 309 numbers are associated with the address of a particular SMSC, perhaps 310 an SMSC that has experienced a failure. The service provider thus 311 wants to formulate a search query across the entire number range, 312 requesting only those numbers that have that association. The 313 service where the numbers are provisioned must be able to 314 authenticate the service provider as this sort of search operation 315 would not be authorized for end users. 317 3.7. Motivation for Extensions 319 While the current version of this specification focuses on a small 320 core set of features, the TeRQ framework should be extensible to 321 support use cases with alterntive identifiers and scopes. 323 3.7.1. SPEERMINT Number Translation 325 An Internet gateway receives a call from the PSTN destined for a 326 telephone number. The gateway resides in a walled garden that has 327 numerous peering points with other administrative domains, including 328 through a number of clearinghouses, typical of a SPEERMINT 329 architecture. The gateway queries two services to determine where it 330 should deliver the call. The gateway first makes a number 331 translation request of a public directory, which returns a service 332 provider identifier (SPID) of the network to which the call should be 333 delivered (LUF). The gateway then makes a query to a private 334 directory, internal to its walled garden, to translate that SPID into 335 the address of the proper point-of-interconnection to exit the walled 336 garden (LRF). 338 In this case, the SPID might take the form of a numerical identifier, 339 a domain name or other identifier; behind the scenes, the internal 340 private directory may contain links between several different forms 341 of identifiers. 343 The internal private directory may respond with a different POI 344 depending on which gateway is asking - a USA West Coast gateway might 345 get a different answer than an East Coast gateway. The directory 346 therefore authenticates incoming queries to identify the originating 347 gateway and serve a customized answer. 349 Although the internal private directory is inherently trusted by the 350 gateway, the public directory (which returns the SPID) is not 351 directly trusted by the gateway. The data in the public directory, 352 however, is provisioned by authorities, including the number owners. 353 As they provision records at the public gateway, they sign those 354 records, and when the gateway receives a response it validates the 355 signatures on the records and trusts those records, or not, based on 356 its association with the signer, independent of any security 357 relationship with the directory. 359 4. Overview of the Framework 361 This framework specifies an abstract query/response protocol that 362 enables a Client to send Queries to a Service about telephone numbers 363 or related telephone services. Queries may pass through one or more 364 Intermediaries on their way from a Client to a Service; for example, 365 through aggregators or service bureaus. A Client establishes the 366 Subject of a Query, and optionally specifies one or more Attributes 367 of particular interest in order to narrow the desired response. When 368 a Service receives a Query, it performs any necessary authorization 369 and policy decisions based on the Source. If policy permits, the 370 Service generates a Response, which will consist of a Response Code 371 and one or more Records associated with the Subject. The Service 372 then sends the Response through the same path that the Query 373 followed; transactional identifiers set by the Client and Service 374 correlate the Query to the Response and assist any intermediary 375 routing. 377 5. Transport Independence 379 The information model provided for Queries and Responses in this 380 framework is independent of any underlying transport or encoding. 381 Future specifications will define Bindings that specify particular 382 transports and Encodings for Queries and Responses. In some 383 deployment environments, for example, a binary encoding and 384 lightweight transport might be more appropriate than the use of a web 385 protocol. This specification provides a template of requirements 386 that must be addressed by any encoding scheme. 388 It is a design goal of this work that the semantics of Queries and 389 Responses survive interworking through translations from one encoding 390 to another; for example, when an Intermediary receives a binary query 391 from a Client, it should be able to transcode it to an XML format to 392 send to a Service without discarding any of the original semantics. 394 5.1. Bindings 396 A TeRQ Binding is an underlying protocol that carries TeRQ Queries 397 and Responses. Future specifications may define Bindings in 398 accordance with the procedures in the IANA Considerations sections of 399 this document. 401 By underlying protocol, this specification means both transport-layer 402 protocols as well as any application-layer protocols that the Binding 403 requires. Thus an example Binding might specify a combination of 404 TCP, TLS, HTTP and SOAP as the underlying transport for TeRQ. 405 Alternatively, it might only specify a very lightweight underlying 406 protocol like UDP. A Binding may be specific to a particular 407 Encoding, or it may be independent of any Encoding. 409 Bindings must specify whether they are continuous, transactional or 410 non-transactional. A continuous Binding creates a persistent 411 connection between two TeRQ entities over which many, potentially 412 unrelated, Queries and Responses might flow. Many Bindings defined 413 for use between an Intermediary and a Service will have this 414 property, as Intermediaries may aggregate on behalf of many Clients, 415 and opening a separate transport-layer connection for each new Query 416 would be inefficient. A transactional Binding creates a temporary 417 connection between two TeRQ entities for the purpose of fulfilling a 418 single Query; any Responses to the Query will use the same connection 419 to return to the sender of the Query. Finally, a non-transactional 420 Binding does not rely on any sort of connection semantics: the 421 senders of Queries and Responses will always initiate a new instance 422 of the Binding to send a message. 424 This document makes no provision for discovering the Bindings 425 supported by a TeRQ Client, Intermediary or Service. Intermediaries 426 may transcode between Bindings if necessary when acting to connect a 427 Client and a Service, especially if the Client and Service support no 428 Bindings in common. 430 A Binding specification must enumerate all categories of metadata 431 required to establish a connection using a Binding. For some 432 Bindings, this might comprise solely an IP address and a port; for 433 other Bindings, this might instead require higher-layer application 434 identifiers like a URI. This metadata includes any identifiers 435 necessary for correlating Queries to Responses in a continuous or 436 non-transactional Binding; any Encoding making use of these Bindings 437 must specify how it carries those elements. 439 Bindings must also describe the security services they make 440 available. Bindings must have a means of providing mutual 441 authentication, integrity and confidentiality between Clients, 442 Intermediaries and Services. If a Binding supports TLS, for example, 443 these features can be provided by using TLS in an appropriate 444 deployment environment. 446 5.2. Encodings 448 A TeRQ Encoding specifies how the Query and Response are constructed 449 syntactically. An Encoding may be specific to a particular Binding, 450 or it may be specified independently of any Binding. 452 An Encoding may define an object format; for example, an XML or JSON 453 object, described with any appropriate schemas, or an ABNF 454 description. An Encoding might alternatively specify a mapping of 455 the semantic elements of Queries and Responses on to the existing 456 fields of headers of a protocol, especially when that protocol has 457 been defined as an underlying protocol Binding. Encodings must also 458 define whether or not they provide a bundling feature that allows 459 multiple Queries to be carried within particular objects or mappings. 461 Every Encoding must specify how each semantic Element Type of a Query 462 and Response will be represented. For all baseline TeRQ Attributes 463 and Element Types, the Encoding specifies whether values will be text 464 or binary, how they will be encoded. Many baseline Element Types 465 (such as telephone numbers) can appear in different places in a TeRQ 466 message; Encodings need only specify these common element types once. 467 Due to the extensibility of TeRQ, however, future specifications 468 might define Element Types that an Encoding does not address. 469 Profiles using those extensions and Encodings must explain their 470 interaction. 472 Encodings must also describe the security services they make 473 available. In particular, encodings must describe a means of 474 providing authentication of the Sources and Authorities of Queries 475 and Responses respectively, as well as an integrity check over 476 critical elements including the Subject of Queries and the Record of 477 Responses. 479 [TBD - we may define more about the computation of this signature, 480 including canonicalization of elements, in this framework, and make 481 it a requirement for encodings to support this mechanism] 483 5.3. Profiles 485 For particular deployment environments, only one Binding, Encoding 486 and set of Attributes or other extended elements may be meaningful. 487 Future specifications may therefore define TeRQ Profiles, which 488 describe a particular deployment environment and the Binding, 489 Encoding and set of Attributes or elements it requires. 491 Profiles may be extensible, but any Attributes or elements required 492 to negotiate support for extensions must be defined within the 493 Profile. 495 6. The Information Model 497 Every query has a Source and a Subject, and may have one or more 498 Attributes. Every Response has a Response Code, one or more Records 499 containing Attributes, and may have a Subject, if the Subject differs 500 from that of the Query. 502 6.1. Source 504 The Source is a required element in Queries. In this specification, 505 three categories of Sources are defined: Query Source, Query 506 Intermediary, and Route Source. At least one of these Sources must 507 be present in a Query, and multiple Sources are permitted. Responses 508 do not contain a Source. 510 Future specifications may extend the set of Source types. 512 6.1.1. Query Source 514 Every Query generated by a client has a Query Source, which 515 identifies the originator of the Query. This represents the logical 516 identity of the user or service provider who first sent the Query, 517 rather than the identity of any Intermediate entity. This field is 518 provided in the Source to authenticate the poser of the Query, so 519 that the Service can make any necessary authorization decisions as it 520 formulates a Response. 522 In some service deployments, an Intermediary may wish to mask the 523 Query Source from a Service. The removal of the Query Source by an 524 intermediary is permitted by TeRQ, but any Intermediary that removes 525 the Query Source must provide a Query Intermediary for the Source 526 element. 528 A Query Source element has a Type, which indicates how the logical 529 identity of the originator of the Query has been represented. The 530 Type field of the Query Source is extensible. Initial values include 531 a domain name, a URI and a telephone number. 533 The Type element of the Query Source is followed by a Value, which 534 contains the identity. The format of the identity is determined by 535 the Type. 537 6.1.2. Query Intermediary 539 Optionally, Queries may contain one or more Query Intermediary 540 elements in the Source. A Query Intermediary resides between the 541 originator of the Query (the Client) and the Service, where it may 542 aggregate queries, proxy them, transcode them, or provide any related 543 relay function to assist the delivery of Queries to the Service. 545 The Query Intermediary element, like the Query Source, contains the 546 logical identity of the service that relayed the Query. This field 547 is provided in the Source for those deployments in which the Service 548 makes an authorization decision based on the identity of the 549 Intermediary rather than a Query Source. 551 A Query Intermediary element has a Type, which indicates how the 552 logical identity of the Intermediary has been represented. The Type 553 element of the Query Intermediary is extensible. Initial values 554 include a domain name or a URI. 556 The Type of the Query Intermediary element is followed by a Value, 557 which contains the identity. The format of the identity is 558 determined by the Type. 560 6.1.3. Route Source 562 Optionally, Queries may contain a Route Source which identifies a 563 reference point in the network from which any Routing Attributes in 564 the response should be calculated. It therefore always designates a 565 network element, though depending on the circumstances, it may be an 566 endpoint, a gateway, a border device, or any other agent that makes 567 forwarding decisions for telephone calls and related services. 569 A Route Source element has a Type, which indicates how the network 570 element has been represented. The Type field of the Query Source is 571 extensible. Initial values include a domain name, an IP address or a 572 trunk group. 574 The Type of the Route Source element is followed by a Value, which 575 designates the network element. The format of the identity is 576 determined by the Type. 578 6.2. Subject 580 All Queries have a Subject. The Subject contains the resource for 581 which the originator of the Query is asking the Service to return 582 Attributes. Responses only contain a Subject if the Subject of the 583 Response differs from that of the original Query, which may occur 584 when (for example) the Subject contains a broad range, and the 585 Service replies with a more narrow Subject. Future specifications, 586 including Profiles, may define alternative Subject elements. 588 6.2.1. Telephone Number 590 The Telephone Number element of the Subject contains an encoding of a 591 telephone number or a telephone number range. 593 A Telephone Number has a Type which designates which sort of 594 telephone number the element contains. Types defined by this 595 specification include: telephone number and telephone number range. 597 The Type of the Telephone Number element is followed by a Value, 598 which contains the telephone number itself. The format of the 599 identity is determined by the Type. 601 6.3. Attributes 603 Attributes in this information model have a Name, which may 604 optionally be associated with a Type and Value. 606 Queries optionally contain Attributes; a Query with no specified 607 Attributes requests that the Service return any Attributes associated 608 with the Subject. In a Query, the presence of one or more Attributes 609 limits the scope of the Query to Records about the Subject containing 610 those Attributes. 612 Responses contain Attributes within one or more Record elements. At 613 least one Record element will always be present in a successful 614 Response, and thus at least one Attribute will be as well. 616 Attributes are broadly divided between Routing Attributes and 617 Administrative Attributes. Routing Attributes provide information 618 required to route communications, including URIs. The format of the 619 elements contained in the Attributes is given below in Section 7. 621 6.4. Records 623 The Record element appears only in Responses. It exists primarily as 624 a means to deliver Attributes in answer to Queries, grouping together 625 Attributes with an Authority and any expiry and preferential data 626 recommended by the Service. 628 6.4.1. Attributes 630 A Record contains an Attribute, which may be either a Routing or 631 Administrative Attribute. 633 6.4.2. Authority 635 The Authority subelement of a Record specifies the source of the 636 data: either the entity that provisioned the data with the Service, 637 or the external source from which the Service collected the data. 638 Like the "Query Source" element, the Authority element ideally gives 639 a logical identity of the source of the data. The format has a Type 640 followed by a Value, where the format of Values is defined by the 641 Type. Types defined by this document include: domain name and IP 642 address. 644 6.4.3. Priority 646 Optionally, a Service may specify a weighted Priority associated with 647 a Record. Priorities are between 0 and 1, with a value of 1 having 648 the highest priority. 650 6.4.4. Expiration 652 Optionally, a Service may specify an absolute time at which a Record 653 will no longer be valid, should a client or intermediary wish to 654 cache a Record. In the absence of an Expiration element, Records may 655 be cached for a maximum of twenty-four hours. 657 6.5. Response Code 659 All Responses contain a Response Code. 661 Response Codes defined by this document include: Success, Subject 662 Does Not Exist, No Suitable Records Exist for Subject, Subject Syntax 663 Error, Unknown Attribute, Unauthorized Source, Route Source Topology 664 Unavailable. 666 [TBD] 668 6.6. Signature 670 A Record optionally concludes with a Signature element. The 671 Signature element contains a signature over the concatenation of the 672 other elements given the Record. Signatures are provided by the 673 Authority responsible for the Record. 675 [Syntax TBD] 677 7. Element Types 679 7.1. Telephone Number Type 681 The telephone number type conforms to the telephone number syntax 682 given in [RFC3966] Section 3, in the ABNF for "telephone-subscriber." 684 Type Code: T 686 [TBD - need for subtying? E.164, Service Code, Short Code, Prefix, 687 Nationally-Specific and Unknown. ] 689 7.1.1. TN Range Type 691 The TN range type consists of a prefix of a telephone number (per 692 [RFC3966] "telephone-subscriber"), and is semantically equivalent to 693 all syntactically-valid telephone numbers below that prefix. For 694 example, in the North American Numbering plan, the prefix 157143454 695 would be equivalent to all numbers ranging from 15714345400 to 696 15714345499. 698 [TBD - identify alternative ways of specifying ranges, potentially as 699 separate element types] 701 Type Code: R 703 7.2. Domain Name Type 705 The domain name type conforms to the syntax of RFC1034 Section 3.5 706 and Section 2.1 of [RFC1123]. 708 Type Code: D 710 7.3. Uniform Resource Indicator (URI) Type 712 The Uniform Resource Indicator (URI) type conforms to the syntax for 713 URIs given in [RFC3986] (see Section 3). 715 Type Code: U 717 7.4. Internet Protocol (IP) Address Type 719 The IP Address type conforms to the ABNF syntax of either the 720 IPv4address given in RFC3986 (Appendix A) or the IPv6reference of 721 [RFC5954]. 723 Type Code: I 725 7.5. Service Provider Identifier (SPID) Type 727 The SPID type consists of a four-digit number. 729 [TBD - introduce other elements for alternative SPID syntaxes] 731 Type Code: S 733 7.6. Trunk Group Type 735 The trunk group type conforms to the "trunk-group-label" ABNF given 736 in [RFC4904] (Section 5). 738 Type Code: G 740 7.7. Display Name Type 742 The display name is a string of Unicode characters, UTF-8 encoded, 743 with a maximum length of fifty octets. 745 Type Code: N 747 7.8. Expiry Type 749 The Expiry type is an absolute time conformant to the syntax of 750 [RFC3339]. 752 Type Code: E 754 7.9. Priority Type 756 The Priority type contains a number between 0 and 1, conforming to 757 the specification of the "q" parameter of the Contact header field in 758 [RFC3261]. 760 Type Code: P 762 7.10. Extension Type 764 This code is reserved for future use. 766 Type Code: X 768 8. Attributes 770 All attributes have a Name, which consists of a string. Optionally 771 an Attribute may take a Value, in which case it also has a Type. 772 Broadly, Attributes are here divided into two categories: Routing 773 Attributes and Administrative Attributes. 775 When an Attribute it specified, if its requires a Value which does 776 not have a Type in the base TeRQ specification, that Type must be 777 defined along with the Attribute. 779 8.1. Routing Attributes 781 Routing Attributes defined by this document include: voip (Type URI), 782 sms (Type URI) [TBD] 784 8.2. Administrative Attributes 786 Administrative Attributes defined by this document include: CNAM 787 (Type Display Name), SPID (Type SPID), dialplan (Type ?) [TBD] 789 9. Security Considerations 791 The framework of this document differs from previous efforts to 792 manage telephone numbers on the Internet largely by offering a much 793 richer set of security services. In particular, it requires that 794 three entities be capable of authenticating themselves to one another 795 at the layer of a binding: Clients, Intermediaries and Services. It 796 furthermore requires object security at the encoding layer so that 797 Sources and Authorities can sign data in order to authenticate 798 Queries and Responses that may pass through Intermediaries, and 799 moreover so that Authorities can prove to Clients that their Records 800 are authoritative even when the Authority does not operate the 801 Service. The requirements that bindings and encodings must satisfy 802 to meet these security needs are specified in Section 5. 804 [TBD - more] 806 10. IANA Considerations 808 This specification defines several registries: A registry of 809 Elements, a registry of Element Types, a registry of Attributes, and 810 a registry of Response Codes. 812 This document creates a registry of Elements for use with this 813 framework. This registry is extensible, with an IANA Registration 814 policy of Specification Required. Any new Element registered must 815 supply the name of the Element, the name of the parent Element in the 816 information model, and a code point. [TBD] 818 This specification pre-provisions the Element Types registry with the 819 entries given in Section 6. These elements are indexed by their Type 820 Code. This registry is extensible, with an IANA Registration policy 821 of Specification Required. Any new Element Type registered must 822 supply the name of the Element Type, the name of the parent element 823 in the information model, and a Type Code. 825 This specification creates an Attribute registry which is indexed by 826 Attribute names. This registry is extensible, with an IANA 827 Registration policy of Specification Required. Any new element 828 registered must supply the name of Attribute, and list all Element 829 Types that may be associated with Values of the Attribute. 831 This document furthermore creates a registry of Response Codes. This 832 registry is pre-provisioned with the values given in Section 5.5. 833 [TBD] 835 11. Acknowledgements 837 The authors would like to thank Paul Kyzviat and Dale Worley for 838 their input into this specification. 840 12. Informative References 842 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 843 and Support", STD 3, RFC 1123, October 1989. 845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 846 Requirement Levels", BCP 14, RFC 2119, March 1997. 848 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 849 A., Peterson, J., Sparks, R., Handley, M., and E. 850 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 851 June 2002. 853 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 854 Identity", RFC 3324, November 2002. 856 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 857 Extensions to the Session Initiation Protocol (SIP) for 858 Asserted Identity within Trusted Networks", RFC 3325, 859 November 2002. 861 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 862 Internet: Timestamps", RFC 3339, July 2002. 864 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 865 3966, December 2004. 867 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 868 Resource Identifier (URI): Generic Syntax", STD 66, RFC 869 3986, January 2005. 871 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 872 Authenticated Identity Management in the Session 873 Initiation Protocol (SIP)", RFC 4474, August 2006. 875 [RFC4904] Gurbani, V. and C. Jennings, "Representing Trunk Groups in 876 tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, 877 June 2007. 879 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 880 Protocol (SIP)", RFC 4916, June 2007. 882 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 883 Protocol (SIP) and Spam", RFC 5039, January 2008. 885 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 886 Requirements", RFC 5067, November 2007. 888 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 889 for the Session Initiation Protocol (SIP) and the Real- 890 time Applications and Infrastructure Area", BCP 67, RFC 891 5727, March 2010. 893 [RFC5954] Gurbani, V., Carpenter, B., and B. Tate, "Essential 894 Correction for IPv6 ABNF and URI Comparison in RFC 3261", 895 RFC 5954, August 2010. 897 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 898 Uniform Resource Identifiers (URI) Dynamic Delegation 899 Discovery System (DDDS) Application (ENUM)", RFC 6116, 900 March 2011. 902 [RFC6406] Malas, D. and J. Livingood, "Session PEERing for 903 Multimedia INTerconnect (SPEERMINT) Architecture", RFC 904 6406, November 2011. 906 [RFC6461] Channabasappa, S., "Data for Reachability of Inter-/Intra- 907 NetworK SIP (DRINKS) Use Cases and Protocol Requirements", 908 RFC 6461, January 2012. 910 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 911 of Named Entities (DANE) Transport Layer Security (TLS) 912 Protocol: TLSA", RFC 6698, August 2012. 914 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 915 "Architectural Considerations on Application Features in 916 the DNS", RFC 6950, October 2013. 918 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 919 Telephone Identity Problem Statement and Requirements", 920 RFC 7340, September 2014. 922 Author's Address 924 Jon Peterson 925 Neustar, Inc. 927 Email: jon.peterson@neustar.biz