idnits 2.17.1 draft-peterson-terq-03.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 (February 25, 2013) is 4050 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 818, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Peterson 2 Internet-Draft NeuStar, Inc. 3 Intended status: Standards Track February 25, 2013 4 Expires: August 29, 2013 6 A Framework and Information Model for Queries about Telephone-Related 7 Queries (TeRQ) 8 draft-peterson-terq-03 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 August 29, 2013. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1. Number translation . . . . . . . . . . . . . . . . . . . . 8 73 3.2. Customer name queries . . . . . . . . . . . . . . . . . . 9 74 3.3. Pre-port validation . . . . . . . . . . . . . . . . . . . 9 75 3.4. Caller-ID Spoofing prevention . . . . . . . . . . . . . . 10 76 3.5. Prefix-based route caching . . . . . . . . . . . . . . . . 10 77 3.6. Multiple authorities . . . . . . . . . . . . . . . . . . . 10 78 3.7. Inventory search . . . . . . . . . . . . . . . . . . . . . 11 79 4. Overview of the Framework . . . . . . . . . . . . . . . . . . 12 80 5. Transport Independence . . . . . . . . . . . . . . . . . . . . 13 81 5.1. Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.2. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 14 83 5.3. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 6. The Information Model . . . . . . . . . . . . . . . . . . . . 16 85 6.1. Source . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 6.1.1. Query Source . . . . . . . . . . . . . . . . . . . . . 16 87 6.1.2. Query Intermediary . . . . . . . . . . . . . . . . . . 16 88 6.1.3. Route Source . . . . . . . . . . . . . . . . . . . . . 17 89 6.2. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 6.2.1. Telephone Number . . . . . . . . . . . . . . . . . . . 17 91 6.2.2. Service Provider Identifier . . . . . . . . . . . . . 18 92 6.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 18 93 6.4. Records . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 19 95 6.4.2. Authority . . . . . . . . . . . . . . . . . . . . . . 19 96 6.4.3. Priority . . . . . . . . . . . . . . . . . . . . . . . 19 97 6.4.4. Expiration . . . . . . . . . . . . . . . . . . . . . . 19 98 6.5. Response Code . . . . . . . . . . . . . . . . . . . . . . 19 99 7. Element Types . . . . . . . . . . . . . . . . . . . . . . . . 20 100 7.1. Telephone Number Type . . . . . . . . . . . . . . . . . . 20 101 7.1.1. TN Prefix Type . . . . . . . . . . . . . . . . . . . . 20 102 7.2. Domain Name Type . . . . . . . . . . . . . . . . . . . . . 20 103 7.3. Uniform Resource Indicator (URI) Type . . . . . . . . . . 20 104 7.4. Internet Protocol (IP) Address Type . . . . . . . . . . . 20 105 7.5. Service Provider Identifier (SPID) Type . . . . . . . . . 21 106 7.6. Trunk Group Type . . . . . . . . . . . . . . . . . . . . . 21 107 7.7. Display Name Type . . . . . . . . . . . . . . . . . . . . 21 108 7.8. Expiry Type . . . . . . . . . . . . . . . . . . . . . . . 21 109 7.9. Priority Type . . . . . . . . . . . . . . . . . . . . . . 21 110 7.10. Extension Type . . . . . . . . . . . . . . . . . . . . . . 21 111 8. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 22 112 8.1. Routing Attributes . . . . . . . . . . . . . . . . . . . . 22 113 8.2. Administrative Attributes . . . . . . . . . . . . . . . . 22 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 117 12. Informative References . . . . . . . . . . . . . . . . . . . . 26 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 120 1. Terminology 122 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 123 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 125 2. Motivation 127 Telephone numbers remain the worldwide standard identifier for 128 routing calls and text messages over the Public Switched Telephone 129 Network (PSTN). As identifiers, however, telephone numbers differ 130 fundamentally from the identifiers commonly used by Internet 131 applications. Email, the web and native Voice over IP (VoIP) systems 132 typically use identifiers that rely on the Domain Name System (DNS) 133 to resolve a domain portion of the identifier to a particular IP 134 address; commonly, Uniform Resource Indicators (URIs) with a user and 135 host component serve this purpose. In order to bridge this gap 136 between the PSTN and the Internet, the ENUM effort specified a DNS 137 profile for translating telephone numbers into URIs. 139 While the ENUM approach suffices for simple number translations, more 140 complex routing and administrative functions can strain the 141 capabilities of the DNS. Many of these problems result from the 142 limiting simplicity of the DNS query string. DNS queries have a 143 fairly rigid syntax oriented towards the resolution of an atomic name 144 in a hierarchical namespace. Telephone call routing, however, may 145 require compound queries that operate on several distinct query 146 elements that are difficult to cast hierarchically. Many of the 147 complex query/response mechanisms used in the PSTN are not tied 148 directly to call routing or establishment, such as finding the 149 caller's name (CNAM) when a call is received. Moreover, the 150 centralized and authoritative hierarchy of the DNS proved a poor 151 match for the actual procedures used to route telephone calls. 153 This led to work on "infrastructure" ENUM, which assumed private DNS 154 implementations, each of which could give a different answer to the 155 same request to translate a telephone number depending on who asked, 156 or other internal factors. The framework of the SPEERMINT working 157 group, expanding on these requirements, differentiated the mapping of 158 a telephone number to a target network (the "Look-up Function") from 159 the mapping made by the originating network to the proper next-hop to 160 reach such a target network (the "Location Routing Function"). While 161 the LUF can be centralized and authoritative, the LRF is necessarily 162 subjective and localized. In the SPEERMINT model, the routing of a 163 call may involve an intermediate lookup that operates on a Service 164 Provider Identifier (SPID) rather than a telephone number. Mapping 165 these capabilities to ENUM requires security and administrative 166 practices that further complicate its DNS implementation. The 167 underlying architectural issues that give rise to all these problems 168 are detailed in draft-iab-dns-applications. 170 Despite these difficulties, the need for solutions in this space is 171 pressing, as many carriers worldwide contemplate migrating their 172 entire PSTN infrastructure onto the Internet within the next decade. 174 Further pressures come from emerging Internet communications 175 providers who never invested in PSTN infrastructure in the first 176 place, but want access to services related to telephone numbers. 177 These different communities have diverse requirements. In some 178 environments, there are performance constraints that would require a 179 very lightweight binary protocol; in others, applications might 180 prefer human-readable markup languages suitable for interfacing with 181 existing APIs. 183 Therefore, this document proposes a reconsideration of telephone 184 routing and administration services on the Internet based on a 185 framework that details queries and responses in an abstract 186 architecture. This document specifies no particular syntax or 187 encoding for queries or responses, but instead describes an 188 extensible information model for the semantics of queries and 189 responses that future specifications might encode in accordance with 190 application needs. 192 3. Use Cases 194 This section records several motivating use cases for the TeRQ 195 framework. 197 3.1. Number translation 199 An Internet gateway receives a call from the PSTN destined for a 200 telephone number. The gateway resides in a walled garden that has 201 numerous peering points with other administrative domains, including 202 through a number of clearinghouses, typical of a SPEERMINT 203 architecture. The gateway queries two services to determine where it 204 should deliver the call. The gateway first makes a number 205 translation request of a public directory, which returns a service 206 provider identifier (SPID) of the network to which the call should be 207 delivered (LUF). The gateway then makes a query to a private 208 directory, internal to its walled garden, to translate that SPID into 209 the the address of the proper point-of-interconnection to exit the 210 walled garden (LRF). 212 In this case, the SPID might take the form of a numerical identifier, 213 a domain name or other identifier; behind the scenes, the internal 214 private directory may contain links between several different forms 215 of identifiers. 217 The internal private directory may respond with a different POI 218 depending on which gateway is asking - a USA West Coast gateway might 219 get a different answer than an East Coast gateway. The directory 220 therefore authenticates incoming queries to identify the originating 221 gateway and serve a customized answer. 223 Although the internal private directory is inherently trusted by the 224 gateway, the public directory (which returns the SPID) is not 225 directly trusted by the gateway. The data in the public directory, 226 however, is provisioned by authorities, including the number owners. 227 As they provision records at the public gateway, they sign those 228 records, and when the gateway receives a response it validates the 229 signatures on the records and trusts those records, or not, based on 230 its association with the signer, independent of any security 231 relationship with the directory. 233 Translations should be available for nationally specific numbers, 234 including freephone numbers. 236 A very similar use case could also be constructed for SMS routing 237 (including short codes). 239 3.2. Customer name queries 241 An Internet gateway receives a call from the PSTN. The gateway wants 242 to put the calling number (IAM CIN) into the username portion of the 243 From header field value of a SIP request, and also to populate the 244 display-name of that header field. The gateway therefore launches a 245 query to a CNAM service, which may or may not be the same as any 246 services used for number translation. The CNAM service only accepts 247 requests from authorized parties with whom it has a billing 248 relationship. Since the Internet gateway launching the query is only 249 one of many gateways in its administrative domain, not every gateway 250 will have a trust relationship n with the CNAM service. Instead, the 251 gateways send their requests to a local intermediary which aggregates 252 requests and maintains a trust relationship with the CNAM service. 254 Ideally, if the gateway uses the same service for number translation 255 and for CNAM, it should be able to place both requests in the same 256 message: one for the called number, flagged for translation, and one 257 for the calling number, flagged for CNAM. 259 Under high volumes, the intermediary maintains a transport connection 260 to the CNAM service, rather than opening a new socket and re- 261 negotiating security for each individual request. The intermediary 262 may also bundle multiple numbers into a single request, and expect to 263 get back a response with multiple records associated with those 264 numbers. In both cases, a transaction number is used to match 265 requests to responses. 267 Finally, the intermediary authenticates sources of traffic and 268 authorizes only gateways to receive responses, as CNAM data is 269 sensitive and the CNAM service may charge for transactions. 271 3.3. Pre-port validation 273 A mall kiosk that sells cellular telephones has a customer that wants 274 to purchase a new phone and port their old number onto the phone. 275 Porting needs to be validated on the spot and typically completed in 276 a very short time frame (say within fifteen minutes). The new 277 service provider for the number needs to make a query to an 278 intercarrier communications process (ICP) service to validate the 279 customer with the old service provider. In order to validate the 280 port, the new service provider needs to submit the telephone number, 281 the customer's name and customer's zip code. The ICP needs to 282 respond either confirming that the customer information is correct 283 for the number in question or not. 285 The responses to ICP queries are potentially privacy-sensitive. It 286 is not feasible for every mall kiosk to have a direct relationship 287 with this database, therefore requests go through an intermediary 288 which has a trust relationship with the ICP service. 290 3.4. Caller-ID Spoofing prevention 292 An SMS service bureau receives an SMS message from a particular 293 telephone number. It wants to be able to consult an authoritative 294 service to ascertain whether or not that calling number is allocated 295 and SMS capable. The bureau sends a request to the service to 296 determine if the number in question exists and has an SMS capability. 297 Only if a record is returned proving that the number is SMS capable 298 does the bureau forward the SMS to its destination. 300 A similar use case could be constructed for voice calls. 302 3.5. Prefix-based route caching 304 A soft client on a tablet attempts to call out to a telephone number. 305 The client has a pre-existing association with a service that 306 performs number translation on its behalf; the client knows the 307 address of an intermediary belonging to the service, and has security 308 credentials to pass requests through that intermediary. When the 309 intermediary forwards the request to the service, the service returns 310 a response indicating that the entire thousand-block to which that 311 number belongs is routed to an enterprise with an Internet PBX. The 312 intermediary receives this response along with a time-to-live and 313 caches the response locally. When subsequent requests come in from 314 clients, the intermediary can match the requests against this prefix, 315 and return the appropriate response without needing to consult the 316 service. 318 3.6. Multiple authorities 320 An end user and a service provider both want to provision data 321 against the same telephone number; for example, a service provider 322 might want to provision an endpoint address on an Internet gateway 323 for the number, whereas an end user might want to provision the 324 preferred voicemail service for the number. A directory service can 325 permit multiple authorities to provision data for the same telephone 326 number. Clients who query for this data might have a trust 327 relationship with either party or both. When a client launches a 328 query, it should receive in response any records that authorities 329 authorize the client to receive, allowing the client to decide what 330 it should trust and use. 332 3.7. Inventory search 334 A Internet service provider provisions many telephone numbers within 335 a given number range. The provider later wants to verify which 336 numbers are associated with the address of a particular SMSC, perhaps 337 an SMSC that has experienced a failure. The service provider thus 338 wants to formulate a search query across the entire number range, 339 requesting only those numbers that have that association. The 340 service where the numbers are provisioned must be able to 341 authenticate the service provider as this sort of search operation 342 would not be authorized for end users. 344 4. Overview of the Framework 346 This framework specifies an abstract query/response protocol that 347 enables a Client to send Queries to a Service about telephone numbers 348 or related telephone services. Queries may pass through one or more 349 Intermediaries on their way from a Client to a Service; for example, 350 through aggregators or service bureaus. A Client establishes the 351 Subject of a Query, and optionally specifies one or more Attributes 352 of particular interest in order to narrow the desired response. When 353 a Service receives a Query, it performs any necessary authorization 354 and policy decisions based on the Source. If policy permits, the 355 Service generates a Response, which will consist of a Response Code 356 and one or more Records associated with the Subject. The Service 357 then sends the Response through the same path that the Query 358 followed; transactional identifiers set by the Client and Service 359 correlate the Query to the Response and assist any intermediary 360 routing. 362 5. Transport Independence 364 The information model provided for Queries and Responses in this 365 framework is independent of any underlying transport or encoding. 366 Future specifications will define Bindings that specify particular 367 transports and Encodings for Queries and Responses. In some 368 deployment environments, for example, a binary encoding and 369 lightweight transport might be more appropriate than the use of a web 370 protocol. This specification provides a template of requirements 371 that must be addressed by any encoding scheme. 373 It is a design goal of this work that the semantics of Queries and 374 Responses survive interworking through translations from one encoding 375 to another; for example, when an Intermediary receives a binary query 376 from a Client, it should be able to transcode it to an XML format to 377 send to a Service without discarding any of the original semantics. 379 5.1. Bindings 381 A TeRQ Binding is an underlying protocol that carries TeRQ Queries 382 and Responses. Future specifications may define Bindings in 383 accordance with the procedures in the IANA Considerations sections of 384 this document. 386 By underlying protocol, this specification means both transport-layer 387 protocols as well as any application-layer protocols that the Binding 388 requires. Thus an example Binding might specify a combination of 389 TCP, TLS, HTTP and SOAP as the underlying transport for TeRQ. 390 Alternatively, it might only specify a very lightweight underlying 391 protocol like UDP. A Binding may be specific to a particular 392 Encoding, or it may be independent of any Encoding. 394 Bindings must specify whether they are continuous, transactional or 395 non-transactional. A continuous Binding creates a persistent 396 connection between two TeRQ entities over which many, potentially 397 unrelated, Queries and Responses might flow. Many Bindings defined 398 for use between an Intermediary and a Service will have this 399 property, as Intermediaries may aggregate on behalf of many Clients, 400 and opening a separate transport-layer connection for each new Query 401 would be inefficient. A transactional Binding creates a temporary 402 connection between two TeRQ entities for the purpose of fulfilling a 403 single Query; any Responses to the Query will use the same connection 404 to return to the sender of the Query. Finally, a non-transactional 405 Binding does not rely on any sort of connection semantics: the 406 senders of Queries and Responses will always initiate a new instance 407 of the Binding to send a message. 409 This document makes no provision for discovering the Bindings 410 supported by a TeRQ Client, Intermediary or Service. Intermediaries 411 may transcode between Bindings if necessary when acting to connect a 412 Client and a Service, especially if the Client and Service support no 413 Bindings in common. 415 A Binding specification must enumerate all categories of metadata 416 required to establish a connection using a Binding. For some 417 Bindings, this might comprise solely an IP address and a port; for 418 other Bindings, this might instead require higher-layer application 419 identifiers like a URI. This metadata includes any identifiers 420 necessary for correlating Queries to Responses in a continuous or 421 non-transactional Binding; any Encoding making use of these Bindings 422 must specify how it carries those elements. 424 Bindings must also describe the security services they make 425 available. Bindings must have a means of providing mutual 426 authentication, integrity and confidentiality between Clients, 427 Intermediaries and Services. If a Binding supports TLS, for example, 428 these features can be provided by using TLS in an appropriate 429 deployment environment. 431 5.2. Encodings 433 A TeRQ Encoding specifies how the Query and Response are constructed 434 syntactically. An Encoding may be specific to a particular Binding, 435 or it may be specified independently of any Binding. 437 An Encoding may define an object format; for example, an XML or JSON 438 object, described with any appropriate schemas, or an ABNF 439 description. An Encoding might alternatively specify a mapping of 440 the semantic elements of Queries and Responses on to the existing 441 fields of headers of a protocol, especially when that protocol has 442 been defined as an underlying protocol Binding. Encodings must also 443 define whether or not they provide a bundling feature that allows 444 multiple Queries to be carried within particular objects or mappings. 446 Every Encoding must specify how each semantic Element Type of a Query 447 and Response will be represented. For all baseline TeRQ Attributes 448 and Element Types, the Encoding specifies whether values will be text 449 or binary, how they will be encoded. Many baseline Element Types 450 (such as telephone numbers) can appear in different places in a TeRQ 451 message; Encodings need only specify these common element types once. 452 Due to the extensibility of TeRQ, however, future specifications 453 might define Element Types that an Encoding does not address. 454 Profiles using those extensions and Encodings must explain their 455 interaction. 457 Encodings must also describe the security services they make 458 available. In particular, encodings must describe a means of 459 providing authentication of the Sources and Authorities of Queries 460 and Responses respectively, as well as an integrity check over 461 critical elements including the Subject of Queries and the Record of 462 Responses. 464 [TBD - we may define more about the computation of this signature, 465 including canonicalization of elements, in this framework, and make 466 it a requirement for encodings to support this mechanism] 468 5.3. Profiles 470 For particular deployment environments, only one Binding, Encoding 471 and set of Attributes or other extended elements may be meaningful. 472 Future specifications may therefore define TeRQ Profiles, which 473 describe a particular deployment environment and the Binding, 474 Encoding and set of Attributes or elements it requires. 476 Profiles may be extensible, but any Attributes or elements required 477 to negotiate support for extensions must be defined within the 478 Profile. 480 6. The Information Model 482 Every query has a Source and a Subject, and may have one or more 483 Attributes. Every Response has a Response Code, one or more Records 484 (containing Attributes), and may have a Subject (if the Subject 485 differs from that of the Query). 487 6.1. Source 489 The Source is a required element in Queries. In this specification, 490 three categories of Sources are defined: Query Source, Query 491 Intermediary, and Route Source. At least one of these Sources must 492 be present in a Query, and multiple Sources are permitted. Responses 493 do not contain a Source. 495 Future specifications may extend the set of Source types. 497 6.1.1. Query Source 499 Every Query generated by a client has a Query Source, which 500 identifies the originator of the Query. This represents the logical 501 identity of the user or service provider who first sent the Query, 502 rather than the identity of any Intermediate entity. This field is 503 provided in the Source to authenticate the poser of the Query, so 504 that the Service can make any necessary authorization decisions as it 505 formulates a Response. 507 In some service deployments, an Intermediary may wish to mask the 508 Query Source from a Service. The removal of the Query Source is 509 permitted by TeRQ, but any Intermediary that removes the Query Source 510 must provide a Query Intermediary for the Source element. 512 A Query Source element has a Type, which indicates how the logical 513 identity of the originator of the Query has been represented. The 514 Type field of the Query Source is extensible. Initial values include 515 a domain name, a URI and a telephone number. 517 The Type element of the Query Source is followed by a Value, which 518 contains the identity. The format of the identity is determined by 519 the Type. 521 6.1.2. Query Intermediary 523 Optionally, Queries may contain one or more Query Intermediary 524 elements in the Source. A Query Intermediary resides between the 525 originator of the Query (the Client) and the Service, where it may 526 aggregate queries, proxy them, transcode them, or provide any related 527 relay function to assist the delivery of Queries to the Service. 529 The Query Intermediary element, like the Query Source, contains the 530 logical identity of the service that relayed the Query. This field 531 is provided in the Source for those deployments in which the Service 532 makes an authorization decision based on the identity of the 533 Intermediary rather than a Query Source. 535 A Query Intermediary element has a Type, which indicates how the 536 logical identity of the Intermediary has been represented. The Type 537 element of the Query Intermediary is extensible. Initial values 538 include a domain name or a URI. 540 The Type of the Query Intermediary element is followed by a Value, 541 which contains the identity. The format of the identity is 542 determined by the Type. 544 6.1.3. Route Source 546 Optionally, Queries may contain a Route Source which identifies a 547 reference point in the network from which any Routing Attributes in 548 the response should be calculated. It therefore always designates a 549 network element, though depending on the circumstances, it may be an 550 endpoint, a gateway, a border device, or any other agent that makes 551 forwarding decisions for telephone calls and related services. 553 A Route Source element has a Type, which indicates how the network 554 element has been represented. The Type field of the Query Source is 555 extensible. Initial values include a domain name, an IP address or a 556 trunk group. 558 The Type of the Route Source element is followed by a Value, which 559 designates the network element. The format of the identity is 560 determined by the Type. 562 6.2. Subject 564 All Queries contain a Subject. The Subject contains the resource for 565 which the originator of the Query is asking the Service to return 566 Attributes. Responses only contain a Subject if the Subject of the 567 Response differs from that of the original Query, which may occur 568 when (for example) the Subject contains a broad range, and the 569 Service replies with a more narrow Subject. Future specifications 570 may define alternative Subject elements. 572 6.2.1. Telephone Number 574 The Telephone Number element of the Subject contains an encoding of a 575 telephone number or a telephone number fragment. 577 A Telephone Number has a Type which designates which sort of 578 telephone number the element contains. Types defined by this 579 specification include: telephone number and telephone number range. 581 The Type of the Telephone Number element is followed by a Value, 582 which contains the telephone number itself. The format of the 583 identity is determined by the Type. 585 6.2.2. Service Provider Identifier 587 A Service Provider Identifier (SPID) may also be the Subject of the 588 Query, if, for example, in a SPEERMINT-like architecture an initial 589 resolution has already translated a telephone number into a SPID, and 590 now the client wishes to find routes or other information related to 591 the SPID. 593 A Service Provider Identifier has a Type which designates the format 594 of the SPID. Types defined by this specification include: SPID and 595 domain name. 597 6.3. Attributes 599 Attributes in this information model are all specified as having a 600 Name, which may optionally be associated with a Type and Value. 602 Queries optionally contain Attributes; a Query with no specified 603 Attributes requests that the Service return any Attributes associated 604 with the Subject. In a Query, the presence of one or more Attributes 605 limits the scope of the Query to Records about the Subject containing 606 those Attributes. 608 Responses contain Attributes within the one or more Record elements. 609 At least one Record element will always be present in a successful 610 Response, and thus at least one Attribute will be as well. 612 Attributes are broadly divided between Routing Attributes and 613 Administrative Attributes. Routing Attributes provide information 614 required to route communications, including URIs. 616 6.4. Records 618 The Record element appears only in Responses. It exists primarily as 619 a means to deliver Attributes in answer to Queries, grouping together 620 Attributes with an Authority and any expiry and preferential data 621 recommended by the Service. 623 6.4.1. Attributes 625 A Record contains an Attribute, which may be either a Routing or 626 Administrative Attribute. 628 6.4.2. Authority 630 The Authority subelement of a Record specifies the source of the 631 data: either the entity that provisioned the data with the Service or 632 the external source from which the Service collected the data. Like 633 the "Query Source" element, the Authority element ideally gives a 634 logical identity of the source of the data. The format has a Type 635 followed by a Value, where the format of Values is defined by the 636 Type. Types defined by this document include: domain name and IP 637 address. 639 6.4.3. Priority 641 Optionally, a Service may specify a weighted Priority associated with 642 a Record. Priorities are between 0 and 1, with a value of 1 having 643 the highest priority. 645 6.4.4. Expiration 647 Optionally, a Service may specify an absolute time at which a Record 648 will no longer be valid, should a client or intermediary wish to 649 cache a Record. In the absence of an Expiration element, Records may 650 be cached for a maximum of twenty-four hours. 652 6.5. Response Code 654 All Responses contain a Response Code. 656 Response Codes defined by this document include: Success, Subject 657 Does Not Exist, No Suitable Records Exist for Subject, Subject Syntax 658 Error, Unknown Attribute, Unauthorized Source, Route Source Topology 659 Unavailable. 661 [TBD] 663 7. Element Types 665 7.1. Telephone Number Type 667 The telephone number type conforms to the telephone number syntax 668 given in RFC3966 Section 3, in the ABNF for "telephone-subscriber." 670 Type Code: T 672 [TBD - need for subtying? E.164, Service Code, Short Code, Prefix, 673 Nationally-Specific and Unknown. ] 675 7.1.1. TN Prefix Type 677 The TN range type consists of a prefix of a telephone number, and is 678 semantically equivalent to all syntactically-valid telephone numbers 679 below that prefix. For example, in the North American Numbering 680 plan, the prefix 157143454 would be equivalent to all numbers ranging 681 from 15714345400 to 15714345499. 683 [TBD - identify alternative ways of specifying ranges, potentially as 684 separate element types] 686 Type Code: R 688 7.2. Domain Name Type 690 The domain name type conforms to the syntax of RFC1034 Section 3.5 691 and Section 2.1 of RFC1123. 693 Type Code: D 695 7.3. Uniform Resource Indicator (URI) Type 697 The Uniform Resource Indicator (URI) type conforms to the syntax for 698 URIs given in RFC3986 (see Section 3). 700 Type Code: U 702 7.4. Internet Protocol (IP) Address Type 704 The IP Address type conforms to the ABNF syntax of either the 705 IPv4address given in RFC3986 (Appendix A) or the IPv6reference of 706 RFC5954. 708 Type Code: I 710 7.5. Service Provider Identifier (SPID) Type 712 The SPID type consists of a four-digit number. 714 [TBD - introduce other elements for alternative SPID syntaxes] 716 Type Code: S 718 7.6. Trunk Group Type 720 The trunk group type conforms to the "trunk-group-label" ABNF given 721 in RFC4904 (Section 5). 723 Type Code: G 725 7.7. Display Name Type 727 The display name is a string of Unicode cahracters, UTF-8 encoded, 728 with a maximum length of fifty octets. 730 Type Code: N 732 7.8. Expiry Type 734 The Expiry type is an absolute time conformant to the syntax of 735 RFC3339. 737 Type Code: E 739 7.9. Priority Type 741 The Priority type contains a number between 0 and 1, conforming to 742 the specification of the "q" parameter of the Contact header field in 743 RFC3261. 745 Type Code: P 747 7.10. Extension Type 749 This code is reserved for future use. 751 Type Code: X 753 8. Attributes 755 All attributes have a Name, which consists of a string. Optionally 756 an Attribute may take a Value, in which case it also has a Type. 757 Broadly, Attributes are here divided into two categories: Routing 758 Attributes and Administrative Attributes. 760 When an Attribute it specified, if its requires a Value which does 761 not have a Type in the base TeRQ specification, that Type must be 762 defined along with the Attribute. 764 8.1. Routing Attributes 766 Routing Attributes defined by this document include: voip (Type URI), 767 sms (Type URI) [TBD] 769 8.2. Administrative Attributes 771 Administrative Attributes defined by this document include: CNAM 772 (Type Display Name), SPID (Type SPID), dialplan (Type ?) [TBD] 774 9. Security Considerations 776 The framework of this document differs from previous efforts to 777 manage telephone numbers on the Internet largely by offering a much 778 richer set of security services. In particular, it requires that 779 three entities be capable of authenticating themselves to one another 780 at the layer of a binding: Clients, Intermediaries and Services. It 781 furthermore requires object security at the encoding layer so that 782 Sources and Authorities can sign data in order to authenticate 783 Queries and Responses that may pass through Intermediaries, and 784 moreover so that Authorities can prove to Clients that their Records 785 are authoritative even when the Authority does not operate the 786 Service. The requirements that bindings and encodings must satisfy 787 to meet these security needs are specified in Section 5. 789 [TBD - more] 791 10. IANA Considerations 793 This specification defines several registries: A registry of 794 Elements, a registry of Element Types, a registry of Attributes, and 795 a registry of Response Codes. 797 This document creates a registry of Elements for use with this 798 framework. This registry is extensible, with an IANA Registration 799 policy of Specification Required. Any new Element registered must 800 supply the name of the Element, the name of the parent Element in the 801 information model, and a code point. [TBD] 803 This specification pre-provisions the Element Types registry with the 804 entries given in Section 6. These elements are indexed by their Type 805 Code. This registry is extensible, with an IANA Registration policy 806 of Specification Required. Any new Element Type registered must 807 supply the name of the Element Type, the name of the parent element 808 in the information model, and a Type Code. 810 This specification creates an Attribute registry which is indexed by 811 Attribute names. This registry is extensible, with an IANA 812 Registration policy of Specification Required. Any new element 813 registered must supply the name of Attribute, and list all Element 814 Types that may be associated with Values of the Attribute. 816 This document furthermore creates a registry of Response Codes. This 817 registry is pre-provisioned with the values given in Section 5.5. 818 [TBD] 820 11. Acknowledgements 822 The authors would like to thank Paul Kyzviat and Dale Worley for 823 their input into this specification. 825 12. Informative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, March 1997. 830 Author's Address 832 Jon Peterson 833 NeuStar, Inc. 835 Email: jon.peterson@neustar.biz